Ethereal-users: Re: [Ethereal-users] Two Ethereal questions
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
ronnie sahlberg on Thu, 4 Nov 2004 08:21:24 +1100 wrote:
>On Wed, 3 Nov 2004 12:08:28 +0000, Julian Fielding wrote:
>>
>> 3. Packets with unusual ports. The enip dissector looks for 44818 (explicit)
>> and 2222 (implicit). That usually works for explicit messages but not
>> necessarily for implicit because any ports may be specified with the
>> preceding (explicit) Forward_Open command and response. (Solution: identify
>> such a packet and use Decode As enip. Enip appears twice in the Decode As
>> list, as do several other protocols. Try both. One will be ignored, the
>> other should work.)
>
>If these other ports are signalled inside previous enip packets, then
>the best solution would be to teach the enip dissector that when it
>sees that a new port is being signalled for enip, then it will create
>a new conversation for that protocol and specify it being enip.
>So that ethereal will automagically detect these pacekts as enip as well.
Yes, that would be nice. But . . .
Implicit enip connections (conversations) are usually intended to last forever, so if you start capturing on a working system the setup information would have happened a long time in the past. You'd still need Decode As.
If you're capturing because of a problem, it's quite likely the problem would involve the connection failing and being re-opened (with new setup information) after a short time. So only packets captured after the problem would be correctly identified, unless the new connection happened to use the same ports and (multicast) IP address. This might mislead inexperienced users into thinking there was something wrong with the unidentified packets (before connection failure), and that this had something to do with the real problem.
It really is not difficult to use Decode As for these packets - they are easily recognisable by a human who is expecting them. (UDP, fixed lengths related to something user configured, repeating at fixed intervals (typically <100ms) that user has configured.)
Julian.