Hello Guy,
I already tried to use token ring dissector, but I think that it is not
possible because of one small detail:
In these 35 bytes reserved for NetBIOS DLC header (actualy token ring
header), the RIF is put as 18 bytes present all the time.
So, if you have actualy only 2 bytes of RIF in a normal token ring
frame, on this DLSW frame you will have 18 bytes of RIF (your 2 bytes +
16 padding bytes). In this case the token ring dissector will not work
properly. And usualy the actual RIF is less than 18 bytes.
Do you have an ideea how to solve this ?
Cheers,
Paul
> I infer from RFC 1434 that NetBIOS control messages should be handed to
> the token ring dissector. RFC 1434 says
>
> The DLC Header Length is set to zero for SNA and is set to x'23' for
> NetBIOS datagrams, indicating a length of 35 bytes. This includes
> the Access Control (AC) field, the Frame Control (FC) field,
> Destination MAC Address (DA), the Source MAC Address (SA), the
> Routing Information (RI) field (padded to 18 bytes), the Destination
> link SAP (DSAP), the Source link SAP (SSAP), and the LLC control
> field (UI).
>
> and those fields sound like token ring header fields; it later says
>
> For the exchange of NetBIOS control messages, the entire DLC header
> is carried as part of the message unit. This includes the MAC
> header, with the routing information field padded to 18 bytes, and
> the LLC header. The following message types are affected:
> NETBIOS_NQ, NETBIOS_NR, NETBIOS_ANQ, NETBIOS_ANR, and DATAFRAME when
> being used by NetBIOS systems. ...
>
> so those are presumably the frame types to be handed to the token ring
> dissector.
