Wireshark · Wireshark-dev: Re: [Wireshark-dev] malformed captured packets

[Toralf Förster <toralf.foerster@xxxxxx>]

@wireshark-devs:

The topic is related to
http://www.wireshark.org/lists/wireshark-users/200707/msg00187.html
and http://bugzilla.kernel.org/show_bug.cgi?id=8793

@all:
Hi,

Am Donnerstag, 30. August 2007 schrieb James Chapman:
> Toralf Förster wrote:
> > Am Mittwoch, 29. August 2007 schrieb James Chapman:
> > 
> >> Can you provide more information about the problem, please? Are you 
> >> using a simple DSL modem with PPPoE, such that the ppp0 interface is 
> >> that of the pppd started by a local PPPoE server? Is this a problem only 
> >> with packet capture or are you seeing actual data corruption? Did this 
> >> work with previous kernels? What is the network topology related to the 
> >> DSL interface?
> >>
> > 
> > I use a ThinkPad T41 with this Ethernet controller:
> > 
> > n22 ~ # lspci | grep Eth
> > 02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev 03)
> > 02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
> > 
> > My DSL provider is Alice DSL (formerly Hansenet) in Hamburg. The T41 is connected
> > with an Ethernet cable to a Siemens DSL modem. The modem (just a modem, not a
> > router) itself is connected to the DSL splitter which itself is plugged into socket.
> > 
> > The current ppp version I'm using is net-dialup/ppp-2.4.4-r9
> > 
> > Here are my kernel config settings:
> > 
> > n22 ~ # zgrep PPP /proc/config.gz
> > CONFIG_PPP=m
> > # CONFIG_PPP_MULTILINK is not set
> > CONFIG_PPP_FILTER=y
> > # CONFIG_PPP_ASYNC is not set
> > # CONFIG_PPP_SYNC_TTY is not set
> > CONFIG_PPP_DEFLATE=m
> > # CONFIG_PPP_BSDCOMP is not set
> > # CONFIG_PPP_MPPE is not set
> > CONFIG_PPPOE=m
> > 
> > I observed this problem since a long time with different kernel versions (Gentoo,
> > plain vanilla kernel, git sources) while playing with ethereal - currently known
> > as wireshark.
> > 
> > I'm wondering b/c for kscd eg. it is always the IP packet containing the content
> > information of a CD (or even a <CD is unknown> message) with is struggled.
> > This packets prevents me from using the "Follow TCP Strem" feature of wireshark
> > for an easy look into the plain text of all TCP packets of this HTTP stream
> > (which was in fact the trigger for me to have a deeper look into the sniffed
> > stream from ppp0 and eth0).
> > 
> > For other apps I observed similar things which cannot fully be explained by
> > terms like "TCP checksum offloading". 
> > 
> > I didn't observed any malfunction at application level so it might be an issue
> > with the capturing itself.
> > 
> > Why is the ppp stream always ok in opposite to the eth0 stream ?
> 
> Toralf, thanks for providing more info about your setup.
> 
> Are you using kernel-mode PPPoE? I know some PPPoE servers do the PPPoE 
> datapath in userspace...
> 
> The captured PPPoE stream seems to show incorrect data lengths in the 
> PPPoE header for some captured PPPoE packets. The kernel's PPPoE 
> datapath uses this length to extract the PPP frame and send it through 
> to the ppp interface. Since your ppp stream is fine, the actual PPPoE 
> header contents must be correct when it is parsed by the kernel PPPoE 
> code. It seems more likely that this is a wireshark bug to me.
> 
> Is it possible to get captures from ppp0 and eth0 simultaneously such 
> that they show the same ppp instance? This might give more clues.
> 

Hi,

yes, I'm using kernel-mode PPPoE. I sniffed at both interfaces the same network stream with the commands:

$>tcpdump -i eth0 -p -s 0 -w tcpdump_eth0.pcap
$>tcpdump -i eth0 -p -s 0 -w tcpdump_eth0.pcap

After that I made an
$>rm -rf .cddb/; kscd
at the 3rd konsole and attached the 2 pcap streams onto this mail.

Thanks for your help.


-- 
MfG/Sincerely

Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Attachment: tcpdump_ppp0.pcap
Description: Binary data

Attachment: tcpdump_eth0.pcap
Description: Binary data

Attachment: signature.asc
Description: This is a digitally signed message part.