Hi. I have a trace of RADIUS accounting requests/responses where I accidentally stumbled upon an event that I happened to be looking for. The pattern I see is a NAD sending multiple RADIUS accounting requests that never received an accounting response. The nature of my problem I am trying to solve is such that I need a display filter to help me find these events. Is there a way I construct a display filter to find RADIUS accounting requests that never received a response? asked 27 Aug '15, 12:52  smp |
2 Answers:
Can't you just do: I haven't tried it, but it looks like it should work. (note that if using answered 28 Aug '15, 06:14  Hadriel showing 5 of 11 show 6 more comments |
MATE can help you with this Examples:
See also similar questions
Regards answered 28 Aug '15, 04:48  Kurt Knochner ♦ Learning MATE seems to be something that will take me quite a bit of time, given my skillset. Not sure if I will be successful or not. But given your forum reputation, I think it's safe to assume this will probably do what I need. Thanks a lot for the references - I have never heard of MATE until now. (28 Aug '15, 06:36) smp |
Hi, thanks for the response. What I am looking for is to isolate radius packets that never receive a radius response. Your filter seems to display /all/ the radius request packets, which admittedly includes the one I am interested it. But it doesn't filter out all the requests that /do/ receive a response.
Sorry if that wasn't clear in my original post.
When you look at the RADIUS request packets that do have responses, do they not have something in the Packet Details display tree that says something like "
[The response to this request is in frame ...]"?Yes, they do.
Huh, well then that display filter should have worked I would think. So I just tried it on a sample capture, and it worked - only RADIUS request packets without a response are shown. Are you sure you did the full filter: "
radius.req && !radius.rspframe"?Thanks for your continued assistance. radius.req && radius.rspframe == 0 removes all the frames.
Are you doing this in Wireshark, or tshark? And what exactly are you doing to apply the display filter?
OK good - "
radius.req && radius.rspframe == 0" should have filtered them all. I was just trying to debug why "radius.req && !radius.rspframe" isn't working, because it should work.I just took another trace and used your "radius.req && !radius.rspframe" filter, and as I study it more closely, it /is/ working. I think the problem is just that there are more packets than I intuitively expected.
Sorry about my laziness which caused you extra work. This is what I needed - thanks a lot!!!
If this solved your problem, please accept the answer.
Be careful when filtering RADIUS packets. The current dissector does not do a very good job at matching up requests and responses, often incorrectly tagging packets as duplicates when they are not. See bug 4096 (and bug 5720 , which was marked as a duplicate of bug 4096).
Then to be safe, you could make it "
(radius.req && !radius.rspframe) || radius.dup" to see only requests without a response and all duplicate RADIUS messages; or "(radius.req && !radius.rspframe) || radius.rsp.dup" to see only requests without a response and all duplicate responses, in case a duplicate response was incorrectly associated with the wrong request.