netdev - Re: loopback IP alias breaks tftp?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1317989073.3207.10.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date:	Fri, 07 Oct 2011 14:04:33 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Josh Boyer <jwboyer@...hat.com>
Cc:	Joel Sing <jsing@...gle.com>, Julian Anastasov <ja@....bg>,
	netdev@...r.kernel.org
Subject: Re: loopback IP alias breaks tftp?

Le vendredi 07 octobre 2011 à 07:40 -0400, Josh Boyer a écrit :

> The original bug reporter explained the loopback testcase is simply a
> trivial example to illustrate the problem.  The real setup seems to be:
> 
> "I have a hardware (Dell PC) booting over the network with PXE, this
> hardware try to load it system from a tftp server. If I used the real
> ip of the tftp server I have no problem, if I used an alias I have the
> problem (I have to use an alias, because I have a Cluster).
> 
> What I think, the bios tftp client talk to the server with the IP alias
> but the server reply with the real IP and the client reject the reply."
> 
> So in this case, because the alias is being used in a cluster, should he
> also setup the local routing table as you suggested?
> 
> I apologize for my lack of depth here.  I'm at the moment somewhat of a
> go-between.  I do greatly appreciate the help!

Its a completely different problem IMHO : You describe a tftp server
bug.

Say your tftp server is multihomed with 3 different IPS : 

192.168.20.21, 192.168.20.22, 192.168.20.23

And tftp server listens to any address (UDP port 69) : 0.0.0.0:69

When receiving a request on 192.168.20.22, it should use same source
address, not let the system chose a "random or whatever policy" one.



So I would suggest to check/fix if TFTP server uses the correct socket
API to get both the client IP and its own IP in each UDP datagram

-> setsockopt(fd, IPPROTO_IP, &on, sizeof(on))

       IP_PKTINFO
              Pass  an  IP_PKTINFO  ancillary message that contains a pktinfo structure that supplies some
              information about the incoming packet.  This only works for datagram oriented sockets.   The
              argument  is a flag that tells the socket whether the IP_PKTINFO message should be passed or
              not.  The message itself can only be sent/retrieved as control message with a  packet  using
              recvmsg(2) or sendmsg(2).

                  struct in_pktinfo {
                      unsigned int   ipi_ifindex;  /* Interface index */
                      struct in_addr ipi_spec_dst; /* Local address */
                      struct in_addr ipi_addr;     /* Header Destination
                                                      address */
                  };

              ipi_ifindex  is  the unique index of the interface the packet was received on.  ipi_spec_dst
              is the local address of the packet and ipi_addr is the destination  address  in  the  packet
              header.  If IP_PKTINFO is passed to sendmsg(2) and ipi_spec_dst is not zero, then it is used
              as the local source address for the routing table lookup and for setting up IP source  route
              options.  When ipi_ifindex is not zero, the primary local address of the interface specified
              by the index overwrites ipi_spec_dst for the routing table lookup.



This permits tftp server to use the same "struct in_pktinfo" for replies, forcing a correct source address.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html