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

Correct, with one exception there : you currently need to hard code the ip, the username, password, etc ...
If you change any of these items in your environement, or move to another computer, go to a friend, etc, you have to redo your image.

OK, now understand but such a scenario is highly unlikely. I always use Tiny PXE Server installed and configured on my laptop. WINDOWS of my friend is damaged

About the ProxyDHCP...

What data TinyPXE inject over the DHCP info that is obtained from the main DHCP server ??

?have a link for a manual

If it injects only over fields that are not assigned by the main DHCP

?is there a option to override some fields (choosen by me of course)

About DNSd

?where can I get more info on configuration

did it recurses over the next server when name is not found?

About the ProxyDHCP...

 

What data TinyPXE inject over the DHCP info that is obtained from the main DHCP server ??

 

?have a link for a manual

 

If it injects only over fields that are not assigned by the main DHCP

?is there a option to override some fields (choosen by me of course)

Here below the options that may be part of the of the proxy dhcp answer from TPS

option54
option13 (if bootp filename<>'')
option17
option43
option60
option66
option67
option97 (if the client sent one)
option252
any other option in opt extra field

About DNSd

 

?where can I get more info on configuration

 

did it recurses over the next server when name is not found?

If DNSd is enabled, on any hostname query that comes in, TPS will first look in config.ini, and if not found will hand over the query to the system (which will then use whatever dns server has been set).

That can be handy to write a batch that will not depend on hardcoded IP's but rather on a hostname which I can always reuse whatever my network config is (that scenario would work only in plain dhcp mode, not in proxydhcp mode).

Example, "repository.local" hostname dns query comes in, TPS will look for the below in config.ini and will resolve to 192.168.1.100.

Note that this would work also for hostnames such as www.facebook.com, etc and would be seen as DNS hijacking.

[repository.local]
ip=192.168.1.100

Note that this would work also for hostnames such as www.facebook.com, etc and would be seen as DNS hijacking.

[repository.local]
ip=192.168.1.100

can you provide a link to info about these DNS configurations...
or better... some diverse examples...

​

​Thx

I try boot from VMware Workstation 8 EFI but no success. I use this file http://boot.ipxe.org/ipxe.efi in root folder after rename to bootx64.efi, TPS 1.0.0.21. This is my config.ini:

[arch]
00006=bootia32.efi
00007=bootx64.efi

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

root=C:\PXE
filename=bootx64.efi
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
opt60=PXEClient
;optextra=43.7.1.4.0.0.0.0.255

[web]
port=80

In TPS logs I noticed this:

19:31:01 DHCPd:Arch=00009

I test also other PXE server runing on OpenWrt CC router and VMware boot OK with same ipxe.efi file:

 openwrt_ok.gif   10.3KB   0 downloads

I try boot from VMware Workstation 8 EFI but no success. I use this file http://boot.ipxe.org/ipxe.efi in root folder after rename to bootx64.efi, TPS 1.0.0.21. This is my config.ini:

[arch]
00006=bootia32.efi
00007=bootx64.efi

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

root=C:\PXE
filename=bootx64.efi
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
opt60=PXEClient
;optextra=43.7.1.4.0.0.0.0.255

[web]
port=80

In TPS logs I noticed this:

19:31:01 DHCPd:Arch=00009

I test also other PXE server runing on OpenWrt CC router and VMware boot OK with same ipxe.efi file:

openwrt_ok.gif

I see that ipxe.efi gets downloaded so this is a good start.

I would need TPS log files.

Just one idea : try removing opt60=PXEClient.

See post which looks similar to what you are trying to achieve.

I see that ipxe.efi gets downloaded so this is a good start.

I would need TPS log files.

Just one idea : try removing opt60=PXEClient.

Yes, after remove opt60 EFI boot working and no need [arch] section in config.ini

There is another matter. Probably option Bind IP work only with BIOS firmware and not work with EFI firmware (maybe only VMware)

VMware with BIOS firmware boot from Tiny PXE (DHCP)

VMware with EFI firmware boot from my OpenWrt router (DHCP)

To workaround problem I need disable option Authoritative in OpenWrt DHCP settings and restart router:

 openwrt_authoritative.png   11.58KB   0 downloads

or disconnect OpenWrt router from network.

Yes, after remove opt60 EFI boot working and no need [arch] section in config.ini
 
There is another matter. Probably option Bind IP work only with BIOS firmware and not work with EFI firmware (maybe only VMware)
 
VMware with BIOS firmware boot from Tiny PXE (DHCP)
VMware with EFI firmware boot from my OpenWrt router (DHCP)
 
To workaround problem I need disable option Authoritative in OpenWrt DHCP settings and restart router:
openwrt_authoritative.png
or disconnect OpenWrt router from network.

Two DHCP servers fighting on your lan.
Use optextra=175... to try to win the battle.

Maybe this help but with BIOS firmware I did not have to use optextra. This is only for EFI.

Maybe this help but with BIOS firmware I did not have to use optextra. This is only for EFI.

Thing is because you have two dhcp servers on your LAN, you will get inconsistent behaviors.

Different boot loaders (bios or UEFI) will react differently to different dhcp servers.

Adding optextra=175.6.1.1.1.8.1.1 will instruct IPXE to use Tiny PXE Server before any other DHCP server on your LAN.

However I cannot guarantee that your initial boot loader (bios or UEFI) will always pick Tiny PXE Server first : OpenWRT may be quicker to respond and/or vmware may "prefer" OpenWRT over Tiny PXE Server.

In your situation, you should have a "basic" DHCP server and a proxy dhcp server OR one unique PXE/DHCP Server.

 

 

There is another matter. Probably option Bind IP work only with BIOS firmware and not work with EFI firmware (maybe only VMware)

The boot loader (BIOS or UEFI) does not care about the server binding or not.

What this means is that you are probably "listening" on the wrong interface/ip.

This is a common setup mistake when playing with vmware workstation (or virtualbox).

These use multiple virtual interfaces (bridge, host-only or NAT) and it is easy to pick (listen to) the wrong one.

Unselecting "bind ip" makes it so that Tiny PXE Server will try to listen to all interfaces but here again you will get inconsistent results.

Not to mention that in host only and nat mode, vmware also acts as a dhcp server thus impacting your DHCP/PXE boot process ...

I personally always go for bridge (my default LAN interface).

In your situation, you should have a "basic" DHCP server and a proxy dhcp server OR one unique PXE/DHCP Server.

The boot loader (BIOS or UEFI) does not care about the server binding or not.

I personally always go for bridge (my default LAN interface).

TPS is cool software but I run it only during installation e.g. Windows over wimboot. TPS does not work non-stop. As I wrote, instead of set optextra disable Authoritative option on OpenWrt.
Yes, Bind IP does not apply to my problem.
Yes, I also only use Bridged mode and disable the DHCP server in VMware.

Indeed, if two DHCP servers are on the same layer 2 segment and either is configured to be Authoritative then it will invalidate the other's attempts to give leases.

By default, I would recommend to always disable DHCP-Authoritative.

https://en.wikipedia...ration_Protocol

 

 

DHCP discovery

The client broadcasts messages on the network subnet using the destination address 255.255.255.255 or the specific subnet broadcast address. A DHCP client may also request its last-known IP address. If the client remains connected to the same network, the server may grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server denies the request, causing the client to issue a new request. A non-authoritative server simply ignores the request, leading to an implementation-dependent timeout for the client to expire the request and ask for a new IP address.

Today I am trying to use DHCP from OpenWrt and it does not work

but after enable back Authoritative option DHCP server began to work  

Now I'm trying TPS with Extra Option: 175.6.1.1.1.8.1.1 but not work

TPS work only after disconnect OpenWrt cable RJ45 from main LAN router.

Edited

--------

OK, I found a solution to the problem, simply use Host-only VMware VMNet1 interface configured static IP with another subnet than my LAN:

 vmnet1.png   10.31KB   0 downloads  vmnet_machine.png   14.73KB   0 downloads  efi_other_subnet.gif   8.81KB   0 downloads

Today I am trying to use DHCP from OpenWrt and it does not work

 

but after enable back Authoritative option DHCP server began to work

 

Now I'm trying TPS with Extra Option: 175.6.1.1.1.8.1.1 but not work

TPS work only after disconnect OpenWrt cable RJ45 from main LAN router.

 

Edited

--------

OK, I found a solution to the problem, simply use Host-only VMware VMNet1 interface configured static IP with another subnet than my LAN:

vmnet1.png vmnet_machine.png efi_other_subnet.gif

Two dhcp servers on the same LAN will always be problematic : you can never be sure which one will answer first.

Your solution of using two different LAN's is a proper solution.

I would add : ensure that TPS is listening on the proper LAN (the vmnet1 one) and to be extra safe, use the "bind ip" option.

Hi erwan, thank you for a great software.

I have a question, how to set a graphical mode for iPXE? ex 1024x768x32,1024x768.

You need to compile support for the console and the background in iPXE e.g. on http://rom-o-matic.eu

http://ipxe.org/cmd/...e#build_options

console --x 1024 --y 768

You need to compile support for the console and the background in iPXE e.g. on http://rom-o-matic.eu

http://ipxe.org/cmd/...e#build_options

Recently I decided to check what maximum date can be set in WinXP Professional using the /year= option in the boot.ini file, e.g. 9999, 10000, 20000, 50000 and 90000:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Professional Edition" /noexecute=optin /fastdetect /year=9999

I set /year=9999 date 31.12.2017 and time 23:55:00 - after restart the system stopped responding to user requests when the date changes to 1.01.10000
I have tried several other /year values then I removed the /year switch, set the normal date and time and restart OS. Now I noticed that the Tiny PXE HTTPd daemon was not working properly. Internet Browsers instead of displaying the list of files in the root path shows an error:

• Mozilla Firefox - The document requested is not availabe.
• Google Chrome - The document requested is not availabe.
• Internet Explorer - HTTP 404 Not Found

This error is from TPS:

 availabe_tiny.png   27.04KB   0 downloads

Interesting that when we specify the full path in the address bar to any file in root path, the File Download window appears e.g. http://192.168.40.1/pxelinux.0

 full_path.png   29.14KB   0 downloads

I cleared CMOS, restored WinXP from the image (with MBR) but that did not help.  

By default I have Tiny PXE on partition C:\PXE  but after moving to partition D:\PXE is still a problem. 

Only after transferring TPS to a USB flash drive HTTPd normally works and browsers display a list of root path files.

I tried the older version of TPS but on each one is the same.

TPS not work if year is 10000:

 tps_date_error.png   113.27KB   0 downloads

I tried also Apache HTTP for Windows and this server display list of root path files and no any problems with bad date.

@reboot12

Maybe unrelated, but JFYI "strange" things happen with "improbable" NTFS timestamps, example:

https://articles.for...tfs-timestamps/

Wonko

@reboot12 : in many places in TPS, I am using delphi builtin date/time decoding function which probably do not handle this rare condition (year=10000).

I could probably improve the error handling but should I really do it as again, what are the chances that such things happen?

Lets make a deal : If I make it to that year then I will fix bug

Edit1:

Some nice reading here ("year 10,000 problem").

Edit2:

Just tested in delphi : date is fine until 9999 ...

erwan.l - I do not want you to repair TPS.

I want to find out why the Internet browsers displays an error The document requested is not availabe. from TPS if the root path is on the same physical hard drive as the operating system.

Why after setting root path from other media such as portable drive, pendrive, CD etc. everything is OK?

In movie is WinXP on MS VPC 2007 with two folders PXE:

• hard disk C:\PXE - Internet browser dispalys error
• optical drive (ISO) D:\PXE - Internet browser displays file list

https://www.youtube....h?v=-VyZ_V-fPAk

@reboot12.

The video really helped to understand your issue, thanks for that.

I tried to reproduce it had no success.

Only idea that comes to my mind right now would be NTFS ACL's : can you try to run the program as admin or even better set full control everyone on c:\pxe\ ?

Regards,

Erwan