From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 Description of problem: If an address within a class A range is used as a class C address, ifconfig will improperly calculate a class A broadcast address value if not specified with the 'broadcast' ifconfig parameter. The provided netmask value is not used to create the default broadcast address. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.ifconfig ethX inet 10.31.1.100 netmask 255.255.255.0 2.ifconfig ethX 3.Notice "Bcast" reflects a class A value rather than class C even though the provided netmask value indicates use as class C. Actual Results: [root@cire Gemini]# ifconfig eth0 inet 10.31.1.100 netmask 255.255.255.0 up [root@cire Gemini]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:01:03:20:A6:58 inet addr:10.31.1.100 Bcast:10.255.255.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4794508 errors:0 dropped:0 overruns:1 frame:0 TX packets:2825986 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:11 Base address:0xcc00 Expected Results: Bcast (the broadcast address) should appear as 10.31.1.255 instead of 10.255.255.255. Additional info:
Perhaps worth a separate bug, but the man page should discuss the default value for broadcast if not provided (as it does for netmask). If what has been described in this defect report is acutally "how it is supposed to work," that should be documented as well so there are no surprises.
Thats a good question... I think it depends, but i tend to agree with you that for a given netmask and a given network the network address as well as the broadcast address can and should be automatically calculated and set correctly, except if someone explicitly sets it to something else (for whatever reason). I'll look into it, probably will change the behaviour, not the manpage. Read ya, Phil
The code in devinet.c shows that calling SIOCSIFADDR sets class A/B/C defaults for netmask, prefixlen and broadcast; while SIOCSIFNETMASK sets only the prefixlen and netmask, and SIOCSIFBRDADDR sets only the broadcast. In this case, if ifconfig does not do an explicit SIOCSIFBRDADDR the result is a 'stale' class A/B/C entry generated by SIOCSIFADDR that does not match the supplied netmask. I am guessing ifconfig only calls SIOCIFBRDADDR if 'broadcast xxx.xxx.xxx.xxx' is specified on the command line. The likely fix, then, is simply to SIOCIFBRDADDR whenever the provided netmask is not identical to a class A/B/C equivalent. Another symptom of this defect report is when 'broadcast' is supplied on the command line but 'netmask' is not. In such a case, the broadcast and netmask do not correspond. This defect should be amended to include this side-effect as well, as it requires a separate fix. To summarize my thoughts on a solution: 1) ifconfig should explicitly SIOCSIFBRDADDR when a netmask is supplied that does not correspond to the class A/B/C default for the supplied IP address and no broadcast has been supplied. 2) ifconfig should explicitly SIOCSIFNETMASK when a broadcast is supplied that does not correspond to the class A/B/C default for the supplied IP address and no netmask has been supplied.
The 1) is debatable but probably should be implemented. The 2) isn't possible to implement because you cannot properly derive a netmask from a broadcast address. Consider: What's the correct netmask for broadcast 1.2.3.7? Is it 255.255.255.252, or 255.255.255.248? Note both are perfectly valid.
net-tools-1.60-39 in FC is now calculating broadcast adress when only netmask is provided. The second option as Tom described won't be fixed. In this case netmask has to be set manualy.