Am I right in believing that the Diameter dissector currently ignores
the gavp entries within a grouped avp?
It may be just as useful (and much less effort?) to only filter based
on the innermost AVP without embedding them.
e.g. just support e.g.
- diameter.avp.server
- diameter.avp.client
- diameter.avp.addr (may be inside a client or server)
- diameter.avp.port (may be inside a client or server)
rather than
- diameter.avp.server
- diameter.avp.client
- diameter.avp.server.addr
- diameter.avp.server.port
- diameter.avp.client.addr
- diameter.avp.client.port
If we only supported the second form, there will be times when you
want to filter based on just the value of addr (i.e. the first form).
It would be confusing to have both in the tree.
But like I said, I've never really had to follow a diameter message
flow, so I could be wrong about which form of filters would be the
most useful.
On 7/11/07, Luis EG Ontanon <luis.ontanon@xxxxxxxxx> wrote:
On 7/11/07, Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx> wrote:
> On 7/10/07, Luis EG Ontanon <luis.ontanon@xxxxxxxxx> wrote:
> I wondered if MATE or the LUA support could make this kind of
> filtering possible, but dynamically creating filters is obviously the
> right way to do it.
In MATE there's no way (mate fields are unmodifiable strings
containing the text representation of another field).
But Lua could do (since you added diameter.avp): a postdissector
fetches the diameter.avp finfos gets the tvb of them and redissects
each field.
A dictionary parser in lua should be easy to write (there's ton's of
xml parsers written for every purpose arrount to start from)...
But I fully agree that dynamically creating filters is obviously the
right way to do it... and C does it better.
The issue that blocked me was on how to handle Group AVPs, I cannot
just ignore them (e.g. an hypotetical group {addr,prt} could lead to
server.addr and server.prt vs client.addr and client.prt and they
should be different), Group AVPs lead to recursion (if the recurring
subgroup is non Mandatory it might be possible to have them but
http://tools.ietf.org/html/rfc3588#section-4.4 says nothing about it)
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev