On Wednesday, August 6, 2003, at 6:12 AM, Kronberg, Peter wrote:
Is there a way toconfigure Ethereal torecognisea SAP of some other
multiple of 04 as SNAdata also?
If by "SAP" you mean "destination SAP", then the answer is yes - the
way you do that is to upgrade to Ethereal 0.9.10 or later. 0.9.9's SNA
dissector registered itself for a destination SAP of 0x04; 0.9.10 also
registers for destination SAPs 0x08, 0x0C, and 0x40.
It is NOT a hard and fast rule that SAP 04 is the only one usedfor
SNA data.It’s truethat SAP 04 is the most standard SNA SAP, but
numerous vendors use other SAPs (that are a multiple of 04) for SNA
data.We have a situation where wehave SNA data on SAP 08, 0C,
etc...but Ethereal tries to format the data as IPX or some other
protocol.
The only destination SAPs for which the current version of Ethereal's
IPX dissector registers itself are 0x10 and 0xE0, and I don't think
it's ever registered itself for destination SAPs of 0x08 or 0x0C.
Note, however, that only the *destination* SAP is checked; a packet
from 0x08 or 0x0C to 0x10 would be treated as IPX, as that SAP is, I
think, assigned to Netware.
If you want to have 0x10 used as a destination SAP for SNA, we'd have
to add a configuration option to allow additional SAPs to be registered
- and even that wouldn't be enough, as we don't guarantee the order in
which dissectors' "register" routines are called, so if the SNA
dissector's register routine is called before the IPX dissector's
register routine, the IPX dissector would win and get 0x10.
However, if 0x10 is truly being used for SNA, not Netware, *and* you
don't have any other Netware traffic on your network, and if we added
an "additional SAPs" configuration option for SNA, you would be able to
configure 0x10 as a SAP for SNA *and* disable the IPX dissector.
Currently, it would have to be disabled whenever you started Ethereal,
but somebody has some code to make those settings persistent, which
we'll probably put into the next release.
Another idea for the future might be to replace the stuff in dissectors
that registers them with particular port numbers, SAPs, etc. with a
configuration file; the problems there are that, if you let users have
their own configuration files, either
1) that file would completely supersede the default file, with the
latter not being used at all, in which case when a new Ethereal release
comes out, and adds new dissectors or new ports/SAPs/Ethernet
types/etc. for dissectors, a user who had their own configuration would
*not* have the new dissectors, or new ports/SAPs/Ethernet types for old
dissectors, supported;
2) that file would add to the default file, in which case users
couldn't get rid of bindings (such as 0x10 to IPX);
3) that file would add to *and* subtract from the default file, in
which case I'm not sure what the user interface would be for that, or
whether there are any cases where that wouldn't work.