
Nmap Development mailing list archives
IPv6 packet.lua review
From: David Fifield <david () bamsoftware com>
Date: Wed, 20 Jul 2011 23:14:12 -0700
This is a quick review of the changes Weilin has made to the packet.lua library to support IPv6 packet construction. The file is in /nmap-exp/weilin/host_discovery_scripts/packet.lua. +--- Build an Ethernet frame. +-- @param mac_dst six-byte string of the destination MAC address. +-- @param mac_src six-byte string of the source MAC address. +-- @param packet string of the payload. +-- @return frame string of the Ether frame. +function Frame:build_ether_frame(mac_dst, mac_src, packet) + self.mac_dst = mac_dst or self.mac_dst + self.mac_src = mac_src or self.mac_src + self.buf = packet or self.buf + local l3_type + if self.ip_v == 4 then + l3_type = string.char(0x08, 0x00) + elseif self.ip_v == 6 then + l3_type = string.char(0x86, 0xdd) + else + return nil, "Unknown packet." + end + self.frame_buf = self.mac_dst..self.mac_src..l3_type..self.buf +end How does self.ip_v get set? Why should IPv4 aznd IPv6 be given special status here? Shouldn't the upper-layer protocol be a parameter? function Packet:new(packet, packet_len, force_continue) local o = setmetatable({}, {__index = Packet}) + if not packet then + return o + end o.buf = packet Why is this handling for packet == nil now necessary? + self.buf = + set_u32("....",0,ver_tc_fl) .. + set_u16("..",0,#(self.exheader or "")+#(self.l4_packet or "")) ..--string.char(0x00,0x10) .. --payload length Using set_u32 and set_u16 in this way is confusing. If necessary, define another function that just returns the string you want, instead of forcing the caller to provide a dummy string of the proper length. +function Packet:build_invalid_extension_header(exheader_type) + local ex_invalid_opt = string.char(0x80,0x01,0xfe,0x18,0xfe,0x18,0xfe,0x18,0x0,0x0,0x0,0x0,0x0,0x0) +function Packet:build_router_advert(mac_src,prefix,prefix_len,valid_time,preferred_time) + self.ip6_src = mac_to_lladdr(mac_src) These functions are too specialized to be in the packet.lua library. Special parameters like these belong in a script. +function inet6_pton_simple(str) +function ipv6tobin(str) These functions are hard to understand for what they do. They don't handle addresses of the form "::ffff:a.b.c.d". There is not enough error checking; try nonsense addresses like "1::2::3" and "1:2:3" and "1:2:3:4:5:6:7:8:9". Rather than trying to debug all these cases; perhaps it would be better to provide a wrapper around getaddrinfo? +function mactobin(str) + if not str then + return mactobin("00:00:00:00:00:00") + end +function toipv6(raw_ipv6_addr) + if not raw_ipv6_addr then + return "?::?" + end +function mac_to_lladdr(mac) + if not mac then + return "?::?" + end I would rather see an error about a nil variable than silently insert default values like this. +--- Pare an IPv6 extension header. Just jump over it at the moment. +-- @param force_continue Ignored. +-- @return Whether the parsing succeeded. +function Packet:ipv6_ext_header_parse(force_continue) + local ext_hdr_len = self.u8(self.ip6_data_offset + 1) + ext_hdr_len = ext_hdr_len*8 + 8 + self.ip6_data_offset = self.ip6_data_offset + ext_hdr_len + self.ip6_nhdr = self.u8(self.ip6_data_offset) +end I think we must be more careful than this with extension headers. All the currently defined extension headers have the nh value in the first byte, but I hven't seen a guarantee that it will always be so. Also, the way the function is called, the code will attempt to skip over any nh value that isn't IPPROTO_TCP, IPPROTO_UDP, and IPPROTO_ICMPV6. What about other things like IPPROTO_SCTP? That will produce nonsense if parsed this way. Instead of looping until you get a known upper-layer protocol (assuming everything else is an extension header), loop as long as you have a known extension header (and assume everything else is an upper-layer protocol). See ipv6_get_data_primitive in netutil.cc. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- IPv6 packet.lua review David Fifield (Jul 20)
- Re: IPv6 packet.lua review Xu Weilin (Jul 21)
- Re: IPv6 packet.lua review Xu Weilin (Jul 22)
- Re: IPv6 packet.lua review Xu Weilin (Jul 21)