Jump to content











Photo

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

pxe network boot

  • Please log in to reply
909 replies to this topic

#751 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3042 posts
  • Location:Nantes - France
  •  
    France

Posted 04 February 2018 - 07:03 PM

Happy it works out for you :)

 

Adding a "map" feature to Tiny PXE Server was a good thing : it should cover a few other scenarios.

 

About your config.ini you can probably make it simpler like below.

boot\boot.sdi being common to all distributions, you could leave it in the root folder.

EFI folders (00006,00007,00009) can probably be treated as one EFI folder '0000X'.

[MAP]
\EFI\Microsoft\boot\=\00007\EFI\Microsoft\boot\
\boot\resources\=\00000\boot\resources\
\boot\fonts\=\00000\boot\fonts\
\boot\en-US\=\00000\boot\en-US\
\boot\boot.sdi=\00000\boot\boot.sdi


#752 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 06 February 2018 - 02:23 PM

@erwan.l
 
Is there a reason to still keep version number 1.0.0.21? There are a lot pxeserv.exe with same version number, same exe size but with different content (build). It would be preferable to have new version number for each build to avoid confusion.
 


#753 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3042 posts
  • Location:Nantes - France
  •  
    France

Posted 06 February 2018 - 04:40 PM

 

@erwan.l
 
Is there a reason to still keep version number 1.0.0.21? There are a lot pxeserv.exe with same version number, same exe size but with different content (build). It would be preferable to have new version number for each build to avoid confusion.

 

 

I was thinking about that lately :)

When is the right time to increase your version...

Note that version.txt contains a timestamp and a MD5 thus.



#754 misty

misty

    Gold Member

  • Developer
  • 1069 posts
  •  
    United Kingdom

Posted 06 February 2018 - 04:45 PM

I was thinking about that lately :)
When is the right time to increase your version...

Maybe with a new release? You could use build numbers based on date - e.g. 20180206 for today.

But then with your release cycle you may need to include hour and minute references too! :whistling:

I lost count of the number of offlinereg releases in one day - I think it was four on the 26th January!!!!!
 

Note that version.txt contains a timestamp and a MD5 thus.

Definitely a step in the right direction.

:cheers:

Misty

P.s. I'm more than happy to put up with this flaw in your development process as the resulting work more than makes up for it.

#755 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 06 February 2018 - 04:56 PM

@erwan.l
 
Ideally each released version should have a different version number. Each released version normally adds/modifies some functions. The associated version.txt included with the zip could be useful but it is more practical to refer to the version number as displayed by TPS at run-time.
 
Under Windows, the bubble information (when mouse over the pxeserv.exe file in file explorer) shows exe file version, company (if any), file description (if any)... which is very useful.
 
Otherwise, previously in since I was at 1.0.0.21 version, I thought I was at the latest version, so ctrl-R hotkey should be operational, but it was not with my version. Correct version number could also help when users report the problem.
 
 


#756 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3042 posts
  • Location:Nantes - France
  •  
    France

Posted 06 February 2018 - 05:24 PM

In a normal env, indeed, a released version=new release number.

Now, on reboot.pro, because I sometimes go in a "live mod" / trial and error, I cannot increase the release number on each new build.

 

Rather, I try to increase the number when a new major addition gets in.

The new "map" feature actually should be enough to have TPS increased to 1.0.22.



#757 misty

misty

    Gold Member

  • Developer
  • 1069 posts
  •  
    United Kingdom

Posted 06 February 2018 - 06:02 PM

"live mod" / trial and error..

So that's what it's called! :P :ph34r:

Keep up the good work :worship:

#758 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3042 posts
  • Location:Nantes - France
  •  
    France

Posted 06 February 2018 - 06:16 PM

Hopefully, Wonko wont see this discussion about versionning  :innocent:



#759 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3042 posts
  • Location:Nantes - France
  •  
    France

Posted 06 February 2018 - 06:16 PM

In the meantime ... and by pure coincidence ...

pxesrv.exe 
1.0.0.22
06/02/2018 19:12 
BD9FAE2E16E16F8986EB9F1D96B746F0
1.0.0.22
added : CTRL+R to refresh interfaces
added : [map] section, before=after


#760 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3042 posts
  • Location:Nantes - France
  •  
    France

Posted 06 February 2018 - 06:22 PM

Maybe with a new release? You could use build numbers based on date - e.g. 20180206 for today.

But then with your release cycle you may need to include hour and minute references too! :whistling:

I lost count of the number of offlinereg releases in one day - I think it was four on the 26th January!!!!!
 
Definitely a step in the right direction.

:cheers:

Misty

P.s. I'm more than happy to put up with this flaw in your development process as the resulting work more than makes up for it.

 

What I missing (or my dev environement is missing) is a last digit in hundreds or thousands that would auto increment each time I build a new binary.

 

A.B.C

with A being major (will almost never change unless drastically rewritten)

with B being significant changes (a new feature? an important bug fix?)

with C being the build number

 

Delphi versionning is : major.minor.release.build.

Just found out I can enable "auto increment build" ... :)

So thinking loud ... actually I could use that feature by shifting current release "22" to minor, leave release to "0" and auto increment build.

 

EQJFbDM.png



#761 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 06 February 2018 - 10:18 PM

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.
 


#762 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3042 posts
  • Location:Nantes - France
  •  
    France

Posted 06 February 2018 - 11:05 PM

@ktp

 

About tftp, it is slow compared to http.
But you can drastically improve speed with these bcd options :
ramdisktftpblocksize 32768
ramdisktftpwindowsize 8 (new option)

You may want to try different numbers.


  • ktp likes this

#763 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 07 February 2018 - 06:50 AM

Wow, by using Ramdisk BCD options (see screen capture):
RamdiskTftpBlocksize 32768
RamdiskTftpWindowSize 8 
I reduce TFTP WIM load time from 7min30s to 40s !
 
@erwan.l
To enhance my previous request 1)
 
Add support for new variable @archtext, and allow @arch, @archtext to be substituted in [arch] and in [map] sections:
@arch values     = 00000, 00006, 00007, 0000a, 0000b
@archtext values = bios, efi32, efi64, arm32, arm64
 
; warning: this is a proposal sample, does not work with current TPS version 1.0.0.22
; you can use @arch instead of @archtext (directory names must match)
[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
; 0 Standard PC BIOS
; 6 32-bit x86 EFI
; 7 64-bit x86 EFI
; 9 64-bit x86 EFI (obsolete)
; 10  32-bit ARM EFI
; 11  64-bit ARM EFI
00000=bootfiles\@archtext\undionly.kpxe
00006=bootfiles\@archtext\bootia32.efi
00007=bootfiles\@archtext\bootx64.efi
0000a=bootfiles\@archtext\arm32.efi
0000b=bootfiles\@archtext\arm64.efi
 
[map]
\EFI\Microsoft\boot\=\bootfiles\@archtext\EFI\Microsoft\boot\    
\sources\boot.wim=\bootfiles\@archtext\sources\boot.wim     
\boot\boot.sdi=\bootfiles\bios\boot\boot.sdi
\bootfiles\boot\en-US\=\bootfiles\bios\boot\en-US\
\bootfiles\boot\fr-FR\=\bootfiles\bios\boot\fr-FR\
\bootfiles\boot\fonts\=\bootfiles\bios\boot\fonts\
\bootfiles\boot\resources\=\bootfiles\bios\boot\resources\
 
 
[dhcp]
opt252=bootfiles\@archtext\BCD
 
Note: currently I used "bios", "efi32", "efi64" in [map], which is more explicit than their coded counterpart.

Attached Files



#764 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3042 posts
  • Location:Nantes - France
  •  
    France

Posted 07 February 2018 - 06:54 AM

 

Wow, by using Ramdisk BCD options (see screen capture):
RamdiskTftpBlocksize 32768
RamdiskTftpWindowSize 8 
I reduce TFTP WIM load time from 7min30s to 40s !
 

 

@ktp

Yes, indeed :)

I am not a big fan of TFTP (compared to HTTP) but these settings make performance plenty acceptable.

 

For the record, here below how to modify the BCD from command line.

MS recommend to not exceed 16384 but some users report that it works fine with 65536.

Some also say that you should leave ramdisktftpblocksize untouched but rather modify RamDiskTFTPWindowSize.

Bcdedit /store %BCD-File% /create {ramdiskoptions}
Bcdedit /store %BCD-File% /set {ramdiskoptions} ramdisktftpblocksize 16384
Bcdedit /store %BCD-File% /set {ramdiskoptions} ramdisktftpwindowsize 8


#765 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3042 posts
  • Location:Nantes - France
  •  
    France

Posted 07 February 2018 - 07:00 AM

 

Wow, by using Ramdisk BCD options (see screen capture):
RamdiskTftpBlocksize 32768
RamdiskTftpWindowSize 8 
I reduce TFTP WIM load time from 7min30s to 40s !
 
@erwan.l
To enhance my previous request 1)
 
Add support for new variable @archtext, and allow @arch, @archtext to be substituted in [arch] and in [map] sections:
@arch values     = 00000, 00006, 00007, 0000a, 0000b
@archtext values = bios, efi32, efi64, arm32, arm64
 

 

@ktp

 

I wont be able to bring the arch variable into the [map] section.

DHCP and TFTP protocols are mostly independent from each other.

I would have to bring in some risky workarounds to be able to match an incoming dhcp request to an incoming tftp request.

 

Furthermore, because you are (rightfully) using option 252, you actually dont need to (re) map boot.wim.

Indeed, with opt252=bootfiles\@arch\BCD, you have the option to have a specific BCD per arch which should point to a specific boot.wim (specific filename and/or path).

Your BCD should either (1) point to \0000x\sources\boot.wim (no need to map then) or (2) point to \sources\boot_arch.wim and you can map based on the filename.

Option (1) above has my preference.

See below for a command line batch for bcdedit which you could use to point to different boot.wim locations.

 

Can you elaborate on @archtext?

rem Create a BCD store using bcdedit.exe
set BCDSTORE=C:\temp\BCD
bcdedit /createstore %BCDSTORE%
rem Configure RAMDISK settings
bcdedit /store %BCDSTORE% /create {ramdiskoptions} /d "Ramdisk options"
bcdedit /store %BCDSTORE% /set {ramdiskoptions} ramdisksdidevice boot
bcdedit /store %BCDSTORE% /set {ramdiskoptions} ramdisksdipath \boot\boot.sdi
bcdedit /store %BCDSTORE% /create /d "winpe boot image" /application osloader>guid.txt
bcdedit.exe /store %BCDSTORE% /create /d "Microsoft Windows" /application osloader>GUID.txt
For /F "tokens=2 delims={}" %%i in (GUID.txt) do (set GUID=%%i)
rem The last command will return a GUID
rem Create a new boot application entry for the Windows PE image
bcdedit /store %BCDSTORE% /set {%GUID%} device ramdisk=[boot]\boot\boot.wim,{ramdiskoptions} 
bcdedit /store %BCDSTORE% /set {%GUID%} path \windows\system32\winload.exe 
bcdedit /store %BCDSTORE% /set {%GUID%} osdevice ramdisk=[boot]\boot\boot.wim,{ramdiskoptions} 
bcdedit /store %BCDSTORE% /set {%GUID%} systemroot \windows
bcdedit /store %BCDSTORE% /set {%GUID%} detecthal Yes
bcdedit /store %BCDSTORE% /set {%GUID%} winpe Yes
rem Configure BOOTMGR settings
bcdedit /store %BCDSTORE% /create {bootmgr} /d "boot manager"
bcdedit /store %BCDSTORE% /set {bootmgr} timeout 30 
bcdedit /store %BCDSTORE% -displayorder {%GUID%} -addlast


#766 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3042 posts
  • Location:Nantes - France
  •  
    France

Posted 07 February 2018 - 07:03 AM

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.

 

@ktp

I should be able to do that.

I'd like to keep the GUI simple thus.

May be a shortcut like CTRL+F to open a dialogbox pointing to another config.ini?



#767 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 07 February 2018 - 08:39 AM

@erwan.l
 
 
About @archtext: I thought @arch and @archtext could be dynamically detected and substituted,
so it would perfectly match the bootfiles directories names I use:
 
Before:
\PXE\bootfiles\00000\
\PXE\bootfiles\00006\
\PXE\bootfiles\00007\
 
After:
\PXE\bootfiles\bios\
\PXE\bootfiles\efi32\
\PXE\bootfiles\efi64\
The last 3 names are much more explicit (self-explanatory), and are less error-prone.
 
@arch values     = 00000, 00006, 00007, 0000a, 0000b
@archtext values = bios, efi32, efi64, arm32, arm64
But from your input about opt252 and change in @arch-dependent BCD, there is now no more dependency
on @arch or @archtext in [map]. The trick is that 
\EFI\Microsoft\boot\=\bootfiles\00007\EFI\Microsoft\boot\*
seems to be compatible with both x86 and x64 (font, resources, en-us, fr-fr).
With this my config.ini is simpler:
[arch]
00000=bootfiles\bios\undionly.kpxe
00006=bootfiles\00006\bootia32.efi
00007=bootfiles\00007\bootx64.efi
 
[map]
\EFI\Microsoft\boot\=\bootfiles\00007\EFI\Microsoft\boot\
\boot\boot.sdi=\bootfiles\bios\boot\boot.sdi
\bootfiles\boot\en-US\=\bootfiles\bios\boot\en-US\
\bootfiles\boot\fr-FR\=\bootfiles\bios\boot\fr-FR\
\bootfiles\boot\fonts\=\bootfiles\bios\boot\fonts\
\bootfiles\boot\resources\=\bootfiles\bios\boot\resources\
 
 
[dhcp]
;opt252=bootfiles\@archtext\BCD ; valid only if implemented by TPS
opt252=bootfiles\@arch\BCD
 
So now no more need for @arch substitution in [map], and the @archtext is needed and to be substituted in opt252 so that I can replace the directory names with more explicit name:
00006 -> efi32
00007 -> efi64
 
Final config.ini if implemented:
[arch]
00000=bootfiles\bios\undionly.kpxe
00006=bootfiles\efi32\bootia32.efi
00007=bootfiles\efi64\bootx64.efi
 
[dhcp]
opt252=bootfiles\@archtext\BCD ; valid only if implemented by TPS
 
 
About dynamic configuration switch:
 
And why not Ctrl-I : for switching ini (I for ini, such as Ctrl-R for refresh interfaces).
After Ctrl-I, dialog popup with :
- combo-box + "browse" button to choose *.ini file in same directory as pxeserv.exe (similar to current boot filename combo-box).
- button Validate or Cancel. Cancel: do nothing. If Validate: load settings from the selected ini file and automatic Offline/Online. With the new request 1) below, user is informed of the actual configuration file applied.
 
New request 1): At startup: display what is the active configuration file used (default: config.ini).
New request 2): At startup: display a short line: "Ctrl-R: refresh interfaces, Ctrl-I: switch configuration" at startup time to remind user of these hotkeys.
 
New request 3): (nice to have only, far from vital) Add command line option -i to use which ini file at startup. No -i option or not found/invalid file: use default config.ini.
 
Note:
Be careful about these existing items (right mouse click):
Save settings to config.ini
Reload settings from config.ini
Open config.ini
 
- Could the string "config.ini" be dynamically changed in these 3 items after switching configuration file?
- If yes, then everything is in sync and OK, the 3 actions applied to the active configuration file (default: config.ini,
but it could applied to config_secure_uefi.ini for example etc...). But reflecting the real file name could break the GUI if the filename is too long. So then maybe change "config.ini" to the generic wording "active configuration file".

Attached Files



#768 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 07 February 2018 - 09:09 AM

 

@ktp

Yes, indeed :)

I am not a big fan of TFTP (compared to HTTP) but these settings make performance plenty acceptable.

 

For the record, here below how to modify the BCD from command line.

MS recommend to not exceed 16384 but some users report that it works fine with 65536.

Some also say that you should leave ramdisktftpblocksize untouched but rather modify RamDiskTFTPWindowSize.

Bcdedit /store %BCD-File% /create {ramdiskoptions}
Bcdedit /store %BCD-File% /set {ramdiskoptions} ramdisktftpblocksize 16384
Bcdedit /store %BCD-File% /set {ramdiskoptions} ramdisktftpwindowsize 8

 

For information, Serva 3.0 does not use RamdiskTftpBlocksize, but only RamdiskTftpWindowSize set to 64.

Edit: I change RamdiskTftpWindowSize from 8 to 64, the WIM load time does not change much, still about 40 seconds.



#769 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3042 posts
  • Location:Nantes - France
  •  
    France

Posted 07 February 2018 - 10:51 AM

For information, Serva 3.0 does not use RamdiskTftpBlocksize, but only RamdiskTftpWindowSize set to 64.

Edit: I change RamdiskTftpWindowSize from 8 to 64, the WIM load time does not change much, still about 40 seconds.

 

The biggest improvement will be achieved with a windowsize of 4 or 8.

Anything above will be marginal hence I would recommend to stick to these max values.

 

About blocksize, I need to do some more reading but here again it could be that anything above 16384 will be marginal.

16384 is probably a good max value to stick with as some reports possible IP fragmentation issues as this value increases.

 

Quoting wikipedia 

In 1998 this limit was extended to 65535 bytes/block x 65535 blocks = 4 GB by TFTP Blocksize Option RFC 2348. 
If the defined blocksize produces an IP packet size that exceeds the minimum MTU at any point of the network path, 
IP fragmentation and reassembly will occur not only adding more overhead[8] but also leading to total transfer failure 
when the minimalist IP stack implementation in a host's BOOTP 
or PXE ROM does not (or fails to properly) implement IP fragmentation and reassembly.


#770 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3042 posts
  • Location:Nantes - France
  •  
    France

Posted 07 February 2018 - 10:53 AM

An interesting article about possible blocksize and windowsize values and performances.

 

http://ccmexec.com/2...n-manager-1606/

 

TFTPSettings.PNG



#771 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3042 posts
  • Location:Nantes - France
  •  
    France

Posted 07 February 2018 - 10:57 AM

 

@erwan.l
 
 
About dynamic configuration switch:
 
And why not Ctrl-I : for switching ini (I for ini, such as Ctrl-R for refresh interfaces).
After Ctrl-I, dialog popup with :
- combo-box + "browse" button to choose *.ini file in same directory as pxeserv.exe (similar to current boot filename combo-box).
- button Validate or Cancel. Cancel: do nothing. If Validate: load settings from the selected ini file and automatic Offline/Online. With the new request 1) below, user is informed of the actual configuration file applied.
 
New request 1): At startup: display what is the active configuration file used (default: config.ini).
New request 2): At startup: display a short line: "Ctrl-R: refresh interfaces, Ctrl-I: switch configuration" at startup time to remind user of these hotkeys.
 
New request 3): (nice to have only, far from vital) Add command line option -i to use which ini file at startup. No -i option or not found/invalid file: use default config.ini.

 

I should be able to implement that rather quickly.

Your request is well written so I'll follow it by the book :)



#772 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 07 February 2018 - 07:27 PM



 

Happy it works out for you :)

 

Adding a "map" feature to Tiny PXE Server was a good thing : it should cover a few other scenarios.

 

About your config.ini you can probably make it simpler like below.

boot\boot.sdi being common to all distributions, you could leave it in the root folder.

EFI folders (00006,00007,00009) can probably be treated as one EFI folder '0000X'.

[MAP]
\EFI\Microsoft\boot\=\00007\EFI\Microsoft\boot\
\boot\resources\=\00000\boot\resources\
\boot\fonts\=\00000\boot\fonts\
\boot\en-US\=\00000\boot\en-US\
\boot\boot.sdi=\00000\boot\boot.sdi
By trials, I discover that the [map] section is in fact a list of string substitutions changing on the fly the requests coming from PXE client.
I had problem with this map rule: "\EFI\Microsoft\boot\=\00007\EFI\Microsoft\boot\".
With this map rule, there is no problem in CSM (Legacy) mode where there is no \EFI string, but in UEFI mode, 
there is a collision between "\boot\fonts\=" and "\EFI\Microsoft\boot\=" when a request
for \EFI\Microsoft\boot\fonts\wgl4_boot.ttf arrives (this font is seemingly requested only in EFI mode).
It appears that TPS uses "\boot\fonts\=" map rule to substitute (instead of using "\EFI\Microsoft\boot\=" map rule), resulting in 
file name \EFI\Microsoft\00000\boot\fonts\wgl4_boot.ttf which does not exist. So there is a priority order in map rules substitution
done by TPS which breaks things. This is why I guess matso had to use several explicit rules like
"\EFI\Microsoft\boot\fonts\wgl4_boot.ttf=\00007\EFI\Microsoft\boot\fonts\wgl4_boot.ttf"
although they do not seem to be optimized.
 
18:35:55 TFTPd:DoReadFile OpenError:\EFI\Microsoft\00000\boot\fonts\wgl4_boot.ttf Cannot open file "S:\PXE\EFI\Microsoft\00000\boot\fonts\wgl4_boot.ttf". Le chemin d'accès spécifié est introuvable
 
With modified "\EFI\Microsoft\=\00007\EFI\Microsoft\" map rule, there is no more collision, and it works:
18:40:37 TFTPd:DoReadFile:\00007\EFI\Microsoft\Boot\Fonts\wgl4_boot.ttf B:0 T:49083
It works also thanks to \00006\EFI\Microsoft\ and \00007\EFI\Microsoft\ content which seem to be compatible
(only fonts *.ttf, *.mui, *.p7b, and bootres.dll).
 
 
[arch]
00000=\00000\undionly.kpxe
00006=\00006\bootia32.efi
00007=\00007\bootx64.efi
[map]
\EFI\Microsoft\=\00007\EFI\Microsoft\
\boot\boot.sdi=\00000\boot\boot.sdi
\boot\en-US\=\00000\boot\en-US\
\boot\fr-FR\=\00000\boot\fr-FR\
\boot\fonts\=\00000\boot\fonts\
\boot\resources\=\00000\boot\resources\
[dhcp]
opt252=@arch\BCD
 
bcd points to \00007\sources\boot.wim
 
18:38:36 ROOT=S:\PXE\
18:38:36 DHCPd 192.168.145.1:67 started...
18:38:36 DHCPd 192.168.145.1:4011 started...
18:38:36 TFPTd 192.168.145.1:69 started...
18:38:37 HTTPd:80 started...
18:38:53 DHCPd:DISCOVER received, MAC:00-0C-29-5E-E2-58, XID:860C1CC5
18:38:53 DHCPd:OFFER sent, IP:0.0.0.0, XID:860C1CC5
18:38:57 DHCPd:REQUEST discarded, MAC:00-0C-29-5E-E2-58, XID:860C1CC5
18:38:57 PDHCPd:REQUEST received, MAC:00-0C-29-5E-E2-58, IP:192.168.145.136, XID:28C8ACE8
18:38:57 Proxy boot filename empty?
18:38:57 PDHCPd:DHCP_ACK sent, IP:192.168.145.136:4011, xid:28C8ACE8
18:38:58 TFTPd:DoReadFile:\00007\bootx64.efi B:1468 T:1252248
18:38:58 TFTPd:DoReadFile:\00007\bootx64.efi B:1468 T:0
18:38:58 TFTPd:DoReadFile:\00007\BCD B:0 T:24576
18:38:58 TFTPd:DoReadFile:\00007\BCD B:1456 T:24576
18:38:58 TFTPd:DoReadFile OpenError:\00007\EFI\Microsoft\Boot\Policies\SbcpFlightToken.p7b Cannot open file "S:\PXE\00007\EFI\Microsoft\Boot\Policies\SbcpFlightToken.p7b". Le chemin d'accès spécifié est introuvable
18:38:58 TFTPd:DoReadFile OpenError:\00007\EFI\Microsoft\Boot\SecureBootPolicy.p7b Cannot open file "S:\PXE\00007\EFI\Microsoft\Boot\SecureBootPolicy.p7b". Le fichier spécifié est introuvable
18:38:58 TFTPd:DoReadFile OpenError:\00007\EFI\Microsoft\Boot\SkuSiPolicy.p7b Cannot open file "S:\PXE\00007\EFI\Microsoft\Boot\SkuSiPolicy.p7b". Le fichier spécifié est introuvable
18:38:58 TFTPd:DoReadFile OpenError:\00007\EFI\Microsoft\Boot\SiPolicy.p7b Cannot open file "S:\PXE\00007\EFI\Microsoft\Boot\SiPolicy.p7b". Le fichier spécifié est introuvable
18:38:58 TFTPd:DoReadFile OpenError:\00007\EFI\Microsoft\Boot\UpdateSkuSiPolicy.p7b Cannot open file "S:\PXE\00007\EFI\Microsoft\Boot\UpdateSkuSiPolicy.p7b". Le fichier spécifié est introuvable
18:38:58 TFTPd:DoReadFile OpenError:\00007\EFI\Microsoft\Boot\UpdateSiPolicy.p7b Cannot open file "S:\PXE\00007\EFI\Microsoft\Boot\UpdateSiPolicy.p7b". Le fichier spécifié est introuvable
18:38:58 TFTPd:DoReadFile OpenError:\00007\EFI\Microsoft\Boot\WinSiPolicy.p7b Cannot open file "S:\PXE\00007\EFI\Microsoft\Boot\WinSiPolicy.p7b". Le fichier spécifié est introuvable
18:38:58 TFTPd:DoReadFile OpenError:\00007\EFI\Microsoft\Boot\UpdateWinSiPolicy.p7b Cannot open file "S:\PXE\00007\EFI\Microsoft\Boot\UpdateWinSiPolicy.p7b". Le fichier spécifié est introuvable
18:38:58 TFTPd:DoReadFile OpenError:\00007\EFI\Microsoft\Boot\ATPSiPolicy.p7b Cannot open file "S:\PXE\00007\EFI\Microsoft\Boot\ATPSiPolicy.p7b". Le fichier spécifié est introuvable
18:38:58 TFTPd:DoReadFile OpenError:\00007\EFI\Microsoft\Boot\UpdateATPSiPolicy.p7b Cannot open file "S:\PXE\00007\EFI\Microsoft\Boot\UpdateATPSiPolicy.p7b". Le fichier spécifié est introuvable
18:38:58 TFTPd:DoReadFile OpenError:\00007\EFI\Microsoft\Boot\EntRevokeSiPolicy.p7b Cannot open file "S:\PXE\00007\EFI\Microsoft\Boot\EntRevokeSiPolicy.p7b". Le fichier spécifié est introuvable
18:38:58 TFTPd:DoReadFile OpenError:\00007\EFI\Microsoft\Boot\UpdateEntRevokeSiPolicy.p7b Cannot open file "S:\PXE\00007\EFI\Microsoft\Boot\UpdateEntRevokeSiPolicy.p7b". Le fichier spécifié est introuvable
18:38:58 TFTPd:DoReadFile OpenError:\00007\en-US\bootx64.efi.MUI Cannot open file "S:\PXE\00007\en-US\bootx64.efi.MUI". Le chemin d'accès spécifié est introuvable
18:38:58 TFTPd:DoReadFile:\00007\bootx64.efi B:0 T:1252248
18:38:58 TFTPd:DoReadFile:\00007\bootx64.efi B:1456 T:1252248
18:38:59 TFTPd:DoReadFile OpenError:\00007\boot.stl Cannot open file "S:\PXE\00007\boot.stl". Le fichier spécifié est introuvable
18:38:59 TFTPd:DoReadFile:\00007\sources\boot.wim B:0 T:585619746
18:38:59 TFTPd:DoReadFile:\00000\boot\boot.sdi B:0 T:3170304
18:38:59 TFTPd:DoReadFile:\00000\boot\fonts\segoe_slboot.ttf B:0 T:86118
18:38:59 TFTPd:DoReadFile:\00000\boot\fonts\segoe_slboot.ttf B:16384 T:86118
18:38:59 TFTPd:DoReadFile:\00000\boot\fonts\segmono_boot.ttf B:0 T:44798
18:38:59 TFTPd:DoReadFile:\00000\boot\fonts\segmono_boot.ttf B:16384 T:44798
18:38:59 TFTPd:DoReadFile:\00000\boot\resources\bootres.dll B:0 T:92568
18:38:59 TFTPd:DoReadFile:\00000\boot\resources\bootres.dll B:16384 T:92568
18:38:59 TFTPd:DoReadFile:\00007\EFI\Microsoft\Boot\Fonts\wgl4_boot.ttf B:0 T:49083
18:38:59 TFTPd:DoReadFile:\00007\EFI\Microsoft\Boot\Fonts\wgl4_boot.ttf B:16384 T:49083
18:38:59 TFTPd:DoReadFile:\00000\boot\boot.sdi B:16384 T:3170304
18:38:59 TFTPd:DoReadFile:\00007\sources\boot.wim B:16384 T:585619746
 


#773 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3042 posts
  • Location:Nantes - France
  •  
    France

Posted 07 February 2018 - 08:09 PM

@ktp

 

"By trials, I discover that the [map] section is in fact a list of string substitutions changing on the fly the requests coming from PXE client."

True

 

"So there is a priority order in map rules substitution done by TPS which breaks things. "

True

 

I shall add :

-one TPS finds a match and substitue : it will stop looking for other matches for that string

-if the after is contained in the before, it will not substiture and will also stop looking for other matches for that string - exemple EFI=00007\EFI will not happen it the string is actuallu 00007\EFI\BOOT\BCD to avoid ending with 00007\00007\EFI\BOOT

 

Side note : are you getting messages in french? "Le chemin d'accès spécifié est introuvable" ?*

Is it TPS or you are actually french? :)



#774 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 07 February 2018 - 08:17 PM

@erwan.l

 

Je suis Français !

 

I guess the French message "Le chemin d'accès spécifié est introuvable" ?* ("Unknown path") comes from my French Windows 10 laptop and not from TPS.

 



#775 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 08 February 2018 - 07:03 PM

@ktp

 

"By trials, I discover that the [map] section is in fact a list of string substitutions changing on the fly the requests coming from PXE client."

True

 

"So there is a priority order in map rules substitution done by TPS which breaks things. "

True

 

I shall add :

-one TPS finds a match and substitue : it will stop looking for other matches for that string

-if the after is contained in the before, it will not substiture and will also stop looking for other matches for that string - exemple EFI=00007\EFI will not happen it the string is actuallu 00007\EFI\BOOT\BCD to avoid ending with 00007\00007\EFI\BOOT

 

Side note : are you getting messages in french? "Le chemin d'accès spécifié est introuvable" ?*

Is it TPS or you are actually french? :)

@erwan.l
 
As I said in previous post, With either map rule order: 
[map]
\EFI\Microsoft\=\00007\EFI\Microsoft\
\boot\fonts\=\00000\boot\fonts\
 
or
 
[map]
\boot\fonts\=\00000\boot\fonts\
\EFI\Microsoft\=\00007\EFI\Microsoft\
 
When a request for \EFI\Microsoft\boot\fonts\wgl4_boot.ttf arrives (there is match in each of the 2 rules),
TPS today unfortunately subsitutes to \EFI\Microsoft\00000\boot\fonts\wgl4_boot.ttf which is bad,
giving
18:39:01 TFTPd:DoReadFile OpenError:\EFI\Microsoft\00000\boot\fonts\wgl4_boot.ttf Cannot open file "S:\PXE\EFI\Microsoft\00000\boot\fonts\wgl4_boot.ttf". Le chemin d'accès spécifié est introuvable
 
Could the substitution rules be changed to the following:
- apply all string substitutions from the list, top to down as indicated by the user in [map] (top down priority).
- only one substitution: if found, quit.
 
With this, When a request for \EFI\Microsoft\boot\fonts\wgl4_boot.ttf arrives,
due to top down priority, "\EFI\Microsoft\=\00007\EFI\Microsoft\" rule will be applied first (and only this rule),
resulting in good "\00007\EFI\Microsoft\boot\fonts\wgl4_boot.ttf" final string.






Also tagged with one or more of these keywords: pxe, network boot

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users