On Tue, Jul 10, 2007 at 08:42:15PM +0200, Luis EG Ontanon wrote:
A year or more ago I abandoned a way towards (3) (similar to what I
did for radius dictionary) a while ago, due to a personal lack of
diameter use after switching jobs and a stall about how to handle
recursion in
On 7/10/07, Luis EG Ontanon [EMAIL PROTECTED] wrote:
A year or more ago I abandoned a way towards (3) (similar to what I
did for radius dictionary) a while ago, due to a personal lack of
diameter use after switching jobs and a stall about how to handle
recursion in attribute_groups.
I will
On Tue, Jul 10, 2007 at 06:49:37PM +0100, Martin Mathieson wrote:
OK, I just implemented (2) with change 22284.
You should be able to right-click on a whole AVP that matches the code
you're interested in, choose 'Prepare as Filter | Selected', edit the
last 4 bytes and apply it.
cristian:
On 7/11/07, Martin Mathieson [EMAIL PROTECTED] wrote:
On 7/10/07, Luis EG Ontanon [EMAIL PROTECTED] 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
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
-
hi!
has anyone tested a filter like this:
(diameter.avp.code == 829) (diameter.avp.data.uint32 == 1)
is it suppossed to work? is it actually working in your config/ver?
in my version, it does not in the sense that it will always show all the
diameter commands having an avp with the code 829
That expression will match any frame that has at least one avp with
code value 829 and at least one avp whose data is uint32 whose value
is 1.
I suspect that what you want is to match the *same* AVP with both
parts of the expression, which I don't think is possible with a simple
display filter.
Hi Christian,
As you are probably aware, version 0.99.6 came out a few days back
which I am sure has several fixes, including those for the diameter
dissector. Have you tried using the latest version?
Hope this helps,
Abhik.
On 7/10/07, cco [EMAIL PROTECTED] wrote:
hi!
has anyone tested a
There are several ways this could be tackled:
(1) A script. Export capture to PDML, parse output and match/check
them yourself
(2) We could add a new filterable field, diameter.avp, whose type was
hex data. You could right-click to create a filter for that AVP, then
edit the last word to check
OK, I just implemented (2) with change 22284.
You should be able to right-click on a whole AVP that matches the code
you're interested in, choose 'Prepare as Filter | Selected', edit the
last 4 bytes and apply it.
Martin
On 7/10/07, Martin Mathieson [EMAIL PROTECTED] wrote:
There are several
A year or more ago I abandoned a way towards (3) (similar to what I
did for radius dictionary) a while ago, due to a personal lack of
diameter use after switching jobs and a stall about how to handle
recursion in attribute_groups.
I will be able to get back into it in September (I'll be
11 matches
Mail list logo
