On Sat, Jan 06, 2001 at 03:28:28PM +0200, Paul Ionescu wrote:
> Unfortunately I have no capture of frame relay to probe the dissector.
> I had to "probe" the dissector by temporary binding it to some tcp port
> and put in some data in that stream with "nc"
> I don't know if right now is possible to capture some frame-relay
> packets in linux with tcpdump.
The FreeBSD version of tcpdump has a "print-fr.c" Frame Relay dissector;
however, the "fr_if_print()" routine that dissects Frame Relay packets
isn't ever called from the rest of tcpdump, as there's no DLT_ value for
Frame Relay in FreeBSD. (There *is* a Frame Relay Netgraph module for
FreeBSD; I don't know what driver it'd be connected to, however, and
don't know how you'd arrange to capture Frame Relay traffic. Perhaps I
should ask Julian Elischer or Archie Cobbs about it....) The FreeBSD TCP
code looks as if it assumes the link-layer header is a LAPF core header
(address, with no control field; I infer that LAPF core is purely a
datagram service, so all packets are the equivalent of UI packets)
followed by an RFC 1490 header (control field (0x03, for UI), padding,
and NLPID).
NetBSD doesn't appear to have any Frame Relay support in tcpdump, nor
does OpenBSD. I don't see any obvious FR support in the NetBSD kernel
source tree as of when I last "cvs update"d the one I have.
BSD/OS *does* have Frame Relay support, including, I infer from some
header files, etc., tcpdump support for it. Unfortunately, the folks I
asked about it didn't have a capture file handy....
Linux 2.2.18 appears to have Frame Relay support, and there's an ARPHRD
type of ARPHRD_DLCI; I very sincerely hope that its Frame Relay code
doesn't screw up the way the Linux PPP code does, and forcibly hide the
header from PF_PACKET sockets by setting "skb->mac.raw" to "skb->data"
*AFTER* "skb_pull()"ing the header off - it *looks* as if
"dlci_receive()" in "drivers/net/dlci.c" sets "skb->mac.raw" to
"skb->data" *before* pulling the header off, so perhaps they did that
one right. I infer that its notion of a Frame Relay link-layer header
is just the RFC 1490 header.
There is a DLPI link-layer type code for Frame Relay LAPF, so in theory
systems using DLPI could let you snoop on a Frame Relay connection;
presumably on Solaris you could do so only if you had the appropriate
add-on product, and I don't know if it supports that. I also don't know
what header you'd get from it if you could snoop on it.
Your dissector is dissecting what I infer to be the LAPF core header; I
don't know whether any capture mechanisms or Frame Relay capture file
formats have both LAPF control frames (which do have an xDLC-style
control field) and LAPF core frames (which don't). It also appears to
treat the address as always being 2 bytes (apparently it can be 2, 3, or
4 bytes, using the ITU-style convention of "keep going until you hit a
byte with the low-order bit set"), and treat the two bytes after the
address as being a 2-byte Ethernet protocol type, which is different
from what RFC 1490 specifies.
So it looks as if
1) there may be several different types of "Frame Relay"
captures, some of which might have a LAPF core header and
some of which wouldn't (I don't know whether any capture
mechanisms would let you capture LAPF control frames - you
can, I think, see PPP control frames if you capture with BPF on
a PPP interface on a BSD system, but I suspect you don't see
D-channel stuff if you capture with BPF on an ISDN
interface);
2) there may be more than one flavor of encapsulation atop LAPF
(RFC 1490 and the type you're dissecting);
so I'm inclined to wait until I see a Frame Relay capture "in the flesh"
before adding any Frame Relay support to Ethereal - or to tcpdump, for
that matter - so that I know how many different flavors of Frame Relay
capture need to be supported and know what to expect as the header for
each of those flavors.
