Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 60509 - ifconfig improperly calculates broadcast addr if not provided
ifconfig improperly calculates broadcast addr if not provided
Product: Red Hat Linux
Classification: Retired
Component: net-tools (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Radek Vokal
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2002-02-28 14:25 EST by Just E
Modified: 2007-04-18 12:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-04 09:01:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Just E 2002-02-28 14:25:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019

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:

Steps to Reproduce:
1.ifconfig ethX inet netmask
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 netmask up
[root@cire Gemini]# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:01:03:20:A6:58  
          inet addr:  Bcast:  Mask:
          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
instead of

Additional info:
Comment 1 Just E 2002-02-28 14:34:17 EST
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.
Comment 2 Phil Knirsch 2002-03-07 10:13:26 EST
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
Comment 3 Just E 2002-03-07 18:40:46 EST
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

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.
Comment 4 Tomas Mraz 2004-11-04 05:24:46 EST
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.

What's the correct netmask for broadcast
Is it, or Note both are perfectly valid.
Comment 5 Radek Vokal 2004-11-04 09:01:05 EST
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. 

Note You need to log in before you can comment on or make changes to this bug.