> first results:
> the patch didn't work. I had a closer look at the data transmitted by the
> Linux-lapether module transmitted to the network. The problem is that
> Linux-X.25 adds an additional length header in front of the LAPB data.
> This seems logically ok, because they can't use a start- and end-flag
> (0x7e), but on the other hand they also don't use a LLC framing.
The page at
http://www.isi.edu/in-notes/iana/assignments/ethernet-numbers
describes the Ethernet type you changed Linux-X25 to use as "X.25 Level
3", which I'd think of as the Packet Layer Protocol, or whatever it's
called, rather than LAPB.
I'd expect an X.25-layer-3-over-802.x to use LLC, as it's an
SDLC-derived protocol just as LAPB is, rather than running atop raw
Ethernet, so I guess I'm not surprised that it's sending LAPB frames
rather than PLP frames.
If it's doing LAPB-over-Ethernet rather than X.25-layer-3-over-Ethernet,
that might also explain why it wasn't using Ethertype 0805.
Is the Linux-X.25 X.25-over-Ethernet using a standard, or is it a
Linuxism? If it's a standard, it sounds as if it's doing X.25 Level 2,
i.e. LAPB, so you'd want to call the LAPB dissector rather than, as I
did, calling the X.25 dissector.
> consequence:
> at the moment the implementation seems to be very experimental and
> therefore I wouldn't check the code to the Ethereal code base. Maybe it
> would make sense to integrate it later as "Linux-X25", because in its
> present state it is far away from standards. Please tell me, wether it
> would make sense to implement an intermediate layer module for Ethereal,
> wich could be switched between the ethernet layer and the LAPB layer module
> of Ethereal. It's only purpose would be to deal with the additional
> length-field between the ethernet header and LAPB.
If there's either a *de jure* or *de facto* standard for
LAPB-over-Ethernet that adds the length field, such an intermediate
layer module would be the right thing to do.
It'd be tricky if there isn't a standard Ethertype for it, though, as we
don't yet have a general mechanism for configuring protcol handoff at
run time (we have one for plugin protocols, but haven't yet generalized
it to built-in protocols).
