[tcpdump-workers] [libpcap] Uninitialized scalar variable
Hello, I do computer security studies and I wanted to test Coverity, a source code analysis tool. If you're interested, I corrected a problem in /pcap-linux.c/ file: uninitialized variable (/req.tp_frame_size/). You will find above the Github commit. https://github.com/peugnezb/libpcap/commit/2bbb0d9f3e1f0337985b4fa8033d465e598ecc46 Respectfully, Baptiste PEUGNEZ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [libpcap] Uninitialized scalar variable
On Jan 27, 2015, at 1:58 AM, PEUGNEZ Baptiste wrote: > I do computer security studies and I wanted to test Coverity, a source code > analysis tool. If you're interested, I corrected a problem in /pcap-linux.c/ > file: uninitialized variable (/req.tp_frame_size/). > > You will find above the Github commit. > > https://github.com/peugnezb/libpcap/commit/2bbb0d9f3e1f0337985b4fa8033d465e598ecc46 Adding the check should be harmless. However, the error message should probably be something such as "internal error: unknown TPACKET_ value XXX", where XXX is the value of handlep->tp_version, because, in the current code, that would happen only if handlep->tp_version had never been set - it's never set to a value other than TPACKET_V1, TPACKET_V2, or TPACKET_V3, and it's only set to TPACKET_V3 if HAVE_TPACKET3 is defined and only set to TPACKET_V2 if HAVE_TPACKET2 is defined (set by init_tpacket()), so the default case in that switch should never be reached. That error message would make it clearer that either 1) some weird glitch happened in the hardware or in some software outside libpcap or 2) there's a case that the analysis above missed, and would give some data that would help figure out which of those is the case. (Sadly, most compilers don't do enough data flow analysis to either prove that it can't happen without a hardware glitch or random out-of-bounds store or to show how it *can* happen and thus to show where the code needs to be fixed.) ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] odd issue with Linux VLAN interface
List, some time ago I did troubleshooting on a Linux PC and that involved running tcpdump with the "not tcp" filter on a few network interfaces to put a number of background TCP connections out of scope (I was interested how other protocols' packets were making from one interface to the other). At some point I had realized that tcpdump was printing TCP packets _only_ and no other protocols (again, the filter was "not tcp"). Later I figured it out how to reproduce the problem but not the cause of it. The host has an Ethernet interface with only an IPv6 link-local address (eth0). On top of it there is a VLAN interface with VID 75 (eth0.75), IPv6 link-local address and IPv4 address 10.0.75.254/24. The difference is, when tcpdump runs with "-i eth0.75", it works as expected and displays ARP and, for instance, UDP from/to the network 10.0.75.0/24. When run with "-i eth0", it displays only TCP from/to network 10.0.75.0. This looks wrong in two ways as the tagged packets should not appear on the bearing interface in the first place and even if they appear there the filter should exclude them, but instead of this it excludes all the other packets. This is the latest build of tcpdump on kernel 3.13.0-44-generic #73-Ubuntu SMP. Not sure if I will get to find the reason myself, but if anybody sees this as a duplicate of or an additional input for one of the known bugs, please let me know. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] odd issue with Linux VLAN interface
On Jan 27, 2015, at 4:09 PM, Denis Ovsienko wrote: > some time ago I did troubleshooting on a Linux PC and that involved running > tcpdump with the "not tcp" filter on a few network interfaces to put a number > of background TCP connections out of scope (I was interested how other > protocols' packets were making from one interface to the other). At some > point I had realized that tcpdump was printing TCP packets _only_ and no > other protocols (again, the filter was "not tcp"). Later I figured it out how > to reproduce the problem but not the cause of it. > > The host has an Ethernet interface with only an IPv6 link-local address > (eth0). On top of it there is a VLAN interface with VID 75 (eth0.75), IPv6 > link-local address and IPv4 address 10.0.75.254/24. The difference is, when > tcpdump runs with "-i eth0.75", it works as expected and displays ARP and, > for instance, UDP from/to the network 10.0.75.0/24. When run with "-i eth0", > it displays only TCP from/to network 10.0.75.0. This looks wrong in two ways > as the tagged packets should not appear on the bearing interface in the first > place and even if they appear there the filter should exclude them, but > instead of this it excludes all the other packets. I.e., "tcpdump -i eth0 not tcp" prints *only* TCP packets? Just out of curiosity, what does "tcpdump -i eth0 -d not tcp" print? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] odd issue with Linux VLAN interface
> I.e., "tcpdump -i eth0 not tcp" prints *only* TCP packets? Yes, exactly. Just checked once again. > Just out of curiosity, what does "tcpdump -i eth0 -d not tcp" print? root@homepc:~# tcpdump -pni eth0 -d not tcp (000) ldh [12] (001) jeq #0x86dd jt 2jf 7 (002) ldb [20] (003) jeq #0x6 jt 10 jf 4 (004) jeq #0x2cjt 5jf 11 (005) ldb [54] (006) jeq #0x6 jt 10 jf 11 (007) jeq #0x800 jt 8jf 11 (008) ldb [23] (009) jeq #0x6 jt 10 jf 11 (010) ret #0 (011) ret #262144 -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] odd issue with Linux VLAN interface
On Jan 27, 2015, at 4:28 PM, Denis Ovsienko wrote: > >> I.e., "tcpdump -i eth0 not tcp" prints *only* TCP packets? > > Yes, exactly. Just checked once again. > >> Just out of curiosity, what does "tcpdump -i eth0 -d not tcp" print? > > root@homepc:~# tcpdump -pni eth0 -d not tcp > (000) ldh [12] > (001) jeq #0x86dd jt 2 jf 7 If ethertype == IPv6, go to 2, else go to 7 > (002) ldb [20] > (003) jeq #0x6 jt 10 jf 4 If IPv6 Next Header is TCP, go to 10, else go to 4 > (004) jeq #0x2cjt 5 jf 11 If IPv6 Next Header is Fragment Header, go to 5, else go to 11 > (005) ldb [54] > (006) jeq #0x6 jt 10 jf 11 If header after that is TCP, go to 10, else go to 11 > (007) jeq #0x800 jt 8 jf 11 If ethertype == IPv4, go to 8, else go to 11 > (008) ldb [23] > (009) jeq #0x6 jt 10 jf 11 If IPv4 Protocol is TCP, go to 10, else go to 11 > (010) ret #0 Reject packet > (011) ret #262144 Accept packet So that *looks* OK. Could you run "tcpdump -i eth0 -xx not tcp" and see what the contents of the TCP packets being accepted are? And what does "tcpdump -v" print? Was it built with the latest libpcap? This might be an issue with the kernel and libpcap not properly working together to deal with VLAN tags - this commit: commit 04660eb1e56102e2369473cae2538e4d3d263607 Author: Michal Sekletar Date: Fri Oct 31 15:19:54 2014 +0100 Use BPF extensions in compiled filters libpcap will generate BPF filter code which uses BPF extensions if target platform supports them. Currently supported BPF extensions are vlan_tci and vlan_pr. Also to properly handle such filters when filtering in userspace libpcap now employs bpf_filter1. fixed some issues there. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Request for Geneve DLT type
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. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for Geneve DLT type
On Jan 27, 2015, at 4:46 PM, Jesse Gross 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. 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. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for Geneve DLT type
On Tue, Jan 27, 2015 at 4:53 PM, Guy Harris wrote: > > On Jan 27, 2015, at 4:46 PM, Jesse Gross 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
Re: [tcpdump-workers] odd issue with Linux VLAN interface
[...] > If IPv4 Protocol is TCP, go to 10, else go to 11 > > > (010) ret #0 > > Reject packet > > > (011) ret #262144 > > Accept packet > > So that *looks* OK. Thank you for the analysis! > > Could you run "tcpdump -i eth0 -xx not tcp" and see what the contents of the > TCP packets being accepted are? I have to correct myself: "tcpdump -pni eth0 not tcp" actually yields both TCP and everything else (ARP and UDP). It turns out that during all previous runs that "everything else" just didn't make it to the screen because of timing. Now it does, please see: root@homepc:~# tcpdump -pni eth0 -xx not tcp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 00:56:19.466860 IP 109.74.202.168.6633 > 10.0.75.2.56538: Flags [.], ack 2668283334, win 235, options [nop,nop,TS val 521910355 ecr 1688339], length 0 0x: d4ca 6d72 b1da 000f ea18 f623 8100 004b 0x0010: 0800 4500 0034 dd1d 4000 3406 dcb1 6d4a 0x0020: caa8 0a00 4b02 19e9 dcda 6f36 d02b 9f0a 0x0030: c5c6 8010 00eb b34a 0101 080a 1f1b 0x0040: b853 0019 c313 00:56:20.332325 ARP, Request who-has 10.0.75.3 tell 10.0.75.254, length 28 0x: d4ca 6d66 cf65 000f ea18 f623 8100 004b 0x0010: 0806 0001 0800 0604 0001 000f ea18 f623 0x0020: 0a00 4bfe 0a00 4b03 It looks like the filter just has no effect at all, as "tcpdump -pni eth0 not arp" also delivers a similar mix of packets including ARP. > And what does "tcpdump -v" print? Was it built with the latest libpcap? > This might be an issue with the kernel and libpcap not properly working > together to deal with VLAN tags - this commit: > > commit 04660eb1e56102e2369473cae2538e4d3d263607 > Author: Michal Sekletar > Date: Fri Oct 31 15:19:54 2014 +0100 > > Use BPF extensions in compiled filters > > libpcap will generate BPF filter code which uses BPF extensions if > target > platform supports them. Currently supported BPF extensions are > vlan_tci and > vlan_pr. > > Also to properly handle such filters when filtering in userspace > libpcap now > employs bpf_filter1. > > fixed some issues there. > It is today's master branch build of both: root@homepc:~# tcpdump --version tcpdump version 4.7.0-PRE-GIT_2015_01_28 libpcap version 1.7.0-PRE-GIT_2015_01_28 OpenSSL 1.0.1f 6 Jan 2014 This Ubuntu host has no BPF extensions: denis@homepc:~/libpcap$ fgrep -r SO_BPF_EXT /usr/include/ denis@homepc:~/libpcap$ If this is a new bug, I can file it if it helps. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] odd issue with Linux VLAN interface
Denis Ovsienko wrote: > The host has an Ethernet interface with only an IPv6 link-local address > (eth0). On top of it there is a VLAN interface with VID 75 (eth0.75), > IPv6 link-local address and IPv4 address 10.0.75.254/24. The difference > is, when tcpdump runs with "-i eth0.75", it works as expected and > displays ARP and, for instance, UDP from/to the network > 10.0.75.0/24. When run with "-i eth0", it displays only TCP from/to > network 10.0.75.0. This looks wrong in two ways as the tagged packets > should not appear on the bearing interface in the first place and even > if they appear there the filter should exclude them, but instead of > this it excludes all the other packets. Tagged packets do appear, and if you add -e, you'll see the entire tag there too. At this point, it's hard to get the behaviour I think you want from the pcap compiler, which is to filter the traffic within the VLAN from the bearer. (I think that showing the tcp packets might be a fluke) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
