Re: [Linux-ATM-General] Supporting tcpdump, pseudo interfaces, and DSL MTU's

[chas w. - C. <ch...@cm...>]

On Sun, 05 Sep 2010 16:15:21 -0700
Philip Prindeville <phi...@re...> wrote:

> You can make the argument that the end-systems sitting behind a
> router/firewall *might* be connected by 10mb/s Ethernet II over coax
> and/or a dumb hub, hence 1500 byte MTU makes sense.  But frankly this
> is highly unlikely.

i think it might be safest to use an mtu of 1500.  if you use anything
else you are doing to be asking some device somewhere to fragment your
traffic and that is going to impose some cpu load.  for embedded
devices, might be too much load.  you cant rely on path mtu detection
since many isp's just blindly block all icmp.

> Which, wanting to investigate this, brought me to the fact that (a) I
> couldn't run tcpdump on an ATM (DSL) interface and look at the actual
> MAC stream, and (b) while PPPoE creates a pseudo-interface (nas0) via
> br2648ctl, using the popular pppoatm.so kernel plugin doesn't create
> a similar pseudo-interface.  Should the pppox kernel module create a
> pseudo-interface that supports hooks for tcpdump inspection?  I'm
> thinking it should.

i dont know how pppoatm works exactly but i gather that pppd eventually
delivers the traffic to the network stack.  you should be able to
capture with at that point.  tcpdump'ing a native atm stream isnt
supported but there is a tool to look at the data on on vpi.vci,
atmdump.  however, you cannot dump vpi.vci that is already in use.

i suppose we could fix push() to send a cloned skb to the network stack
so that tcpdump dump could see it (only for 'raw' connections i guess
that you cant watch any other way). however, it will be missing any atm
headers so i am not sure how useful this would be.