On 12/6/05, Harms, Kyle J <Kyle.J.Harms@xxxxxxxxxx> wrote:
> I decided that dissect_cigi should dissect the packet not discover what
> it is. I figure that part should be in another function. In the
> process I have tried to strength the heuristics.
Nice.
If we need to strenghten them even more it is possible to check
if(tvb_length(tvb)>=20)
and then check the first four bytes, if present, of the next cigi pdu
following the first one.
>
> If they are strong enough, should I remove the port preference?
I think so.
Because
> even if you use it now, since we return 0 if the packet is not
> recognized as CIGI it will not force CIGI dissection as before.
> Currently this preference is quite useless, unless it is possible to
> force CIGI dissection even if it is rejected as being CIGI.
>
> The IG Status code has values 0 to 255 so it is of no use in heuristics.
> I was able to use the IG Mode because its valid values are 0, 1, or 2
> (not 3). And for CIGI 3 the specification says that all reserved fields
> must be 0. ( this is not a requirement for other versions of CIGI).
> The other bit fields can be 0 or 1 so they are of no use.
Ok those bits can be 1, but are they in any of the available cigi
implementations?
I imagine there are only a handful of implementations of this protocol.
>
> I would give an svn diff as a patch however, we are not allowed to
> connect Linux boxes onto the network. Otherwise I have to go to great
> lengths to do `svn diff`. I can do a `diff -u old-file new-file >
> file.patch` if that would be preferred.
If you send an old style diff not against the curent svn please do
also send a new packet-cigi.c so i can regernerate the diff in case
svn has changed and the diff does not apply.
A new packet-cigi.c.gz is fine in case you are svn disabled.
I will have a look at the new file later today and check it in if it looks good.
Im a bit distracted from ethereal right new with a new baby in the
house and all...
