lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 30 Aug 2007 10:51:31 +0100 From: James Chapman <jchapman@...alix.com> To: Toralf Förster <toralf.foerster@....de> CC: netdev@...r.kernel.org Subject: Re: malformed captured packets 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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists