[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dhcp-workers
Subject:    Stefan Rompf: Re: "David W. Hankins": Linux BSD sockets.
From:       Michael Richardson <mcr () sandelman ! ottawa ! on ! ca>
Date:       2006-03-12 21:40:23
Message-ID: 15473.1142199623 () sandelman ! ottawa ! on ! ca
[Download RAW message or body]

Return-Path: stefan@loplof.de
Delivery-Date: Sun Mar 12 16:05:47 2006
Return-Path: <stefan@loplof.de>
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on 
	lox.sandelman.ottawa.on.ca
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=4.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.0
Received: from natfrord.rzone.de (natfrord.rzone.de [81.169.145.161])
	by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id k2CL5Vp17459
	for <mcr@sandelman.ottawa.on.ca>; Sun, 12 Mar 2006 16:05:31 -0500 (EST)
Received: from dose.hogan.de (p54B03D94.dip0.t-ipconnect.de [84.176.61.148])
	by post.webmailer.de (8.13.1/8.13.1) with ESMTP id k2CKpnZV014719;
	Sun, 12 Mar 2006 21:51:49 +0100 (MET)
From: Stefan Rompf <stefan@loplof.de>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Subject: Re: "David W. Hankins": Linux BSD sockets.
Date: Sun, 12 Mar 2006 21:50:56 +0100
User-Agent: KMail/1.8
Cc: netdev@vger.kernel.org
References: <13289.1142182233@sandelman.ottawa.on.ca>
In-Reply-To: <13289.1142182233@sandelman.ottawa.on.ca>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Disposition: inline
Message-Id: <200603122150.56148.stefan@loplof.de>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lox.sandelman.ottawa.on.ca id k2CL5Vp17459

Am Sonntag 12 März 2006 17:50 schrieb Michael Richardson:

> I recently got a bug in my ear to try and get multiple-dhclients to
> work on separate interfaces under Linux (a one-daemon-per-interface
> model).  Could use some advice from the linux masters (Jason, Andrew?)
> if you can spare some time for me.
>
> Another motivation is trying to kill our LPF support (switch to BSD
> sockets or similar - so all we have to do is DHCP).

Forget it. With my dhcpclient, I tried avoiding the raw socket first too, but 
both sending and receiving packets through the IP stack was not entirely 
successful.

You've already stumbled over issues receiving. At least, the bootp broadcast 
flag needs to be set because a packet destined to the card's MAC address, but 
not IP address is a target for forwarding. Even with broadcast, you can hit 
reverse path validation, you've seen the martian source logs. This can be 
configured with /proc/sys/net/ipv4/conf/*/rp_filter, but that's something a 
DHCP client should not mess with.

Sending is as problematic. You cannot send IP packets from an interface 
without legal address - the kernel will either use the address of another 
interface or just fail (funny thing learned: ifconfig ... 0.0.0.0 is 
different to ip addr dev ... flush)

I did not report these as bugs as I don't expect an IP stack to be able to 
handle an interface without valid address ;-) Now I use AF_PACKET/SOCK_DGRAM 
socket that hides layer 2 for receiving and sending broadcasts, and a UDP 
socket for unicasts, with SO_BINDTODEVICE. The later seems to fail with 
multiple clients, it seems binding to a device is not sufficient.

> Chiefly, to only construct the fallback interface once at least one
> interface assigned to the daemon's purview has acheived BOUND state,
> and to bind() the socket to the address assigned to that interface
> (which may mean having multiple 'fallback interfaces' if a daemon is
> being asked to process multiple physical interfaces).

Yes, that should work. dhcpclient takes the easy way out and sends it's 
unicasts as broadcast over the raw socket if it cannot open the UDP socket 
and bind it to a device. Something to fix for one of the next snapshots ;-)

Stefan

[prev in list] [next in list] [prev in thread] [next in thread]