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@xxxxxxxxxx <mailto:louis@xxxxxxxxxx>> 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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
