Wireshark-dev: Re: [Wireshark-dev] malformed captured packets
From: Toralf Förster <[email protected]>
Date: Fri, 31 Aug 2007 09:36:55 +0200
@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
Description: Binary data
Description: Binary data
Description: This is a digitally signed message part.
- Prev by Date: Re: [Wireshark-dev] RRC Messages does not decode correctely
- Next by Date: [Wireshark-dev] Again broken windows build?
- Previous by thread: Re: [Wireshark-dev] SVN Commit With IPMB Support?
- Next by thread: [Wireshark-dev] Code compiles but building a Wireshark installer fails