Fedora 20 broadcast address

[Louis Lagendijk]

On Thu, 2013-11-21 at 11:05 -0600, Kevin Martin wrote:
> 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.
For applications it is often ok to use the global broadcast
(255.255.255.255). In a multi-homed setup that can become tricky so then
it is better to use the network broadcast address. I have therefore
raised a bugzilla case (BZ 1032819) for this. I am not sure whether this
qualifies as a blocker (networking is blocking, but this is not
completely so I doubt if it should qualify) but it is awkward in certain
cases. As the ifdown/ ifup case sets the broadcast I am fairly confident
that thi is a bug somewhere (mot likely NM) but I unfortunately don't
know how to debug this. The old network script was much easier to debug
Br, Louis