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

Discussion:

Pedro MG Palmeiro

2017-04-06 13:01:33 UTC

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&task_id=673
for tcpdumps.

Simon Kelley

2017-04-07 22:00:11 UTC

Permalink

Post by 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&task_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=<MAC address of printer>,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.

Pedro MG Palmeiro

2017-04-07 23:55:42 UTC

Permalink

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.

Post by Simon Kelley

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=<MAC address of printer>,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
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Simon Kelley

2017-04-30 17:24:47 UTC

Permalink

I just reverted the guilty change, so 2.77 should be OK now.

Cheers,

Simon.

Post by 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.

Post by Pedro MG Palmeiro
Dnsmasq trunk replies are being ignored by some devices, in my

case, two

Post by Pedro MG Palmeiro
epson printers (AL-M200).
Dnsmasq 2.76 works fine.
This could be related with
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit

<http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit>;

Post by Pedro MG Palmeiro
=88a77a78ad27adc3ed87b7ee603643d26cb896ee
Please refer to
https://bugs.lede-project.org/index.php?do=details&task_id=673

<https://bugs.lede-project.org/index.php?do=details&task_id=673>

Post by Pedro MG Palmeiro
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=<MAC address of printer>,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
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
<http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss>
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Kevin Darbyshire-Bryant

2017-04-08 08:29:05 UTC

Permalink

Post by Simon Kelley

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

Post by Simon Kelley

Post by Pedro MG Palmeiro
Please refer to
https://bugs.lede-project.org/index.php?do=details&task_id=673
for tcpdumps.

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

Cheers,

Kevin

Floris Bos

2017-04-08 10:56:39 UTC

Permalink

Post by Kevin Darbyshire-Bryant

Post by Simon Kelley

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

Post by Simon Kelley

Post by Pedro MG Palmeiro
Please refer to
https://bugs.lede-project.org/index.php?do=details&task_id=673
for tcpdumps.

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

Floris Bos

2017-04-08 11:01:40 UTC

Permalink

Post by Simon Kelley
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

Simon Kelley

2017-04-09 20:46:12 UTC

Permalink

Post by Floris Bos

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.