[solved] Problem booting clients with PXE over Fortigate DHCP

[ipranger]

Hi, We changed to an fortigate 60C Wifi (v5.0,build0128 (GA)). So we would like to use dhcpservices too. But the problem is real hardwareclients do not boot with pxe. For the first, here is my configuration:

 config system dhcp server
     edit 1
         set default-gateway 192.168.1.254
         set interface " internal" 
             config ip-range
                 edit 1
                     set end-ip 192.168.1.150
                     set start-ip 192.168.1.53
                 next
             end
         set netmask 255.255.255.0
         set next-server 192.168.1.56
         set option1 67 ' 7078656c696e75782e30' 
             config reserved-address
                 edit 1
                     set ip 192.168.1.56
                     set mac 52:54:00:ca:79:ee
                 next
                 edit 2
                     set ip 192.168.1.150
                     set mac 00:14:5e:29:a3:80
                 next
                 edit 3
                     set ip 192.168.1.54
                     set mac 00:14:38:d7:bf:b3
                 next
                 edit 4
                     set ip 192.168.1.53
                     set mac 00:1f:1f:71:fa:f3
                 next
             end
         set dns-server1 192.168.1.254
         set dns-server2 8.8.8.8
         set dns-server3 80.120.17.70
     next
 end
 

Ok, listen, the crazy thing is with an virtualpxeclient it works perfectly. I' ve tested this with KVM and Virtualbox. And a real Hardware does not boot. I' ve changed to another TFTPserver and i' ve changed the hardware. But nothing helps. The message from Hardware is:

 ProxyDHCP services did not reply to request on port 4011
 

Before i upgrade to Forti version 5 i had the message " PXE Filename to long" ... Yes, i think this is really crazy. Why to this work with virtual machines? With another dhcpserver (for example on Ubuntu) it works with real hardware too. Thanks for help Greetings ipranger

[ipranger]

We added some bugreport #192750. Should be fixed next patch.

[Matthijs]

This is a confirmed bug that will be fixed in 5.0.2 It is scheduled to be released this week ;)

[Carl_Wallmark]

I think tomorrow

[lindblom]

Tomorrow or next week, either way it' s awesome!

[lindblom]

Hello! Follow-up: Just upgraded an 80C to test this with, and the result is... With FortiOS 5.0.2 build 0179 it does indeed work

[GusTech]

With FortiOS 5.0.2 build 0179 it does indeed work

TY 4 update!

[ipranger]

Hi :) I' ve done the Upgrade. But still it does not work. I get an diverent error message (pxe name to long). Can you tell me with what tftpserver and what software you have tested this please? With KVM it work fine, the same as before. Greetings and Thanks

[lindblom]

Hm okey. As I wrote earlier in this thread, it started working for me (again) using windows deployment services, on a windows server 2008. ...pxebooting a new Lenovo laptop.

[ipranger]

Has anyone tested this with an Linux?

[ipranger]

We sniffed with wireshark. Ok, the problem was: n the file " pxe_tftp_test_1" I can see 3 DHCP transactions: 08:00:27:e5:17:c3 (VirtualBox) - IP 192.168.1.57 - TFTP: - requests the size of " pxelinux.0" - gets the size of file 26773 - requests the file " pxelinux.0" with blocksize 1456 - correctly receives the file 00:01:2e:bc:c6:03 (PCPartner) - IP 192.168.1.59 - TFTP: - requests the size of " pxelinux.0\377\377\377\377..." - gets " File name too long" error 64:31:50:24:2c:f5 (HP) - 192.168.1.61 - TFTP: - requests the size of " pxelinux.0" - gets the size of file 26773 - requests file " \003" with blocksize 1456 - gets " File not found" error In " pxe_tftp_test_2" file there are three DHCP transactions, two of them are the same HP machine as in the first file, the third is 00:c0:9f:75:ba:c0 (Quanta) - IP 192.168.1.63 - TFTP: - requests the size of " pxelinux.0:\004" - gets " File not found" error - requests the file " pxelinux.0:\004" with blocksize 1456 - gets " File not found" error So we can see that all physical machines request the wrong file, but all of them have the file name corrupted differently. " \0377" is octal representation of 0xFF which is the character right after the boot file name in it' s DHCP ACK. " :\004" are also characters in the DHCP response to Quanta' s request. Based on the above, it seems that some PXE firmwares are expecting the zero character at the end of filename: " \000" . Having a look into RFC 2132, there explicitly written that this zero character should not be used: " " Options containing NVT ASCII data SHOULD NOT include a trailing NULL; however, the receiver of such options MUST be prepared to delete trailing nulls if they exist. The receiver MUST NOT require that a trailing null be included in the data. " " But you can try to modify the DHCP server configuration to include it:

 config system dhcp server 
 edit 2 
 set option1 67 ' 7078656c696e75782e3000'  
 end 
 

Yes, and this works fine. Really strange. Regards ipranger