-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please add DHCP option 119 #35
Comments
Are you not looking for 'dns search suffix'?
Simon
…On Fri, 11 Aug 2023 at 17:46, Pieter Viljoen ***@***.***> wrote:
Please add DHCP option 119 for domain search, accompanies DHCP option 15.
[https://www.rfc-editor.org/rfc/rfc3397]
I am not sure how to interpret multiple strings as per RFC vs.
OptionFormat.str?
As FYI: In my environment the search domain typically just matches the
domain name. Some OS's (even some versions of Win11) ignore option 15 and
use option 119 for the default domain, which is how I ended up adding
option 119.
—
Reply to this email directly, view it on GitHub
<#35>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJCQ5PU3NBN4HB6QTTAOPMLXUZOVZANCNFSM6AAAAAA3NFC6RY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I think the main difficulty is compression: https://www.rfc-editor.org/rfc/rfc1035#section-4.1.4 Do you have any example packets with this option? |
The examples I saw use interface config as a string, and it works on Windows and Linux, so not sure the And comments in dnsmasq config: And from dhcpoptions docs:
This config on my Firewalla appliance and it works on Windows and Linux clients (I use numeric 119 and not
This is the capture from a Win11 client: > .\dhcptest-0.7-win64.exe --query
dhcptest v0.7 - Created by Vladimir Panteleev
https://github.com/CyberShadow/dhcptest
Run with --help for a list of command-line options.
Listening for DHCP replies on port 68.
Sending packet:
op=BOOTREQUEST chaddr=A0:C8:99:DE:24:E6 hops=0 xid=6A5F9469 secs=0 flags=8000
ciaddr=0.0.0.0 yiaddr=0.0.0.0 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file=
1 options:
53 (DHCP Message Type): discover
Received packet from 192.168.1.1:67:
op=BOOTREPLY chaddr=A0:C8:99:DE:24:E6 hops=0 xid=6A5F9469 secs=0 flags=8000
ciaddr=0.0.0.0 yiaddr=192.168.1.128 siaddr=192.168.1.1 giaddr=0.0.0.0 sname= file=
11 options:
53 (DHCP Message Type): offer
54 (Server Identifier): 192.168.1.1
51 (IP Address Lease Time): 86400 (1 day)
58 (Renewal (T1) Time Value): 43200 (12 hours)
59 (Rebinding (T2) Time Value): 75600 (21 hours)
1 (Subnet Mask): 255.255.255.0
28 (Broadcast Address Option): 192.168.1.255
119 (Unknown): 04 68 6F 6D 65 0C 69 6E 73 61 6E 65 67 65 6E 69 75 73 03 6E 65 74 00
15 (Domain Name): home.insanegenius.net
6 (Domain Name Server Option): 192.168.1.1
3 (Router Option): 192.168.1.1 |
From reading that section of RFC1035, it looks like the compression is optional (so a 7-bit string is always valid, but decoding may require implementing decompression). But also, I see now that the value itself is not just a string, but a list (or a hierarchy?) of length-prefixed strings. The example in RFC 3397 also shows an example of that format. I think it would also be the first option in dhcptest in which a single value can span and be represented by several occurrences of the option within a packet. In short, it's doable but needs some work. |
If I use the the jjordan test encoder, and I use the hex On the same page the encoding results in It would be good progress if you cover the basic cases, even if not all more complex cases. |
Please add DHCP option 119 for domain search, accompanies DHCP option 15.
[https://www.rfc-editor.org/rfc/rfc3397]
I am not sure how to interpret multiple strings as per RFC vs.
OptionFormat.str
?As FYI: In my environment the search domain typically just matches the domain name. Some OS's (even some versions of Win11) ignore option 15 and use option 119 for the default domain, which is how I ended up adding option 119.
The text was updated successfully, but these errors were encountered: