Hi
How Can Using a Mikrotik router to PXE Boot?
Thank you
- setup DHCP server with the required options for your client
- add storage to your router for the required bootfiles (USB stick, SD card, M.2 card, whatever fits your router)
- put required bootfiles on the storage
- configure TFTP service with these files
I did it
But Error Number 0 is displayed in the Mikrotik log!
Hello,
Really interested in a solution. Trying to setup a PXE boot server. For initial testing Iâve setup a standalone network on a CCR1009. OS 6.40.8.
4 ports in a bridge to a DHCP server for a single LAN 192.168.0.0/24. DHCP lease scope 192.168.0.10-50. Options set for PXE boot, but this doesnât really matter yet since Iâm first just trying to get the tftp to work⌠Thereâs no firewall or routing.
Used the CCR to format an SD card fat32. Used the FTP protocol to copy the files from another working PXE server. The files are located in disk1/tftpboot . (again need to focus on tftp first)
Iâve used several dozen versions of the syntax to setup the tftp server. (Also MS Windows native tftp client, and a third party download).
/ip tftp add allow-rollover=yes real-filename=disk1/tftpboot/ req-filename=.*
Just to try and get some success I tried
/ip tftp add allow-rollover=yes real-filename=disk1/tftpboot/pxelinux.0 req-filename=pxelinux.0
Sometimes I specify the 192.168.0.0/24 for allowed. Sometimes I specify 0.0.0.0 Most of the time I leave this blank.
There are three resultâŚ
ERROR code;0 string:permission denied!
or
ERROR code:1 string: file no found (typically when I deliberately GET something invalid like a file I know isnât there)
ERROR code: 8 (no other text after this. (This occurs when I boot a NUC on this LAN, which indicates DHCP is working.).
When I specify a req-filename (specific or wildcard) the tftp GET fails immediately (usually with permission denied)
If I donât specify any req-filename the GET command has to time out or exhaust all retries.
Ultimately I would like a blank (or wildcard) req-filename parameter, and a real-filename parameter that sets disk1/tftpboot folder as the TFTP rootâŚ
This shouldnât be hard.
Anyone out there have any success with this.
Thanks
Kevin
Well, I consider it brave to try that. Good luck!
I have some experience with making a PXE server work, to install Windows from the network starting with a PXE
boot (and then starting a dialog with pxelinux, user selects and enters some options, finally setup is loaded and started).
This all without using Microsoftâs tools that work only on Windows Server (which we donât have).
I got it all working (on a Linux server) but there so many small details and tricks that I would not even think of implementing
this on RouterOSâŚ
When you want to use it to install Windows I also wonder how you implement the Boot Information Negotiation Layer?
(I use a Python program called binlsrv2.py for that, but I would not know how to do that on RouterOS)
Easy solution: do it on a Raspberry Pi.
Still not working in ROS 7.10. The error is still the same âpermission denied!â, in the log it appears as:
ERROR code:0 string:permission denied!
If i increase the logging to DEBUG, an additional line appears before:
requested file(binary): pxeboot access: denied
this is strange as there is no permission setting in the router.
I i use a different external tftp server there is no problem to get the boot file, but this SHOULD work on ROS.
I tried removing the IP address parameter as this is like an ACL, but now the error is: Error 8 (no more info)
tftp error code explained:
hope this helps.
/ip dhcp-server option
add code=66 name=boot-server value="IP_of_PXE_Server"
add code=67 name=boot-file value="pxelinux.0"
Hello all,
I would like to contribute to this discussion what it is I found necessary to get TFTP network boot to work for those struggling. I hope this helps out.
Best
As a foundation, I am using a server w/ Proxmox 8.0.4. Iâve set up a LXC container running Docker and the netboot.xyz image to serve as my TFTP Server. Then I can configure a VM to network boot. It works just as well for bare metal hardware client.
For reference to the netboot.xyz: Linuxserver.io
RouterOS Config:
As @jonnes86 pointed out, you need to set some DHCP Options. Notice, though, you have to be specific in the value formats or RouterOS will complain itâs not a valid entry with
"... Unknown data type"
Notice the double quote around a single quoted string. You then configure an Option Set to include both of the Options defined. Then, you need to update one, any or all of your Networks to include a Next Server, which points to your PXE server IP and select the DHCP Option Set you configured. Alternatively, you can skip the Option Set and select the DHCP Options themselves. I donât understand why itâs necessary to select a Next Server when itâs already been defined in an Option Set and by virtue of the fact that youâve set the DHCP Open Set (or DHCP Options) it should already know youâre configuring the Network to point to a TFTP Server, but oh well.
CLI method:
/ip dhcp-server option
add code=66 name=pxe-boot-server value="'10.13.37.113'"
add code=67 name=boot-file value="'netboot.xyz.kpxe'"
/ip dhcp-server option sets
add name=NetworkBoot options=pxe-boot-server,boot-file
Set the needed changes to the network(s) entry to include next-server and dhcp-option-set (or dhcp-option alternatively)
/ip dhcp-server network
add address=10.13.37.0/24 dhcp-option-set=NetworkBoot dns-server=10.0.2.11,10.0.2.12,1.1.1.1 gateway=10.13.37.1 \
next-server=10.13.37.113
GUI Method:
I seem to be having a similar issue. My router is set up the way itâs described here and yet, I get:
Start PXE over IPv4.
Station IO address is 172.16.0.9
Server IP address is 172.16.0.13
NBP filename is netboot.xyz.kpxe â here it adds an âyâ with umlauts that I am unable to retype here (see screenshot)⌠why???
NBP filesize is 0 Bytes
PXE-E23: Client received TFTP error from server
What am I doing wrong?
Any ideas are more than welcome!!
yet no y with umlauts in the config:
Did you try from the CLI to set the DHCP Option? I suppose itâs possible winbox/webfig used ßľsmartquoteß´ or some unknown Windows locale/code-page/keyboard thing in winboxâŚ
This will explicitly update any existing entry, if any unicode was present the CLI will strip it.
/ip dhcp-server option set [find code=67 name=boot-file] value="'netboot.xyz.kpxe'"
â (apostrophe) in AltCODE is entered as 0255 (4 digits) but German Ăż is Unicode 00FF so IMHO if there is an apostrophe in the filename then it becomes y umlat in Unicode as 255 = 0xFF and 0 is just 0. Seems that it could be an error but maybe the âconsumerâ side misunderstands the received data.
Iâve set up everything from the CLI originally, I just did the screenshots from the GUI.
I thought about that as the y with umlaut is Alt-0255 as Iâve learned 
Still, it seems as itâs not finding the appropriate file (length = 0). What could be wrong?
Not to mention that based on the matchers, the selected file should be the efi file, not the kpxeâŚ
Iâm redoing the whole config based on a working example⌠weâll see.
Ok, well the error is still the same with the brand new config. The only thing that is seemingly working now is that the matcher finally selects the right file so the error is now:
Iâm really lost.
Client is a DELL PowerEdge R720⌠maybe that is the culprit?
Looks like if I create a new VM on my Proxmox server and set it to netboot with SeaBIOS (not uefi), that works.
So the question I guess becomes why the DELL is refusing to netboot?
Sorry for being this problematic 
Semi-random thought, but do you really need a âmultidotâ filename?
I know that the (good olâ) â90âs are long gone, but (still good olâ) 8.3 filename can some times help.
Only for the record, in the (again good olâ) days of BartPe, XP USB booting, etc. it was a common saying âoh noes, itâs a Dell!â as Dell PCâs had their own non- standard behaviours both at BIOS and Windows drivers levels.
The strange y can Indeed be a parsing error of some kind of the single quote/apostroph, but I have no idea if there Is a way to workaround It.
I actually didnât touch the filename, thatâs literally the default in netboot.xyz
It works in UEFI mode with the Proxmox VM. Pfff
I first got an error, but that was a setting on the Proxmox side (âPre-Enroll Keysâ had to be disabled in System/Advanced when creating the VM).
Iâm also starting to suspect itâs a DELL thang
I stumbled across a very similar issue today while trying to network boot an old LGA775 Gigabyte motherboard.
I kept getting the âERROR code:0 string:permission denied!â message, while in fact there was no issue within RouterOS.
To troubleshoot, I decided to enable logging from the âtftpâ log topic in the router.
Here are two PXE boot attempts, one successful from a newer UEFI-based Gigabyte board, and one from the older LGA775 board:
With newer MoBo:
03:18:54 dhcp,info server1 deassigned 192.168.1.36 for FC:AA:14:70:FE:C2
03:18:58 dhcp,info server1 assigned 192.168.1.36 for FC:AA:14:70:FE:C2
03:18:58 tftp,packet recieved type: 1 size: 24
03:18:58 tftp,packet read filename: netboot binary: 1
03:18:58 tftp,packet option: tsize value: 0
03:18:58 tftp,debug tftpd incoming connection from 192.168.1.36:2070 on 192.168.1.1
03:18:58 tftp,debug requested (binary) file: netboot access: allowed
03:18:58 tftp,debug opened 192.168.1.1:57783
03:18:58 tftp,packet sending type: 6 size: 15
03:18:58 tftp,packet option: tsize value: 374433
03:18:58 tftp,packet recieved type: 5 size: 17
03:18:58 tftp,packet error: 0
03:18:58 tftp,error ERROR: code 0
03:18:58 tftp,debug closing connection to 192.168.1.36:2070
03:18:58 tftp,packet recieved type: 1 size: 29
03:18:58 tftp,packet read filename: netboot binary: 1
03:18:58 tftp,packet option: blksize value: 1456
03:18:58 tftp,debug tftpd incoming connection from 192.168.1.36:2071 on 192.168.1.1
03:18:58 tftp,debug requested (binary) file: netboot access: allowed
03:18:58 tftp,debug opened 192.168.1.1:42375
03:18:58 tftp,packet sending type: 6 size: 15
03:18:58 tftp,packet option: blksize value: 1456
03:18:58 tftp,packet recieved type: 4 seq: 0 size: 4
03:18:58 tftp,packet sending type: 3 seq: 1 size: 1460
With older MoBo:
03:26:32 dhcp,info server1 deassigned 192.168.1.32 for 00:1A:4D:46:C6:58
03:26:34 dhcp,info server1 assigned 192.168.1.32 for 00:1A:4D:46:C6:58
03:26:34 tftp,packet recieved type: 1 size: 25
03:26:34 tftp,packet read filename: netbootFF binary: 1
03:26:34 tftp,packet option: tsize value: 0
03:26:34 tftp,debug tftpd incoming connection from 192.168.1.32:2070 on 192.168.1.1
03:26:34 tftp,debug requested (binary) file: netbootFF access: denied
03:26:34 tftp,error ERROR code:0 string:permission denied!
03:26:34 tftp,packet sending type: 5 size: 23
03:26:34 tftp,packet error: 0
03:26:34 tftp,packet recieved type: 1 size: 30
03:26:34 tftp,packet read filename: netbootFF binary: 1
03:26:34 tftp,packet option: blksize value: 1456
03:26:34 tftp,debug tftpd incoming connection from 192.168.1.32:2071 on 192.168.1.1
03:26:34 tftp,debug requested (binary) file: netbootFF access: denied
03:26:34 tftp,error ERROR code:0 string:permission denied!
03:26:34 tftp,packet sending type: 5 size: 23
03:26:34 tftp,packet error: 0
The requested (binary) file logs as ânetbootFFâ from the old board. In the WinBox log viewer, it shows as " read filename: netbootË binary: 1".
The âËâ character is U+02D9 âDOT ABOVEâ (https://www.fileformat.info/info/unicode/char/02d9/index.htm).
Itâs interesting that it shows up as a two byte character in WinBox, while the log tells us that the whole packet was only one byte longer than the one received from the newer motherboard, which booted fine.
I tried experimenting with the TFTP request filename and DHCP option 67 to make this old board boot, but it might be impossible with how these components of RouterOS are designed. I think the old board just has badly implemented PXE boot.
The problem is that in DHCP the fields have a length, so a filename is in the DHCP packet e.g. as 03 41 42 43 to indicate the filename ABC with length 3.
This is not understood by some programmers who assume that such a filename would be stored as 41 42 43 00 with 00 being the terminator byte for a string.
In the DHCP reply, when the filename is the last option, the next byte would be FF which means âend of optionsâ after which there will probably be a 00 byte by accident (as it is stored in a buffer that was all 00).
So what you now get is a name like 41 42 43 FF 00 which in some context is interpreted as ABCĂż and in other context some other invalid name.
It is always a pain to get it right. While I feel with the poster above complaining about Dell (the Dell BIOS people are d*ckh**ds that refuse to admit their bugs), in the current Dell machines with current BIOS versions it works OK. I regularly netboot Dell machines.
However, when you have an old unsupported machine and no available BIOS updates you may well be in trouble.
For other manufacturers, it might be the same. It appears features like this are often not really tested.