18 replies to this topic

[applesauce]

Hi everyone - 

 

I've recently been trying to set up Tiny PXE Server to boot Active Kill Disk over the network to many machines for easy drive formatting. I have had some success so far but have run into issues.
 

When I run Tiny PXE Server with ProxyDhcp OFF - I get about a 50% success rate - I assume this is my router's DHCP server and Tiny PXE's DHCP server racing and whoever leases the IP first is what the PXE client tried to connect to to download the Menu etc.

 

However when I run with ProxyDHCP enabled - it stops working all together. I have attached the server Log and a picture of a client computer trying to connect. It seems like it is trying to connect to the IP address of my router which leased the IP instead of the Tiny PXE Server.

 

Server log: (C8-60-00-43-DF-1D is the client computer in question)

9:30:20 AM DHCPd:DISCOVER discarded, MAC:88-3D-24-A8-C6-C6, XID:5CD42B6B
9:30:32 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:443DF1D
9:30:32 AM DHCPd:OFFER sent, IP:0.0.0.0, XID:443DF1D
9:30:34 AM DHCPd:REQUEST discarded, MAC:C8-60-00-43-DF-1D, XID:443DF1D
9:30:34 AM PDHCPd:REQUEST received, MAC:C8-60-00-43-DF-1D, IP:192.168.1.70, XID:443DF1D
9:30:34 AM Proxy boot filename empty?
9:30:34 AM PDHCPd:DHCP_ACK sent, IP:192.168.1.70:68, xid:443DF1D
9:30:34 AM TFTPd:DoReadFile:undionly.kpxe B:1456 T:0
9:30:45 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:7D1E2048
9:30:45 AM DHCPd:OFFER sent, IP:0.0.0.0, XID:7D1E2048
9:30:45 AM DHCPd:REQUEST discarded, MAC:C8-60-00-43-DF-1D, XID:7D1E2048
9:30:51 AM DHCPd:DISCOVER received, MAC:88-3D-24-A8-C6-C6, XID:5CD42B8A
9:30:51 AM DHCPd:OFFER sent, IP:0.0.0.0, XID:5CD42B8A
9:31:21 AM DHCPd:DISCOVER received, MAC:88-3D-24-A8-C6-C6, XID:5CD42BA8
9:31:21 AM DHCPd:OFFER sent, IP:0.0.0.0, XID:5CD42BA8

Picture of client PC:

 

 

[erwan.l]

Hi Applesauce,

 

Indeed, if you set proxydhcp=off, then you will have a racing condition affecting both items : pxe booting but also your dhcp clients on our lan.

 

Proxydhcp=on is highly recommend to ensure smooth coexistence between TPS and your DHCP server.

 

A few questions (to complement your screenshot):

-what is your DHCP server IP

-what is the IP of the host where you run TPS : seems to be 192.168.1.1

-what is the TPS version (should be 1.0.0.23)

-why use undionly.kpxe and not ipxe.pxe (including in tps.zip) - you seem to be using an old and custom AIO version

-what is menu.ipxe (i.e what script)

-what is your config.ini

 

You seem to download the pxe boot loader fine : good start.

You seem to download the alternative file/script fine : still a good start.

You encouter a timeout during or after downloading your script.

 

Regards,

Erwan

[applesauce]

Hi thanks for the reply! Here is the info you requested:

 

DCHP Server IP: 192.168.1.1

TPS Host IP: 192.168.1.35

 

(this is why I am confused - as it seems its trying to pull the menu from 192.168.1.1 instead of 192.168.1.35)

 

TPS Version: 1.0.0.21 - I didn't realize I had an older version and am updating now

 

I'm using undionly.kpxe simply because it is what the AIO Boot tutorial said to use (I am a noob at this stuff)

 

menu.ipxe is a menu that allows selection of multiple operating systems / boot files once loaded in - I'll quote part of it but it is pretty long:

#!ipxe
console --x 1024 --y 768
console --picture ${boot-url}/grub/themes/splash.png

# Setup some basic convenience variables
set menu-timeout 5000
set submenu-timeout ${menu-timeout}

# Ensure we have menu-default set to something
isset ${menu-default} || set menu-default winpe

######## MAIN MENU ###################
:start
menu Welcome to iPXE's Boot Menu
item
item --gap -- ------------------------------ Utilities --------------------------------
item --key 1 winpe				[1] WinPE & Setup
item --key 2 diskutilities		[2] Disk Utilities
item --key 3 backuprecovery		[3] Backup & Recovery
item --key 4 dosprogs			[4] DOS Programs
item --key 5 livelinux			[5] Linux ISO Live
item --key 6 antivirus			[6] Antivirus
item --key 7 specialpack		[7] Special Pack
item --gap -- ------------------------------ Advanced ---------------------------------
item --key c config				[c] Configure settings
item --key s shell				[s] Enter iPXE shell
isset ${legacy} && item --key l local				[l] Boot from local disk || ###
item --key r reboot				[r] Restart
item --key p poweroff			[p] Power Off
item --key e exit				[e] Exit (boot local disk)
choose --default winpe --timeout 30000 target && goto ${target}

########## UTILITY ITEMS ####################
:shell
echo Type exit to get the back to the menu
shell
set menu-timeout 0
goto start

:failed
echo Booting failed, dropping to shell
goto shell

:local
sanboot --no-describe --drive 0x80 || goto failed  
goto start

:reboot
reboot

:poweroff
poweroff

:exit
exit

:cancel
echo You cancelled the menu, dropping you to a shell
 
:config
config
goto start
 
:back
set submenu-timeout 0
clear submenu-default
goto start

ETC....

Finally here is my config file:

; 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

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

[dhcp]
root=E:\AIO\
filename=undionly.kpxe
optextra=175.6.1.1.1.8.1.1
httpd=1
bind=1
dnsd=0
smb=0
tftpd=1
proxydhcp=1
start=1

In the meantime I'll try updating TPS and using the ipxe.pxe file instead

[erwan.l]

It could be that there is an embedded script in your undionly.kpxe trying to pull menu.ipxe from the dhcp server.

This seems to be confirmed since I dont see any mention of altfilename=menu.ipxe in your config.ini.

 

1/

Use ipxe.pxe (as boot loader) which is included in Tiny PXE Server zip file to start with so that we rule out an embedded script in your boot loader.

 

2/

Make sure that you have altfilename=menu.ipxe defined.

 

3/

You definitely want to be running proxydhcp mode to avoid a racing condition.

 

In that setup, TPS will let your dhcp server do its main job (provide a dhcp lease) and will simply add some extra informations to tell your pxe client where to download files (ipxe.pxe then menu.ipxe) from.

 

In proxydhcp mode, the variable to use (if needed) is ${next-server} and no longer ${dhcp-server} .

[applesauce]

After updating to the newest version some interesting things happened - I'm using the same config.

 

Here is the TPS log:

11:34:45 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:443DF1D
11:34:45 AM DHCPd:OFFER sent, IP:0.0.0.0, XID:443DF1D
11:34:47 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:543DF1D
11:34:47 AM DHCPd:OFFER sent, IP:0.0.0.0, XID:543DF1D
11:34:48 AM DHCPd:DISCOVER received, MAC:88-3D-24-A8-C6-C6, XID:5CD59A18
11:34:48 AM DHCPd:OFFER sent, IP:0.0.0.0, XID:5CD59A18
11:34:49 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:643DF1D
11:34:49 AM DHCPd:OFFER sent, IP:0.0.0.0, XID:643DF1D
11:34:51 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:743DF1D
11:34:51 AM DHCPd:OFFER sent, IP:0.0.0.0, XID:743DF1D
11:34:53 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:843DF1D
11:34:54 AM DHCPd:OFFER sent, IP:0.0.0.0, XID:843DF1D

However the client computer doesn't seem to actually get an IP - here is a picture:

 

I also can't get an IP leased to the client even when having ProxyDhcp disabled. It seems I've taken a step backward.

Also tried ipxe.pxe instead of undionly.kpxe with no difference. 

 

Here is a screencap of my TPS 

[applesauce]

Here is the TPS log when I have ProxyDhcp disabled:

11:42:29 AM DHCPd:DISCOVER received, MAC:88-3D-24-A8-C6-C6, XID:5CD59BE5
11:42:30 AM DHCPd:OFFER sent, IP:192.168.1.39, XID:5CD59BE5
11:42:30 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:743DF1D
11:42:30 AM DHCPd:OFFER sent, IP:192.168.1.40, XID:743DF1D
11:42:32 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:843DF1D
11:42:32 AM DHCPd:OFFER sent, IP:192.168.1.41, XID:843DF1D
11:42:34 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:943DF1D
11:42:34 AM DHCPd:OFFER sent, IP:192.168.1.42, XID:943DF1D
11:42:36 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:A43DF1D
11:42:36 AM DHCPd:OFFER sent, IP:192.168.1.43, XID:A43DF1D
11:42:38 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:B43DF1D
11:42:38 AM DHCPd:OFFER sent, IP:192.168.1.44, XID:B43DF1D

[erwan.l]

 

Here is the TPS log when I have ProxyDhcp disabled:

11:42:29 AM DHCPd:DISCOVER received, MAC:88-3D-24-A8-C6-C6, XID:5CD59BE5
11:42:30 AM DHCPd:OFFER sent, IP:192.168.1.39, XID:5CD59BE5
11:42:30 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:743DF1D
11:42:30 AM DHCPd:OFFER sent, IP:192.168.1.40, XID:743DF1D
11:42:32 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:843DF1D
11:42:32 AM DHCPd:OFFER sent, IP:192.168.1.41, XID:843DF1D
11:42:34 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:943DF1D
11:42:34 AM DHCPd:OFFER sent, IP:192.168.1.42, XID:943DF1D
11:42:36 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:A43DF1D
11:42:36 AM DHCPd:OFFER sent, IP:192.168.1.43, XID:A43DF1D
11:42:38 AM DHCPd:DISCOVER received, MAC:C8-60-00-43-DF-1D, XID:B43DF1D
11:42:38 AM DHCPd:OFFER sent, IP:192.168.1.44, XID:B43DF1D

yes, wont work without proxydhcp.

a discover is sent by the client, TPS replies with an offer and this is never picked up, probably because your lan dhcp server replies first.

 

will only work with proxydhcp=enabled.

[applesauce]

However I can't get it to work with ProxyDhcp enabled either - it seems that when trying to update the TPS version I must have broken my config or something because nothing is working at all now.

[erwan.l]

The below minimal setup should boot any pxe client on any network.

 

D.O.R.A is what you are looking for : discover...offer.request...acknowledge.

 

If you see nothing appearing in TPS log (at least a discover/offer pair), then the issue is elsewhere on your network (firewall, cabling, etc)

 

 

 

[dhcp]
binl=0
proxydhcp=1
httpd=1
dnsd=0
bind=1
smb=0
root=\_pxe
filename=ipxe.pxe
altfilename=menu.ipxe
opt1=255.255.255.0
opt3=192.168.1.250
opt6=192.168.1.250
opt28=192.168.1.255
opt43=0
opt51=3600
optextra=175.6.1.1.1.8.1.1
poolsize=10
verbose=1

18:24:19 DHCPd:DISCOVER received, MAC:00-0C-29-29-F4-45, XID:2A29F445
18:24:19 DHCPd:OFFER sent, IP:0.0.0.0, XID:2A29F445
18:24:21 DHCPd:DISCOVER received, MAC:00-0C-29-29-F4-45, XID:2B29F445
18:24:21 DHCPd:OFFER sent, IP:0.0.0.0, XID:2B29F445
18:24:25 DHCPd:REQUEST discarded, MAC:00-0C-29-29-F4-45, XID:2B29F445
18:24:25 PDHCPd:REQUEST received, MAC:00-0C-29-29-F4-45, IP:192.168.1.157, XID:2B29F445
18:24:26 DHCPd:Arch=00000
18:24:26 Proxy boot filename empty?
18:24:26 PDHCPd:DHCP_ACK sent, IP:192.168.1.157:68, xid:2B29F445
18:24:26 TFTPd:DoReadFile:ipxe.pxe B:1456 T:0
18:24:26 TFTPd:TransferComplete=True (192.168.1.157:2070)
18:24:29 DHCPd:DISCOVER received, MAC:00-0C-29-29-F4-45, XID:2D829F46
18:24:29 DHCPd:iPXE user-class detected
18:24:29 DHCPd:OFFER sent, IP:0.0.0.0, XID:2D829F46
18:24:29 DHCPd:REQUEST discarded, MAC:00-0C-29-29-F4-45, XID:2D829F46
18:24:29 TFTPd:DoReadFile:menu.ipxe B:1432 T:16656
18:24:29 TFTPd:TransferComplete=True (192.168.1.157:47095)

[Domen]

Hello Erwan and everyone can write here about PXE Server for problems and everything possible for Pxe functions !!
 
I tried to install the Tiny server on a laptop computer, but also works proxyDHCP and basic to a desktop computer that also has a built-in boot networrk agent (yes) laptop boot agent (yes

I suspect that he is guilty of an internet cable router modem with 4 RJ45 connectors. I suspect that Tiny Server software is bugged ... that should work the same way as TFTP PXE Server X32 / 64 shares in both directions just like desktop and laptop it's real, and vice versa, you know what I mean

please what should I do to set up in the cable router to work Tiny PXE Server from a desktop computer in a laptop .... please help ..... I am very busy with the PXE ..


Greetings to all  !!! sorry my english

[erwan.l]

About the original post :

 

-user had two nic bound bridged together : removing that fixed part of the issue (we can see requests coming in)

-second part of the issue I believe (looking at a wireshark capture) seems to be a rogue dhcp detection i.e network admin not allowing another dhcp (or proxydhcp) on their lan (which i would not allow as well as a corp network admin)...

 

Lesson learned?

Dont run a dhcp/proxydhcp on a LAN you dont own

[applesauce]

To clarify - I would hardly say we have a "network admin" - it's just a Google WiFi setup with default settings. So sure I don't "own" the LAN but I was asked by the owner to set up a network boot system.

 

No real lesson learned - and no real solution. Apparently Google WiFi has rouge DHCP detection on by default? Who knows...

[erwan.l]

To clarify - I would hardly say we have a "network admin" - it's just a Google WiFi setup with default settings. So sure I don't "own" the LAN but I was asked by the owner to set up a network boot system.

 

No real lesson learned - and no real solution. Apparently Google WiFi has rouge DHCP detection on by default? Who knows...

 

Actually, looking at the wireshark capture you sent me, i can see the a device named "gwifi_rouge_dhcp_detection".

 

Notice the typo : rouge vs rogue.

It is probably a human error.

It would be worth walking to whoever set this network device and discuss this matter with that person.

 

There is definitely something on your LAN at best interfering, at worse preventing pxe/dhcp/proxydhcp on your LAN.

Generally speaking, you can only perform pxe/dhcp/proxydhcp on a LAN if prerequisites are met.

 

Side note, using a google wifi AP as a DHCP server for your whole network (including wired devices) is discussable (you are wired ,right?).

I would personally not recommend it.

If you cannot afford a DHCP device (usually a server or a robust switch on your LAN), consider using your WAN router may be?

But this is deviating from the original post.

 

 

[applesauce]

Yes I am wired - I wish I could do something about it honestly - the google WiFi is a mesh network thing. I wanted to post this update as well:

 

I decided to give it another shot today - starting with a freshly downloaded TPS and now it works with completely default settings + proxy DHCP enabled. Here is a screenshot of the client computer

Right after this screen it goes to the iPXE Server Menu

 

I don't think I did anything differently. Maybe my network was just happy today? If you are interested erwan I could get a wireshark capture again to see if it's different or not.

[Wonko the Sane]

Notice the typo : rouge vs rogue.

It is probably a human error.

 

Out of curiosity, how would you call a RED dhcp detection device?

 

 

Seriously, only today I bought a new cash register (available in white, black and red) at a discount because it was actually red, and seemingly everyone want the black and a few are ok with the white one.

People are strange , I mean it is a d@mn cash register, not - say - a car or a piece of furniture ... 

 

 Wonko

[erwan.l]

Yes I am wired - I wish I could do something about it honestly - the google WiFi is a mesh network thing. I wanted to post this update as well:

 

I decided to give it another shot today - starting with a freshly downloaded TPS and now it works with completely default settings + proxy DHCP enabled. Here is a screenshot of the client computer

Right after this screen it goes to the iPXE Server Menu

 

I don't think I did anything differently. Maybe my network was just happy today? If you are interested erwan I could get a wireshark capture again to see if it's different or not.

 

Ah, this is good news : happy for you.

 

While reviewing your setup with you the other day, I believe it was OK but I could have missed something.

 

Restarting from scratch when stuck remains the best solution always

[erwan.l]

Out of curiosity, how would you call a RED dhcp detection device?

 

 

Actually I got puzzled there and even wondered if my theory was right (i.e some admin introducing a typo).

 

gwifi_rogue_dhcp_detection means something (to me at least...), but i cannot figure what gwifi_rouge_dhcp_detection could mean (or could it be as "simple" as a google wifi AP which is red and does rouge detection ? ).

 

Not to mention that the OP is apparently originating from US and would not be using the (french) word rouge.

[cabye]

in my testing, with or without enabling proxydhcp both work,

the most important parameter is that extra 175 option.

without that option, proxydhcp cannot work,

be it 175.3.1.1 or 175.6.1.1.1.8.1.1 or 175.9.1.1.1.8.1.1.176.1.1

show 175.1 will tell you if you set that priority parameter

[erwan.l]

in my testing, with or without enabling proxydhcp both work,

the most important parameter is that extra 175 option.

without that option, proxydhcp cannot work,

be it 175.3.1.1 or 175.6.1.1.1.8.1.1 or 175.9.1.1.1.8.1.1.176.1.1

show 175.1 will tell you if you set that priority parameter

 

might be a racing condition specific to your environement.

normally this option surely helps but should not be a MUST HAVE (by the rfc book).

 

in any case, as soon as you have an existing dhcp server on your lan, it is really (i mean really) recommend to go with a proxydhcp if you want to experience random results.