@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.
