I've been trying to get a FoG server to play with ClearOS. Fog worked great with a consumer router, but I'm struggling getting clear and fog to play nice. The fog server is intended to run on a ClearOS LAN subnet and use ClearOS dhcp, instead of its own dhcp. The expected configuration uses fog dnsmasq to broadcast tftp address, and while troubleshooting, I find a curious piece in the packets. ClearOS is broadcasting a nextserver call to itself, which seems to step on the FoG nextserver broadcast, (and any other server's dnsmasq) I would think. Thus, the TFTP broadcast from fog is overridden. Is this intentional or fixable? I did try using TFTP field in the GUI and it fails with a no media present error. I assume I could work with ClearOS DNSmasq further to get where I want, but this seems like a bug to me.
Attachments:
In DHCP Server
Share this post:
Responses (15)
-
Accepted Answer
-
Accepted Answer
Try to separate out in your mind the ClearOS api (webconfig) and dnsmasq. All the Webconfig does is add an option 66 line to a config file that is read by dnsmasq and then it reloads dnsmasq. Dnsmasq is then responsible for the contents of the DHCP replies to the client. Its responses are based entirely round the config files I mentioned. If you add a TFTP line in the webconfig the option 66 line appears in the config file. If you blank the line in the webconfig it option 66 line then disappears.
I've loaded up wireshark (I've never used it before). Adding option 66 in dnsmasq causes the "Server host name" to be populates in wireshark. It makes no difference to Next Server.
Can I suggest you post to the dnsmasq mailing list and see what they say, or perhaps your FoG server support? -
Accepted Answer
Nick Howitt wrote:
I am just hypothesizing that, perhaps with it not set, Wireshark is interpreting it as the router IP. The package we use comes directly unchanged from Centos and I think theirs comes directly from RedHat. The only things dnsmasq is then doing is set up in /etc/dnsmasq.conf and /etc/dnsmasq.d/*. If you use Gateway Management/DNSThingy, there is a chance they play with some options, but it is to do do with the DNS side and not the DHCP side.
I'm just using Wireshark to read the tcp dump. Try the tcpdump with the options I used, and see what you get? The Clear API would have to fiddle with next server to make the tftp bit work wouldn't it? Maybe it presets that and just adds the tftp line when needed. -
Accepted Answer
I am just hypothesizing that, perhaps with it not set, Wireshark is interpreting it as the router IP. The package we use comes directly unchanged from Centos and I think theirs comes directly from RedHat. The only things dnsmasq is then doing is set up in /etc/dnsmasq.conf and /etc/dnsmasq.d/*. If you use Gateway Management/DNSThingy, there is a chance they play with some options, but it is to do do with the DNS side and not the DHCP side. -
Accepted Answer
Nick Howitt wrote:
Is that with or without the TFTP option being set? Please also remember we are using standard dnsmasq and just populating it with various configs.
This is without setting tftp or any meddling in dnsmasq config files in clear. It's my understanding that this isn't standard, like something is injecting this setting. Will investigate. -
Accepted Answer
-
Accepted Answer
I'll add this more complete snip of the capture using "tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011"Attachments:
-
-
Accepted Answer
No mention of next server here either. I'm guessing it isn't captured by the dump. Wireshark sees it, as shown in initial post.
At this point my head is kid of swimming.
[root@Clear0 etc]# tcpdump -i enp17s0f0 port 67 or port 68 -e -n -vv
tcpdump: listening on enp17s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:24:14.566873 1c:6f:65:83:a0:95 > Broadcast, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 20, id 1, offset 0, flags [none], proto UDP (17), length 576)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 1c:6f:65:83:a0:95, length 548, xid 0x6783a095, secs 8, Flags [Broadcast] (0x8000)
Client-Ethernet-Address 1c:6f:65:83:a0:95
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Parameter-Request Option 55, length 36:
Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
IEN-Name-Server, Domain-Name-Server, RL, Hostname
BS, Domain-Name, SS, RP
EP, RSZ, TTL, BR
YD, YS, NTP, Vendor-Option
Requested-IP, Lease-Time, Server-ID, RN
RB, Vendor-Class, TFTP, BF
Option 128, Option 129, Option 130, Option 131
Option 132, Option 133, Option 134, Option 135
MSZ Option 57, length 2: 1260
GUID Option 97, length 17: 0.49.67.54.70.54.53.56.51.65.48.57.53.255.255.255.255
ARCH Option 93, length 2: 0
NDI Option 94, length 3: 1.2.1
Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
11:24:14.567192 00:15:17:c4:a9:92 > Broadcast, ethertype IPv4 (0x0800), length 366: (tos 0xc0, ttl 64, id 2182, offset 0, flags [none], pr oto UDP (17), length 352)
172.17.17.1.bootps > 255.255.255.255.bootpc: [bad udp cksum 0xbe6f -> 0x1006!] BOOTP/DHCP, Reply, length 324, xid 0x6783a095, secs 8, Flags [Broadcast] (0x8000)
Your-IP 172.17.17.191
Server-IP 172.17.17.1
Client-Ethernet-Address 1c:6f:65:83:a0:95
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.17.17.1
Lease-Time Option 51, length 4: 43200
RN Option 58, length 4: 21600
RB Option 59, length 4: 37800
Domain-Name Option 15, length 22: "xxx"
Domain-Name-Server Option 6, length 12: 172.17.17.16,172.17.17.17,172.17.17.1
Default-Gateway Option 3, length 4: 172.17.17.1
BR Option 28, length 4: 172.17.17.255
Subnet-Mask Option 1, length 4: 255.255.255.0
11:24:14.574606 00:15:5d:02:0a:16 > Broadcast, ethertype IPv4 (0x0800), length 374: (tos 0xc0, ttl 64, id 10347, offset 0, flags [none], p roto UDP (17), length 360)
172.17.17.82.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 332, xid 0x6783a095, secs 8, Flags [Broadcast] (0 x8000)
Server-IP 172.17.17.82
Client-Ethernet-Address 1c:6f:65:83:a0:95
file "undionly.kpxe"[|bootp]
11:24:14.575555 00:15:5d:02:0a:16 > Broadcast, ethertype IPv4 (0x0800), length 374: (tos 0xc0, ttl 64, id 10348, offset 0, flags [none], p roto UDP (17), length 360)
172.17.17.82.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 332, xid 0x6783a095, secs 8, Flags [Broadcast] (0 x8000)
Server-IP 172.17.17.82
Client-Ethernet-Address 1c:6f:65:83:a0:95
file "undionly.kpxe"[|bootp]
11:24:22.585346 1c:6f:65:83:a0:95 > Broadcast, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 20, id 2, offset 0, flags [none], proto UDP (17), length 576)
-
Accepted Answer
-
Accepted Answer
Just noting our posts crossed. Feel free to remove the TFTP setting then add another file in /etc/dnsmasq.d with:
in it. Note no quotes. Then restart dnsmasq and see what happens. When I looked around I found other references with examples of option 66 in quotes. I don't think I found any without them.dhcp-option=enp5s0,66,172.17.2.2 -
Accepted Answer
Booting a laptop without a TFTP server set gives the following tcpdump:[root@server ~]# tcpdump -i enp5s0 port 67 or port 68 -e -n -vv
tcpdump: listening on enp5s0, link-type EN10MB (Ethernet), capture size 262144 b ytes
15:19:37.324835 74:e5:43:2d:b1:b3 > Broadcast, ethertype IPv4 (0x0800), length 299: (tos 0x0, ttl 128, id 28608, offset 0, flags [none], proto UDP (17), length 285)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 74:e5:43:2d:b1:b3, length 257, xid 0x331c813, Flags [none] (0x0080)
Client-Ethernet-Address 74:e5:43:2d:b1:b3
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 74:e5:43:2d:b1:b3
Parameter-Request Option 55, length 2:
Subnet-Mask, Default-Gateway
15:19:37.324995 a0:36:9f:26:7c:52 > 74:e5:43:2d:b1:b3, ethertype IPv4 (0x0800), length 342: (tos 0xc0, ttl 64, id 31420, offset 0, flags [none], proto UDP (17), length 328)
172.17.2.1.bootps > 172.17.2.111.bootpc: [bad udp cksum 0x5dd8 -> 0x4508!] BOOTP/DHCP, Reply, length 300, xid 0x331c813, Flags [none] (0x0080)
Your-IP 172.17.2.111
Server-IP 172.17.2.1
Client-Ethernet-Address 74:e5:43:2d:b1:b3
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.17.2.1
Lease-Time Option 51, length 4: 86400
RN Option 58, length 4: 43200
RB Option 59, length 4: 75600
Default-Gateway Option 3, length 4: 172.17.2.1
Subnet-Mask Option 1, length 4: 255.255.255.0
15:19:37.346096 74:e5:43:2d:b1:b3 > Broadcast, ethertype IPv4 (0x0800), length 346: (tos 0x0, ttl 128, id 42036, offset 0, flags [none], proto UDP (17), length 332)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 74:e5:43:2d:b1:b3, length 304, xid 0xd6e27d9b, Flags [none] (0x0000)
Client-Ethernet-Address 74:e5:43:2d:b1:b3
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether 74:e5:43:2d:b1:b3
Requested-IP Option 50, length 4: 172.17.2.111
Hostname Option 12, length 6: "Laptop"
FQDN Option 81, length 9: "Laptop"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 14:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server
Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route
Classless-Static-Route-Microsoft, Option 252
15:19:37.378754 a0:36:9f:26:7c:52 > 74:e5:43:2d:b1:b3, ethertype IPv4 (0x0800), length 380: (tos 0xc0, ttl 64, id 31432, offset 0, flags [none], proto UDP (17), length 366)
172.17.2.1.bootps > 172.17.2.111.bootpc: [bad udp cksum 0x5dfe -> 0xe944!] BOOTP/DHCP, Reply, length 338, xid 0xd6e27d9b, Flags [none] (0x0000)
Your-IP 172.17.2.111
Server-IP 172.17.2.1
Client-Ethernet-Address 74:e5:43:2d:b1:b3
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 172.17.2.1
Lease-Time Option 51, length 4: 86400
RN Option 58, length 4: 43200
RB Option 59, length 4: 75600
Domain-Name Option 15, length 13: "howitts.co.uk"
FQDN Option 81, length 23: [SO] 255/255 "laptop.howitts.co.uk"
T252 Option 252, length 1: 10
Domain-Name-Server Option 6, length 4: 172.17.2.1
Netbios-Node Option 46, length 1: h-node
Netbios-Name-Server Option 44, length 4: 172.17.2.1
Default-Gateway Option 3, length 4: 172.17.2.1
Subnet-Mask Option 1, length 4: 255.255.255.0
Adding the TFTP server with a dummy IP gives the following tcpdump:15:32:09.254692 74:e5:43:2d:b1:b3 > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 128, id 42037, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 74:e5:43:2d:b1:b3, length 300, xid 0xade628b0, Flags [none] (0x0000)
Client-Ethernet-Address 74:e5:43:2d:b1:b3
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 74:e5:43:2d:b1:b3
Requested-IP Option 50, length 4: 172.17.2.111
Hostname Option 12, length 6: "Laptop"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 14:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server
Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route
Classless-Static-Route-Microsoft, Option 252
15:32:09.254913 a0:36:9f:26:7c:52 > 74:e5:43:2d:b1:b3, ethertype IPv4 (0x0800), length 355: (tos 0xc0, ttl 64, id 1403, offset 0, flags [none], proto UDP (17), length 341)
172.17.2.1.bootps > 172.17.2.111.bootpc: [bad udp cksum 0x5de5 -> 0x4fd8!] BOOTP/DHCP, Reply, length 313, xid 0xade628b0, Flags [none] (0x0000)
Your-IP 172.17.2.111
Server-IP 172.17.2.1
Client-Ethernet-Address 74:e5:43:2d:b1:b3
sname "172.17.2.2"[|bootp]
15:32:09.263084 74:e5:43:2d:b1:b3 > Broadcast, ethertype IPv4 (0x0800), length 352: (tos 0x0, ttl 128, id 42038, offset 0, flags [none], proto UDP (17), length 338)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 74:e5:43:2d:b1:b3, length 310, xid 0xade628b0, Flags [none] (0x0000)
Client-Ethernet-Address 74:e5:43:2d:b1:b3
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether 74:e5:43:2d:b1:b3
Requested-IP Option 50, length 4: 172.17.2.111
Server-ID Option 54, length 4: 172.17.2.1
Hostname Option 12, length 6: "Laptop"
FQDN Option 81, length 9: "Laptop"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 14:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server
Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route
Classless-Static-Route-Microsoft, Option 252
15:32:09.299702 a0:36:9f:26:7c:52 > 74:e5:43:2d:b1:b3, ethertype IPv4 (0x0800), length 380: (tos 0xc0, ttl 64, id 1440, offset 0, flags [none], proto UDP (17), length 366)
172.17.2.1.bootps > 172.17.2.111.bootpc: [bad udp cksum 0x5dfe -> 0x762b!] BOOTP/DHCP, Reply, length 338, xid 0xade628b0, Flags [none] (0x0000)
Your-IP 172.17.2.111
Server-IP 172.17.2.1
Client-Ethernet-Address 74:e5:43:2d:b1:b3
sname "172.17.2.2"[|bootp]
I can see the sname field popping up after adding the TFTP server. Where is the Next Server field you are talking about? I don't think I see it (but I've never done a tcpdump on dhcp before). -
Accepted Answer
When I set the tftp option in the clear gui, pxe boot breaks completely. It's strange. I get some "media not present" error. The whole option 66 line with the ip in quotes (in dhcp.conf) is very suspicious. None of the other lines get quotes. When leaving ClearOS alone and leaving the dnsmasq config to fog, it comes very close to working, except for this ClearOS self-call for nextserver. -
Accepted Answer
-
Accepted Answer
Hi Nick. I understand that I may be able to get this setup to work editing Clear. I noted that, and that's not really the issue I'm describing. Clear seems to be interfering with the functionality of dnsmasq in general, as it is making a nextserver call to itself. As I understand it, "nextserver" is there to allow another server to piggy-back on the dhcp broadcast for things like another pxe server on the network. It basically says, "after you talk to the dhcp server, now check here." There is a subtle beauty in each element standing alone and having limited dependencies on other servers, which is why I'd like fog's config specifics to reside on it. -
Accepted Answer
I know nothing about FOG servers so I don't really understand your issue, but I believe the TFTP field is only configures option 66 with an IP address which should point to your TFTP server.
If you want a more complex set up you can create your own conf file in /etc/dnsmasq.d called anything you want and use it for your custom configuration, e.g, for using dnsmasq's own built-in TFTP server.
I don't know about DHCP nextservers at all.
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »