This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

RADIUS Disconnect-NAK replies not associated with Disconnect-Requests

0

Hi All,

Is it deliberate that RADIUS Disconnect-NAK replies are not associated with their respective Disconnect-Requests based on Packet ID value in them? (a) they have no "This is a response to a request in frame x" line, and (b) their respective Disconnect-Request messages have no "The response to this request is in frame y" line

Disconnect-ACK replies have no such problem.

Not sure how to attach a pcap trace illustrating the issue.

Update: Packet trace uploaded: https://drive.google.com/file/d/0B31e47Ucqt4BRzZQYUh6eHJZaVU/edit?usp=sharing

Thanks in advance,

Dmitriy

asked 19 Sep '14, 06:57

Dmitriy's gravatar image

Dmitriy
216711
accept rate: 0%

edited 19 Sep '14, 09:02

Put your capture in a publically accessible space, e.g. CloudShark, Google Drive, Dropbox etc. and post a link to the capture back here by editing your question, or raise an Incident in the Wireshark Bugzilla and attach the pcap there. The attachment can be marked "private" to restrict access to the core developers.

(19 Sep '14, 07:06) grahamb ♦
(19 Sep '14, 07:20) Dmitriy

2 Answers:

0

Looks like a bug\enhancement to me, take your pick. Likely to be in the radius dissector not considering a NACK as a reply. Best handled via the Wireshark Bugzilla by raising an entry there, or even submit a patch via Gerrit.

answered 19 Sep '14, 08:08

grahamb's gravatar image

grahamb ♦
19.8k330206
accept rate: 22%

grahamb:

Thank you - will try Bugzilla first. Btw I'd also suggest considering NAK as a reply: if there's a NAK there should never be an ACK later.

Update: just filed it in Bugzilla as: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10487

(19 Sep '14, 08:30) Dmitriy

I agree. Either the folks who created that dissector didn't think about that, or there's a bug and it doesn't work correctly.

(19 Sep '14, 08:38) grahamb ♦

0

Apparently there's a config option that affects it:

Pascal Quantin 2014-09-19 19:03:38 UTC Hi,

Radius dissector has a parameter allowing you to define what should be the maximum RTT allowed for request/response tracking. By default it is set to 5 seconds but in your capture the Disconnect NAK takes 6.0039 seconds to be received. Simply go to Edit -> Preferences ->Protocols -> Radius -> Request TimeToLive and increase it.

answered 19 Sep '14, 13:18

Dmitriy's gravatar image

Dmitriy
216711
accept rate: 0%