How to limit source port range on UDP broadcasts

[Ron Kinner]

We have had an application for years which ran on 10.20 and generated a UDP broadcast on port 1901. The broadcast was then picked up by a Cisco router and turned into a unicast by the IP Helper-address and Forward-protocol commands and sent to a distant subnet as a directed broadcast.

We upgraded to 11.0. The application runs as before but the Cisco refuses to forward the packets. The only difference we can see is that the 10.20 packets always have a source port in the 2000-3000 range. The 11.0 prefers source ports in the 40000-64000 range.

We do not have the source code for the application and upgrading to a newer Cisco code does not help. Cisco admits it's their problem but has no solution. Is there a way to get 11.0 to go back to the old source port range?

Ron Kinner

[James R. Ferguson · Accepted solution]

Hi Ron:

You can use 'ndd' to set the values of 'tcp_largest_anon_port' and 'udp_largest_anon_port'. These control the automatic assignment of port numbers when an application binds to port-0.

To make this permanent, put the settings in /etc/rc.config.d/nddconf.

In 10.20 automatic assignment occured in the range 1024-5000. In 11.x these automatic/anonymous port numbers are chosen, by default, from the range 49152-65535.

...JRF...

[Ron Kinner]

Thanks for the tip. Turns out you also have to change udp_smallest_anon_port in order to get it to work. (Otherwise it takes the command and ndd -get looks good but the first use resets it back to the default.) Oddly enough that parameter is listed as NOT supported by 11.0 but does seem to work OK.

Alas, it did not fix our problem. The router still refuses to accept the packets even tho they have the same source ports of the old 10.20. I looked at our lab's old 10.20's output with a sniffer and I see very little that could cause a problem other than perhaps the TTL. I can't sniff the new machine's output cause it's in California and I'm in FL but I was wondering if perhaps HP 11.0 thinks a broadcast packet should not have a TTL bigger than 1? ndd claims ttl is set to 64 but perhaps they make an exception for UDP broadcasts?

Ron