Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Floris Bos]

On 03/29/2017 07:43 PM, Chris Novakovic wrote:

+1 for a dhcp-delay setting, ideally per-MAC: the Ethernet adapters on
older RPi models (as well as the built-in wifi adapter on the RPi 3)
also use the b8:27:eb OUI, and this artificial delay oughtn't be applied
to them.


Note that if you are using dnsmasq as plain DHCP server to hand out IPs 
instead of for PXE booting, you will likely already have a 3 second 
delay in most cases while it performs a ping check to see if the IP it 
intends to hand out is really free.
If there is already such existing delay, the patch will not delay things 
further, so things are a little less dramatic than they may seem.


That said, will submit a patch that supports tags for consideration.


Yours sincerely,

Floris Bos


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Pali Rohár]

On Wednesday 29 March 2017 23:22:39 Eric Luehrsen wrote:
> On 03/29/2017 04:35 PM, Dan Sneddon wrote:
> > On 03/29/2017 10:43 AM, Chris Novakovic wrote:
> >> On 29/03/2017 18:13, Kurt H Maier wrote:
> >>> On Wed, Mar 29, 2017 at 02:48:48PM +0200, Floris Bos wrote:
>  The PXE boot firmware implementation of the Raspberry Pi 3
>  has a bug causing it to fail if it receives replies
>  instantly.
> >>>
> >>> Why not have a configurable dhcp-delay setting instead of putting
> >>> device-specific quirks into the source code of dnsmasq forever?
> >>
> >> +1 for a dhcp-delay setting, ideally per-MAC: the Ethernet adapters on
> >> older RPi models (as well as the built-in wifi adapter on the RPi 3)
> >> also use the b8:27:eb OUI, and this artificial delay oughtn't be applied
> >> to them.
> >
> > Another +1 for adding a dhcp-delay setting on a per-MAC basis.
> 
> PXE devices are limited. I guess in a way of thinking that is 
> intentionally so. A server side robustness action is a valid use case 
> consideration. I would suggest the "tag" option method. You can tag a 
> network if say a whole subnet was only to serve PXE security cameras. 
> You can tag a partial MAC (wildcard) to ID a manufacturer. Assign the 
> delay option to the tag. This is just like DHCP "need broadcast" and 
> other client-server quirks.

+1 for tag method.

-- 
Pali Rohár
pali.ro...@gmail.com

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Eric Luehrsen]

On 03/29/2017 04:35 PM, Dan Sneddon wrote:
> On 03/29/2017 10:43 AM, Chris Novakovic wrote:
>> On 29/03/2017 18:13, Kurt H Maier wrote:
>>> On Wed, Mar 29, 2017 at 02:48:48PM +0200, Floris Bos wrote:
 The PXE boot firmware implementation of the Raspberry Pi 3
 has a bug causing it to fail if it receives replies
 instantly.
>>>
>>> Why not have a configurable dhcp-delay setting instead of putting
>>> device-specific quirks into the source code of dnsmasq forever?
>>
>> +1 for a dhcp-delay setting, ideally per-MAC: the Ethernet adapters on
>> older RPi models (as well as the built-in wifi adapter on the RPi 3)
>> also use the b8:27:eb OUI, and this artificial delay oughtn't be applied
>> to them.
>
> Another +1 for adding a dhcp-delay setting on a per-MAC basis.

PXE devices are limited. I guess in a way of thinking that is 
intentionally so. A server side robustness action is a valid use case 
consideration. I would suggest the "tag" option method. You can tag a 
network if say a whole subnet was only to serve PXE security cameras. 
You can tag a partial MAC (wildcard) to ID a manufacturer. Assign the 
delay option to the tag. This is just like DHCP "need broadcast" and 
other client-server quirks.

-Eric

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Dan Sneddon]

On 03/29/2017 10:43 AM, Chris Novakovic wrote:
> On 29/03/2017 18:13, Kurt H Maier wrote:
>> On Wed, Mar 29, 2017 at 02:48:48PM +0200, Floris Bos wrote:
>>> The PXE boot firmware implementation of the Raspberry Pi 3
>>> has a bug causing it to fail if it receives replies
>>> instantly.
>>>
>>> As a workaround ensure there is a minimum delay of one
>>> second if the client is a Pi.
>>>
>>> On Linux it looks up the exact receive time of the UDP
>>> packet with the SIOCGSTAMP ioctl to prevent multiple
>>> delays if multiple packets come in around the same time,
>>> or if there already was a delay caused by a ping check.
>>
>>
>> Why not have a configurable dhcp-delay setting instead of putting
>> device-specific quirks into the source code of dnsmasq forever?
> 
> +1 for a dhcp-delay setting, ideally per-MAC: the Ethernet adapters on
> older RPi models (as well as the built-in wifi adapter on the RPi 3)
> also use the b8:27:eb OUI, and this artificial delay oughtn't be applied
> to them.
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

Another +1 for adding a dhcp-delay setting on a per-MAC basis.

There is a side-benefit that this would enable a form of HA where you
have two servers, and one is set to have a built-in delay in its
responses. This would allow the primary server to (nearly) always
respond first if up, and the secondary server would respond after a
delay in case the first server was down.

-- 
Dan Sneddon |  Senior Principal Software Engineer
dsned...@redhat.com |  redhat.com/openstack
dsneddon:irc|  @dxs:twitter

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Kurt H Maier]

On Wed, Mar 29, 2017 at 08:48:30PM +0200, Floris Bos wrote:
> > 
> > I'm not sure hardcoding an entire OUI is the right reaction to such
> > opposition.
> 
> So what do you propose that the reaction should be instead?

In your specific case, I would use netem [1] to introduce a delay to
incoming DHCP packets.  I dislike the idea of deliberately introducing
performance penalties to upstream software, and I think fixes like this
needlessly complicate things.  Broken hardware is a site-specific issue
and should be addressed in a site-specific manner.

khm

1 - https://wiki.linuxfoundation.org/networking/netem

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Floris Bos]

On 03/29/2017 07:49 PM, Kurt H Maier wrote:

On Wed, Mar 29, 2017 at 07:17:41PM +0200, Floris Bos wrote:

That was my first proposal.
But there was opposition against introducing extra options.

I'm not sure hardcoding an entire OUI is the right reaction to such

opposition.


So what do you propose that the reaction should be instead?


   I'm also wary about hardcoding the duration.


Was configurable in the original patch...


Yours sincerely,

Floris Bos


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Kurt H Maier]

On Wed, Mar 29, 2017 at 07:17:41PM +0200, Floris Bos wrote:
>
> That was my first proposal.
> But there was opposition against introducing extra options.
   
I'm not sure hardcoding an entire OUI is the right reaction to such 
opposition.  I'm also wary about hardcoding the duration.   
   
As it sits this patch is both too specific and too general.   
   
khm


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Chris Novakovic]

On 29/03/2017 18:13, Kurt H Maier wrote:
> On Wed, Mar 29, 2017 at 02:48:48PM +0200, Floris Bos wrote:
>> The PXE boot firmware implementation of the Raspberry Pi 3
>> has a bug causing it to fail if it receives replies
>> instantly.
>>
>> As a workaround ensure there is a minimum delay of one
>> second if the client is a Pi.
>>
>> On Linux it looks up the exact receive time of the UDP
>> packet with the SIOCGSTAMP ioctl to prevent multiple
>> delays if multiple packets come in around the same time,
>> or if there already was a delay caused by a ping check.
>
>
> Why not have a configurable dhcp-delay setting instead of putting
> device-specific quirks into the source code of dnsmasq forever?

+1 for a dhcp-delay setting, ideally per-MAC: the Ethernet adapters on
older RPi models (as well as the built-in wifi adapter on the RPi 3)
also use the b8:27:eb OUI, and this artificial delay oughtn't be applied
to them.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Floris Bos]

On 03/29/2017 07:13 PM, Kurt H Maier wrote:

On Wed, Mar 29, 2017 at 02:48:48PM +0200, Floris Bos wrote:

The PXE boot firmware implementation of the Raspberry Pi 3
has a bug causing it to fail if it receives replies
instantly.

As a workaround ensure there is a minimum delay of one
second if the client is a Pi.

On Linux it looks up the exact receive time of the UDP
packet with the SIOCGSTAMP ioctl to prevent multiple
delays if multiple packets come in around the same time,
or if there already was a delay caused by a ping check.


Why not have a configurable dhcp-delay setting instead of putting

device-specific quirks into the source code of dnsmasq forever?


That was my first proposal.
But there was opposition against introducing extra options.

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011336.html


Yours sincerely,

Floris Bos


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Kurt H Maier]

On Wed, Mar 29, 2017 at 02:48:48PM +0200, Floris Bos wrote:
> The PXE boot firmware implementation of the Raspberry Pi 3
> has a bug causing it to fail if it receives replies
> instantly.
>
> As a workaround ensure there is a minimum delay of one
> second if the client is a Pi.
>
> On Linux it looks up the exact receive time of the UDP
> packet with the SIOCGSTAMP ioctl to prevent multiple
> delays if multiple packets come in around the same time,
> or if there already was a delay caused by a ping check.
   
   
Why not have a configurable dhcp-delay setting instead of putting
device-specific quirks into the source code of dnsmasq forever?
   
khm

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Albert ARIBAUD]

Hi again,

Le Wed, 29 Mar 2017 17:24:45 +0200
Floris Bos  a écrit:

> Hi,
> 
> On 03/29/2017 05:02 PM, Albert ARIBAUD wrote:
> > Le Wed, 29 Mar 2017 14:48:48 +0200
> > Floris Bos  a écrit:
> >  
> >> The PXE boot firmware implementation of the Raspberry Pi 3
> >> has a bug causing it to fail if it receives replies
> >> instantly.
> >>
> >> As a workaround ensure there is a minimum delay of one
> >> second if the client is a Pi.
> >>
> >> On Linux it looks up the exact receive time of the UDP
> >> packet with the SIOCGSTAMP ioctl to prevent multiple
> >> delays if multiple packets come in around the same time,
> >> or if there already was a delay caused by a ping check.  
> > Just a side question: can't / won't the boot firmware be fixed?  
> 
> There is a fix.
> However that requires sticking a SD card with the newer boot firmware
> in the Pi, and leaving it in permanently.
> 
> To be able to PXE boot without SD card, the firmware in the ROM of
> the SoC has to be used, which is not reflashable, and -at least for
> the devices currently out there- comes with this bug.

Oh, OK, so that's not an upgradable firmware, that's the ROM boot. Pity.

Thanks for the clarification!

> Yours sincerely,
> 
> Floris Bos

Amicalement,
-- 
Albert.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Floris Bos]

Hi,

On 03/29/2017 05:02 PM, Albert ARIBAUD wrote:

Le Wed, 29 Mar 2017 14:48:48 +0200
Floris Bos  a écrit:


The PXE boot firmware implementation of the Raspberry Pi 3
has a bug causing it to fail if it receives replies
instantly.

As a workaround ensure there is a minimum delay of one
second if the client is a Pi.

On Linux it looks up the exact receive time of the UDP
packet with the SIOCGSTAMP ioctl to prevent multiple
delays if multiple packets come in around the same time,
or if there already was a delay caused by a ping check.

Just a side question: can't / won't the boot firmware be fixed?


There is a fix.
However that requires sticking a SD card with the newer boot firmware in 
the Pi, and leaving it in permanently.


To be able to PXE boot without SD card, the firmware in the ROM of the 
SoC has to be used, which is not reflashable, and -at least for the 
devices currently out there- comes with this bug.




Yours sincerely,

Floris Bos

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Albert ARIBAUD]

Hi,

Le Wed, 29 Mar 2017 14:48:48 +0200
Floris Bos  a écrit:

> The PXE boot firmware implementation of the Raspberry Pi 3
> has a bug causing it to fail if it receives replies
> instantly.
> 
> As a workaround ensure there is a minimum delay of one
> second if the client is a Pi.
> 
> On Linux it looks up the exact receive time of the UDP
> packet with the SIOCGSTAMP ioctl to prevent multiple
> delays if multiple packets come in around the same time,
> or if there already was a delay caused by a ping check.

Just a side question: can't / won't the boot firmware be fixed?

Amicalement,
-- 
Albert.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Floris Bos]

The PXE boot firmware implementation of the Raspberry Pi 3
has a bug causing it to fail if it receives replies
instantly.

As a workaround ensure there is a minimum delay of one
second if the client is a Pi.

On Linux it looks up the exact receive time of the UDP
packet with the SIOCGSTAMP ioctl to prevent multiple
delays if multiple packets come in around the same time,
or if there already was a delay caused by a ping check.

Signed-off-by: Floris Bos 
---
 src/dhcp.c|  19 +++
 src/dnsmasq.c | 102 +++---
 src/dnsmasq.h |   1 +
 3 files changed, 81 insertions(+), 41 deletions(-)

diff --git a/src/dhcp.c b/src/dhcp.c
index 08952c8..203d9d5 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -356,6 +356,25 @@ void dhcp_packet(time_t now, int pxe_fd)
 #ifdef HAVE_SOCKADDR_SA_LEN
   dest.sin_len = sizeof(struct sockaddr_in);
 #endif
+
+  if (mess->htype == ARPHRD_ETHER && mess->hlen == ETHER_ADDR_LEN &&
+  mess->chaddr[0] == 0xB8 && mess->chaddr[1] == 0x27 && mess->chaddr[2] == 
0xEB)
+{
+  /* Raspberry Pi 3 boot firmware has a bug in which it fails if it 
receives DHCP
+ replies instantly. As a workaround ensure there is a delay of at 
least a second */
+
+  int starttime = now;
+#ifdef HAVE_LINUX_NETWORK
+  struct timeval tv;
+
+  /* Use timestamp of the UDP packet received as start time for delay */
+  if (ioctl(fd, SIOCGSTAMP, ) == 0)
+{
+  starttime = tv.tv_sec;
+}
+#endif
+  delay_dhcp(starttime, 1, -1, 0, 0);
+}
   
   if (pxe_fd)
 { 
diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index d2cc7cc..6ae8296 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -1747,29 +1747,15 @@ int icmp_ping(struct in_addr addr)
 {
   /* Try and get an ICMP echo from a machine. */
 
-  /* Note that whilst in the three second wait, we check for 
- (and service) events on the DNS and TFTP  sockets, (so doing that
- better not use any resources our caller has in use...)
- but we remain deaf to signals or further DHCP packets. */
-
-  /* There can be a problem using dnsmasq_time() to end the loop, since
- it's not monotonic, and can go backwards if the system clock is
- tweaked, leading to the code getting stuck in this loop and
- ignoring DHCP requests. To fix this, we check to see if select returned
- as a result of a timeout rather than a socket becoming available. We
- only allow this to happen as many times as it takes to get to the wait 
time
- in quarter-second chunks. This provides a fallback way to end loop. */ 
-
-  int fd, rc;
+  int fd;
   struct sockaddr_in saddr;
   struct { 
 struct ip ip;
 struct icmp icmp;
   } packet;
   unsigned short id = rand16();
-  unsigned int i, j, timeout_count;
+  unsigned int i, j;
   int gotreply = 0;
-  time_t start, now;
 
 #if defined(HAVE_LINUX_NETWORK) || defined (HAVE_SOLARIS_NETWORK)
   if ((fd = make_icmp_sock()) == -1)
@@ -1799,14 +1785,46 @@ int icmp_ping(struct in_addr addr)
   while (retry_send(sendto(fd, (char *), sizeof(struct icmp), 0, 
   (struct sockaddr *), sizeof(saddr;
   
-  for (now = start = dnsmasq_time(), timeout_count = 0; 
-   (difftime(now, start) < (float)PING_WAIT) && (timeout_count < PING_WAIT 
* 4);)
+  gotreply = delay_dhcp(dnsmasq_time(), PING_WAIT, fd, addr.s_addr, id);
+
+#if defined(HAVE_LINUX_NETWORK) || defined(HAVE_SOLARIS_NETWORK)
+  while (retry_send(close(fd)));
+#else
+  opt = 1;
+  setsockopt(fd, SOL_SOCKET, SO_RCVBUF, , sizeof(opt));
+#endif
+
+  return gotreply;
+}
+
+int delay_dhcp(time_t start, int sec, int fd, uint32_t addr, unsigned short id)
+{
+  /* Delay processing DHCP packets for "sec" seconds counting from "start".
+ If "fd" is not -1 it will stop waiting if an ICMP echo reply is received
+ from "addr" with ICMP ID "id" and return 1 */
+
+  /* Note that whilst waiting, we check for
+ (and service) events on the DNS and TFTP  sockets, (so doing that
+ better not use any resources our caller has in use...)
+ but we remain deaf to signals or further DHCP packets. */
+
+  /* There can be a problem using dnsmasq_time() to end the loop, since
+ it's not monotonic, and can go backwards if the system clock is
+ tweaked, leading to the code getting stuck in this loop and
+ ignoring DHCP requests. To fix this, we check to see if select returned
+ as a result of a timeout rather than a socket becoming available. We
+ only allow this to happen as many times as it takes to get to the wait 
time
+ in quarter-second chunks. This provides a fallback way to end loop. */
+
+  int rc, timeout_count;
+  time_t now;
+
+  for (now = dnsmasq_time(), timeout_count = 0;
+   (difftime(now, start) <= (float)sec) && (timeout_count < sec * 4);)
 {
-  struct sockaddr_in faddr;
-  socklen_t len = sizeof(faddr);
-  
   poll_reset();
-  poll_listen(fd, POLLIN);
+