----- 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?
