Date:	Thu, 30 Aug 2007 10:51:31 +0100
From:	James Chapman <jchapman@...alix.com>
To:	Toralf Förster <toralf.foerster@....de>
CC:	netdev@...r.kernel.org
Subject: Re: malformed captured packets

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.

-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists