[ipxe-devel] Confirm Possible mishandling of http port when http auth is used.
andrew at shopcusa.com
Thu May 5 23:28:46 BST 2011
On 5/4/2011 10:26 AM, Andrew Stuart wrote:
> On 4/26/2011 5:58 PM, Andrew Stuart wrote:
>> Using ipxe dated Apr 19th 17:51 (according to filesystem.. I haven't
>> figured out how to tell which git revision I am at yet)
>> I can successfully boot http://my.boot.server:8081/myfile.img,
>> when I try the authmenus example from etherboot's site the download
>> fails, unfortunately I have been unable to capture the output, but as it
>> flashes by, it appears :8081 has been stripped from the url.
>> I setup the same site on port 80 as a temporary trial, and confirmed it
>> works as expected, initial handoff is 8081 for boot.php / vesamenu.c32,
>> then after it authenticates everything else goes to port 80.
>> I reverted my setup to be identical to the setup used for authmenus to
>> have a working example for anyone else.
> I have confirmed it was something with my setup, although at this time I
> am not sure what. I do know I was having issues with vmware workstation
> 7 and ipxe/vesamenu, but that is/should be unrelated.
Is there a way to compile with more (debug) information for http.c and
I did finally figure out what I did differently. Gene's modifcation to
boot.php on http://etherboot.org/wiki/appnotes/authmenus to return the
http port the request was sent to appears to be ignored by iPXE.
To clarify loading http://boot.myserver.com:9090/boot.php in a browser
set 209:string bootcfg.php
Which is the expected result.
However, booting with iPXE I see the request going to the webserver on
port 9090, and /boot.php is retrieved as expected, all other requests
fail, as they go to port 80.
Modifying boot.php from:
Does give the expected results as long as you remember to change the
port # if you are using different port #'s for different tasks.
Additionally, I am having an issue with having authentication being
passed reliably, and was hoping to try and track it down.
Example from webserver log:
188.8.131.52 - - [05/May/2011:15:04:55 -0700] "GET /boot.php HTTP/1.1"
200 165 "-" "iPXE/1.0.0+"
184.108.40.206 - - [05/May/2011:15:05:22 -0700] "GET /pxelinux.0 HTTP/1.1"
200 26442 "-" "iPXE/1.0.0+"
220.127.116.11 - andrew [05/May/2011:15:05:23 -0700] "GET /bootcfg.php
HTTP/1.1" 200 75 "-" "iPXE/1.0.0+"
18.104.22.168 - - [05/May/2011:15:05:23 -0700] "GET /devel/vesamenu404.c32
HTTP/1.1" 200 155792 "-" "iPXE/1.0.0+"
22.214.171.124 - andrew [05/May/2011:15:05:24 -0700] "GET /menu/menu.php
HTTP/1.1" 200 1055 "-" "iPXE/1.0.0+"
126.96.36.199 - - [05/May/2011:15:05:25 -0700] "GET
/menu/backgrounds/test.png HTTP/1.1" 200 66962 "-" "iPXE/1.0.0+"
188.8.131.52 - - [05/May/2011:15:05:35 -0700] "GET /memtest HTTP/1.1" 200
164504 "-" "iPXE/1.0.0+"
notice only bootcfg.php and menu.php have authentication, all other
requests have none.
This is also repeatable without the use of pxelinux.0 calling menu.c32
from syslinux 3.86. The initial menu load has authentication, subsequent
requests do not.
This is an issue for me, for two reasons:
A) Ideally I want to call a premenu.php, similar to netboot.me which
acts as a failsafe for machines that don't boot vesamenu.c32, giving you
the option of using menu.c32.. But once you call a second file menu.php
in this example, the authentication information does not exist.
(Using only iPXE/(vesa)menu.c32, does work via pxelinux.0 so far, as log
One might suggest moving authentication to premenu.php and call it a
day, which solves my authentication complaint, but removes the dynamic
menu.php capabilities (unless I get really creative?)
B) While I am getting this setup I have it firewalled to allow my home
and work ip addresses, but I envision having it open to the world so
that I can go to any computer, boot off my thumb drive and access my
boot system. Some of what I intend to boot, includes WinPE images, which
I could imagine Microsoft coming after me for if someone figures out the
path to my file, and downloads it manually.
There are at least a few ways to obscure this information to make it
difficult, but it would be ideal to turn on http authentication for the
entire directory, requiring a valid user which should solve the problem
Looking through http.c, it appears if I did turn on http auth in the
webserver, that iPXE would respond accordingly?
More information about the ipxe-devel