> -----Original Message----- > From: grub-devel-bounces+joseph.t.mroczek=intel....@gnu.org > [mailto:grub-devel-bounces+joseph.t.mroczek=intel....@gnu.org] On > Behalf Of Mroczek, Joseph T > Sent: Monday, April 28, 2014 5:07 PM > To: Andrey Borzenkov > Cc: The development of GNU GRUB > Subject: RE: RFC Remove classful causing incorrect routing behavior > > > > > From: Andrey Borzenkov [mailto:arvidj...@gmail.com] > > Sent: Monday, April 21, 2014 7:36 PM > > > > В Tue, 22 Apr 2014 00:13:15 +0000 > > "Mroczek, Joseph T" <joseph.t.mroc...@intel.com> пишет: > > > > > > From: Andrey Borzenkov [mailto:arvidj...@gmail.com] > > > > Sent: Monday, April 21, 2014 10:42 AM > > > > > > > > В Mon, 21 Apr 2014 15:56:07 +0000 > > > > "Mroczek, Joseph T" <joseph.t.mroc...@intel.com> пишет: > > > > > > > > > > > From: Behalf Of Vladimir 'f-coder/phcoder' Serbinenko On > > > > > > 19.04.2014 02:48, Mroczek, Joseph T wrote: > > > > > > > Hello: > > > > > > > > > > > > > > Currently, the DHCP logic assumes that if a gateway is > > > > > > > received in the DHCP > > > > > > packet the boot server is on a remote network. Given that CIDR > > > > > > is now over > > > > > > 20 years old, I think it is a safe assumption that a netmask > > > > > > will be offered in DHCP options. > > > > > > > > > > > > > > Can this be removed? Or is there still a need to cover the > > > > > > > classful > > case? > > > > > > > > > > > > > Please detail the failure scenario. > > > > > > Current code follows standard behaviour for PXE clients and > > > > > > changing it would break any installation which relies on it. > > > > > > > > > > > > > Hmm ... re-reading RFC2131 I ask myself what are conditions when > > > > *client* is supposed to use gateway_ip at all. According to RFC, > > > > giaddr is set by DHCP relay when it forwards request from client > > > > so server knows where to send reply to. DHCP relay then forwards > > > > reply on local subnet according to standard rules. RFC does not > > > > say anything > > about client usage of this field. > > > > Actually there is no requirement that DHCP relay also functions as > > > > normal router. > > > > > > Use of giaddr as a gateway dates back to RFC951. At that point in > > > time we > > did not have DHCP options, so this was a way to dynamicially learn the > > gateway. > > > > > > > Oh. Digging further, RFC1542 quite explicitly states the same: > > > > A BOOTP client MUST NOT interpret the 'giaddr' field of a BOOTREPLY > > message to be the IP address of an IP router. A BOOTP client SHOULD > > completely ignore the contents of the 'giaddr' field in BOOTREPLY > > messages. > > > > I saw this. I did not remove all of the use of giaddr field because of > regression > concerns. > > > > > > The failure will occur in most if not all cases where the DHCP > > > > > sends a gateway when the boot server is on the same subnet as > > > > > the client, > > > > > > > > In view of the above, how is it possible? DHCP server is not > > > > supposed to set this field at all - at the most it simply replies > > > > back to relay with same value of giaddr it got. If giaddr is set > > > > it is already indication that server and client are on different > > > > subnets. > > > > > > For my case, DHCP server is on different subnet but boot/TFTP server > > > is on > > same as client. > > > > > > > I see. I rather agree with your patch, it looks like semantic of > > giaddr was settled 20 years ago. >
I don't see this in the list of commits. Is there anything I can do to help this change along? ~joe _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel