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

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

Please refer to
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

Reply via email to