[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-atm
Subject:    Re: tcpdump on lane
From:       Heikki Vatiainen <hessu () cs ! tut ! fi>
Date:       1998-09-23 10:26:10
[Download RAW message or body]


> I feel slightly uncomfortable patching the atm code, I would think it
> would be better to patch the tcpdump to handle the lane code correctly.
> Since ver. 3.3 failed we can tell in tcpdump wether we have lane or
> real ethernet frames and then eat the 16 bits there.

You are quite right. I took a look at tcpdump 3.4 and libpcap 0.4 and 
came up with this patch:

--- libpcap-0.4.orig/pcap-linux.c       Fri Oct  3 08:39:53 1997
+++ libpcap-0.4/pcap-linux.c    Wed Sep 23 14:04:21 1998
@@ -183,6 +183,8 @@
                p->linktype = DLT_EN10MB;
                p->offset = 2;
                ++broadcast;
+               /* skip ATM LANE LECID bytes */
+               if (strncmp(device, "lec", 3) == 0) p->md.skip = 2;
                break;
 
        case ARPHRD_EETHER:

This means that you need to compile both libpcap and tcpdump. The 
easies way to do it is to put libpcap-0.4.tar.Z and tcpdump-3.4.tar.Z 
in the same directory, untar them and compile libpcap first.

When compiling tcpdump-3.4 it automatically finds libpcap.a from 
../libpcap-0.4/ directory.

> The other question is what are these 16 bits for in the first place?

LANE clients can use this 16 bit LECID e.g. for filtering 
multicast/broadcast frames they receive from BUS. This is necessary 
since when a LANE client sends a multicast/broadcast frame it 
immediately gets it back from BUS. Using LECID it can discard all the 
frames for which it is originator.

// Heikki
-- 
Heikki Vatiainen                  * hessu@cs.tut.fi
Tampere University of Technology  * Tampere, Finland

[prev in list] [next in list] [prev in thread] [next in thread]