Wireshark · Wireshark-dev: [Wireshark-dev] Fwd: Re: [0/7] [PPP]: Fix shared/cloned/non-linear skb bugs (was: malformed captured

[Toralf Förster <toralf.foerster@xxxxxx>]

I forget to add wireshark-dev@xxxxxxxxxxxxx to Cc: for the msg see below

BTW the checksum is 0x0000.

----------  Weitergeleitete Nachricht  ----------

Betreff: Re: [0/7] [PPP]: Fix shared/cloned/non-linear skb bugs (was: malformed captured packets)
Datum: Dienstag, 11. September 2007
Von: Toralf Förster <toralf.foerster@xxxxxx>
An: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>

Am Freitag, 31. August 2007 schrieb Herbert Xu:
> On Thu, Aug 30, 2007 at 09:51:31AM +0000, James Chapman wrote:
> >
> > 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.
> 
> If he were using the kernel pppoe driver, then this is because
> PPP filtering is writing over a cloned skb without copying it.
> 
> In fact, there seems to be quite a few bugs of this kind in
> the various ppp*.c files.
> 
> Please try the following patches to see if they make a
> difference.
> 
> I've audited ppp_generic.c and pppoe.c.  I'll do pppol2tp
> tomorrow.
> 
> Cheers,

Running a stable Gentoo kernel 2.6.22-gentoo-r5 now for a while there's only
one thing left related to this topic.

I'm wondering why some UDP packets of the MS messenger protocol (with the usual
text like "please click at www.we-destroy-your-computer.com") always have wrong
check sums regardless whether sniffed at ppp0 or eth0 interface.

But from all UDP packets of this (today) useless protocol only those have wrong
check sums which are marked as "[Long frame (2 bytes)]" within wireshark.

And - last but now least - I have defined the following rule for this protocol :

Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
...
8        1   485 DROP       udp  --  any    any     anywhere             anywhere            multiport dports 1026,1027

and this kernel options :
n22 ~ # zgrep ^CONFIG_PPP /proc/config.gz
CONFIG_PPP=m
CONFIG_PPP_FILTER=y
CONFIG_PPPOE=m

and I'm wondering why it is still possible to capture such packets at eth0.

Thanks for an answer.

-- 
MfG/Sincerely

Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

-------------------------------------------------------

-- 
MfG/Sincerely

Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Attachment: messenger_ethereal_eth0.pcap
Description: Binary data

Attachment: messenger_tcpdump_ppp0.pcap
Description: Binary data

Attachment: signature.asc
Description: This is a digitally signed message part.