HTTPd Error

Hello,

I'm new here and I like to use Tiny PXE server, it's exactly what I'm looking for

I have WIndows 10 pro and when I run the programm I have un error "httpd error, Socket Error # 10013 Access denied." so I turned off my antivirs and the firewalland the same error, I tried the same thing withe Windows 7 and have the same problem.

Can someone help me? thanks

Samy

Hello erwan.I

I did but I had the same error

sorry but I dont know how to post or upload image to the forum  I was looking every where for 30 min and I cant do it

I will use onedrive

https://1drv.ms/i/s!...S3D7hisMhagovxQ

just out of curiosity, try with "bind" unticked.

winsock error 10013 is usually triggered by a local firewall and/or anti virus but you reported you have disabled them already.

Thanks erwan... but I have the same error

The same error on win7 too

P.S. win7 is a new and fresh installation

Firewall windows defender and antivirus, all OFF

would you be ok to try the below and display the content of reset.log.

if you get error or access denied in that log file then you must have a software or driver messing up.

netsh winsock reset catalog
netsh int ip reset reset.log 

Hello, I am new to the forum, sorry please let me know if I need to make a new thread. Encountering the exact same error in Tiny PXE:

httpd error, Socket Error # 10013 Access denied.

With all fresh o/s installs, I am hoping this troubleshooting should be relatively straightforward. , as far as I can tell I am configuring everything but I must be missing some crucial step.

I am using Windows Server 2012 R2 hosting an iSCSI target.

-initiator has matching MAC to client

-Tiny PXE is running in admin

-iSCSI + pxeserv have been allowed in firewall

The Windows 10 vhdx in the target was created by installing the o/s to the client SSD:

-during o/s install, diskpart constrain the size & contain the boot folder to a single partition.

-client successfully wrote the image directly to the shared folder on the server using Disk2vhd.

-client successfully discovered the target IQN after adding the server ip to target portal in iSCSI initiator.

-client successfully PXE boots to the correct script & TFTP root on the server

I can never seem to get past this. Have also been getting stuck with:

proxy boot filename empty? 

The client booting the script will either hang or say select proper boot device. I have never seen any evidence of network o/s trying to boot yet...

Is there a better log info that I can provide?

Am I missing something in the prep config?

Should I attempt a different image? Is there an example PE.vhdx file to attempt the boot in order to test your iSCSI target connection?

Hello, I am new to the forum, sorry please let me know if I need to make a new thread. Encountering the exact same error in Tiny PXE:

httpd error, Socket Error # 10013 Access denied.

With all fresh o/s installs, I am hoping this troubleshooting should be relatively straightforward. , as far as I can tell I am configuring everything but I must be missing some crucial step.

 

I am using Windows Server 2012 R2 hosting an iSCSI target.

-initiator has matching MAC to client

-Tiny PXE is running in admin

-iSCSI + pxeserv have been allowed in firewall

 

The Windows 10 vhdx in the target was created by installing the o/s to the client SSD:

-during o/s install, diskpart constrain the size & contain the boot folder to a single partition.

-client successfully wrote the image directly to the shared folder on the server using Disk2vhd.

-client successfully discovered the target IQN after adding the server ip to target portal in iSCSI initiator.

-client successfully PXE boots to the correct script & TFTP root on the server

 

I can never seem to get past this. Have also been getting stuck with:

proxy boot filename empty? 

The client booting the script will either hang or say select proper boot device. I have never seen any evidence of network o/s trying to boot yet...

 

Is there a better log info that I can provide?

Am I missing something in the prep config?

Should I attempt a different image? Is there an example PE.vhdx file to attempt the boot in order to test your iSCSI target connection?

Hi RCarHar,

First thing first (i.e one issue at the time) : "httpd error, Socket Error # 10013 Access denied.".

Usually means that you have another process listening on tcp port 80.

Either location/shutdown the other process or change TPS http listening port (in which case you will also need to update your pxe scripts).

I recommend that you use the excellent Misty guide here : http://www.mistyrebo...rver/index.html .

Regards,

Erwan

another process listening on tcp port 80.

or change TPS http listening port (in which case you will also need to update your pxe scripts).

Erwan, I much appreciate the quick response. I applied all the firewall settings as suggested in the guide, and am trying a simpler test config.ini but am encountering the same httpd error when starting Tiny PXE...

I am unable to find anything listening on port 80 using resmon. I have installed wireshark but I don't know what I'm doing.

Would the server having multiple NIC's require an entry in the config or script? Only one has been used for setup troubleshooting purposes.

[web]

The following table lists all options that its possible to set in the [web] section of the Tiny PXE Server configuration file config.ini -

The default port used by the 

HTTPd daemon is port 80. This may cause conflicts if another web server is running on the network - use this setting to change the port used for HTTP connections. Syntax is "port=PORT_NUMBER"

Example config.ini entry - port=1024

It may be that you dont need httpd : try to disable it?

Post a screenshot of TPS so that I can see how what are your plans.

 

I tried changing the port in the config.ini using 1024 & a few arbitrary numbers, the error remains the same when starting Tiny.

with httpd disabled the error is gone, but unfortunately I guess I don't know enough to know if I need it or not.

I just realized I did not change port information in the scripts. If I do need this I may need the script entry context.

Using httpd=0 in the config file:

 

ok, at first look it looks all right :

1-your computer will boot

2-your built in boot loader will download via tftp the ipxe boot loader (there thus, why go for the kpxe version? i would go for ipxe.pxe)

3-your pxe boot loader will download your ipxe script (share a copy there)

4-next logical step is for ipxe to boot an operating system over iscsi from your iscsi target

You dont need http in that scenario : will bring little to nothing.

-you dns server looks wrong to me but you may have after all a local dns server.

-I would leave the router to 0.0.0.0 specially with iscsi.

-Your IP pool size is definitely wrong (be generous, give it a 10 )

-you can spare yourself the hassle of a ipxe script and use the root path option but this is another discussion.

I really must apologize for my crude illiteracy in configuring PXE. I have encountered the opportunity to learn and I have taken a great interest in becoming proficient enough to start using PXE to multiboot various environments for personal applications every day. However, I must achieve the setup of this project first. I appreciate your promptness & patience in assisting with this matter!! I don't particularly understand the difference between the script filenames, extensions, or their contents to be honest. I am merely following a guide from here, who are also using WS2012R2 + W10 clients. 

The guide I am following they use the kpxe file in the boot filename, but never explicitly indicate the contents of that script, or why to use kpxe.

The iscsi.ipxe script referred to in the guide is set as alt filename, & contains all the basic scripting that I believe I should need, which has line: 

set net0/gateway 0.0.0.0

At one point, in tinkering on my own, I had a custom menu script booting on the client - which is what I intend to implement before the target boot; this is about the furthest I've gotten - but the actual remote o/s image boot, I have never achieved. I captured a photo of the client & server displays when I successfully booted the custom menu, and the dns server was set to 127.0.0.1 with proxydhcp=0 in that case. Router in the config.ini was

192.168.1.1, but the 0.0.0.0 line runs in the iscsi.ipxe script. Not sure if this could interfere with booting the disk image.

I will actually ultimately be using more than 10 diskless clients, but the router is serving dhcp; so it was my understanding in this case, that the proxydhcp=1 and the pool=0 in order to utilize client auto ip assignment from the router. I have the client MAC addresses captured and added to the iSCSI target - but at the moment I am only working with the client PC with the 1st MAC on the list. For setup troubleshooting purposes, my scripts only contain the initiator IQN of this 1st PC. Also, ultimately, I think there will be multiple vhdx's to achieve multiple disk volumes on the remote booting devices.

1. Keeping as close to thread topic as possible - "HTTPd" is checked in the guide I follow, but not explained. Can you confirm whether it would serve a purpose in my case? It is great to disable & no longer receive the initial error message, & I am eager to move on, but I have no idea what I am actually disabling here.
2. What should the logical best practice using router ip line in config, & gateway ip line in ipxe script? Should both be set?
3. Can you clarify the function of the proxydhcp & pool size, if I have misunderstood them?
4. Can you please clarify for my case, the purpose & minimum contents of the boot filename + alt-filename scripts with different extensions? Can I just have a single menu.ipxe with no alt-filename? or both files with the same contents? I am unclear whether they chain or one is skipped or what...
5. How does this differ from proxyboot filename? When is a proxyboot filename entry needed? Which is the boot file that will be used if this is not needed?
6. Is it feasible to include a vhdx for the o/s + a dynamic vhdx for program installation & user data in the same iSCSI target? Will this be feasible to boot multiple clients to the same target in this case?

In the meantime, I will attempt to get a menu script booting again...

1. Keeping as close to thread topic as possible - "HTTPd" is checked in the guide I follow, but not explained. Can you confirm whether it would serve a purpose in my case? It is great to disable & no longer receive the initial error message, & I am eager to move on, but I have no idea what I am actually disabling here.
2. What should the logical best practice using router ip line in config, & gateway ip line in ipxe script? Should both be set?
3. Can you clarify the function of the proxydhcp & pool size, if I have misunderstood them?
4. Can you please clarify for my case, the purpose & minimum contents of the boot filename + alt-filename scripts with different extensions? Can I just have a single menu.ipxe with no alt-filename? or both files with the same contents? I am unclear whether they chain or one is skipped or what...
5. How does this differ from proxyboot filename? When is a proxyboot filename entry needed? Which is the boot file that will be used if this is not needed?
6. Is it feasible to include a vhdx for the o/s + a dynamic vhdx for program installation & user data in the same iSCSI target? Will this be feasible to boot multiple clients to the same target in this case?

 

1.in your case, you dont need httpd : you would use it fi you were to serve a wim file for example (or an iso, etc).

2.you can either alter (some of) the dhcp parameters in TPS or in a script file

3.proxydhcp is recommended as like most of us, you probably already have a dhcp on our lan (your router, modem, adsl box, etc).

pool size will define how many dynamic IP's you want to serve (in both proxydhcp mode or in dhcp mode)

4.client boots to its builtin pxe client, download via ftp a first boot loader, possibly download a script file, and boots to some wim, iso, iscsi, etc

5.not sure what you mean by proxyboot?

6.the vhdx versus vhd difference here is probably irrevelant since your target (MS here) will abstract the underlying disk container.

Hope this was clear

About kpxe, kkpxe, pxe extensions, they are just different boot loader formats but they are still all binary "executables".

See this thread : http://forum.ipxe.or...ad.php?tid=6989 .

ipxe is a simple text file aka script : look at iscsi.ipxe in TPS.zip file.

Regards,

Erwan

Thank you!!!!

I don't have time to comment on everything right now, but I was finally able to boot a menu script that actually loads the iSCSI target & boots Windows 10 over the network. I successfully booted 3 PCs to Windows 10 simultaneously using the same vhdx, but the rest were booting to either 'please wait' which I know means preparing automatic repair, or they booted directly to a chkdsk, wherein they all ultimately rebooted into the 'Choose your keyboard layout' recovery utility. The original client PC gave disk write errors when attempting an application install.

Now I need to understand the way to create one or more images that will allow the client to install applications, etc.

I am unsure if this weekend I will get to complete any further config or troubleshooting.

Thank you!!!!

 

I don't have time to comment on everything right now, but I was finally able to boot a menu script that actually loads the iSCSI target & boots Windows 10 over the network. I successfully booted 3 PCs to Windows 10 simultaneously using the same vhdx, but the rest were booting to either 'please wait' which I know means preparing automatic repair, or they booted directly to a chkdsk, wherein they all ultimately rebooted into the 'Choose your keyboard layout' recovery utility. The original client PC gave disk write errors when attempting an application install.

 

Now I need to understand the way to create one or more images that will allow the client to install applications, etc.

 

I am unsure if this weekend I will get to complete any further config or troubleshooting.

I believe what you are experiencing is an expected behavior.

If you were to network boot in memory (wim, etc), then doing so from multiple clients would be fine (each client would have its own readonly instance).

But because you are network booting on disk (hosted on your target/server), all changes will happen on that disk.

If you boot multiple clients, you will quickly corrupt your image.

What you may try is to use differencing vhd's (one per client).

That means one target per disk.

It's definitely an expected behaviour, I started another thread to overcome this.

5.not sure what you mean by proxyboot?

[arch]
;will over rule the bootp filename or opt67 if the client arch matches one of the below
;00006=bootia32.efi
;00007=bootx64.efi
;00009=bootx64.efi
[dhcp]
;needed to tell TFTPd where is the root folder
root=files
;bootp filename as in http://tools.ietf.org/html/rfc951
;filename=ipxe-undionly.kpxe
filename=ipxe.pxe
;alternative bootp filename if request comes from ipxe or gpxe
altfilename=menu.ipxe
;start HTTPd
httpd=1
binl=0
start=0
dnsd=0
proxydhcp=0
;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= <------------------------------------------------------This entry right here
;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=182
left=182

Please see line 42 of the current original config.ini above

Curious - is there a reason log=0 is included twice?

Please see line 42 of the current original config.ini above

Curious - is there a reason log=0 is included twice?

No reason, some left over from the past.

As a whole logging to a file is not recommended/supported anymore (thread issues, triggering issues/crashes).

Rather, use the logging to syslog (provided client in the zip file).

Referencing this thread (continued discussions).