I believe that I've found a bug in print-radius.c. When running tcpdump
3.6.2 on RedHat
Linux 7.0 system the following line is output:

21:00:36.575763 204.37.11.5.1812 > 128.38.0.228.27960:  rad-reserved 1028
[id
255]Attr[#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0
#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#
0#0#0#0#0#

ad infinitum. (It keeps printing the #0 characters forever).


On an unmodified LBL tcpdump 3.4 system the line is:

21:00:36.575763 204.37.11.5.1812 > 128.38.0.228.27960: udp 1028

I suspect print-radius.c because I grepped for "rad-reserved" in the
source. I know nothing about the radius protocol, so I didn't feel
qualified to attempt a fix.

In print-radius.c, function radius_attr_print at line 744:

   while (length > 0)
   {
     if ( rad_attr->len <= length )
     {
        ...

     }
     else
     {
        printf(" [|radius]");
        return;
     }
     length-=(rad_attr->len);
     rad_attr = (struct radius_attr *)( ((char
*)(rad_attr))+rad_attr->len);
   }

If the rad_attr->len data from the packet is zero, length is never
decremented and the loop will continue forever.

This brings up a more encompassing problem. In this case, tcpdump has found
a packet with a source
port of 1812, so it assumes that it is a Radius packet and proceeds to
decode it as such, even though it is not a Radius packet. Consequently, the
Radius protocol decoder gets into an infinite loop, (most likely caused by
the programmer assuming that every UDP packet with a port of 1812 must be a
Radius packet). Obviously, in this
case, port 1812 was selected as a transient port by the source system. In
my opinion, we need a way to tell tcpdump to decode or not to decode a
protocol at our option, e.g. command line parameter. It seems to me that
Radius is an obscure enough protocol that the majority of UDP packets with
a port of 1812, (or 1813, 1645, or 1646) should not be assumed by default
to be Radius packets in the general case. There are plenty more cases where
we might not want tcpdump to "assume" the protocol within the packet based
only on the port number.

Any thoughts?

---------------------------------------
 ___  _  _  _   ___       _       _
| . ><_>| || | | . \ ___ | | ___ | |_
| . \| || || | |   /<_> || || . \| . |
|___/|_||_||_| |_\_\<___||_||  _/|_|_|
Developer of SHADOW. The US |_| Navy
is not responsible for my mistakes.
[EMAIL PROTECTED] - (540)653-5593
---------------------------------------

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe

Reply via email to