Home / server / Questions / 21875
Accepted
Raphaël Hertzog
Asked: 2009-06-09 05:32:21 +0800 CST

What is responsible of setting up the default broadcast address?

  • 772

The broadcast address is apparently misconfigured on some (old) Linux embedded device that I setup (but that I don't own anymore) because it doesn't match the expected value given the IP address and the netmask (for example, it has a broadcast of 192.168.70.255 instead of 192.168.71.255 for 192.168.70.243/255.255.254.0). It runs a kernel 2.4.31 with busybox 0.60.5. The network configuration is simply done with that shell snippet:

ifconfig eth0 $IPADDR netmask $NETMASK
if [ -n "$GATEWAY" ]; then
    route add default gw $GATEWAY
fi

Thus the broadcast address is not explicitely configured. The question is: what is responsible of this bad behaviour? Is it busybox's ifconfig that doesn't set the broadcast address correctly or is it the kernel that set it up badly?

Note: it's possible that none of them are responsible but something else gets in the way in the boot process (and reconfigures it badly) as the device runs user-specific software that I don't know. I will follow up with more info once I have them.

linux networking busybox

4 Answers

  1. Best Answer

    Starting investigations on the topic I discovered with strace that changing the broadcast address with ifconfig leads to a supplementary ioctl() call (SIOCSIFBRDADDR - Set InterFace BRoadcast ADDRess) that doesn't appear in the normal trace when you leave out the broadcast parameter. So it looks like that ifconfig doesn't deal with the broadcast address in the default case and leave that up to the kernel.

    • 2

  2. It isn't the kernel, I would bet.

    If you've got shell access to the machine, try to recursively grep in /etc for that string: 

      grep -R "192.168.70.255" *

    That should tell you where the config is that needs changed.

    • 0

  3. Having actually read the question this time, my gut reaction is that the problem would lie in BusyBox making the wrong assumptions or possibly living in some parallel universe where classful routing didn't disappear. You don't say how old the kernel or the busybox is, but you might be able to test which is at fault if you can get a more recent version of busybox, a copy of ip or strace on the box. ip or newer busybox would allow you to set the ip and netmask with a tool with a known good behaviour. If it's still wrong, it's probably the kernel. If it's right, it's busybox. With strace you could see what syscalls busybox is making.

    If you can't get any new binaries on the box then there's not really much more you can do other than set the broadcast to the right value yourself.

    • 0

  4. Is it possible that the broadcast is dynamically generated from the IP/Mask combo and that you actually entered the netmask wrong?

    • 0