Is it possible to connect to the Fog server remotely?
-
Hi,
I’m using the fog server for twee weeks now. Everything works perfect in the same subnet. Now I want to deploy an image to a remote client.
All my locations are connected to each other with site-tot-site VPN of Meraki. I use the built-in DHCP service from the Meraki security appliane. I’ve set the boot next server and tftp option (66) value to the IP address of the Ubuntu FOG server. i’ve defined also the boot filename: undionly.kpxe
I can ping the FOG server from the remote client.
I get this error:
PXE-32: TFTP open TimeoutWhat am I overlooking?
thx
-
@pjb1983 Well I have success, but still confused why the instructions were wrong. For background the tftp service can be managed by xinetd (normal) but it can also be launch by systemctl directly. It appears with ubuntu 20.04 both methods are setup but only the service route is configured to run.
So exit /etc/default/tftpd-hpa
Make the tftp options look like this:
TFTP_OPTIONS="-s --blocksize 1368"
Once that is done restart the tftp service
sudo systemctl restart tftpd-hpa
Looking at the pcap I see it working as intended (may not be fixing your problem but the block site being adjusted according to the settings).
I can see the client asking for a 1468 block size. The tftp server saying ok but the block site is 1368. Then it sends only 1368 bytes at a time.
So why 1368. That is the mtu 1400 - 32 bytes for the ethernet header == 1368.
-
@pjb1983 The problem may be in the meraki. Typically we find that router’s do some pretty strange things when they provide dhcp services.
If this happens at the HQ you can use the fog server to debug this issue, at the remote location you will need someone that can run wireshark on a computer on the same subnet as the pxe booting computer. Use the capture filter of
port 67 or port 68
in wireshark.In the wireshark packet capture look at the OFFER packet from your dhcp server. In that OFFER packet in the ethernet header it should list the {next-server} as the IP address of the fog server (sometimes we find the routers will put their IP address here even if you program a different next server) and {boot-file} as undionly.kpxe also these values should appear in dhcp options 66 and 67. The values in the dhcp header is for the bootp protocol and in dhcp options for dhcp boot. If these values are set then upload the pcap file to a file share site and post the link here. One of us will take a look at it. There are some other strangeness that is a bit complicated to explain.
-
@pjb1983 said in Is it possible to connect to the Fog server remotely?:
I use the built-in DHCP service from the Meraki security appliane.
Does it provide a router/gateway IP as well for the clients to connect to your FOG server across the VPN?
-
@sebastian-roth thx for your reply.
The Meraki security appliance provide ip addresses and a gateway for that perticular site (school). -
@george1421 thx for the reply.
I’ll run wireshark asap and send the link to the pcap file. -
I think the UDP request had a bad length?
What can i do about it?reading from file -, link-type EN10MB (Ethernet)
13:02:42.546737 ARP, Request who-has 192.168.5.121 tell 192.168.5.1, length 28
13:02:42.547604 ARP, Reply 192.168.5.121 is-at 00:15:5d:00:fc:09, length 46
13:02:47.831592 IP 95.0.0.85.59214 > 192.168.5.121.2071: UDP, bad length 1460 > 1400
13:02:47.831592 IP 95.0.0.85 > 192.168.5.121: ip-proto-17
13:02:57.548243 ARP, Request who-has 192.168.5.121 tell 192.168.5.1, length 28
13:03:04.618441 ARP, Request who-has 192.168.5.1 tell 192.168.5.121, length 46
13:03:04.618441 ARP, Reply 192.168.5.1 is-at e0:55:3d:8f:6e:50, length 28
13:03:04.625881 IP 192.168.5.121.2070 > 95.0.0.85.69: 30 RRQ “undionly.kpxe” octet tsize 0
13:03:04.650645 IP 95.0.0.85.48771 > 192.168.5.121.2070: UDP, length 14
13:03:04.651880 IP 192.168.5.121.2070 > 95.0.0.85.48771: UDP, length 17
13:03:04.667062 IP 192.168.5.121.2071 > 95.0.0.85.69: 35 RRQ “undionly.kpxe” octet blksize 1456
13:03:04.692814 IP 95.0.0.85.52966 > 192.168.5.121.2071: UDP, length 15
13:03:04.693826 IP 192.168.5.121.2071 > 95.0.0.85.52966: UDP, length 4
13:03:04.718623 IP 95.0.0.85.52966 > 192.168.5.121.2071: UDP, bad length 1460 > 1400
13:03:04.718623 IP 95.0.0.85 > 192.168.5.121: ip-proto-17
13:03:05.719924 IP 95.0.0.85.52966 > 192.168.5.121.2071: UDP, bad length 1460 > 1400
13:03:05.719924 IP 95.0.0.85 > 192.168.5.121: ip-proto-17
13:03:07.721833 IP 95.0.0.85.52966 > 192.168.5.121.2071: UDP, bad length 1460 > 1400
13:03:07.721833 IP 95.0.0.85 > 192.168.5.121: ip-proto-17
13:03:11.726666 IP 95.0.0.85.52966 > 192.168.5.121.2071: UDP, bad length 1460 > 1400
13:03:11.726666 IP 95.0.0.85 > 192.168.5.121: ip-proto-17
13:03:12.550408 ARP, Request who-has 192.168.5.121 tell 192.168.5.1, length 28
13:03:12.551594 ARP, Reply 192.168.5.121 is-at 00:15:5d:00:fc:09, length 46
13:03:19.731344 IP 95.0.0.85.52966 > 192.168.5.121.2071: UDP, bad length 1460 > 1400
13:03:19.731344 IP 95.0.0.85 > 192.168.5.121: ip-proto-17
13:03:27.552009 ARP, Request who-has 192.168.5.121 tell 192.168.5.1, length 28
13:03:27.553072 ARP, Reply 192.168.5.121 is-at 00:15:5d:00:fc:09, length 46 -
@pjb1983 What is your MTU on your VPN link? Would it happen to be 1400?
-
@pjb1983 said in Is it possible to connect to the Fog server remotely?:
UDP, bad length 1460 > 1400
To me this looks like a window size/MTU issue on first sight. You can test the window size/MTU in the VPN tunning using ping ICMP packets like this - using your FOG server IP instead of
x.x.x.x
:- Linux:
ping -s 1300 -c 8 -M do x.x.x.x ping -s 1500 -c 8 -M do x.x.x.x
- Windows:
ping -l 1300 -n 8 -f x.x.x.x ping -l 1500 -n 8 -f x.x.x.x
My guess is the 1300 byte pings will go through but not the 1500 byte ones. You can play with those numbers to see which MTU works.
Though this doesn’t solve your issue as you cannot tell iPXE to use a smaller MTU. You need to talk to you network engineers to set framenting and MTU correctly to packets won’t get truncated.
-
@sebastian-roth hi thx for your reply.
the support on this forum is incredible.I’ve done a ping with 1300 packet size -> No problem
1500 packet size -> Packet need to be fragmented but DF set.I’ll search on my Meraki security appliance to increase the packet size.
Does this have some consequences for my network performance? -
@george1421 thx for your reply.
the support on this forum is incredible.I’ve done a ping with 1300 packet size -> No problem
1500 packet size -> Packet need to be fragmented but DF set.I’ll search on my Meraki security appliance to increase the packet size.
Does this have some consequences for my network performance? -
@pjb1983 Try the same test with a packet size of 1461
If we find that the MTU is 1400 we can set the tftp block size just a bit smaller so the packets don’t fragment.
What host OS is your FOG server using?
-
This post is deleted! -
@george1421 the max MTU size is 1404.
I’ve installed the FOG server on a Linux Ubuntu. -
@george1421 said in Is it possible to connect to the Fog server remotely?:
If we find that the MTU is 1400 we can set the tftp block size just a bit smaller so the packets don’t fragment.
That would get you past the TFTP part but it would fail downloading the kernel and init over HTTP then I suppose.
-
-
@sebastian-roth thx for your reply, but i doesn’t have a CLI on the Meraki Firewall. I have to contact support i guess.
-
@sebastian-roth I think our only option is to handle this on the tftp server size. I think the issue is packet fragmentation over UDP. I think we can set a maximum block size for the tftp server. What we need to do is set it at -64b from the MTU. I did find an example of it here: https://askubuntu.com/questions/644031/tftpd-hpa-how-can-i-set-blksize-option but I don’t know if ubuntu uses xinetd or something else.
@pjb1983 What version number of ubuntu? 20.04?
-
Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
Release: 20.04 -
@pjb1983 So following the link I provided did you try to reduce the maximum packet size to something below 1400 (the mtu)? Something like 1385 would be a start.
-
@george1421 i’ve changed the block size and rebooted the device.
But that did not solve the problem.
If i ask meraki support to increase the MTU for the site-to-site VPN, will that solve it?