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

[Philip P. <phi...@re...>]

  On 9/7/10 10:37 AM, ashgupta wrote:
> On Tuesday 07 September 2010 09:17 PM, chas williams - CONTRACTOR wrote:
>> 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.
>>
>>    
> pppd will not create net_device till lcp is not negotiated successfully. so either way is to dump pkt some where (like inpppoatm_push or in atm driver  <http://lxr.linux.no/linux+*/+code=pppoatm_push>)
> or clone skb and redirect it to some Ethernet interface (if your box has one) there you can connect some pc with Ethernet interface and snoop those
> lcp pkts.

Why do we even need an Ethernet interface?

Tcpdump understands non-Ethernet packets, and I think there might be some value to having certain low-level dialog (such as OAM and OLMI) be dumpable (although tcpdump might need hacking to support the AAL's and OAM).

On a side-note: does ATM even advertise "carrier" (such as sync on a DSL link) in any detectable way to user-space?

I'd like to have the pppoe and pppoatm plugins bomb out if carrier is down on the DSL link you're trying to use them with.

-Philip