Hi Experts, While analysing radius packet traces in wireshark - I noticed error i.e. "Not enough room in packet for AVP" Besides - 1. this packet is visible only in wireshark. If I search such packets in application logs I don't find them at all. 2. there are certain other packets also which look genuine in wireshark - but they too are not visible in application logs at all. We are using RHEL 7 with kernel 3.10.0-229.1.2.el7.x86_64. It is VM instance & not physical server. I tried searching Internet but didnt find much hints (other than dictionary defination which is not the case here). Has anyone observed such issue pertaining to radius/UDP message not visible in application debug logs ? Is it something to do with linux kernel ? Any guidance would be really appreciated. Thanks in advance ! asked 25 Feb '17, 11:19  Vijay Gharge edited 25 Feb '17, 11:25 |
One Answer:
This means that an AVP in the packet has a length that implies that the AVP goes past the end of the packet. This presumably means either that 1) the packet required multiple TCP segments but was not reassembled for some reason or 2) the packet really is malformed. We'd have to see the packet (preferably in the form of a capture file, NOT a screenshot!) in order to figure out which of those is the case. answered 26 Feb '17, 01:46  Guy Harris ♦♦ showing 5 of 7 show 2 more comments |
It is also possible that the traffic isn't radius at all if some other protocol is using the ports on which radius is expected.
Thanks for response. Actually there was error in the analysis process itself. Instead of looking at /proc/net/udp6 we were concentrating on /proc/net/udp only. Radius clients and server communicate over IPv6. We noticed dropped packets in udp6 file. Thanks once again...
Thanks for response. Actually there was error in the analysis process itself. Instead of looking at /proc/net/udp6 we were concentrating on /proc/net/udp only. Radius clients and server communicate over IPv6. We noticed dropped packets in udp6 file. Thanks once again...
The problem comes from the Radius header that indicates a length shorter than what it is in reality.
For example if you look at packet 2 you will see that the length indicated in Radius header is 58 bytes while UDP payload length is 186 bytes.
In other words, whatever software is sending those RADIUS packets is buggy, according to RFC 2865, the RADIUS protocol specification; it's not correctly filling in the Length field in the header.
Perhaps the application that received the packet silently dropped the packet, without logging it.
thanks for response. My source node (radius proxy) can decode it correctly. Do you suspect that it may be turning malformed as soon as it enters radius server ? How exactly I could troubleshoot this issue ? Do I need to provide any more information ? Besides, I want to know which exact element calculates radius length ? Is it source node i.e. radius proxy or destination server ?
So do you mean that 1) Wireshark, when running on the source node and capturing traffic to and from the source node, can decode it correctly, or 2) the packet was sent to the RADIUS proxy running on the source node and it decodes the packet correctly, or 3) both?