(This is a libpcap/Linux kernel issue, not an Ethereal issue, so I'm
redirecting the discussion to [EMAIL PROTECTED])
On Fri, Jan 25, 2002 at 06:42:30PM -0500, Michael Garrett wrote:
> I have ethereal .9 and libpcap .7
>
> In a linux box running Marconi/Fore HE155 drivers. (marconi drivers, not
> zepplin)
>
> I can capture LANE traces, but I don't get anything lower in the protocol
> stack than the datalink layer. I would love to be able to capture VPI/VCI
> ATM header information (even if it isn't decoded), but I can't see a way
> to do it.
Ethereal uses libpcap to do its packet capturing; libpcap, on Linux,
uses PF_PACKET sockets (or SOCK_PACKET sockets, if it's an old version
of libpcap that doesn't support PF_PACKET sockets, or it's a 2.0[.x]
kernel, which doesn't have PF_PACKET sockets).
This means it can only do what libpcap lets it do, and libpcap only lets
it do what the Linux networking stack lets libpcap do.
In the 2.4.9 kernel, at least, outgoing packets are delivered to sockets
in "dev_queue_xmit_nit()" and incoming packets are delivered to sockets
in "net_rx_action()"; any packet that doesn't get passed to those
routines won't be seen.
In addition, the only data that's delivered is the data that appears in
the sk_buff for the packet; the data that's delivered starts at the
location pointed to by the "mac.raw" pointer in the sk_buff.
It may be that the driver sets "mac.raw" to point to the beginning of
the MAC header in the LANE packet; if so, you won't see any data other
than that. (I don't see anything in the LANE code that either sets
"mac.raw".)
I don't know what would break if the driver were to construct some kind
of VPI/VCI/AAL5 header at the beginning of the sk_buff and set "mac.raw"
to point to that; I don't see anything *immediately* obvious in a *very*
quick scan through the 2.4.9 kernel code, but that doesn't mean there's
nothing.
Note that this might be harder for outgoing packets, as the fake header
would have to be added before "dev_queue_xmit_nit()" is called *and*
you'd have to make sure no other crap added to the beginning of the
frame.
I'm not a Linux networking stack expert, and cannot offer any advice on
how to do all of the above.
> ps. I also tried to capture using the /dev/fatm0 interface, because I
> thought maybe the raw device would have to be snooped to get the atm layer
> information, but I get a bind (no such device) error from ethereal.
If there's no network interface named "fatm0" on your machine ("network
interface" in the sense of something whose driver plugs into the Linux
networking stack; "ifconfig" would probably show networking devices),
neither Ethereal nor any other program using libpcap will be able to
capture on it. If so, and *if* there's a mechanism in the driver for
the "/dev/fatm0" device to allow raw packets to be captured, libpcap
could perhaps be modified to support capturing on that as well as on
PF_PACKET sockets on normal network interfaces.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
