Re: RFC Remove classful causing incorrect routing behavior

[Andrey Borzenkov <arvidjaar@gmail.com>]

В Mon, 21 Apr 2014 15:56:07 +0000
"Mroczek, Joseph T" <joseph.t.mroczek@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.

PXE spec indeed mentions giaddr as possible source for gateway to
connect to TFTP server, without going into much details how stack
selects between multiple gateways if present. But grub does not call
PXE TFTP, right?

> 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.

>  with the additional condition that the gateway and boot server are on
>  different hosts. There may be some routers that will forward the
>  traffic back on the local subnet, but most routers do not do this. The
>  net result is grub fails to contact the boot server. I am not sure
>  what you mean by standard behavior. Mulitple Intel option ROMs (i386 &
>  EFI), broadcom option ROMs, gPXE, Microsoft WDS, and syslinux/pxelinux
>  all route properly for local boot servers when both netmask and
>  gateway are set. 

> 



> The only use cases I could see breaking with this change require two conditions, one of which I would be very surprised to see. The two conditions are that the boot server is on a remote network (not-common but does happen), and the DHCP server does not send a subnet mask in options (rare to non-existent.) Not sending a subnet mask in this day and age is arguably broken behavior. 
> 
> ~joe
> 
> 
> > > Thank you for any attention you can pay this matter.
> > >
> > > ~joe
> > >
> > >
> > > diff -Naur grub-2.02~beta2/grub-core/net/bootp.c grub-2.02~beta2-jtm-
> > clean/grub-core/net/bootp.c
> > > --- grub-2.02~beta2/grub-core/net/bootp.c	2013-12-24
> > 11:40:31.000000000 -0500
> > > +++ grub-2.02~beta2-jtm-clean/grub-core/net/bootp.c	2014-04-18
> > 20:38:05.858208600 -0400
> > > @@ -191,18 +227,6 @@
> > >    if (bp->gateway_ip)
> > >      {
> > >        grub_net_network_level_netaddress_t target;
> > > -      grub_net_network_level_address_t gw;
> > > -      char *rname;
> > > -
> > > -      target.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
> > > -      target.ipv4.base = bp->server_ip;
> > > -      target.ipv4.masksize = 32;
> > > -      gw.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
> > > -      gw.ipv4 = bp->gateway_ip;
> > > -      rname = grub_xasprintf ("%s:gw", name);
> > > -      if (rname)
> > > -	grub_net_add_route_gw (rname, target, gw);
> > > -      grub_free (rname);
> > >
> > >        target.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
> > >        target.ipv4.base = bp->gateway_ip;
> > >
> > > _______________________________________________
> > > Grub-devel mailing list
> > > Grub-devel@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/grub-devel
> > >
> > 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel