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

@glendon00
Firstly - my apologies for stating earlier that...
... the ${keep-san} variable (and possibly some of the others in your post) is set by ipxe during the boot process and is defined - I'm still learning too!

In regards to your setup and source files - there are lots of unknowns so there is a large element of guesswork in responding to your questions.
The term bartpe covers a multitude of sins - flat boot or ramloading? If ramloading - which ramdisk/driver?

BartPE is a WinPE 1.* build (using Windows XP or 2003 as source) - it does not natively support iSCSI and will not be able to find the target - hence failing to boot. I have no idea whether it's possible to integrate an iSCSI initiater into WinPE 1.*, however even if you can you are likely to have problems SAN booting any WinPE from a target on your server - unless maybe the network adapter is manually configured in the WinPE registry before booting starts.

A WinPE 2.* ISO is very easy to SANBOOT as the required files (boot.wim and boot.sdi) are loaded into RAM on the client system during the initial stages of boot - the files are therefore still detected even if the SAN is not found.

Most likely method of successfully SAN booting a bartPE iso is to use the RAM loading method with WIndows 2003 SP1 ramdisk files (google here and on the 911cd forum).

Regards,

Misty

P.s. reboot12 has made a valid point - please do consider starting a new thread(s) for any off topic posts.

How kind and thoughtful your apologies were. I understood where you were coming from though, they were confusing entries and I should have cleaned up the sample better. I guess I don't need to add that I am still learning, eh? <smile>

In regards to flat boot or ramloading, I don't know. I can't even remember where that bartpe.iso came from or how it was created. But I have the same problem with floppy image files or Hiren's UBCD4WIN, etc. I thought that at least a floppy boot image file would make a good iSCSI target for remote booting. I see I have much more to learn.

I suppose I was beguiled by the hype that an iSCSI target was just like having the remote drive as a local one. But then there are all those pesky little details. Sigh…

OK, I'll search on the info you suggested and see what I can learn.

Thanks for the guidance and have a wonderful day!

Glen

pxesrv.exe version 1.0.0.20
Jan 23, 2017 - 21:07
CRC32: 5955B7B8

Host OS has two network connection static IP, different subnet:

1. real Wifi - with setting gateway and DNS

2. virtual VMware VMnet1 Host-only - without setting the gateway and DNS

I use VMware connection with virtual machines for LAN networking only.

TPS default runs with Wifi interface and all settings OK but if change the interface to the VMware (Option 54), TPS does not clean Option 6 (DNS Server) and IP is from previous interface. Only Option 3 (Router) is cleaned - set to 0.0.0.0.

I think that Option 6 (DNS Server) also should be cleaned - set to 0.0.0.0

pxesrv.exe version 1.0.0.20
Jan 23, 2017 - 21:07
CRC32: 5955B7B8

 

Host OS has two network connection static IP, different subnet:

 

1. real Wifi - with setting gateway and DNS

2. virtual VMware VMnet1 Host-only - without setting the gateway and DNS

 

I use VMware connection with virtual machines for LAN networking only.

 

TPS default runs with Wifi interface and all settings OK but if change the interface to the VMware (Option 54), TPS does not clean Option 6 (DNS Server) and IP is from previous interface. Only Option 3 (Router) is cleaned - set to 0.0.0.0.

 

I think that Option 6 (DNS Server) also should be cleaned - set to 0.0.0.0

Good catch !

My function was always returning the system DNS instead of the NIC DNS.

Fixed !

Tiny PXE Server version 1.0.0.20
Jan 29, 2017 - 13:42
CRC32: 59268361
MD5: 70E3EBE997A738CF5D4FB93F381F4EDF
SHA-1: EF78C8293F691202346B1E18EE3D2B2A913482DE

"...For the sake of backwards compatibility, you can use the keep-san setting to prevent iPXE from detaching a SAN drive, and you can use the skip-san-boot setting to prevent iPXE from booting from a SAN drive. The combination of both of these settings provides functionality which is approximately equivalent to the sanhook command...."

Hi all,

I'm a bit confused by the numerous instructions to use gpxe encapsulated commands (optextra=175.6.1.1.1.8.1.1) when booting from an iSCSI (and possibly AoE) Target.

These commands appear to set keep-san as 1. The iPXE documantation for the SANBOOT command (http://ipxe.org/cmd/sanboot) states -

I was able to successfully boot AoE and iSCSI targets without using any optextra settings - with and without setting keep-san 1 in my iPXE configuration files.

I'm confused. Specifying additional settings that do not appear to be required does not comply with the KISS principle.



Anyone have any thoughts on this matter?

Regards

Misty

Yes! I'm glad to know that I am not the only one that found that confusing. Thanks for putting it out there. When I read it I just thought it was my ignorance that made it confusing. When Misty is confused it is confusing indeed. Maybe now someone can clarify, and simplify things a bit.

Glen

There seems to be an issue in 1.0.0.20 (and earlier?) where the Boot File name specified in the GUI is still present in the initial proxyDHCP reply on port 68 even when an override is specified in the [arch] section of config.ini. The correct filename is present in the 4011 reply. This normally works fine, but I have a device that attempts to use the incorrect file.

Is this something that could be fixed?

The client identifies itself as PXEClient:Arch:00007 and 00007 is set to ipxe.efi in the config.

Thanks

There seems to be an issue in 1.0.0.20 (and earlier?) where the Boot File name specified in the GUI is still present in the initial proxyDHCP reply on port 68 even when an override is specified in the [arch] section of config.ini. The correct filename is present in the 4011 reply. This normally works fine, but I have a device that attempts to use the incorrect file.

 

Is this something that could be fixed?

 

The client identifies itself as PXEClient:Arch:00007 and 00007 is set to ipxe.efi in the config.

 

 

Thanks

Nice catch.

I believe Iunderstand the issue.

However, to be sure I reproduce it correctly at home, can you share your config.ini file?

And a wireshark trace would be perfect

Bug is indeed probably there since I introduced the arch option (which was a painful process).

Nice catch.

 

I believe Iunderstand the issue.

However, to be sure I reproduce it correctly at home, can you share your config.ini file?

And a wireshark trace would be perfect

 

Bug is indeed probably there since I introduced the arch option (which was a painful process).

I will PM you the wireshark trace. For some reason the Port 4011 stuff does not show up in wireshark using the bootp filter from an UEFI client. It does from a BIOS client.

Here is my Tiny PXE Server config:

[arch]
;will over rule the bootp filename or opt67 if the client arch matches one of the below
00006=ipxe.efi
00007=ipxe.efi
[dhcp]
;needed to tell TFTPd where is the root folder
root=bootfiles
;bootp filename as in http://tools.ietf.org/html/rfc951
;filename=ipxe-undionly.kpxe
filename=undionly.kpxe
;alternative bootp filename if request comes from ipxe or gpxe
;altfilename=menu.ipxe
;start HTTPd
httpd=0
binl=0
start=0
dnsd=0
proxydhcp=1
;default=1
bind=1
;tftpd=1 by default
;will share (netbios) the root folder as PXE
smb=0
;will log to log.txt
log=0
;opt1=
;opt3=
;opt6=
;opt28=
;opt15=
;opt17=
;opt43=
;opt51=
;opt54=
;opt67=
;opt66=
;opt252=
;poolstart=
;poolsize=
;alternative bootp filename if request comes thru proxydhcp (udp:4011)
;proxybootfilename=
;any extra dhcp options
;my gpxe / ipxe dhcp options
;optextra=175.6.1.1.1.8.1.1
;the below will be executed when clicking on the online button
;cmd=_test.bat
;if log=1, will log to log.txt
log=0
[frmDHCPServer]
top=67
left=13

 

I will PM you the wireshark trace. For some reason the Port 4011 stuff does not show up in wireshark using the bootp filter from an UEFI client. It does from a BIOS client.

 

Here is my Tiny PXE Server config:

[arch]
;will over rule the bootp filename or opt67 if the client arch matches one of the below
00006=ipxe.efi
00007=ipxe.efi
[dhcp]
;needed to tell TFTPd where is the root folder
root=bootfiles
;bootp filename as in http://tools.ietf.org/html/rfc951
;filename=ipxe-undionly.kpxe
filename=undionly.kpxe
;alternative bootp filename if request comes from ipxe or gpxe
;altfilename=menu.ipxe
;start HTTPd
httpd=0
binl=0
start=0
dnsd=0
proxydhcp=1
;default=1
bind=1
;tftpd=1 by default
;will share (netbios) the root folder as PXE
smb=0
;will log to log.txt
log=0
;opt1=
;opt3=
;opt6=
;opt28=
;opt15=
;opt17=
;opt43=
;opt51=
;opt54=
;opt67=
;opt66=
;opt252=
;poolstart=
;poolsize=
;alternative bootp filename if request comes thru proxydhcp (udp:4011)
;proxybootfilename=
;any extra dhcp options
;my gpxe / ipxe dhcp options
;optextra=175.6.1.1.1.8.1.1
;the below will be executed when clicking on the online button
;cmd=_test.bat
;if log=1, will log to log.txt
log=0
[frmDHCPServer]
top=67
left=13

Got it thanks.

Looking at my code right now.

Probably not linked but in case you are dealing with "native" bootp client, worth adding rfc951=1 in your config file.

Also, in proxy dhcp mode, if the client is a pxeclient (information included in the dhcp packet), TPS will not send a dhcp offer on udp:68 to an incoming discover packet coming on udp:67, it will simply ignore/discard it (per RFC).

case status of
1://DISCOVER
  begin
  if chkproxydhcp.Checked then
  begin
  //PXEClient
  p:=#$50#$58#$45#$43#$6c#$69#$65#$6e#$74; //PXEClient
  is_pxeclient:=false;
  for offset:=0 to 254-9 do
  begin
  if comparemem(@vend[offset],@p[0],9) then
    begin
    is_pxeclient:=true;
    break;
    end; //if comparemem
  end;//for
  //send dhcp_offer in proxydhcp mode only if request comes from a PXEClient
  if is_pxeclient =false then
    begin
    if skip_dhcp_discarded ='0' then log_memo('DHCPd:DISCOVER discarded, MAC:'+smac+', XID:'+inttohex(ntohl(pkt.xid),4));
    goto fin; //exit;
  end;
  end; //if chkproxydhcp.Checked then

 

Got it thanks.

Looking at my code right now.

 

Probably not linked but in case you are dealing with "native" bootp client, worth adding rfc951=1 in your config file.

 

Also, in proxy dhcp mode, if the client is a pxeclient (information included in the dhcp packet), TPS will not send a dhcp offer on udp:68 to an incoming discover packet coming on udp:67, it will simply ignore/discard it (per RFC).

Thanks for looking into this. I added rfc951=1 but still see the erroneous bios file specified in the initial reply when booting an EFI system.

You obviously know a lot more about this than me, but I thought a proxy dhcp server was suppose to respond initially on port 68 with an IP of 0.0.0.0 and Option 60 set to PXEClient. Then a new Request/Acknowledgment happens over port 4011 with the boot file information. At least that is what I have always observed on a successful boot.

Hi,

Based on the D.O.R.A process (discover, offer, request, ack), my reading :

-in proxydchp mode, the server will ignore "discover" (incoming on udp:67), i.e will not send "offer"

-in proxydhcp mode, the server will answer "request" (incoming on udp:67), i.e will send "ack (incoming udp:4011)

In the capture you sent me, it looks like we are not in proxydhcp mode but in plain dhcp mode.

Still, the original question remains, does the bootfilename in the initial offer matter? (whatever the dhcp mode we are in).

And if so, should not the bootfilename be consistent in the offer and in the ack?

Answer there should be 'yes' and therefore TPS has a bug : it does care about the architecture in the offer and therefore send the default bootfilename (i.e not the architecture one.

Regards,

Erwan

I have uploaded a new version : the architecture will be handled in the dhcp offer.

Give it a try and let me know.

I have uploaded a new version : the architecture will be handled in the dhcp offer.

 

Give it a try and let me know.

Thanks so much, that seems to have fixed the specific issue I was seeing!

In proxy mode, should any filename be present in the initial offer? It seems to cause some clients, including iPXE to skip the port 4011 stuff altogether. No idea if that is good or bad, but something I noticed when comparing wireshark traces from different servers/clients.

Thanks so much, that seems to have fixed the specific issue I was seeing!

 

In proxy mode, should any filename be present in the initial offer? It seems to cause some clients, including iPXE to skip the port 4011 stuff altogether. No idea if that is good or bad, but something I noticed when comparing wireshark traces from different servers/clients.

 

Good to hear it fixed your issue : in any case, the bootfilename should be consistent between the offer and the ack.

To answer your question, in proxymode, the server is not support to send an offer : it will ignore/discard it (and it will be reported in TPS).

TPS is coded to ignore the offer in proxymode IF the incoming packet contains OPT60=PXEClient.

To answer your question, in proxymode, the server is not support to send an offer : it will ignore/discard it (and it will be reported in TPS).

TPS is coded to ignore the offer in proxymode IF the incoming packet contains OPT60=PXEClient.

The OP may be correct that the behavior shown in his/her screenshot is not 100% compliant with the spec, even if it works in most (all?) cases. If I am understanding Figure 2-4 on page 18 of the PXE Spec document correctly, a filename should only be present in the 4011 ACK, not the initial Offer like he/she mentioned. After checking 3com Boot Services and WDS, I can confirm that both of these servers do not include a filename in their initial offers. With Tiny PXE Server, like the OP, I do see a filename in the initial offer in proxy mode.

iPXE seems to be aware that some servers behave this way and intentionally skips the rest of the proxy stuff in these cases, explaining why the last screenshot only shows an Offer from TPS, never a Request and ACK on port 4011. https://git.ipxe.org...1693de54b6ad43c

Keep up the great work. This really is an incredible project. I have been working with PXE for a long time and have never see a utility so easy to configure. Really impressive to be able to run TPS from a flash drive and start booting machines over the network immediately.

 This really is an incredible project. I have been working with PXE for a long time and have never see a utility so easy to configure. Really impressive to be able to run TPS from a flash drive and start booting machines over the network immediately.

To be fair, and not to take any merit away from erwan.l and his exceptionally good work, of course,  , in all my life I have rarely seen a tool (once excluded mkisofs command parameters of course ) with a more complex, difficult and hard to set correctly set of options/settings  (for anyone not having worked with PXE for a long time).

Just like with mkisofs it is the complexity (and sometime the misreading or misinterpretation) of the ISO9660  specs, it is the underlying complexity of the PXE specifications (and the lack or poor documentation for them) that create that, but even with the good work by Misty with the Guide, some (more than a few) things still look a lot like (white) magic to me. 

Wonko

To be fair, and not to take any merit away from erwan.l and his exceptionally good work, of course,  , in all my life I have rarely seen a tool (once excluded mkisofs command parameters of course ) with a more complex, difficult and hard to set correctly set of options/settings  (for anyone not having worked with PXE for a long time).

 

Just like with mkisofs it is the complexity (and sometime the misreading or misinterpretation) of the ISO9660  specs, it is the underlying complexity of the PXE specifications (and the lack or poor documentation for them) that create that, but even with the good work by Misty with the Guide, some (more than a few) things still look a lot like (white) magic to me. 

 

Wonko

Actually you summarized it well : between the numerous possible pxe settings and the broken implementation out there, I had to introduce a lot of tweaks to bring flexibility but this is having a cost : complexity.

However, for next version, I am planning to simplify it : I want TPS to work "as is", i.e without the user to have to enter any specific setting.

Some sort of "plug and play".

I will hide more fields and these will be in advanced section.

The OP may be correct that the behavior shown in his/her screenshot is not 100% compliant with the spec, even if it works in most (all?) cases. If I am understanding Figure 2-4 on page 18 of the PXE Spec document correctly, a filename should only be present in the 4011 ACK, not the initial Offer like he/she mentioned. After checking 3com Boot Services and WDS, I can confirm that both of these servers do not include a filename in their initial offers. With Tiny PXE Server, like the OP, I do see a filename in the initial offer in proxy mode.

 

iPXE seems to be aware that some servers behave this way and intentionally skips the rest of the proxy stuff in these cases, explaining why the last screenshot only shows an Offer from TPS, never a Request and ACK on port 4011. https://git.ipxe.org...1693de54b6ad43c

 

Keep up the great work. This really is an incredible project. I have been working with PXE for a long time and have never see a utility so easy to configure. Really impressive to be able to run TPS from a flash drive and start booting machines over the network immediately.

Thanks for this positive feedback, much appreciated.

My current reading (and implementation) of the proxydhcp mode is the following : 

If the client is a "pxeclient" (string/information included in the dhcp packet), TPS will not send a dhcp offer on udp:68 to an incoming discover packet coming on udp:67, it will simply ignore/discard it.

Your reading is slightly different :

there should be an offer sent back but without the boot filename.

I will review the RFC and ensure I am compliant.

Now, the extra difficult is that clients out there (including iPXE) have their own reading as well so it does not make things easy to test

To be fair, and not to take any merit away from erwan.l and his exceptionally good work, of course,  , in all my life I have rarely seen a tool (once excluded mkisofs command parameters of course ) with a more complex, difficult and hard to set correctly set of options/settings  (for anyone not having worked with PXE for a long time).

 

Just like with mkisofs it is the complexity (and sometime the misreading or misinterpretation) of the ISO9660  specs, it is the underlying complexity of the PXE specifications (and the lack or poor documentation for them) that create that, but even with the good work by Misty with the Guide, some (more than a few) things still look a lot like (white) magic to me. 

 

Wonko

Have you tried the original Intel PXE Utility? Now that was complicated. I remember spending days trying to get that working properly back in the day. 3com Boot Services was better, but still quite difficult to setup compared to Tiny PXE Server. Many tasks required editing the bootptab file manually.

Looks like there is some screenshots and a download link to the original Intel PXE server on this site: http://www.k62.net/PXE-ND.php

TPS 1.0.0.20 CRC-32: 59268361 - DHCP iPXE error 0x040ee119. After change to TPS 1.0.0.19 CRC-32: 4d797981 DHCP OK:
 tps_dhcp.png   15.97KB   0 downloads
Tested on MS VPC 2007 SP1 with iPXE on virtual VMware VMNet Host-only interface
 
config.ini
=======

[dhcp]
;for Netboot working
rfc951=1

root=C:\PXE
filename=pxelinux.0
httpd=1
binl=0
;start=1
dnsd=0
proxydhcp=0
bind=0
smb=0
log=0
cmd=freenfs.exe
offline=freenfs_off.bat

;for RIS client working (for TPS 1.0.0.11 need opt43)
;opt43=0.0.0.0
opt60=PXEClient
optextra=43.7.1.4.0.0.0.0.255

[web]
port=80

[frmDHCPServer]
top=38
left=499

The error occurs only sometimes.

TPS 1.0.0.20 CRC-32: 59268361 - DHCP iPXE error 0x040ee119. After change to TPS 1.0.0.19 CRC-32: 4d797981 DHCP OK:
tps_dhcp.png
Tested on MS VPC 2007 SP1 with iPXE on virtual VMware VMNet Host-only interface
 
config.ini
=======

[dhcp]
;for Netboot working
rfc951=1

root=C:\PXE
filename=pxelinux.0
httpd=1
binl=0
;start=1
dnsd=0
proxydhcp=0
bind=0
smb=0
log=0
cmd=freenfs.exe
offline=freenfs_off.bat

;for RIS client working (for TPS 1.0.0.11 need opt43)
;opt43=0.0.0.0
opt60=PXEClient
optextra=43.7.1.4.0.0.0.0.255

[web]
port=80

[frmDHCPServer]
top=38
left=499

The error occurs only sometimes.

can you try with bind=1 and share a wireshark trace?

do you need optextra=43.7.1.4.0.0.0.0.255 ? can not you smply use the opt 43 subopt 1 option in TPS ?

more details about your error here : http://ipxe.org/err/040ee1 .

could it be that you have an other dhcp server on your network (try proxydhcp may be?).

Strange but option Bind IP is selected in GUI but in config.ini bind=0 ???

VMnet interface is in a different subnet than the interface Wifi.

Strange but option Bind IP is selected in GUI but in config.ini bind=0 ???

VMnet interface is in a different subnet than the interface Wifi.

TPS will enable bind (in the GUI) if multiple interfaces are detected, even if bind=0 in config.ini .

Following Misty's thread around compiling iPXE, i have recompiled it all and updated Tiny PXE Server zip file.

iPXE version is 30f9 .

Below my general config.

For BIOS

For EFI

Console.h

Hi all,

I'm a bit confused by the numerous instructions to use gpxe encapsulated commands (optextra=175.6.1.1.1.8.1.1) when booting from an iSCSI (and possibly AoE) Target.

These commands appear to set keep-san as 1. The iPXE documantation for the SANBOOT command (http://ipxe.org/cmd/sanboot) states -

I was able to successfully boot AoE and iSCSI targets without using any optextra settings - with and without setting keep-san 1 in my iPXE configuration files.

I'm confused. Specifying additional settings that do not appear to be required does not comply with the KISS principle.



Anyone have any thoughts on this matter?

Regards

Misty

More details here : http://ipxe.org/howto/dhcpd .

You can push multiple dhcp options to iPXE.

optextra=175.6.1.1.1.8.1.1 mean option 175, length of options = 6, 1.1.1 means priority (1) length=1 value=1, 8.1.1 means keep-san (8) length=1 value=1

priority is about dhcp : if more than one server replies, ipxe should give the priority to TPS since it is requesting so.