On Thu, 11 May 2000, Richard June wrote:
> I guess then the question becomes, why not deduce broadcast from the
> netmask yet still allow that to be overridden? this allows the most common
> case to be easier, and makes the odd case require extra work, not the
> other way around.
That's exactly what happens.
It's not the kernel that is causing the misunderstanding here, it is that
the 'ifconfig' program is processing its parameters in order.
> > > ifconfig eth0 10.10.10.1 netmask 255.255.255.252
Lets take it one parameter at a time.
ifconfig eth0
We are working with "eth0". Network interfaces are dynamically created
and destroyed, and thus have no consistent namespace mappings as
entities in "/dev", so they exist in "socket space". We open a socket
and see if "eth0" exists as an interface name.
10.10.10.1
Set the interface address to 10.10.10.1. At this point the kernel knows
that the netmask has not been set. It must guess a netmask based based
on the old "Class A/B/C/D" address divisions, and it calculates a
broadcast address based on its guess.
[[ Note: The 'ifconfig' program is flawed by design -- try naming a host
"broadcast". ]]
netmask 255.255.255.252
Set a new netmask "/30". The kernel cannot decide "Oh, I guessed wrong
before" and change the broadcast address calculated above. If it did,
there would be some configurations you could not set up. So the kernel
dutifully sets just the netmask and leaves the bogus broadcast address
in place.
With a fresh initialized device (starting with no broadcast address) try
ifconfig eth0 netmask 255.255.255.252
Donald Becker [EMAIL PROTECTED]
Scyld Computing Corporation
410 Severn Ave. Suite 210
Annapolis MD 21403
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
