Bug 223445 - tcpdump(8) stops sniffing ADSL interface
tcpdump(8) stops sniffing ADSL interface
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Neil Horman
Brian Brock
: Regression
Depends On:
  Show dependency treegraph
Reported: 2007-01-19 09:13 EST by Jan Kratochvil
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-14 06:48:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jan Kratochvil 2007-01-19 09:13:21 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):
Otherwise updated:

How reproducible:

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:
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.
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:
14:46:18.138729 IP > 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 > P 2193:2326(133) ack 1 win 50400 <nop,nop,timestamp
304684728 11392973>
Comment 1 Jan Kratochvil 2007-01-22 06:18:12 EST
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
Comment 2 Jan Kratochvil 2007-01-29 08:47:35 EST
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.
Comment 3 Jan Kratochvil 2007-02-10 22:52:38 EST
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
Comment 4 Neil Horman 2007-04-17 07:59:48 EDT
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!
Comment 5 Jan Kratochvil 2007-06-14 06:48:03 EDT
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).

Note You need to log in before you can comment on or make changes to this bug.