Re: [Dnsmasq-discuss] bug: trunk DHCP offer/replies being ignored by some devices

2017-04-30 Thread Simon Kelley 
I just reverted the guilty change, so 2.77 should be OK now.


Cheers,

Simon.

On 08/04/17 00:55, Pedro MG Palmeiro wrote:
> The latest firmware for the printer is from 2015. This is one of those
> shared Epson/Fuji/Xerox models which I believe is entering EOL, since
> there is already another printer
> called M200 (Ecotank). Anyway, I'll report it.
> 
> Should the the implementation be correct in dnsmasq, then there will be
> more reports of this behavior from gateways implementing it, and that
> may move Epson into action.
> 
> Adding a mac exclude switch to dnsmasq is just marginally better than
> setting the printer IP manually, since both require intervention per device.
> 
> A switch disabling the whole implementation, or making it optional, thus
> reverting to the old behavior would be better if feasible, but I don't
> agree with removing it completely.
> 
> If nothing can be done, or be deemed unfeasible to be done, my opinion
> is that not much harm is done, since there is a way of getting things
> working (manual IP).
> 
> So, for me (3) it is.
> 
> Cheers.
> 
> On Fri, Apr 7, 2017 at 11:00 PM, Simon Kelley  > wrote:
> 
> On 06/04/17 14:01, Pedro MG Palmeiro wrote:
> > Dnsmasq trunk replies are being ignored by some devices, in my
> case, two
> > epson printers (AL-M200).
> > Dnsmasq 2.76 works fine.
> >
> > This could be related with
> > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit
> ;
> > =88a77a78ad27adc3ed87b7ee603643d26cb896ee
> >
> > Please refer to
> > https://bugs.lede-project.org/index.php?do=details_id=673
> 
> > for tcpdumps.
> >
> 
> But RFC 6842 assures us that no clients are broken by this change :)
> 
> The options here, as I see it are
> 
> 1) revert the change and don't support 6842
> 2) provide a way to disable the client-id reply for broken clients.
> 3) provide a flag to disable the client-id for all clients.
> 4) make the new behaviour optional, and provide a flag to enable it.
> 5) declare it No Our Problem and get the broken clients fixed.
> 
> 
> 5) is possible - have you talked to Epson? the AL-M200 looks like a
> current product, and likely has field-upgradable firmware.
> 
> 1) is not attractive.
> 
> 2) may be possible. There is already a config option to tell dnsmasq to
> ignore _incoming_ client-ids for a particular client, that could be
> extended to apply to _outgoing_ cones too.
> 
> Specifically, you'd need to add something like
> 
> dhcp-host=,id:*
> 
> to turn off this for just those machines.
> 
> 4) is not attractive.
> 
> I'm interested in peoples opinions; a flag to kill the new client-uid
> behaviour globally, or just for particular MAC/IP addresses, or based on
> a tag?
> 
> A pity, the original patch was so simple...
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> 
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
> 
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


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

Re: [Dnsmasq-discuss] bug: trunk DHCP offer/replies being ignored by some devices

2017-04-09 Thread Simon Kelley 
On 08/04/17 12:01, Floris Bos wrote:
> On 04/08/2017 12:00 AM, Simon Kelley wrote:
>>
>> But RFC 6842 assures us that no clients are broken by this change :)
>>
>> The options here, as I see it are
>>
>> 1) revert the change and don't support 6842
>> 2) provide a way to disable the client-id reply for broken clients.
>> 3) provide a flag to disable the client-id for all clients.
>> 4) make the new behaviour optional, and provide a flag to enable it.
>> 5) declare it No Our Problem and get the broken clients fixed.
> 
> What about only sending client-id back if chaddr is zeroed?
> 
> Isn't that the corner case 6842 is actually trying to fix?
> 
> ==
>In some cases, a client may not have a valid hardware address to
>populate the 'chaddr' field and may set the field to all zeroes. One
>such example is when DHCP is used to assign an IP address to a mobile
>phone or a tablet and where the 'chaddr' field is set to zero in DHCP
>request packets.
> ==
> 

A good suggestion. The bald assertion that DHCP-relays drop packets
without chaddrs in 6842 seems quite dodgy to me, why should they, unless
the chaddr is needed to return the reply to the client?


I'll go offline from here and talk to some DHCP people...

Cheers,

Simon.




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

Re: [Dnsmasq-discuss] bug: trunk DHCP offer/replies being ignored by some devices

2017-04-08 Thread Floris Bos 

On 04/08/2017 12:00 AM, Simon Kelley wrote:


But RFC 6842 assures us that no clients are broken by this change :)

The options here, as I see it are

1) revert the change and don't support 6842
2) provide a way to disable the client-id reply for broken clients.
3) provide a flag to disable the client-id for all clients.
4) make the new behaviour optional, and provide a flag to enable it.
5) declare it No Our Problem and get the broken clients fixed.


What about only sending client-id back if chaddr is zeroed?

Isn't that the corner case 6842 is actually trying to fix?

==
   In some cases, a client may not have a valid hardware address to
   populate the 'chaddr' field and may set the field to all zeroes. One
   such example is when DHCP is used to assign an IP address to a mobile
   phone or a tablet and where the 'chaddr' field is set to zero in DHCP
   request packets.
==


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] bug: trunk DHCP offer/replies being ignored by some devices

2017-04-08 Thread Floris Bos 

On 04/08/2017 10:29 AM, Kevin Darbyshire-Bryant wrote:



On 07/04/17 23:00, Simon Kelley wrote:

On 06/04/17 14:01, Pedro MG Palmeiro wrote:
Dnsmasq trunk replies are being ignored by some devices, in my case, 
two

epson printers (AL-M200).
Dnsmasq 2.76 works fine.

This could be related with
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;
=88a77a78ad27adc3ed87b7ee603643d26cb896ee


Has the 'could' been confirmed?  Otherwise the wrong problem is being 
fixed.




Please refer to
https://bugs.lede-project.org/index.php?do=details_id=673
for tcpdumps.



But RFC 6842 assures us that no clients are broken by this change :)

The options here, as I see it are

1) revert the change and don't support 6842
2) provide a way to disable the client-id reply for broken clients.
3) provide a flag to disable the client-id for all clients.
4) make the new behaviour optional, and provide a flag to enable it.
5) declare it No Our Problem and get the broken clients fixed.


For me: Option 2 - client specific fix for client specific bug.


Do keep in mind that the original RFC 2131 clearly says servers MUST NOT 
send the client id back though.
So is it actually a bug, if a client rejects an offer that simply does 
not conform to the spec at the time client was written?


I don't think it is reasonable to expect a vendor to release a firmware 
update because someone decided to change the specification later on...



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] bug: trunk DHCP offer/replies being ignored by some devices

2017-04-08 Thread Kevin Darbyshire-Bryant 



On 07/04/17 23:00, Simon Kelley wrote:

On 06/04/17 14:01, Pedro MG Palmeiro wrote:

Dnsmasq trunk replies are being ignored by some devices, in my case, two
epson printers (AL-M200).
Dnsmasq 2.76 works fine.

This could be related with
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;
=88a77a78ad27adc3ed87b7ee603643d26cb896ee


Has the 'could' been confirmed?  Otherwise the wrong problem is being fixed.



Please refer to
https://bugs.lede-project.org/index.php?do=details_id=673
for tcpdumps.



But RFC 6842 assures us that no clients are broken by this change :)

The options here, as I see it are

1) revert the change and don't support 6842
2) provide a way to disable the client-id reply for broken clients.
3) provide a flag to disable the client-id for all clients.
4) make the new behaviour optional, and provide a flag to enable it.
5) declare it No Our Problem and get the broken clients fixed.


For me: Option 2 - client specific fix for client specific bug.

Cheers,

Kevin

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

Re: [Dnsmasq-discuss] bug: trunk DHCP offer/replies being ignored by some devices

2017-04-07 Thread Pedro MG Palmeiro 
The latest firmware for the printer is from 2015. This is one of those
shared Epson/Fuji/Xerox models which I believe is entering EOL, since there
is already another printer
called M200 (Ecotank). Anyway, I'll report it.

Should the the implementation be correct in dnsmasq, then there will be
more reports of this behavior from gateways implementing it, and that may
move Epson into action.

Adding a mac exclude switch to dnsmasq is just marginally better than
setting the printer IP manually, since both require intervention per device.

A switch disabling the whole implementation, or making it optional, thus
reverting to the old behavior would be better if feasible, but I don't
agree with removing it completely.

If nothing can be done, or be deemed unfeasible to be done, my opinion is
that not much harm is done, since there is a way of getting things working
(manual IP).

So, for me (3) it is.

Cheers.

On Fri, Apr 7, 2017 at 11:00 PM, Simon Kelley 
wrote:

> On 06/04/17 14:01, Pedro MG Palmeiro wrote:
> > Dnsmasq trunk replies are being ignored by some devices, in my case, two
> > epson printers (AL-M200).
> > Dnsmasq 2.76 works fine.
> >
> > This could be related with
> > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;
> > =88a77a78ad27adc3ed87b7ee603643d26cb896ee
> >
> > Please refer to
> > https://bugs.lede-project.org/index.php?do=details_id=673
> > for tcpdumps.
> >
>
> But RFC 6842 assures us that no clients are broken by this change :)
>
> The options here, as I see it are
>
> 1) revert the change and don't support 6842
> 2) provide a way to disable the client-id reply for broken clients.
> 3) provide a flag to disable the client-id for all clients.
> 4) make the new behaviour optional, and provide a flag to enable it.
> 5) declare it No Our Problem and get the broken clients fixed.
>
>
> 5) is possible - have you talked to Epson? the AL-M200 looks like a
> current product, and likely has field-upgradable firmware.
>
> 1) is not attractive.
>
> 2) may be possible. There is already a config option to tell dnsmasq to
> ignore _incoming_ client-ids for a particular client, that could be
> extended to apply to _outgoing_ cones too.
>
> Specifically, you'd need to add something like
>
> dhcp-host=,id:*
>
> to turn off this for just those machines.
>
> 4) is not attractive.
>
> I'm interested in peoples opinions; a flag to kill the new client-uid
> behaviour globally, or just for particular MAC/IP addresses, or based on
> a tag?
>
> A pity, the original patch was so simple...
>
> Cheers,
>
> Simon.
>
>
>
>
>
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] bug: trunk DHCP offer/replies being ignored by some devices

2017-04-07 Thread Simon Kelley 
On 06/04/17 14:01, Pedro MG Palmeiro wrote:
> Dnsmasq trunk replies are being ignored by some devices, in my case, two
> epson printers (AL-M200).
> Dnsmasq 2.76 works fine.
> 
> This could be related with
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;
> =88a77a78ad27adc3ed87b7ee603643d26cb896ee
> 
> Please refer to
> https://bugs.lede-project.org/index.php?do=details_id=673
> for tcpdumps.
> 

But RFC 6842 assures us that no clients are broken by this change :)

The options here, as I see it are

1) revert the change and don't support 6842
2) provide a way to disable the client-id reply for broken clients.
3) provide a flag to disable the client-id for all clients.
4) make the new behaviour optional, and provide a flag to enable it.
5) declare it No Our Problem and get the broken clients fixed.


5) is possible - have you talked to Epson? the AL-M200 looks like a
current product, and likely has field-upgradable firmware.

1) is not attractive.

2) may be possible. There is already a config option to tell dnsmasq to
ignore _incoming_ client-ids for a particular client, that could be
extended to apply to _outgoing_ cones too.

Specifically, you'd need to add something like

dhcp-host=,id:*

to turn off this for just those machines.

4) is not attractive.

I'm interested in peoples opinions; a flag to kill the new client-uid
behaviour globally, or just for particular MAC/IP addresses, or based on
a tag?

A pity, the original patch was so simple...

Cheers,

Simon.








signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] bug: trunk DHCP offer/replies being ignored by some devices

2017-04-06 Thread Pedro MG Palmeiro 
Dnsmasq trunk replies are being ignored by some devices, in my case, two
epson printers (AL-M200).
Dnsmasq 2.76 works fine.

This could be related with
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;
=88a77a78ad27adc3ed87b7ee603643d26cb896ee

Please refer to
https://bugs.lede-project.org/index.php?do=details_id=673
for tcpdumps.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss