Fedora 20 broadcast address

Kevin Martin ktmdms at gmail.com
Thu Nov 21 17:05:15 UTC 2013


On 11/21/2013 09:06 AM, James Hogarth wrote:
> 
> 
> 
> On 20 November 2013 22:29, Louis Lagendijk <louis at fazant.net <mailto:louis at fazant.net>> wrote:
> 
>     On Wed, 2013-11-20 at 16:21 -0600, Kevin Martin wrote:
>     > On 11/20/2013 03:21 PM, Louis Lagendijk wrote:
>     > > Some time ago I asked a question about the broadcast address on Fedora
>     > > 20. On my desktop (installed from one of Alpha TC's) the interface is
>     > > brought up correctly, except that the broadcast address does not get set
>     > > correctly:
>     > > Ifconfig reports:
>     > >
>     > >> p5p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>     > >>         inet 192.168.159.186  netmask 255.255.255.0  broadcast 0.0.0.0
>     > >>         inet6 2001:981:688d:f2:1e6f:65ff:fed5:7742  prefixlen 128
>     > >> scopeid 0x0<global>
>     > >>         inet6 fe80::1e6f:65ff:fed5:7742  prefixlen 64  scopeid
>     > >> 0x20<link>
>     > >>         ether 1c:6f:65:d5:77:42  txqueuelen 1000  (Ethernet)
>     > >>         RX packets 568712  bytes 540500284 (515.4 MiB)
>     > >>         RX errors 0  dropped 0  overruns 0  frame 0
>     > >>         TX packets 359977  bytes 282238000 (269.1 MiB)
>     > >>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>     > >
>     > > The broadcast address is not set when I use DHCP, but is also missing
>     > > when I use static address allocation. When I try a
>     > > ifdown p5p1; ifup05p1
>     > > the broadcast address is setup correctly.
>     > >
> 
> 
> Interestingly enough using the iproute tools mirrors the net-tools here to some extent... although net-tools reports 0.0.0.0 whereas
> iproute shows no broadcast address:
> 
>  2: p4p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
>     link/ether d4:be:d9:7e:f3:ce brd ff:ff:ff:ff:ff:ff
>     inet 10.81.10.110/24 <http://10.81.10.110/24> scope global dynamic p4p1
>        valid_lft 18508sec preferred_lft 18508sec
>     inet6 fe80::d6be:d9ff:fe7e:f3ce/64 scope link 
>        valid_lft forever preferred_lft forever
> 
> No brd bit is included in this compared to another interface that does have it:
> 
> 12: virbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
>     link/ether 52:54:00:72:fa:28 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.244.1/24 <http://192.168.244.1/24> brd 192.168.244.255 scope global virbr1
>        valid_lft forever preferred_lft forever
> 
> However I'm curious as to the consequences of this given that broadcast address is just a function of network address against
> network mask anyway ...
> 
> 
> 
> 
I'm guessing (and this is only a guess) that most network tools don't derive broadcast address "on the fly" but use the system
settings when the broadcast address information is needed.  It becomes of particular importance I would suppose when using a mask
that could be considered atypical (whatever that might be).  I just find it disturbing that this has suddenly stopped being set by
default (for example,the network scripts, when not using NetworkManager, use ipcalc to set the broadcast address (which is why ifup
sets the address correctly) but dhclient/NetworkManager apparently are ignoring this at this time).  I've yet to find anything on
the web that indicates that this was a conscious decision.

Kevin


More information about the test mailing list