Bug Reports, Requests, HowTo's about Tiny PXE Server

does tinypxeserver support only file smaller than 2GB?

I saw it can serve file at 1.9GB, but not 2.3GB.
no error, just shows: 04:23:59 HTTPd:Server : Returning /sp3.iso
and client get nothing

it's named "Tiny" so can only serve tiny file? maybe not a bug.

You meant "bigger than" not "smaller than" right?

Normally yes it can do but I can look for a possible bug.

In which scenario does it fail : using memdisk or sanboot (as they use a slightly different http process).

booting linux live CD usually need a second stage filesystem.squashfs, and it's a big file. I can boot it after changing to other httpd server.

even at browser firefox I can not download file bigger than 2G from tinypxeserver

Understood.

Will have a look at it over the week end.

booting linux live CD usually need a second stage filesystem.squashfs, and it's a big file. I can boot it after changing to other httpd server.

even at browser firefox I can not download file bigger than 2G from tinypxeserver

I have uploaded a new version.

Tiny PXE Server now supports files bigger than 2GB over HTTP.

pxesrv.exe 
1.0.0.23
06/07/2019 12:50 
3B8AA11D517651DB5AF705373FC65A97

Edited by cabye, 07 July 2019 - 03:57 AM.

Hi Cabye,

The "hosts" file way will always work as this you are forcing dns resolution at the system level.

As such TPS will also be submitted to these changes.

However, I dont want to ask the user to modify this system file as this is way to drastic and possibly introduces side effects.

Hence me introducing an extra config.ini section.

One possible application is to come with generic batches for install where you could force a hostname named MY_REPO_SERVER pointing to an IP you would set on your PXE server side (no more hardcoded ip in your batch then).

Related to that topic is also the discover.exe tool (here and here and here) part of TPS as well but this is another discussion and I dont want to deviate too much...

The syntax in config.ini is may be unclear.

You have to put the hostname between brackets and for this section then add ip=a.b.c.d.

Or in the case of ip to hostname resolution, put the ip between brackets and for this section add host=whatever.fr

Example below

->host to ip resolution (192.168.1.144 being my TPS acting as DNSd).

[mydomain.fr]
ip=10.0.0.254

>nslookup mydomain.fr 192.168.1.144
Serveur :   erwan-pc2.home
Address:  192.168.1.144

Réponse ne faisant pas autorité :
Nom :    mydomain.fr
Address:  10.0.0.254

And the other way around ->ip to host resolution (192.168.1.144 being my TPS acting as DNSd).

[10.0.0.253]
host=mydomain2.fr

>nslookup -type=PTR 10.0.0.253 192.168.1.144
Serveur :   erwan-pc2.home
Address:  192.168.1.144

Réponse ne faisant pas autorité :
253.0.0.10.in-addr.arpa name = mydomain2.fr

EDIT : found a small bug where under some circumstances, the DNSd would stop.

Fixed in latest upload today.

Regards,

Erwan

Latest changelog for version 1.0.0.23 so far, most of it thanks to Cabye feedback.

1.0.0.23
added: php,vbs,py files can be processed server side using php, vbs, py entries under web section
added : will notify in the log window if another dhcp server exists on the LAN
added : if index.html exists, http will display this file instead of listing directory
added : httpd will be bound to one interface (or binded...) if bind option is selected
fixed : http server now supports bigger than 2gb
fixed : minor bug in dnsd where the daemon would stop unexpectedly under some circumstances

Hey everyone,

Please forgive me if I'm posting in the wrong area.  I've struggled to find support for the very specific issue I'm having;

I should firstly say I'm quite confident this isn't an issue with Tiny PXE itself, as I'm having the exact same problem when using a similar but different program called Serva.

My goal is to install Windows 10 onto a newly built machine via network boot.  Both Tiny PXE and Serva appear to run flawlessly.  But consistently, after loading the windows files, as soon as I reach any point in the installation which requires input (in Tiny PXE's case, as soon as I reach the step to enter the shared folder path) my machine simply locks up and keyboard/mouse movements aren't registered.  It's consistently about 0.5 seconds after my first input.  Sometimes my mouse appears to completely disconnect (ie. power light goes off) and sometimes it stays powered on.

The obvious first thought would be that it's a hardware issue with the mouse or keyboard, but they in fact work flawlessly in every other machine I've tried.  They also work flawlessly in the BIOS for long periods of time.  I've also tried navigating with the mouse unplugged, but inputs from the keyboard still aren't registered (after about 0.5 sec from initial input).  I've tried unplugging the keyboard directly after making necessary inputs, and the problem persists.

I've tried every USB and combination of USB ports on the machine, same issue.

I've tried many different Windows 10 ISOs including the one directly from Microsoft's media creation tool, same issue.

Firewall is off, and in/outgoing connections for Tiny PXE (and Serva) are explicitly allowed in defender.

I've contacted Gigabyte support thinking it may be some strange issue with my H110m.2 rev. 1 board.  They are as stumped as I am.

Is there anyone here who might have any idea as to what's going on?  Its been days of trial and error and tweaks and headaches but I'd really like to get this working.

For the record, Tiny PXE is soooo much smoother and simpler than Serva.  I'm glad I found this program.  Just wish I could solve this very strange issue!

Thanks.

I can't seem to get mine going. I am getting these errors:

Thanks for your response!

That looks to be similar to my problem. He appears to be attempting to setup an unattended uefi boot for 32bit AND 64bit environments.

I am looking to do the same.

I also noticed that my option 67 entry isn't being saved and doesn't appear to be in the config file. Am I missing something? I have attached a screenshot below my config.

I am reading through the forum post entries you pointed me to. I will try and figure it out. If anyone can assist in this I would appreciate it!

It appears I can't attach a file so here is my config.

 

Wow, good news. By following @matso's and @erwan.l's posts, I succeeded to UEFI PXE boot in secure mode both x86 and x64 WIM files, after several attempts playing with new [map] directive. For x64 WIM (558 MB), it took me about 7min30s to get to the WinPE desktop with TFTPd.

 

Following is an excerpt of my config.ini with most important parameters:

 

 
[arch]
; http://reboot.pro/topic/21614-ipxe-wimboot-and-multi-platform-pcbiosefii386x86-64/
; will overrule filename or opt67 if client arch matches one of the below
; DHCP option 93  Client architecture
; 00000 Standard PC BIOS
; 00006 32-bit x86 EFI
; 00007 64-bit x86 EFI
; 00009 64-bit x86 EFI (obsolete)
; 00010  32-bit ARM EFI
; 00011  64-bit ARM EFI
00000=bootfiles\00000\undionly.kpxe
00006=bootfiles\00006\bootia32.efi
00007=bootfiles\00007\bootx64.efi
 
[dhcp]
; no root, so default to TPS startup directory
;root=
;boot file - can be empty if you boot directly with ipxe/gpxe rather than intel pxe agent
filename=undionly.kpxe
altfilename=menu.ipxe
; http://reboot.pro/topic/18962-bug-reports-requests-howtos-about-tiny-pxe-server/page-30
opt252=bootfiles\@arch\BCD
 
[map]
; did not work yet with TPS 1.0.0.22
;\EFI\Microsoft\boot\=\bootfiles\@arch\EFI\Microsoft\boot\    
; for x64
\EFI\Microsoft\boot\=\bootfiles\00007\EFI\Microsoft\boot\
; for x86
;\EFI\Microsoft\boot\=\bootfiles\00006\EFI\Microsoft\boot\    
 
; did not work yet with TPS 1.0.0.22
;\sources\boot.wim=\bootfiles\@arch\sources\boot.wim          
; for x64
\sources\boot.wim=\bootfiles\00007\sources\boot.wim
; for x86
;\sources\boot.wim=\bootfiles\00006\sources\boot.wim          
 
\boot\boot.sdi=\bootfiles\00000\boot\boot.sdi
\bootfiles\boot\en-US\=\bootfiles\00000\boot\en-US\
\bootfiles\boot\fr-FR\=\bootfiles\00000\boot\fr-FR\
\bootfiles\boot\fonts\=\bootfiles\00000\boot\fonts\
\bootfiles\boot\resources\=\bootfiles\00000\boot\resources\
 

 

Directory structure of files: (common_path)\PXE\ is the root.

(common_path)\PXE\pxesrv.exe 
(common_path)\PXE\config.INI 
(common_path)\PXE\menu.ipxe 
(common_path)\PXE\bootfiles\00000\undionly.kpxe 
(common_path)\PXE\bootfiles\00000\boot\bcd 
(common_path)\PXE\bootfiles\00000\boot\boot.sdi 
(common_path)\PXE\bootfiles\00000\boot\en-US\*.mui
(common_path)\PXE\bootfiles\00000\boot\fr-FR\*.mui
(common_path)\PXE\bootfiles\00000\boot\fonts\*.ttf 
(common_path)\PXE\bootfiles\00000\boot\Resources\bootres.dll 
(common_path)\PXE\bootfiles\00000\boot\Resources\fr-FR\*.mui 
(common_path)\PXE\bootfiles\00006\bcd 
(common_path)\PXE\bootfiles\00006\bootia32.efi 
(common_path)\PXE\bootfiles\00006\EFI\Microsoft\boot\boot.sdi 
(common_path)\PXE\bootfiles\00006\EFI\Microsoft\boot\*.p7b 
(common_path)\PXE\bootfiles\00006\EFI\Microsoft\boot\en-US\*.mui 
(common_path)\PXE\bootfiles\00006\EFI\Microsoft\boot\fr-fr\*.mui 
(common_path)\PXE\bootfiles\00006\EFI\Microsoft\boot\fonts\*.ttf 
(common_path)\PXE\bootfiles\00006\EFI\Microsoft\boot\resources\bootres.dll 
(common_path)\PXE\bootfiles\00006\sources\boot.wim 
(common_path)\PXE\bootfiles\00007\bcd 
(common_path)\PXE\bootfiles\00007\bootx64.efi 
(common_path)\PXE\bootfiles\00007\EFI\Microsoft\boot\boot.sdi 
(common_path)\PXE\bootfiles\00006\EFI\Microsoft\boot\*.p7b 
(common_path)\PXE\bootfiles\00007\EFI\Microsoft\boot\en-US\*.mui
(common_path)\PXE\bootfiles\00007\EFI\Microsoft\boot\fr-fr\*.mui 
(common_path)\PXE\bootfiles\00007\EFI\Microsoft\boot\fonts\*.ttf 
(common_path)\PXE\bootfiles\00007\EFI\Microsoft\boot\resources\bootres.dll 
(common_path)\PXE\bootfiles\00007\sources\boot.wim 

 

Question:

1) [arch] section: What should I use:

; 00010  32-bit ARM EFI

; 00011  64-bit ARM EFI

or 

; 0000a  32-bit ARM EFI

; 0000b  64-bit ARM EFI

?

 

2) Since iPXE does not support yet UEFI Secure boot, currently to PXE boot in UEFI secure boot, I need to use TFTP, which is very slow, is it true?

 

For @erwan.l

 

Requests for implementation:

1) Allow use of @arch in each [map] line, e.g.

[map]
\EFI\Microsoft\boot\=\bootfiles\@arch\EFI\Microsoft\boot\    

This would allow simultaneous PXE clients regardless of its architecture (x86/x64...) without changing the config.ini.

 

2) Allow dynamic switching of configuration file (e.g. via combo-box), and change with Offline/Online button.

So I can choose config.ini for standard configuration with iPXE, and config_secure.ini for booting MS WIM files in UEFI secure mode.

 

In fact, my need is to be able to switch easily between

[arch]
00000=bootfiles\00000\undionly.kpxe
00006=bootfiles\00006\bootia32.efi
00007=bootfiles\00007\bootx64.efi

 

and

 

[arch]
00000=bootfiles\00000\undionly.kpxe
00006=bootfiles\00006\ipxe32.efi
00007=bootfiles\00007\ipxe64.efi

 

without requring to edit config.ini file. All the other parameters are unchanged between the tow configurations.

 

I don't see where you are placing the WIM file for the standard PC Bios 00000 option. Am I missing something?

Hi

hi,

when downloading unknown files using tftp protocol, tinypxeserver reported "file not found“ with specific file names.
but when downloading unknown files using http protocol, it reported nothing.

I think the report is important and useful.

is there any parameter to make tinypxeserver report a 404 error with detailed missing file name?

Hi,

What do you mean by "unknown files" ?

You mean file that do not exist on your storage?

Regards,

Erwan

hi,  sorry for another little question:
how to use @arch variable ?

I see this in your changelog pxesrv.txt:

added : @arch variable can be used in the altfilename

 

and I see in this thread somethine like this:
 

@arch values     = 00000, 00006, 00007, 0000a, 0000b
@archtext values = bios, efi32, efi64, arm32, arm64

 

and from TPS GUI window mouse hovering tooltip box I see there're some tip about altfilename and opt252,

"you can use @mac and @arch variable"

 

I think this is useful for serving both UEFI and BIOS.

to use variable @mac @ip @arch @opt54 in : filename
I set altfilename @mac-@arch.ipxe, only got 00-0c-xx-xx-xx-xx-.ipxe, @mac is ok, @arch is blank.
and
I set opt252 to @mac-@arch.ipxe, only got @mac-.ipxe, @mac is unchanged, @arch is blank.

I trid these in  both  BIOS and UEFI, DHCP and ProxyDHCP, same result.
is this a bug or removed feature?


 

yes unknown missing not existed files

a missing file will now give the below

hi,  sorry for another little question:
how to use @arch variable ?

I see this in your changelog pxesrv.txt:

and I see in this thread somethine like this:
 

and from TPS GUI window mouse hovering tooltip box I see there're some tip about altfilename and opt252,

I think this is useful for serving both UEFI and BIOS.

to use variable @mac @ip @arch @opt54 in : filename
I set altfilename @mac-@arch.ipxe, only got 00-0c-xx-xx-xx-xx-.ipxe, @mac is ok, @arch is blank.
and
I set opt252 to @mac-@arch.ipxe, only got @mac-.ipxe, @mac is unchanged, @arch is blank.

I trid these in  both  BIOS and UEFI, DHCP and ProxyDHCP, same result.
is this a bug or removed feature?


 

looking into this.

although for now, rather than trying to use the @arch , you could use the config.ini [arch] section like below

[arch]
00000=ipxe.pxe
00006=ipxe-i386.efi
00007=ipxe-x86_64.efi

About arch, I am getting it in the DHCP discover request (sent by the client).

I check if option 60 is set.

I then look for a string which should look like PXEClient:Arch:0000x and will extract 0000x.

In config.ini, enable verbose=1, restart pxesrv and copy paste your logs here.

You should get something like below - observe "18:51:58 DHCPd:Arch=00000".

18:51:19 DHCPc:discovering for another DHCPd on LAN
18:51:19 DHCPd 192.168.1.144:67 started...
18:51:19 DHCPd 192.168.1.144:4011 started...
18:51:19 TFPTd 192.168.1.144:69 started...
18:51:19 HTTPd:80 started...
18:51:19 PID created: 12964
18:51:19 executing online.bat succeeded
18:51:24 DHCPc:another DHCPd detected on your LAN @ 192.168.1.250
18:51:52 DHCPd:DISCOVER received, MAC:00-0C-29-5C-36-5A, XID:2A5C365A
18:51:52 DHCPd:OFFER sent, IP:0.0.0.0, XID:2A5C365A
18:51:54 DHCPd:DISCOVER received, MAC:00-0C-29-5C-36-5A, XID:2B5C365A
18:51:54 DHCPd:OFFER sent, IP:0.0.0.0, XID:2B5C365A
18:51:58 DHCPd:REQUEST discarded, MAC:00-0C-29-5C-36-5A, XID:2B5C365A
18:51:58 PDHCPd:REQUEST received, MAC:00-0C-29-5C-36-5A, IP:192.168.1.124, XID:2B5C365A
18:51:58 DHCPd:Arch=00000
18:51:58 Proxy boot filename empty?
18:51:58 PDHCPd:DHCP_ACK sent, IP:192.168.1.124:68, xid:2B5C365A
18:51:58 TFTPd:DoReadFile:ipxe.pxe B:1456 T:0
18:51:59 TFTPd:TransferComplete=True (192.168.1.124:2070)
18:52:02 DHCPd:DISCOVER received, MAC:00-0C-29-5C-36-5A, XID:9662BF00
18:52:02 DHCPd:iPXE user-class detected
18:52:02 DHCPd:OFFER sent, IP:0.0.0.0, XID:9662BF00
18:52:02 DHCPd:REQUEST discarded, MAC:00-0C-29-5C-36-5A, XID:9662BF00
18:52:02 TFTPd:DoReadFile:menu.ipxe B:1432 T:16529
18:52:02 TFTPd:TransferComplete=True (192.168.1.124:48913)

I meant report in log window. since downloading is in ipxe batch.
when downloading missing file I saw in log sth like this:

9:07:02 HTTPd:DisConnect: TID=12444

does this "DisConnect" always mean "missing file"?
if so, that's ok, I just check DisConnect for missing files.
 

adding verbose = 1

I see. no problem now. I might messed up sth by switching proxydhcp after boot.


another little question:

in your config.ini I saw lines these lines:
 

;alternative bootp filename if request comes thru proxydhcp (udp:4011)
;proxybootfilename=

can I serve DHCP noramlly and ProxyDHCP at the same time?
I tried, but this option only work in ProxyDHCP mode.

it seems that DHCP is at port 67, and ProxyDHCP is at port 4011,
there'd be no collision


 

and, why every reboot or dhcp command got a new IP, with default 3600 lease time ? :

20:35:57 DHCPd:DISCOVER received, MAC:00-0C-29-DF-84-73, XID:43AADF6B
20:35:57 DHCPd:iPXE user-class detected
20:35:57 DHCPd:OFFER sent, IP:192.168.0.203, XID:43AADF6B
20:35:57 DHCPd:REQUEST received, MAC:00-0C-29-DF-84-73, XID:43AADF6B
20:35:57 DHCPd:Arch=00000
20:35:57 DHCPd:iPXE user-class detected
20:35:57 DHCPd:ACK sent, IP:192.168.0.203, XID:43AADF6B
20:35:58 DHCPd:DISCOVER received, MAC:00-0C-29-DF-84-73, XID:2C71122A
20:35:58 DHCPd:iPXE user-class detected
20:35:58 DHCPd:OFFER sent, IP:192.168.0.204, XID:2C71122A
20:35:58 DHCPd:REQUEST received, MAC:00-0C-29-DF-84-73, XID:2C71122A
20:35:58 DHCPd:Arch=00000
20:35:58 DHCPd:iPXE user-class detected
20:35:58 DHCPd:ACK sent, IP:192.168.0.204, XID:2C71122A
20:36:01 DHCPd:DISCOVER received, MAC:00-0C-29-DF-84-73, XID:485AA60E
20:36:01 DHCPd:iPXE user-class detected
20:36:01 DHCPd:OFFER sent, IP:192.168.0.205, XID:485AA60E
20:36:01 DHCPd:REQUEST received, MAC:00-0C-29-DF-84-73, XID:485AA60E
20:36:01 DHCPd:Arch=00000
20:36:01 DHCPd:iPXE user-class detected
20:36:01 DHCPd:ACK sent, IP:192.168.0.205, XID:485AA60E
20:36:02 DHCPd:DISCOVER received, MAC:00-0C-29-DF-84-73, XID:4F52B955
20:36:02 DHCPd:iPXE user-class detected
20:36:02 DHCPd:OFFER sent, IP:192.168.0.206, XID:4F52B955
20:36:02 DHCPd:REQUEST received, MAC:00-0C-29-DF-84-73, XID:4F52B955
20:36:02 DHCPd:Arch=00000
20:36:02 DHCPd:iPXE user-class detected
20:36:02 DHCPd:ACK sent, IP:192.168.0.206, XID:4F52B955
20:37:18 WorkingSetSize=20872 KB
20:37:18 PagedPool=269KB
20:37:18 Pagefile=269KB

Edited by cabye, 08 January 2020 - 02:46 AM.

hi,  just found another useful feature: [map] section.

to pxe boot some debian live CD
there's always a huge file filesystem.squashfs,
and, for some unknown strange reason, after mounting the ISO in win10,
I can only see a file named FILESYST.SQU, i.e., name in 8.3 format.

sure I can recreate the debian.ISO to make it support long file names,
but if I can map the file FILESYST.SQU to filesystem.squashfs, then I can boot the orignal ISO without any modification.

I found that the file name mapping only works in TFTP,
and using TFTP and mapping, I can boot to my debian live CD.
but the true power of ipxe is fast speed in HTTP.

can you guide me to make name mapping work in HTTP downloading?


 

You don't need the whole ISO - just three files are enough: vmlinuz, initrd.img, filesystem.squashfs to run Debian using the NFS file system. Download this NFS server for Windows, copy to the TPS root directory and setup this way:
 nfs_settings.png   8.82KB   9 downloads
 
config.ini

[dhcp]
verbose=1
;for Netboot working
rfc951=1

root=C:\PXE
filename=pxelinux.0
httpd=1
binl=0
;start=1
dnsd=0
proxydhcp=0

;if multiple interfaces detected bind is always enabled in GUI
bind=1

smb=0
cmd=freenfs.exe
offline=freenfs_off.bat
;log=0
;syslog=127.0.0.1

;for RIS client working (for TPS 1.0.0.11 need opt43=0.0.0.0)
opt43=1

;for EFI boot opt60 need be disabled but for RIS need be PXEClient
;opt60=PXEClient
;optextra=43.7.1.4.0.0.0.0.255

[web]
port=80

[frmDHCPServer]
top=54
left=507
[frmAbout_1]
top=486
left=509
[frmAbout]
top=73
left=703

taskkill /IM FreeNFS.exe /F

Copy files vmlinuz and initrd.img to: C:\PXE\images\debian9
Copy file filesystem.squashfs to C:\PXE\images\debian9\live
 
Boot over PXELINUX:
 
Configure startup in the C:\PXE\pxelinux.cfg\default file:

LABEL live9
MENU LABEL Debian Live 9
kernel images/debian9/vmlinuz
append initrd=images/debian9/initrd.img boot=live config netboot=nfs ip=dhcp nfsroot=/debian9

 
Boot over iPXE by HTTP protocol:
 
Use script debian9.ipxe and undionly.kpxe or snponly.efi in TPS:
 tps_settings_ipxe.png   1.77KB   4 downloads

#!ipxe

set url http://${dhcp-server}

initrd ${url}/images/debian9/initrd.img
kernel ${url}/images/debian9/vmlinuz initrd=initrd.img boot=live config netboot=nfs ip=dhcp nfsroot=/debian9
boot

You can also run via iPXE -> PXELINUX from HTTP - use the ipxe script:

# Setup DHCP options for PXELINUX over HTTP
set 209:string pxelinux.cfg/default
set 210:string http://${dhcp-server}/
chain ${210:string}pxelinux.0

I meant report in log window. since downloading is in ipxe batch.
when downloading missing file I saw in log sth like this:

9:07:02 HTTPd:DisConnect: TID=12444

does this "DisConnect" always mean "missing file"?
if so, that's ok, I just check DisConnect for missing files.

 

HTTPd:DisConnect does NOT mean there is a missing file.

It only means that a tcp connection has terminated (usually from the client side).

 

another little question:

in your config.ini I saw lines these lines:
 

can I serve DHCP noramlly and ProxyDHCP at the same time?
I tried, but this option only work in ProxyDHCP mode.

it seems that DHCP is at port 67, and ProxyDHCP is at port 4011,
there'd be no collision

You cannot.

It is either plain/full dhcp or "light" proxydhcp.

DHCP provides the full list of parameters.

ProxyDHCP only provides some parameters like the boot filename.

Having a server run both a dhcp service AND a proxydhcp service would not make sense as parameters provided by proxydhcp can already be served by dhcp.

and, why every reboot or dhcp command got a new IP, with default 3600 lease time ? :

20:35:57 DHCPd:DISCOVER received, MAC:00-0C-29-DF-84-73, XID:43AADF6B
20:35:57 DHCPd:iPXE user-class detected
20:35:57 DHCPd:OFFER sent, IP:192.168.0.203, XID:43AADF6B
20:35:57 DHCPd:REQUEST received, MAC:00-0C-29-DF-84-73, XID:43AADF6B
20:35:57 DHCPd:Arch=00000
20:35:57 DHCPd:iPXE user-class detected
20:35:57 DHCPd:ACK sent, IP:192.168.0.203, XID:43AADF6B
20:35:58 DHCPd:DISCOVER received, MAC:00-0C-29-DF-84-73, XID:2C71122A
20:35:58 DHCPd:iPXE user-class detected
20:35:58 DHCPd:OFFER sent, IP:192.168.0.204, XID:2C71122A
20:35:58 DHCPd:REQUEST received, MAC:00-0C-29-DF-84-73, XID:2C71122A
20:35:58 DHCPd:Arch=00000
20:35:58 DHCPd:iPXE user-class detected
20:35:58 DHCPd:ACK sent, IP:192.168.0.204, XID:2C71122A
20:36:01 DHCPd:DISCOVER received, MAC:00-0C-29-DF-84-73, XID:485AA60E
20:36:01 DHCPd:iPXE user-class detected
20:36:01 DHCPd:OFFER sent, IP:192.168.0.205, XID:485AA60E
20:36:01 DHCPd:REQUEST received, MAC:00-0C-29-DF-84-73, XID:485AA60E
20:36:01 DHCPd:Arch=00000
20:36:01 DHCPd:iPXE user-class detected
20:36:01 DHCPd:ACK sent, IP:192.168.0.205, XID:485AA60E
20:36:02 DHCPd:DISCOVER received, MAC:00-0C-29-DF-84-73, XID:4F52B955
20:36:02 DHCPd:iPXE user-class detected
20:36:02 DHCPd:OFFER sent, IP:192.168.0.206, XID:4F52B955
20:36:02 DHCPd:REQUEST received, MAC:00-0C-29-DF-84-73, XID:4F52B955
20:36:02 DHCPd:Arch=00000
20:36:02 DHCPd:iPXE user-class detected
20:36:02 DHCPd:ACK sent, IP:192.168.0.206, XID:4F52B955
20:37:18 WorkingSetSize=20872 KB
20:37:18 PagedPool=269KB
20:37:18 Pagefile=269KB

This is how dhcp works.

With every new incoming request, it will provide a new dhcp lease (aka a new IP).

About that, before serving that IP, pwesrv will check that the IP is not already live on the LAN but will also avoid providing an IP it served within the previous 60 seconds (to avoid collisions).

Wait over 60 secs between 2 "dhcp & show ip" and you will most probably get the same ip.

3600 seconds as a lease time is option 51.