Red Hat Bugzilla – Bug 223445
tcpdump(8) stops sniffing ADSL interface
Last modified: 2007-11-30 17:07:40 EST
Description of problem: Recently tcpdump(8) and wireshark(1) stopped correctly sniffing my software ADSL (ueagle-atm) "ppp0" interface. Impact: Probably low as native "eth0" works and enterprises probably do not use `ueagle-atm' and similiar devices. Version-Release number of selected component (if applicable): kernel-xen-2.6.18-2.el5.i686 Otherwise updated: http://armstrong.rhts.boston.redhat.com/distros/nightly/RHEL5-Client-20070118.nightly/5/i386/rhts-i386/ How reproducible: Always. Steps to Reproduce: 1. Plugin Sagem F*st 840 ADSL modem on USB. 2. Wait till it loads `ueagle-atm.ko'. 3. br2684ctl -c 0 -b -a 8.48 4. ifconfig nas0 up 5. pppd call adsl # plugin rp-pppoe.so nas0 6. tcpdump -i ppp0 -n Actual results: tcpdump(8): 14:58:43.711367 In ethertype Unknown (0x0000), length 1508: 0x0000: 4500 05d4 81d3 4000 2e06 2567 cdbc d7e1 E.....@...%g.... 0x0010: c316 3735 1f44 bc3e 8767 f3c7 8d2f 9c46 ..75.D.>.g.../.F 0x0020: 8010 c4e0 3fd0 0000 0101 080a 1228 b2a1 ....?........(.. 0x0030: 00ac c9a5 0524 0090 d372 5065 b88e c40b .....$...rPe.... 0x0040: 2723 7c2c 8173 073e e171 42fd 67c5 72c1 '#|,.s.>.qB.g.r. wireshark(1): No. Time Source Destination Protocol Info 6 14:59:09.164053 SLL Unicast to us Frame 6 (80 bytes on wire, 80 bytes captured) Arrival Time: Jan 19, 2007 14:59:09.164053000 [Time delta from previous packet: 0.000066000 seconds] [Time since reference or first frame: 0.308998000 seconds] Frame Number: 6 Packet Length: 80 bytes Capture Length: 80 bytes [Frame is marked: False] [Protocols in frame: sll:data] Linux cooked capture Packet type: Unicast to us (0) Link-layer address type: 64 Link-layer address length: 0 Source: <MISSING> Protocol: Unknown (0x0000) Data (64 bytes) 0000 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ 0010 45 00 00 40 48 e5 40 00 40 06 51 e9 c3 16 37 35 E..@H.@.@.Q...75 0020 cd bc d7 e1 bc 3e 1f 44 8d 2f 9c 46 87 6c c7 06 .....>.D./.F.l.. 0030 b0 10 05 01 e7 f1 00 00 01 01 08 0a 00 ac e2 a1 ................ 0040 12 28 bc 74 01 01 05 0a 87 6c cc fc 87 6c d2 9c .(.t.....l...l.. Expected results: Standard IP packets dump, like: tcpdump(8): 14:46:18.138729 IP 192.168.66.2 > 192.168.66.1: ICMP echo request, id 634, seq 9, length 64 Additional info: It is a very recent regression, I believe since 2.6.18-1.3002.el5 ? I can test the kernels to reduce the domain of possibilities more but it means a lot of rebooting for me. Unaware whether it is XEN related. Sniffing works on eth0 interface so it will be related to the software ADSL layer. Sniffing of the base device of "ppp0" - the "nas0" device - still works: tcpdump -i nas0 -n -s 2000 15:03:20.420843 PPPoE [ses 0x517f] IP 205.188.215.225.8004 > 195.22.55.53.48190: P 2193:2326(133) ack 1 win 50400 <nop,nop,timestamp 304684728 11392973>
Verification on: (therefore not xen related) kernel-2.6.18-4.el5.i686: BROKEN kernel-xen-2.6.18-4.el5.i686: BROKEN kernel-xen-2.6.18-2.el5.i686: BROKEN kernel-xen-2.6.18-1.2798.fc6.i686: OK
kernel-xen-2.6.19-1.2898.2.3.fc7.i686: OK It is apparently a RHEL5 specific bug, this was my last update for this bug as I am now running back on RawHide.
Reverting back: AssignedTo: kernel-mgr@redhat.com -> xen-maint@redhat.com as this Bug is _not_ XEN specific, see Comment 1: kernel-2.6.18-4.el5.i686: BROKEN kernel-xen-2.6.18-4.el5.i686: BROKEN
Before you go to all the trouble bisecting the kernel tree, would you mind terribly retrying your test using a stock RHEL5 system? I would suggest first reproducing the problem as you have described it above, and then upgrade the libpcap, tcpdump and wireshark packages to the versions available in rawhide, then retesting. I'm wondering if something subtle about the ppp encapsulation hasn't changes and older versions of our capture tools aren't prepared to handle it. Normally you won't see the encapsulation data on ppp interfaces, but if for some reason RHEL5 is trapping the frames before we do the encap strip that would be the start of an explination. Also, if you could please attach a binary copy of the non-functional tcpdump, so that I could look over it for clues as to whats going on, I would appreciate it. Thanks!
Well I failed to reproduce it on RHEL5-GA as there is NO `linux-atm' package at all and so no `br2684ctl' command is available there. I had it apparently left there from some FC release before. Not sure what other networking the kernel change could apply to but it is definitely not this Bug. Sorry for the report; RHEL just does not support ATM (and thus even software ADSL).