Re: [tcpdump-workers] [tcpdump] After setjmp/longjmp update
--- Begin Message ---
On Sat, 5 Sep 2020 18:20:42 +0200
Francois-Xavier Le Bail via tcpdump-workers
wrote:
Hello Francois-Xavier.
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.
[...]
> C) The -x printing begins now by:
>
> 028e: Begin of destination MAC address, IPv4 is 14 octets after.
>
> ./tcpdump -#envx -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):
d4c3b2a10200040045000100
45000400028e00506ae10101fc83080045088034d940
400040116a700a0100ea9ad600585e0a028000b104020f0f0f0f0f15
0f040f0f0f0f0f0f0f0f0f0f0f0f001688
> reading from file krb-truncated.pcap, link-type EN10MB (Ethernet),
> snapshot length 69 1 01:00:00.00 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]
> 0x: 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?
> 0x0010: 8034 d940 4000 4011 6a70 0a00 0001 00ea
> 0x0020: 9ad6 0058 5e0a 0280 00b1 0402 0f0f 0f0f
> 0x0030: 0f15 0f04 0f0f 0f0f 0f0f 0f0f 0f0f
> 0x0040: 0f0f 0016 88
I confirm the patch changes the hex output exactly as described.
--
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] After setjmp/longjmp update
--- 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 -#envx -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):
>
> d4c3b2a10200040045000100
> 45000400028e00506ae10101fc83080045088034d940
> 400040116a700a0100ea9ad600585e0a028000b104020f0f0f0f0f15
> 0f040f0f0f0f0f0f0f0f0f0f0f0f001688
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.00 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]
>> 0x: 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 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
Re: [tcpdump-workers] [tcpdump] After setjmp/longjmp update
--- Begin Message --- On Mon, 7 Sep 2020 17:26:28 +0200 Francois-Xavier Le Bail wrote: > 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) My commit is in the master branch, I tried not to touch the patterns above and to make only the changes that are obviously safe. Regarding the loss of ability to skip the link layer header on a pseudo-return via longjmp(), is there a formal definition (or at least a workable convention) of a link layer header? For example, ether_if_print() can return one value for ordinary Ethernet and another for ordinary Ethernet inside Arista Ethernet. I do not understand yet if it would be right in theory to increment ndo_ll_hdr_len each time a decoder has retrieved another complete link layer header and is about to dig deeper, and how hard in practice it would be to do that in all DLT printers. Maybe it could be a simpler problem to solve if the current DLT printer functions were setting ndo_ll_hdr_len to a sensible DLT-specific value just once before a full decode, not after. Does it make sense? -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
