> I don't know if this is possible, but I know when you use a
> protocol analyzer (e.g. from Agilent) you can put it inline on one of the
> fibers, so perhaps you could do a similar thing with Ethereal:
>
> 1. connect transmit port of one end of the ATM link to receive port of the
> ATM NIC, and transmit port of the ATM NIC to the receive port on the other
> end of the link.
> 2. assuming that the hardware supports this, transmit all received packets
> straight back out with exactly the same headers, so that it is as if your
> workstation was not even part of the link. This would probably require
> you to write some sort of special driver, but it might be easier than the
> normal case of writing a driver if constructing packets with the exact
> headers you want is possible.
> 3. run Ethereal on the interface your driver created.
>
> I guess if you're not a kernel hacker, this option isn't available
> to you! Maybe someone here can comment on whether it would be feasible to
> d this
I can't speak for the physical hardware part, or the "transmit all
received packets straight back out" part, but note that Ethereal just
uses libpcap to capture packets, so your "interface" would have to be a
network interface, of the sort that "ifconfig" knows about.
On BSD, you could conceivably make it an interface that never accepts
any packets as real network input, and just supplies those packets to
BPF.
On Linux, it might be trickier, as the packet capture mechanism in
Linux, as I remember, expects packets to pass through the network stack,
so you'd have to treat those packets the same way that, for example,
incoming Ethernet packets that are not intended for the machine to see
(e.g., unicast packets not sent to one of its MAC addresses) are
treated, so that they go to "taps" but not to the rest of the networking
stack.
Similar things could conceivably be done on other OSes.
Note, however, that:
on BSD, there's a DLT_ type of DLT_ATM_RFC1483, but that's not
for raw ATM AAL5 frames, it's for LLC-encapsulated frames, so
programs that see that will expect to see the frame start with
an LLC header, not anything containing a VPI/VCI pair, for
example;
ARPHRD_ATM on Linux is similar, but even less friendly to raw
capture;
so you'd probably have to invent a new DLT_ type and ARPHRD_ type for
it to use it on BSD and Linux.