🚀 go-pugleaf

In article <qkgev7.5o8.ln@anacon.demon.co.uk>,
  Mark Evans <mpe@anacon.demon.co.uk> wrote:
> Mike Pellatt <newsfrom@pellatt.co.uk> wrote:
> > On Wed, 27 Oct 1999 23:30:24 +0100, Dmitri Barsoukov
> > <dmitri@nexusnetwork.co.uk> wrote:
> >>Hello,
> >>
> >>I use AVM !Fritz PCI ISDN card when snooping the interface (ippp0),
I
> >>have a lot of similar messages. What does this mean?
>
> > [ snip ]
>
> > It means that tcpdump doesn't work properly on ppp interfaces. The
> > encapsulation is different from that on an ethernet interface.
>
> It does work on ordinary PPP, however it appears confused by the
> HLDC used in SyncPPP.
>

I have the same problem, but I don't think tcpdump has a problem.
I can see how the isdn-connection is "stuck" from time to time.
This is what I found in the tcpdump-trace of ippp0:

10:30:51.834802 1.5.42.79 > 0.0.62.17: (frag 2080:52@52576) [tos 0xab]
                         ebab 0060 0820 d9ac 0800 4500 0105 2a4f
                         0000 3e11 b047 c0a8 2001 c0a8 ffff 008a
                         008a 00f1 2734 110a 665c c0a8 2001 008a
                         00e9 0000 2045 4c46 4345 4245 4f44 4543
                         4143 4143
10:30:51.863186 1.5.42.79 > 0.0.62.17: (frag 2080:52@52576) [tos 0xab]
                         ebab 0060 0820 d9ac 0800 4500 0105 2a4f
                         0000 3e11 b047 c0a8 2001 c0a8 ffff 008a
                         008a 00f1 2734 110a 665c c0a8 2001 008a
                         00e9 0000 2045 4c46 4345 4245 4f44 4543
                         4143 4143
10:30:51.893624 1.5.42.79 > 0.0.62.17: (frag 2080:52@63512+) [tos 0xab]
[ttl 0]
                         ebab 0060 0820 ff03 0021 4500 0105 2a4f
                         0000 3e11 b047 c0a8 2001 c0a8 ffff 008a
                         008a 00f1 2734 110a 665c c0a8 2001 008a
                         00e9 0000 2045 4c46 4345 4245 4f44 4543
                         4143 4143

and the interfaces used elsewhere:
relais (192.168.31.3) at 00:60:08:20:D9:AC [ether] on eth0
eth0      Link encap:Ethernet  HWaddr 00:60:8C:51:EB:AB

The data in the beginning of the packet is a part of an old
MAC-header of a packet that was from "relais" to eth0.

dst  src            proto IP-header
ebab 0060 0820 d9ac 0800 4500 0105 2a4f

The data after the "old partial" MAC-header are the data
that were supposed to be sent via ippp0.

And in the 3rd packet:
               ???? ????
ebab 0060 0820 ff03 0021 4500 0105 2a4f

the sequence ff03 0021 also seen a lot times. I know this sequence
from somewhere, but I can't remember right now.

Anyway, when the IP-headers are wrong, they're always off
by 10 bytes. Could it be that someone does a "memcpy (to + offset, .."
and doesn't make sure that offset is zero?


Sent via Deja.com http://www.deja.com/
Before you buy.