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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
