[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200708291822.35128.toralf.foerster@gmx.de>
Date: Wed, 29 Aug 2007 18:22:34 +0200
From: Toralf Förster <toralf.foerster@....de>
To: James Chapman <jchapman@...alix.com>
Cc: netdev@...r.kernel.org
Subject: Re: malformed captured packets
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 ?
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
Download attachment "signature.asc " of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists