Changes fall into these categories:
1. Avoid pathological string building. Loops over x = x .. "foo" can
become very slow. Instead, use strbuf.lua, table.concat, or just one
continuous concatenation; a = x .. y .. z is one operation, better than
a = x .. y; a = a .. z
2. Use hex-escaped strings instead of string.char. I find this more
readable in many cases, and it avoids a table lookup and function call.
3. Don't duplicate code. A few libraries and scripts had re-implemented
stdnse.generate_random_string or openssl.rand_bytes.
This function will format a MAC address as colon-separated hex bytes.
It's really very simple: stdnse.tohex(mac, {separator=":"})
This commit updates all the instances I could find of the varying
convoluted attempts at performing this conversion.
All IP packet objects now have the following attributes:
- ip_bin_src (binary src address)
- ip_bin_dst (binary dst address)
- ip_src (decimal-dotted string src address)
- ip_dst (decimal-dotted string dst address)
The ip6_src and ip6_dst attributes have therefore been renamed (ip_bin_src and
ip_bin_dst).
This patch also updates the scripts accordingly.
The packet construction had a bug that made it more effective in at
least one case for me. Weilin had supplied a 16-byte destination options
buffer, including some random bytes from a packet capture. But the
length of buffer was set incorrectly in the packet, making it look like
it was 8 bytes instead of 16. Therefore the expected ICMPv6 packet
started in the middle of the buffer, making it appear to have a
type/code of 254/24 instead of 128/0 as expected.
I tried setting the proper length, while keeping the invalid destination
option, but then stopped getting a Parameter Problem response. I also
tried setting a proper destination options buffer with no invalid
options, followed by ICMPv6 with type/code of 128/0, and again got no
response. It appears that I get a response only when both of these
conditions are satisfied: 1) an invalid destination option exists, and
2) the ICMPv6 type is unknown. This is against OS X.
The probe was being effective by accident, but now I've simplified it
and documented these strange conditions.
This breaks any hosts that might have ignored the invalid destination
option (which they shouldn't do) and replied to the echo request. But we
have targets-ipv6-multicast-echo for that.
