Re: [tcpdump-workers] BPF Extended: addressing BPF's shortcomings

some sort of virtual program that doesn't have to concern itself with the mundane trivialities of how silicon actually implements it. -- Paul "LeoNerd" Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS ___

Re: [tcpdump-workers] BPF Extended: addressing BPF's shortcomings

we'd also have to add), and then look at certain indexes into SKF_TRANS_OFF; it doesn't have to *find* the TCP header at all, doesn't care if it's IPv4 or IPv6 or whatever... -- Paul "LeoNerd" Evans leon...@leonerd.org.

Re: [tcpdump-workers] BPF Extended: addressing BPF's shortcomings

make sure you haven't gone beyond the end of the packet, the filter > program immediately fails". (Yes, that means it's no longer > Turing-complete, as there's no longer a halting problem. :-)) That's exactly what my LOOP instruction suggestion does. -- Paul "L

Re: [tcpdump-workers] BPF Extended: addressing BPF's shortcomings

the transport layer. Both of these ideas are ones I've tried to point either Linux or FreeBSD in the direction of, and received almost total silence on. If you did want to make some direct impact on making IPv6 easier to handle, I'd suggest either or both of these would ma

Re: [tcpdump-workers] BPF_COP support for libpcap

generic loop ability. https://lists.freebsd.org/pipermail/freebsd-hackers/2013-October/043602.html If you want to support 'v6 better, maybe take a look at that? -- Paul "LeoNerd" Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVA

[tcpdump-workers] [PING] - Any comments on my recent posts?

cpdump-group/tcpdump-htdocs/pull/3 Is there any remaining objection to this? If not can someone give it the official stamp of approval please? -- Paul "LeoNerd" Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS _

Re: [tcpdump-workers] LINUX_SLL2

On Mon, 2 Mar 2015 19:25:10 + "Paul \"LeoNerd\" Evans" wrote: > On Wed, 25 Feb 2015 10:20:40 + > Denis Ovsienko wrote: > > > This makes SLL2 quite close to sockaddr_ll (except the the order of > > fields and the sll_family field, which is told

Re: [tcpdump-workers] How to capture the data at transport layer (not on interface)

See the thread beginning http://lists.sandelman.ca/pipermail/tcpdump-workers/2015-January/000127.html -- Paul "LeoNerd" Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS ___ tcpdump-workers mail

Re: [tcpdump-workers] LINUX_SLL2

eed with the implementation. Ah; I wasn't intentionally making the order different to the underlying address struct. Does that matter? I'm happy to amend it if anyone thinks that's an issue, otherwise we'll just go with it. -- Paul "LeoNerd" Evans leon...@leonerd.o

Re: [tcpdump-workers] LINUX_SLL2

ould be great to have it supported by core after all. -- Paul "LeoNerd" Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] RFC: DLT for "application TCP stream capture"

-header, all the remaining bytes of the frame are the protocol data payload. -- Paul "LeoNerd" Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] RFC: DLT for "application TCP stream capture"

ing this format to debug multi-path TCP, in > which case the IP addresses (and maybe even the IP4/IP6-ness of it) > might change. > > And gzip'ed those addresses will compress quite easily. OK, so I'll stick with the simplicity of just repeating it for every frame then. -- Pau

Re: [tcpdump-workers] RFC: DLT for "application TCP stream capture"

ing this format to debug multi-path TCP, in > which case the IP addresses (and maybe even the IP4/IP6-ness of it) > might change. > > And gzip'ed those addresses will compress quite easily. OK, so I'll stick with the simplicity of just repeating it for every frame then. -- Pau

Re: [tcpdump-workers] RFC: DLT for "application TCP stream capture"

ng information). Though I don't know if that outweighs the statefulness and added complexity of representing "flow setup" operations and "more bytes of data sent/received on this flow" as extra frame types. -- Paul "LeoNerd" Evans leon...@leonerd.org.uk htt

[tcpdump-workers] RFC: DLT for "application TCP stream capture"

thing suitable, I'll come up with a proposal for a new DLT instead. -- Paul "LeoNerd" Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcp

Re: [tcpdump-workers] LINUX_SLL2 - TEST REPLY

the cornercase offchance that the failure is caused by my MUA (claws-mail), here's a reply from mutt instead. -- Paul "LeoNerd" Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS ___ tcpdump-worker

Re: [tcpdump-workers] Display of packet direction and interface

on record/replay"? -- Paul "LeoNerd" Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature

[tcpdump-workers] Display of packet direction and interface name

#x27;ed on wired. It would be really useful if libpcap were to provide, perhaps via a new datalink type, this information, to enable tcpdump or other applications to display it. Is there any way I can assist in making this happen? -- Paul "LeoNerd" Evans leon...@leonerd.org.uk