Jump to content











Photo

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

pxe network boot

  • Please log in to reply
783 replies to this topic

#351 reboot12

reboot12

    Frequent Member

  • Advanced user
  • 226 posts
  • Interests:WinXP, Debian, OpenWrt, gPXE, iPXE, BIOS, EFI, Coreboot, MS VirtualPC, VMware
  •  
    European Union

Posted 19 July 2015 - 03:19 AM

In 1.0.0.11:
  • need also set opt43=0.0.0.0 to VMware get IP from DHCPd daemon

  • You cannot mix filename and pxe options (opt 60,66,67).
    it is either one or the other :
    -use opt60,66 AND 67 (Pxe)
    or
    -use filename (plain dhcp)

    in this version possible and required mix settings PXE because if not set plain DHCP boot file then not start TFTPd and HTTPd daemons
  • if set boot file name in plain DHCP then VMware boot even without Bind IP option (I never use this option)
VMware boot only with this config.ini in 1.0.0.11 with filename=pxelinux.0:
Spoiler

I try also this but still not boot:
  • both at once filename and opt67=pxelixux.0
  • Bind IP off and on
  • ProxyDHCP off and on
VMware Workstation 8.0.2 build-591240 not work with TPS 1.0.0.19 if PXE options set.
This is tested with build-in Boot Agent:
Network boot from AMD Am79C970A
If use third-party boot agent e.g. gPXE ISO then VMware boot :-) without ProxyDHCP & Bind IP options

I test also MS VPC 2007 6.0.192.0 with Argon PXE Boot agent - also not work with 1.0.0.19 + PXE options
Please see this video: MS VPC2007 Argon boot agent & Tiny PXE Server 1.0.0.19
A workaround is to use gPXE/iPXE boot agent but for boot from RIS floppy also not possible :-(
In 1.0.0.11 version to boot from RIS floppy simply need only 3 options and no need use opt66 & 67:
  • filename=pxelinux.0
  • opt43=0.0.0.0
  • opt60=PXEClient
Video TPS 1.0.0.11 with RIS working Tiny PXE Server 1.0.0.11 and RIS boot OK
in 1.0.0.19 RIS boot not work.

#352 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2291 posts
  • Location:Nantes - France
  •  
    France

Posted 19 July 2015 - 05:04 PM

In 1.0.0.11:

  • need also set opt43=0.0.0.0 to VMware get IP from DHCPd daemon

  • in this version possible and required mix settings PXE because if not set plain DHCP boot file then not start TFTPd and HTTPd daemons
  • if set boot file name in plain DHCP then VMware boot even without Bind IP option (I never use this option)
VMware boot only with this config.ini in 1.0.0.11 with filename=pxelinux.0:
Spoiler

This is packet capture while boot 1.0.0.11: attachicon.gif10011.cap.zip
This is packet capture while not boot 1.0.0.19: attachicon.gif10019.cap.zip (not boot if filename or opt67 = pxelinux.0)

I try also this but still not boot:
  • both at once filename and opt67=pxelixux.0
  • Bind IP off and on
  • ProxyDHCP off and on
VMware Workstation 8.0.2 build-591240 not work with TPS 1.0.0.19 if PXE options set.
This is tested with build-in Boot Agent:
Network boot from AMD Am79C970A
If use third-party boot agent e.g. gPXE ISO then VMware boot :-) without ProxyDHCP & Bind IP options

I test also MS VPC 2007 6.0.192.0 with Argon PXE Boot agent - also not work with 1.0.0.19 + PXE options
Please see this video: MS VPC2007 Argon boot agent & Tiny PXE Server 1.0.0.19
A workaround is to use gPXE/iPXE boot agent but for boot from RIS floppy also not possible :-(
In 1.0.0.11 version to boot from RIS floppy simply need only 3 options and no need use opt66 & 67:
  • filename=pxelinux.0
  • opt43=0.0.0.0
  • opt60=PXEClient
Video TPS 1.0.0.11 with RIS working Tiny PXE Server 1.0.0.11 and RIS boot OK
in 1.0.0.19 RIS boot not work.

 

 

In 1.0.0.11:

  • need also set opt43=0.0.0.0 to VMware get IP from DHCPd daemon

  • in this version possible and required mix settings PXE because if not set plain DHCP boot file then not start TFTPd and HTTPd daemons
  • if set boot file name in plain DHCP then VMware boot even without Bind IP option (I never use this option)
VMware boot only with this config.ini in 1.0.0.11 with filename=pxelinux.0:
Spoiler

This is packet capture while boot 1.0.0.11: attachicon.gif10011.cap.zip
This is packet capture while not boot 1.0.0.19: attachicon.gif10019.cap.zip (not boot if filename or opt67 = pxelinux.0)

I try also this but still not boot:
  • both at once filename and opt67=pxelixux.0
  • Bind IP off and on
  • ProxyDHCP off and on
VMware Workstation 8.0.2 build-591240 not work with TPS 1.0.0.19 if PXE options set.
This is tested with build-in Boot Agent:
Network boot from AMD Am79C970A
If use third-party boot agent e.g. gPXE ISO then VMware boot :-) without ProxyDHCP & Bind IP options

I test also MS VPC 2007 6.0.192.0 with Argon PXE Boot agent - also not work with 1.0.0.19 + PXE options
Please see this video: MS VPC2007 Argon boot agent & Tiny PXE Server 1.0.0.19
A workaround is to use gPXE/iPXE boot agent but for boot from RIS floppy also not possible :-(
In 1.0.0.11 version to boot from RIS floppy simply need only 3 options and no need use opt66 & 67:
  • filename=pxelinux.0
  • opt43=0.0.0.0
  • opt60=PXEClient
Video TPS 1.0.0.11 with RIS working Tiny PXE Server 1.0.0.11 and RIS boot OK
in 1.0.0.19 RIS boot not work.

 

 

 

oki I believe I found the issue.

 

In version 1.0.0.18, I changed the following :

changed : if opt54/opt43='0.0.0.0' then skip the option

So if you actually add the below ine extra option :

43.7.1.4.0.0.0.0.255

next to your current options, TPS 1.0.0.19 should work.

 

In theory, one should not need option 43 but it seems that some (broken?) pxe clients out there needs it.

Note that in some cases, it will actually introduce other issues.

 

I quote (http://www-01.ibm.co...uid=swg21247032) :

Problem(Abstract)
Configuring your DHCP infrastructure to support PXE servers is usually limited to adding option 60 depending on where the PXE server is located. This article shows how to configure DHCP option 43 in order to modify how PXE clients find the PXE server.
Resolving the problem
In order to support PXE clients on a network, the DHCP server is usually configured in one of the following three modes:
Option 60 not set, Option 43 not set 

Option 60 set to 'PXEClient', Option 43 not set 

Option 60 set to 'PXEClient', Option 43 set 


When neither option 60 nor option 43 is set, PXE clients will have no clue on where the PXE server is, and they will therefore wait until a PXE server contact them. In this mode, the PXE server must listen to DHCP discovery packets sent by PXE clients and answer at the same time as the DHCP server does. 

When option 60 is set to 'PXEClient', it means that the DHCP server knows where the PXE server is. If option 43 is not set, the PXE server is on the same computer as the DHCP server (same IP address). If option 43 is set, PXE clients must decode option 43 to know how to reach the PXE server. 

In most situations, option 43 does not need to be setup, because the PXE server will either listen to DHCP discovery packets (DHCPProxy), or be on the same computer as the DHCP server. However, if the PXE server is on a separate subnet (it cannot listen to DHCP discovery packets), or if there are several PXE servers on the same subnet, option 43 is the only viable solution in order to instruct PXE clients on what to do. 

You have some nice reading about this option also here and here.

 

I will probably remove the text field option 43 as this is needed only in some very rare occasions and you can also use the extra options features in TPS.

 

Thank you for your videos next to your detailed feedback : it did help.

You wireshark capture did not contain any dhcp packets thus (did you select the right interface?).

 

Let me know the above solution works for you (you should use latest version as it contains many other fixes).



#353 reboot12

reboot12

    Frequent Member

  • Advanced user
  • 226 posts
  • Interests:WinXP, Debian, OpenWrt, gPXE, iPXE, BIOS, EFI, Coreboot, MS VirtualPC, VMware
  •  
    European Union

Posted 20 July 2015 - 03:48 AM

Yes, after add optextra=43.7.1.4.0.0.0.0.255 VMware, MS VPC boot agent and boot from RIS floppy work :-) Thx. This is my config.ini:
Spoiler

P.S. Please don't quote all post's and use 'code' in 'spoiler'. Forum works often slow, and if you use 'spoiler' is more readable :-). Please delete also double 'quote' from previous post.

#354 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2291 posts
  • Location:Nantes - France
  •  
    France

Posted 20 July 2015 - 06:56 AM

@reboot12 : Ok, good to know it works.

 

I am going to rework the interface as opt43=0.0.0.0 is confusing currently.

Indeed, TPS 1.0.0.19 will skip this opt43 if it is equal to 0.0.0.0 ...

 

I might just add a checkbox named "skip m/tftpd" which if checked, will add opt43=0.0.0.0 in the dhcp offer/ack reply.



#355 pxe

pxe
  • Members
  • 6 posts
  •  
    United States

Posted 20 July 2015 - 10:39 PM

I know it is not officially out yet, but is anybody having issues with TPS on Windows 10? I get errors like these:

7/20/2015 14:18:35:997,2:18:35 PM TFTPd:DoReadFile Exception: pxeboot.n12 I/O error 103
7/20/2015 14:24:07:010,2:24:07 PM analysedata4011:I/O error 103
7/20/2015 14:24:23:042,2:24:23 PM goUDP4011:EInOutError,I/O error 103


#356 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2291 posts
  • Location:Nantes - France
  •  
    France

Posted 20 July 2015 - 10:55 PM

I know it is not officially out yet, but is anybody having issues with TPS on Windows 10? I get errors like these:

7/20/2015 14:18:35:997,2:18:35 PM TFTPd:DoReadFile Exception: pxeboot.n12 I/O error 103
7/20/2015 14:24:07:010,2:24:07 PM analysedata4011:I/O error 103
7/20/2015 14:24:23:042,2:24:23 PM goUDP4011:EInOutError,I/O error 103

What is your path?
Did you try to run as admin?
Also make sure log=0 in config.ini.

#357 pxe

pxe
  • Members
  • 6 posts
  •  
    United States

Posted 20 July 2015 - 11:27 PM

What is your path?
Did you try to run as admin?
Also make sure log=0 in config.ini.

 

1. root=files, running pxesrv.exe from C:\pxesrv

2. Yes

3. Wow, this seemed to fix it. I had log to file enabled before.

 

Thanks for the quick reply.



#358 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2291 posts
  • Location:Nantes - France
  •  
    France

Posted 21 July 2015 - 06:40 AM

1. root=files, running pxesrv.exe from C:\pxesrv

2. Yes

3. Wow, this seemed to fix it. I had log to file enabled before.

 

Thanks for the quick reply.

 

Logging to a file has always given me problems in TPS because it is multi threaded : I will soon disable it.

If you want to log, you can use syslog feature builtin TPS.



#359 misty

misty

    Silver Member

  • Developer
  • 881 posts
  •  
    United Kingdom

Posted 22 July 2015 - 08:29 PM

I've been playing around with booting WinPE via WDS (or more accurately setting wdsnbp.com as opt67) as per the instructions in the FAQ. I was surprised to see that it was still possible to boot WinPE despite NOT setting the proxybootfilename as pxeboot.com. wdsnbp.com appears to fallback to loading (or attempting to load) pxeboot.com by default if a WDS Server is not found - in my experiments the proxybootfilename was ignored! For example when I set proxybootfilename=pxeboot.0 I received an error due to a missing pxeboot.com - no attempt was made to load pxeboot.0.

In my experiments there did not appear to be any advantage in setting opt67=wdsnbp.com - it actually delayed the boot process. Setting opt67=pxeboot.com gave better results in terms of boot time and still used the opt252 entry to load an alternative (to /boot/BCD) BCD store.

I don't have a WDS Server on my network - the FAQ appears to be incorrect as WDS is not actually being used in my case to boot WinPE - it's falling back to loading the standard WinPE PXE boot file.

Hope this makes sense!

Regards,

Misty

#360 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2291 posts
  • Location:Nantes - France
  •  
    France

Posted 22 July 2015 - 10:54 PM

I believe wdsnbp.com does one extra thing compared to pxeboot.com which is load the correct bootstrap based on the client architecture.

If you dont care about this, then indeed using pxeboot.com straight away is probably the quickest path.

 

/Erwan



#361 misty

misty

    Silver Member

  • Developer
  • 881 posts
  •  
    United Kingdom

Posted 23 July 2015 - 07:03 AM

 

I believe wdsnbp.com does one extra thing compared to pxeboot.com which is load the correct bootstrap based on the client architecture.
If you dont care about this, then indeed using pxeboot.com straight away is probably the quickest path.
 
/Erwan


Hi Erwan,

In real terms, does this make any difference? I can't test at the moment, however I recall that the same bootstrap is loaded whether the processor archetecture is x86 or x86_x64 - I'm sure that pxeboot.com was loaded either way in my tests.

Regards,

Misty

#362 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2291 posts
  • Location:Nantes - France
  •  
    France

Posted 23 July 2015 - 07:16 AM

 

Hi Erwan,

In real terms, does this make any difference? I can't test at the moment, however I recall that the same bootstrap is loaded whether the processor archetecture is x86 or x86_x64 - I'm sure that pxeboot.com was loaded either way in my tests.

Regards,

Misty

 

More here (comparing different MS bootstraps).

The boot process is also well explained here. (ipxe web site).

Wdsnbp.com
An NBP developed for Windows Deployment Services that serves the following general purposes:
1. Architecture detection
2. Pending computer scenarios. When the Auto-Add policy is enabled, this NBP is sent to pending computers to pause the network boot and report back the client computer's architecture to the server.
3. Network boot referral cases (including use of Dynamic Host Control Protocol (DHCP) options 66 and 67)

Bullet 1 & 3 might be of interest (i.e investigate and identify what it means practically).

 

Bullet 2 is useful only if you have a MS WDS server.

 

It can go this way (x86/x64) :

wdsnbp.com->pxeboot.com->bootmgr.exe->bcd->winload.exe

 

OR this way (x86/x64)

pxeboot.com->bootmgr.exe->bcd->winload.exe

 

Now I am wondering, what about UEFI?

can pxeboot.com load bootmgr.efi? if yes, can it detect the platform by itself?



#363 misty

misty

    Silver Member

  • Developer
  • 881 posts
  •  
    United Kingdom

Posted 23 July 2015 - 07:54 AM

Hi Erwan,

Thanks for the response - I'll read through your post properly later - I'm about to go out.

...Now I am wondering, what about UEFI?
can pxeboot.com load bootmgr.efi? if yes, can it detect the platform by itself?


I doubt it! Based on my memory of a quick test in a VM (VMWare Player with UEFI Firmware) when setting wdsnbp.com or pxeboot.com as opt67 the system failed to boot. There's a wdsnbp.efi included in some versions of WinPE - not sure what that tries to load though!

#364 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2291 posts
  • Location:Nantes - France
  •  
    France

Posted 23 July 2015 - 08:16 AM

I think this is where wdsnbp.com (using extra dhcp option 250 next to 252) can help : it will detect the architecture and dynamically propose the proper bootloader and BCD.

See the link above on ipxe.

The WDS boot process
Once wdsnbp.com starts, it initiates a session with the WDS server that was specified in the DHCP next-server parameter. 
The session protocol uses a combination of DHCP requests and responses and TFTP to provide the client with the appropriateboot loader (such as bootmgr.exe or bootmgfw.efi) and boot configuration data (BCD).


#365 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14303 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 23 July 2015 - 12:01 PM

Only to remind that this "issue" (actually more curiosity than anything else):

http://reboot.pro/to...erver/?p=193585

is still open and sounds like connected with what Misty is experimenting with. :unsure:

 

:duff:

Wonko



#366 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2291 posts
  • Location:Nantes - France
  •  
    France

Posted 23 July 2015 - 12:25 PM

Only to remind that this "issue" (actually more curiosity than anything else):

http://reboot.pro/to...erver/?p=193585

is still open and sounds like connected with what Misty is experimenting with. :unsure:

 

:duff:

Wonko

 

Aggreed.

Pxeboot + opt252 is one nice trick.

And actually adding opt43 (see post here) is also another trick for some devices (which will either not boot or will be slow to boot).

 

And now next to that, it seems that opt 250 might also do us some good on the architecture side when using wdsnbp.com.

Once I understand this one better, I may add it to TPS.



#367 pxe

pxe
  • Members
  • 6 posts
  •  
    United States

Posted 23 July 2015 - 03:47 PM

 

Now I am wondering, what about UEFI?

can pxeboot.com load bootmgr.efi? if yes, can it detect the platform by itself?

 

Looking at a WDS boot in wireshark, it appears efi clients load 'boot\x64\wdsmgfw.efi' directly. This would have saved me a lot of effort in the past if it was possible though.



#368 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2291 posts
  • Location:Nantes - France
  •  
    France

Posted 26 July 2015 - 02:02 PM

Looking at a WDS boot in wireshark, it appears efi clients load 'boot\x64\wdsmgfw.efi' directly. This would have saved me a lot of effort in the past if it was possible though.

 

Did some tests : 

 

UEFI

-I have to use wdsmgfw.efi as bootstrap on my UEFI machine

-I need a DHCPv6 server (which I dont have)

 

NON UEFI

-wdsnbp.com adds an extra dhcp option 250 (which I did not parse yet)

-I suspect this option probably indicates x86 or x64 (since nor the opt93 not the opt60 is able to do so)

-I suspect the wds dhcp/pxe server may use this option to dynamically indicate a x86 or x64 bootstrap and path



#369 misty

misty

    Silver Member

  • Developer
  • 881 posts
  •  
    United Kingdom

Posted 28 July 2015 - 12:22 PM

@Erwan - BUG REPORT

Hi Erwan,

I've been playing around with RIS for the guide. I've experienced some issues whilst testing in a VM (VMWare Player version 6.0.2) that I thought you should know about.

When using the built in BINL service I received the following error during the Windows installation -
File  caused an unexpected error (21) at
line 3788 in d:\xpsp\base\boot\setup\setup.c.

Press any key to continue.
Looks like the correct driver is not being parsed. Relevant lines from the log file -
10:44:28 PDHCPd:incoming NCQ packet from MAC:00-50-56-2B-7E-BE, IP:192.168.2.2
10:44:28 NCR:requested VID:0x1022 PID:0x2000 Subsys:0x20001022
10:44:28 NCR: found in C:\pxesrv\files\INF\pcntpci5.inf

.....lots of other entries....

10:44:30 TFTPd:DoReadFile:\winxp\i386\netbt.sy_ B:1432 T:90332
10:44:30 TFTPd:TransferComplete=True (192.168.2.2:38792)
10:44:30 TFTPd:DoReadFile OpenError:\winxp\i386\._ Cannot open file "C:\pxesrv\files\winxp\i386\._". The system cannot find the file specified
10:44:30 TFTPd:DoReadFile OpenError:\winxp\i386\ Cannot open file "C:\pxesrv\files\winxp\i386\". The system cannot find the path specified
Using nics.txt resolved the issue of the driver name not being parsed, however this resulted in an 0xBB error. Relevant entries in the log file -
.....lots of other entries....

12:59:05 TFTPd:DoReadFile:\winxp\i386\netbt.sy_ B:1432 T:90332
12:59:05 TFTPd:TransferComplete=True (192.168.2.2:46868)
12:59:05 TFTPd:DoReadFile OpenError:\winxp\i386\pcntpci5.sy_ Cannot open file "C:\pxesrv\files\winxp\i386\pcntpci5.sy_". The system cannot find the file specified
12:59:05 TFTPd:DoReadFile:\winxp\i386\pcntpci5.sys B:1432 T:36352
12:59:05 TFTPd:TransferComplete=True (192.168.2.2:46870)
12:59:05 TFTPd:DoReadFile:\winxp\i386\rdbss.sy_ B:1432 T:85758
12:59:05 TFTPd:TransferComplete=True (192.168.2.2:46871)
12:59:05 TFTPd:DoReadFile:\winxp\i386\mup.sy_ B:1432 T:51496
12:59:05 TFTPd:TransferComplete=True (192.168.2.2:46872)
12:59:05 TFTPd:DoReadFile:\winxp\i386\mrxsmb.sy_ B:1432 T:218709
12:59:05 TFTPd:TransferComplete=True (192.168.2.2:46873)
When using an alternative BINL service (the one diddy compiled for his "Setting Up A Windows XP PXE Server" guide based on Gianluigi Tiesi's BINL service) the installation was successful. Relevant entries -
.....lots of other entries....

10:51:58 TFTPd:DoReadFile:\winxp\i386\netbt.sy_ B:1432 T:90332
10:51:58 TFTPd:TransferComplete=True (192.168.2.2:39240)
10:51:58 TFTPd:DoReadFile OpenError:\winxp\i386\PCNTPCI5.sy_ Cannot open file "C:\pxesrv\files\winxp\i386\PCNTPCI5.sy_". The system cannot find the file specified
10:51:58 TFTPd:DoReadFile:\winxp\i386\PCNTPCI5.sys B:1432 T:36352
10:51:58 TFTPd:TransferComplete=True (192.168.2.2:39242)
10:51:58 TFTPd:DoReadFile:\winxp\i386\rdbss.sy_ B:1432 T:85758
10:51:58 TFTPd:TransferComplete=True (192.168.2.2:39243)
10:51:58 TFTPd:DoReadFile:\winxp\i386\mup.sy_ B:1432 T:51496
10:51:58 TFTPd:TransferComplete=True (192.168.2.2:39244)
10:51:58 TFTPd:DoReadFile:\winxp\i386\mrxsmb.sy_ B:1432 T:218709
10:51:58 TFTPd:TransferComplete=True (192.168.2.2:39245)
Output from Sherypa's BINL service -
Succesfully loaded 10717 devices
Binlserver started... pid 3040
Recv BINL NCQ len = 48
NCQ Driver request
[R] Mac address 00:50:56:2b:7e:be
[R] Vid: 0x1022
[R] Pid: 0x2000
[R] rev_u1 = 0x2
[R] rev_u2 = 0x0
[R] rev_u3 = 0x0
[R] rev    = 0x10
[R] rev2   = 0x208
[R] subsys = 0x20001022
[R] Source path: \\192.168.2.1\files\winxp
Checking PCI\VEN_1022&DEV_2000&SUBSYS_20001022
Checking PCI\VEN_1022&DEV_2000
Found PCI\VEN_1022&DEV_2000 in C:\pxesrv\files\INF\pcntpci5.inf
[S] Packet len = 0xc7 (199)
[S] Result code: 0x0
[S] type: 0x2
[S] base offset = 0x24 (36)
[S] drv_off = 0x50 (80)
[S] srv_off: 0x6a (106) -> 98 from start
[S] plen: 0x59 (89)
[S] p_off: 0x76 (118) -> 110 from start
[S] hid: PCI\VEN_1022&DEV_2000 - Len 0x15 (21)
[S] drv: PCNTPCI5.sys - Len 0xc (12)
[S] srv: PCnet - Len 0x5 (5)
[S] Description (REG_EXPAND_SZ [2]) = AMD PCNET Family Ethernet Adapter (PCI)
[S] Characteristics (REG_SZ [1]) = 132
[S] BusType (REG_SZ [1]) = 5
[S] Total Params: 3
If you want the complete log files then let me know.

Regards,

Misty

#370 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2291 posts
  • Location:Nantes - France
  •  
    France

Posted 30 July 2015 - 07:51 PM

RIS works like this :

 

-client send VID & PID

-server parses all inf files in a folder matching this vid & pid

-if one inf file found, server sends back the driver filename (*.sys)

 

or using nics.txt

 

-client send VID & PID

-server looks in nics.txt for a match

-if there is a match, server sends back the driver filename (*.sys)

 

I usually prefer using nics.txt as several inf files can contain the same vid  & pid (client vs server for example).

 

Now where I get surprise is that since you are using the same set of files with TPS and BINL, the issue does not seem to the files.

 

A wireshark capture (filtering on udp) up to the point BINL sends the driver filename would be great..



#371 misty

misty

    Silver Member

  • Developer
  • 881 posts
  •  
    United Kingdom

Posted 31 July 2015 - 06:27 AM

@Erwan

A wireshark capture (filtering on udp) up to the point BINL sends the driver filename would be great..


It would be if I actually knew how to do one! Will look into this when I get some time - currently busy writing a guide!!

:cheers:

Regards,

Misty

#372 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2291 posts
  • Location:Nantes - France
  •  
    France

Posted 02 August 2015 - 07:20 AM

@Misty - about bug report.

 

Found the issue.

 

For some inf files, TPS fails on parsing and therefore send a empty driver filename.

I will fix the bug after holidays but in the meantime I uploaded a new version that will mention that the parsing failed.

10:44:28 PDHCPd:incoming NCQ packet from MAC:00-50-56-2B-7E-BE, IP:192.168.2.2
10:44:28 NCR:requested VID:0x1022 PID:0x2000 Subsys:0x20001022
10:44:28 NCR: found in C:\pxesrv\files\INF\pcntpci5.inf

.....lots of other entries....

10:44:30 TFTPd:DoReadFile:\winxp\i386\netbt.sy_ B:1432 T:90332
10:44:30 TFTPd:TransferComplete=True (192.168.2.2:38792)
10:44:30 TFTPd:DoReadFile OpenError:\winxp\i386\._ Cannot open file "C:\pxesrv\files\winxp\i386\._". The system cannot find the file specified
10:44:30 TFTPd:DoReadFile OpenError:\winxp\i386\ Cannot open file "C:\pxesrv\files\winxp\i386\". The system cannot find the path specified


#373 misty

misty

    Silver Member

  • Developer
  • 881 posts
  •  
    United Kingdom

Posted 02 August 2015 - 08:15 AM

@erwan
No rush - enjoy the holidays.

Misty

P.s. not 100% sure this is the only issue as using nics.txt also failed - albeit later in the boot process.

#374 MickeyXM

MickeyXM
  • Members
  • 6 posts
  •  
    China

Posted 11 August 2015 - 04:14 PM

Hi Erwan:

    I am newer for this great PXE Server tool(1.0.0.19), and today I have successfully boot winpe from this PXE tool by pxelinux.0 , but I found one problem, when boot into winpe, I try to use "ipconfig /renew" and "ipconfig /all" to get DHCP, after about 3m still can't get DHCP, repro above steps about 3 or more times, at the end get the DHCP, and I found PXE server assign IP from the begin and continue to add one till responed .

    forgive my poor english,thanks very much!



#375 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2291 posts
  • Location:Nantes - France
  •  
    France

Posted 11 August 2015 - 04:25 PM

Hi Erwan:
I am newer for this great PXE Server tool(1.0.0.19), and today I have successfully boot winpe from this PXE tool by pxelinux.0 , but I found one problem, when boot into winpe, I try to use "ipconfig /renew" and "ipconfig /all" to get DHCP, after about 3m still can't get DHCP, repro above steps about 3 or more times, at the end get the DHCP, and I found PXE server assign IP from the begin and continue to add one till responed .
forgive my poor english,thanks very much!

Hi,

Are you in proxydhcp or dhcp mode?
Are you using latest latest version?

Regards'
Erwan
  • MickeyXM likes this





Also tagged with one or more of these keywords: pxe, network boot

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users