----- Original Message -----
From: "Brad Hards"
Sent: Monday, September 30, 2002 11:21 PM
Subject: Re: [Ethereal-dev] SLPv2 support
> OK, I've done this (and your other suggestions, I hope) for the SLPv2
stuff.
> Still no SLPv1 changes, for lack of any ability to test them. If anyone
has
> SLP (v1 or v2) traces, feel free to mailbomb me.
If you want to, update it in small steps one obviously correct
transformation at a time, or leave it for someone else to fix.
>
> Only after doing all the helper functions did I realise that most
dissectors
> don't do this. So it really wasn't _that_ deficient in the first place.
Grrr.
I wouldnt say most. Some of the more esoteric and older dissectors are
still
using a lot of proto_tree_add_text() mainly because no one has found a
reason
or itch to update them.
Most of the more common dissectors and the huge ones, like packet-smb.c and
packet-nfs.c and all the dcerpc ones all are converted to use
proto_tree_add_text()
as little as possible.
If i remember correctly, I think packet-smb.c had >400 hf_ fields some time
ago.
But I think it is worth it. Stuff like rightclicking on a line and getting
the Match Selected to work is really nice.
> But it is done now, any I'm only marginally crazy, so I guess all is fine.
> Patch is attached - compressed because 44K->6K is a worthwhile saving,
> especially with some mailing lists blocking at 40K.
>
> Is there a good example of doing stateful snooping? Erik Guttman pointed
out
> that with SLP: "Requester 'RQ' uses an ephemeral port E1 to send a request
to
> SLP reserved port 427, and this could be to a multicast address MQ or a
host
> address H. The DA or SA 'RP' will likely respond to E1 using ephemeral
port
> E2. The filter has to remember
>
> 1) multicast request
> RQ,E1 -> MQ,SLP
> RQ,E1 <- RP,E2
>
> 2) unicast request
> RQ,E1 -> RP,SLP
> RQ,E1 <- RP,E2
>
> In either case, the filter has to keep the request and port # as
> state, and apply this state to subsequent unicast datagrams to
> map them to replies. This will allow you to apply a filter to
> say RP. It is useful to show RQ,E1 -> MQ,SLP before showing the
> RQ,E1 <- RP,E2 reply to show the context of the reply."
>
> Any hints or applicable examples?
See the changes to packet-portmap.c between version 1.35 and 1.36 I think
it is reasonably similar to what you are after.
(When portmap sees certain packets it will register a dissector for that
port.)
So, inside the dissector for the RQ,E1 -> x,SLP packet, you just create a
conversation
for RQ,E1 <-> ANY,ANY and attach your dissector to it.
There may be other examples i dont know of.
I looked at the patch and it looks really good.
There is the switch(function) thingy where inside each case: x
there is a proto_tree_add_text() to put the name of the function in the
tree.
Is this not redundant and really the same as the previous
proto_tree_add_uint(srvloc_tree, hf_srvloc_function,
earlier in the same function?
