Toralf Förster wrote:

Am Mittwoch, 29. August 2007 schrieb James Chapman:

quoted

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