Re: etherconf or ifupdown problem with subnets
On Sun, 14 Jul 2002, Steve Langasek wrote:
>On Sun, 14 Jul 2002, Carlo U. Segre wrote:
>
>>
>>Hello All:
>>
>>I have run across an odd problem when using etherconf in woody to
>>configure IP addresses statically on a 128 number subnet.
>>
>>I have a subnet which goes from 164.54.244.0 to 164.54.244.127
>>
>>When I use etherconf I tell give the mask as 255.255.255.128 but etherconf
>>does not ask for a broadcast address, nor does it put one in
>>/etc/network/interfaces.
>>
>>when the interface is brought up by /sbin/ifup, the broadcast address is
>>incorrectly set to 164.54.255.255
>>
>>This causes some huge problems on my network and I have had to remove
>>etherconf and just edit the /etc/network/interfaces by hand.
>>
>>BTW, if the netmask is 255.255.255.0 all works perfectly!
>>
>>I don't know if I should report this as a bug to etherconf or ifupdown, or
>>even ifconfig. In the first case, it would be good to have a "broadcast"
>>line in /etc/network/interfaces but that might just be masking a problem
>>in ifupdown's calculation of a broadcast address from the netmask. Or
>>perhaps it is a problem in ifconfig. The final possibility is that I am
>>making a stupid mistake.
>>
>
>If I list both the netmask and the broadcast explicitly in
>/etc/network/interfaces for my /25 network (which is in a class-A
>netblock), then the interface is configured correctly. If I omit one or
>the other, then the default class-A value is used. This seems
>reasonable to me; if the netmask or broadcast address should be derived,
>it should be done at the kernel level for you -- not in the userspace
>tools. But this is not done, presumably for those rare cases when
>someone deliberately wants to have mismatched values...
>
But the behavior that I observed is that if the netmask is set up for a
class C, then the broadcast address is correct (xxx.yyy.zzz.255). If I
have a subnet, such as the one in the example (xxx.yyy.zzz.128), the
broadcast is configured for a class B (xxx.yyy.255.255) rather than the
correct value (xxx.yyy.zzz.127). This raises several inconsistencies:
1. If the correct behavior is to use a class A broadcast, why is the class
C domain correctly set up and why does the machine in my example have a
class B boradcast?
2. If the broadcast address is supposed to be explicitly in the
/etc/network/interfaces file for reliable operation, shouldn't etherconf
ask what broadcast address to use and insert it in the file?
The way it is working now makes it impossible to use etherconf for static
IP configuration of anything but class C (or maybe A and B too). My
thought is to file a bug against etherconf.
Cheers,
Carlo
--
Carlo U. Segre -- Professor of Physics
Illinois Institute of Technology
Voice: 312.567.3498 Fax: 312.567.3494
Carlo.Segre@iit.edu http://www.iit.edu/~segre
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: