--- Begin Message ---
On 07/09/2020 16:43, Denis Ovsienko via tcpdump-workers wrote:
> On Sat, 5 Sep 2020 18:20:42 +0200
> Thank you for posting a detailed explanation and making the first round
> of changes. I am looking into the logic of this work. As soon as it
> feels I can tell the right instances of ND_TCHECK() to remove from the
> wrong ones, I am going to convert some more code manually if that's OK.
That's OK, just try to avoid those like:
ND_TCHECK_LEN(e, sizeof(nd_ipv4)) calls followed by a GET_IPADDR_STRING(e)
call, same e.
ND_TCHECK_4(e) calls followed by a GET_IPADDR_STRING(e) call, same e.
ND_TCHECK_LEN(e, sizeof(nd_ipv6)) calls followed by a GET_IP6ADDR_STRING(e)
call, same e.
ND_TCHECK_16(e) calls followed by a GET_IP6ADDR_STRING(e) call, same e.
(I am working to remove them)
> [...]
>
>> C) The -x printing begins now by:
>>
>> 028e: Begin of destination MAC address, IPv4 is 14 octets after.
>>
>> ./tcpdump -#envvvvvx -r krb-truncated.pcap
> The .pcap file in your examples is not in the repository, but I could
> reconstruct it to get the same output as yours. For convenience here is
> a hex dump of my .pcap file ("xxd -r -p" to restore):
>
> d4c3b2a10200040000000000000000004500000001000000000000000000
> 00004500000000000400028e00506ae10101fc830000080045088034d940
> 400040116a700a00000100ea9ad600585e0a028000b104020f0f0f0f0f15
> 00000f040f0f0f0f0f0f0f0f0f0f0f0f001688
Yes, it's pkt#15 from tests/babel_update_oobr.pcap.
(extracted with editcap from Wireshark)
>> reading from file krb-truncated.pcap, link-type EN10MB (Ethernet),
>> snapshot length 69 1 01:00:00.000000 01:01:fc:83:00:00 >
>> 02:8e:00:50:6a:e1, ethertype IPv4 (0x0800), length 262144: (tos 0x8,
>> ttl 64, id 55616, offset 0, flags [DF], proto UDP (17), length 32820,
>> bad cksum 6a70 (->3baf)!) 10.0.0.1.88 > 0.234.154.214.24074: v4 be
>> KDC_REQUEST: ^O^O^O^O^O^U.@^O^D^O^O^O^O^O^O^O^O^O^O^O^O [|krb]
>> 0x0000: 028e 0050 6ae1 0101 fc83 0now 000 0800 4508
> Just to confirm, "now" in the line above is not a part of the output,
> right?
Yes!
>> 0x0010: 8034 d940 4000 4011 6a70 0a00 0001 00ea
>> 0x0020: 9ad6 0058 5e0a 0280 00b1 0402 0f0f 0f0f
>> 0x0030: 0f15 0000 0f04 0f0f 0f0f 0f0f 0f0f 0f0f
>> 0x0040: 0f0f 0016 88
> I confirm the patch changes the hex output exactly as described.
--
Francois-Xavier
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
