views:

18

answers:

0

I've been having problems with a third-party application that uses UDP broadcasts to configure some propitiatory networked hardware and I think I've worked out what's going on. It seems that all outgoing broadcast packets are being lost because of bunch of entries in my routing table that route broadcast packets to a non-existent link-local network interface. Here's an extract from my routing table:

Network Destination Netmask Gateway Interface Metric 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 169.254.116.153 276 255.255.255.255 255.255.255.255 On-link 192.168.0.101 276

As I understand it, the route to the "link-local" 169.254 address is a fall-back route that's added in case DHCP fails but here DHCP has worked fine - that's where the 192.168.0.101 address came from.

So my question is, why is that 169.254 route still there?

I've done some experiments and I reckon that, because the link-local route has the same metric as the real physical route, and it occurs before it in the routing table, all broadcast packets are being sent through that interface and lost. If I specifically bind to 192.168.0.101 or add a route to 192.168.0.101 with a lower metric, this seems to fix the problem. But what I really want is for these link-local routes to go away without me having to mess around with the routing table - like they did in Windows XP.