On Sun, Jul 14, 2002 at 11:41:03PM -0500, Carlo U. Segre wrote: > 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: Then it sounds to me like something is incorrectly setting the broadcast when using a /24 netmask. > 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? The particular network numbers you cited were in the class-B range, not in the class-A range, were they not? Therefore, the kernel will default to using a class-B broadcast. > 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? If etherconf is a front-end config tool for /etc/network/interfaces (I don't use it myself), I would argue the correct behavior is to automatically calculate the broadcast address and set it appropriately, without prompting the user. Deliberate netmask/broadcast mismatches are rare enough that the option should be hidden from those using configuration tools. > 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. That sounds reasonable. Steve Langasek postmodern programmer
Attachment:
pgpusiGwgG3q3.pgp
Description: PGP signature