On Tue, Jan 27, 2015 at 4:53 PM, Guy Harris <g...@alum.mit.edu> wrote: > > On Jan 27, 2015, at 4:46 PM, Jesse Gross <je...@nicira.com> wrote: > >> I'm working on implementing support for Geneve in libpcap, which is >> documented here: >> http://tools.ietf.org/html/draft-gross-geneve-02 >> >> Geneve is a tunneling protocol than can encapsulate many different >> things - normally this would be Ethernet, IP, or IPv6 but it can be >> anything with an EtherType. I would like for filters that appear after >> the Geneve keyword to apply to the inner payload, i.e. geneve && ip. >> >> Since the inner protocol is no longer the same as the outer wire >> format, the checks that are done on linktype don't really make sense >> at that point. The easiest solution would seem to be to allocate a new >> DLT for Geneve and change to that when processing the inner header, so >> I'm requesting a new type for that purpose. I realize that this is a >> little weird because it's not actually a format that will ever appear >> in pcap files and could also be handled purely internally (similar to >> the is_pppoes variable). However, having implemented it both ways, it >> definitely seems cleaner to have a new type that fits into the >> existing switch statements rather than a bunch on one-off checks. > > Having a placeholder DLT_ type that doesn't actually correspond to anything > you get from an interface, and a corresponding LINKTYPE_ value that won't > ever appear in files, definitely doesn't seem at all clean to me; it's using > DLT_/LINKTYPE_ values for a purpose completely different from the purpose for > which they are intended.
Yeah, I understand that it's not great. The code is clean (and more robust since it avoids cases where Geneve isn't properly handled) but it is externally visible when it should not be. > I will see whether the handling of PPPoE and MPLS can be cleaned up > internally to gencode.c; if so, *that* would be the right way to handle > Geneve. OK, I'll go down this path instead. If you have any ideas on how to make it better, that would be great. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
