linql @centran.cn | 21 Nov 11:23 2014
Picon

help: Got incorrect next-server when booting from proxyDHCP server

 
 
hi, there
It seems that I have encountered the same problem with Floris Bos in the mailing list (http://comments.gmane.org/gmane.network.ipxe.devel/1171).
My booting log shows that PXE stack has no problem with distinguishing the regular DHCP server and proxyDHCP server, and will download ipxe.pxe
from proxyDHCP server normally. But when running 'show next-server' under IPXE shell, the result comes out to be the address of the regular DHCP server.
In the mailing list, Brandon replied that it's something to do with the DNSMasq stuff. Is that true?  Or a bug of ipxe?
I am also using dnsmasq as the proxyDHCP server, and the dnsmasq configuration is as follows:
dhcp-no-override
port=0
log-dhcp
enable-tftp
tftp-root=/var/lib/tftpboot
dhcp-range=192.168.1.0,proxy
dhcp-option=vendor:PXEClient,6,2b
pxe-service=x86PC,"booting from network",ipxe.pxe
 
 
Thanks,
Peter Lin
<div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div><span>
<div>
<div>hi, there</div>
<div>It seems that I have encountered the same problem with Floris Bos in the 
mailing list (<a href="http://comments.gmane.org/gmane.network.ipxe.devel/1171">http://comments.gmane.org/gmane.network.ipxe.devel/1171</a>).</div>
<div>My booting log shows that PXE stack has no problem with distinguishing the 
regular DHCP server and proxyDHCP server, and will download ipxe.pxe</div>
<div>from proxyDHCP server normally.&nbsp;But&nbsp;when&nbsp;running&nbsp;'show 
next-server'&nbsp;under IPXE shell, the result comes out to&nbsp;be the address 
of the&nbsp;regular DHCP server.</div>
<div>In the mailing list, Brandon replied that it's something to do with the 
DNSMasq stuff. Is that true?&nbsp; Or a bug of ipxe?</div>
<div>I am also using dnsmasq as the proxyDHCP server, and the dnsmasq 
configuration is as follows:</div>
<div>dhcp-no-override </div>
<div>port=0 </div>
<div>log-dhcp </div>
<div>enable-tftp </div>
<div>tftp-root=/var/lib/tftpboot </div>
<div>dhcp-range=192.168.1.0,proxy </div>
<div>dhcp-option=vendor:PXEClient,6,2b </div>
<div>pxe-service=x86PC,"booting from network",ipxe.pxe 
</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>Thanks,</div>
<div>Peter Lin</div>
</div></span></div>
</div>
Brian Rak | 20 Nov 19:13 2014

OCSP issues

Recently we switched over to SHA256 signed SSL certificates, and I've 
been having issues with OCSP ever since.  It seems that OCSP 
verification never completes for our certificate anymore, though it 
works fine in browsers (and works according to ssllabs).

I enabled OCSP debugging, and the root of the issue seems to be that the 
length of the SHA1 hash and the length of the response don't match.

I added this patch:

diff --git a/src/crypto/ocsp.c b/src/crypto/ocsp.c
old mode 100644
new mode 100755
index d4815a1..7fe30eb
--- a/src/crypto/ocsp.c
+++ b/src/crypto/ocsp.c
 <at>  <at>  -411,8 +411,12  <at>  <at>  static int ocsp_compare_responder_key_hash ( struct 
ocsp_chec

         /* Sanity check */
         difference = ( sizeof ( digest ) - responder->id.len );
+       DBGC2 ( ocsp, "OCSP %p digest id length: %i  responder id 
length: %i\n", o
         if ( difference )
-               return difference;
+       {
+               DBGC2 ( ocsp, "OCSP %p digest id length (%i) and 
responder id leng
+               //return difference;
+       }

         /* Generate SHA1 hash of certificate's public key */
         digest_init ( &sha1_algorithm, ctx );
 <at>  <at>  -421,6 +425,12  <at>  <at>  static int ocsp_compare_responder_key_hash ( struct 
ocsp_chec
                         cert->subject.public_key.raw_bits.len );
         digest_final ( &sha1_algorithm, ctx, digest );

+       DBGC2 ( ocsp, "responder key hash is:\n" );
+       DBGC2_HDA ( ocsp, 0, responder->id.data, responder->id.len );
+
+       DBGC2 ( ocsp, "computed key hash is:\n" );
+       DBGC2_HDA ( ocsp, 0, digest, sizeof(digest) );
+
         /* Compare responder ID with SHA1 hash of certificate's public 
key */
         return memcmp ( digest, responder->id.data, sizeof ( digest ) );
  }

Which produces the following output:

<6>ipxe: OCSP 0x29704 digest id length: 20  responder id length: 22
<6>ipxe: OCSP 0x29704 digest id length (20) and responder id length (22) 
different!
<6>ipxe: responder key hash is:
<6>ipxe: 00000000 : 04 14 fa 58 db 09 53 bc-19 c5 e7 b5 8b f6 10 f8 : 
...X..S.........
<6>ipxe: 00000010 : 1e 84 6d 3a 8f d8                               : ..m:..
<6>ipxe: computed key hash is:
<6>ipxe: 00000000 : fa 58 db 09 53 bc 19 c5-e7 b5 8b f6 10 f8 1e 84 : 
.X..S...........
<6>ipxe: 00000010 : 6d 3a 8f d8                                     : m:..

It looks like there's an extra \x04\x14 at the beginning of the 
response.  Other then that, the computed hash appears to match.

Any idea where this is coming from?

If I just add a dumb offset to this check:

-       return memcmp ( digest, responder->id.data, sizeof ( digest ) );
+       return memcmp ( digest, responder->id.data + 2, sizeof ( digest ) );

Verification works correctly (though, obviously this isn't a fix).

Reproducing this is fairly straightforward, just try 'chain 
https://api.vultr.com' (that particular url doesn't have a valid iPXE 
script, but since the issue happens before that even gets executed that 
should be ok)

I'm on IRC as 'devicenull' if you need any further info.
Picon

help: sanboot from AoE target not working



hi, there
I am working on booting from ipxe.efi on EFI Shell. The ipxe.efi(revision a937) is compiled with SANBOOT_PROTO_AOE flag on, and when executed on EFI Shell,  error occurs as 'Could not open SAN device', and also can not chain boot from http url with error goes 'Permission denied'. I'm pretty sure that the ipxe.efi supports features like HTTP, AoE and the corresponding AoE target has been exported because everything goes ok when booting from PXE (legacy BIOS). 
Revision of the EFI as follows:
    EFI Specification Revision   2.31
    EFI Revision                     5.9

Did I miss something with compiling ipxe or ipxe does not support EFI very well.



Best regards,
Perter Lin
<div>
<div>
<span></span><br>
</div>
<div><br></div>
<div><span><div>
<div>hi, there</div>
<div>I am working on booting from ipxe.efi on EFI Shell. The ipxe.efi(revision a937) is compiled with SANBOOT_PROTO_AOE flag on,&nbsp;<span>and when executed on EFI Shell, &nbsp;error occurs as 'Could not open SAN device', and also can not chain boot from&nbsp;</span><span>http url with error goes 'Permission denied'. I'm pretty sure that the ipxe.efi supports features like HTTP, AoE and&nbsp;</span><span>the corresponding&nbsp;</span><span>AoE target has been</span><span>&nbsp;exported because&nbsp;</span><span>everything goes ok when booting from PXE (legacy BIOS).&nbsp;</span>
</div>
<div>Revision of the EFI as follows:</div>
<div><span>&nbsp; &nbsp; EFI Specification Revision &nbsp; 2.31</span></div>
<div>
<span>&nbsp; &nbsp; EFI Revision&nbsp;</span><span>&nbsp; &nbsp;&nbsp;</span><span>&nbsp; &nbsp;&nbsp;</span><span>&nbsp; &nbsp;&nbsp;</span><span>&nbsp; &nbsp;&nbsp;</span><span>&nbsp; &nbsp; 5.9</span>
</div>
<div><br></div>
<div>Did I miss something with compiling ipxe or ipxe does not support EFI very well.</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div>Best regards,</div>
<div>Perter Lin</div>
</div></span></div>
</div>
Christian Nilsson | 19 Nov 02:03 2014
Picon

Problems with snponly and snp while ipxe.efi works

Hi,

Trying to boot with snponly with latest git a937 results in no network device on this machine. (laptop)
an much earlier snponly gets network, but it's from the time where the efi chainload didn't work.

Unfortunately only blurry images. If it helps i will transcribe them.
snponly will be needed since it will be used on different unknown hardware.

Is there any obvious step i have missed to help out debug or development?
Thanks
<div><div dir="ltr">
<div>
<div>Hi,<br><br>
</div>Trying to boot with snponly with latest git a937 results in no network device on this machine. (laptop)<br>
</div>
<div>an much earlier snponly gets network, but it's from the time where the efi chainload didn't work.<br>
</div>
<div><br></div>
<div>Unfortunately only blurry images. If it helps i will transcribe them.<br>
</div>
<div>snponly will be needed since it will be used on different unknown hardware.<br><br>
</div>
<div>Is there any obvious step i have missed to help out debug or development?<br>
</div>
<div>Thanks<br>
</div>
<div><div>
<br>&#8203;<br><div class="gmail_chip gmail_drive_chip"><a href="https://docs.google.com/file/d/0BxmW52ncEy6LZWswbk1YbWw5eWc/edit?usp=drive_web" target="_blank">&nbsp;<span dir="ltr">snponly_efi_snponlybranch_c26b_nodev.jpg</span></a></div>&#8203;&#8203;<br><div class="gmail_chip gmail_drive_chip"><a href="https://docs.google.com/file/d/0BxmW52ncEy6LdkdWa2ZwcVk0RWc/edit?usp=drive_web" target="_blank">&nbsp;<span dir="ltr">snp_efi_a937_nodev.png</span></a></div>&#8203;&#8203;<br><div class="gmail_chip gmail_drive_chip"><a href="https://docs.google.com/file/d/0BxmW52ncEy6LY2IzWnlCQlhjdkU/edit?usp=drive_web" target="_blank">&nbsp;<span dir="ltr">snponly_efi_a937_nodev.png</span></a></div>&#8203;&#8203;<br><div class="gmail_chip gmail_drive_chip"><a href="https://docs.google.com/file/d/0BxmW52ncEy6LT005UjY3ZUpBM3M/edit?usp=drive_web" target="_blank">&nbsp;<span dir="ltr">ipxe_efi_a937_ok.jpg</span></a></div>&#8203;<br>
</div></div>
</div></div>
Picon

help: How to disable HTTPS certificate verification with iPXE?



Hi there, 
I am trying to chainload boot image from web server using https. Is there any way to disable https certificate verification while compiling iPXE (something like "curl -k https://example.com/index.php")? 


Thanks,
Peter Lin
<div>
<div>
<span></span><br>
</div>
<div><br></div>
<div><span><div>
<div>Hi there,&nbsp;</div>
<div>I am trying to chainload boot image from web server using https. Is there any way to disable https certificate verification while compiling iPXE (something like&nbsp;<span></span><span>"curl -k</span><span>&nbsp;</span><a href="https://example.com/index.php">https://example.com/index.php")?</a><span>&nbsp;</span>
</div>
<div><br></div>
<div><br></div>
<div>Thanks,</div>
<div>Peter Lin</div>
</div></span></div>
</div>
Christian Wäschenfelder | 12 Nov 17:40 2014
Picon

iPXE on Moonshot node

Hi,

I'm trying to get iPXE working on a Moonshot m700 Node.
The Network Chip is a Broadcom BCM5720.

If I load the undionly.kpxe image it tries to get an IP from DHCP, but 
the NIC doesn't receive any packets.
RX counter stays at 0, but I see that the DHCP Server sends the 
responses.

If I use the ipxe.pxe image it already fails bringing up the link at 
all.

I've tried it with the binaries from Ubuntu 14.04 and with self compiled 
binaries from the latest source.

Any Ideas how to solve this?

Best,
Christian
Ivan Krutskikh | 10 Nov 11:44 2014
Picon

Windows bootup problems after successfull wimboot-iscsi setup

Hi,

Thou this is not technically speaking a ipxe question, but I think this is an appropriate place to get some help with it.

So I am developing a Linux/Windows diskless boot system based on ipxe, zfsonlinux and python. Linux part works like a bliss with multiple distros, different hardware e.t.c.

At first I made some progress with windows 7 too, using pure cd-rom setup for single station ( a supposed to be  a Microsoft supported scenario) and a ccboot client v2.0 for injecting multiple nic drivers for different hardware.

I used the same booting script for both:
eg:

#!ipxe set keep-san 1 set netX/gateway 0.0.0.0 sanboot iscsi:192.168.0.242:::1:iqn.2014-06.bootup.mtt:testinstall

But after some time ( maybe some windows updates as well, hard to tell) the whole windows booting sequence broke and I cannot fix it or reproduce it with fresh install. All windows bootups end with hang windows logo followed by
bsod 7e and a reboot. As far as I can tell, this is because windows couldn't find the driver for main hdd storage. ( basically, it is the lan driver + msicsi)

After some experiments with never ccboot versions, I tried a different approach based on http://ipxe.org/howto/winpe. So I made a custom 3.0 winpe, booted it with ipxe script:

#!ipxe

set netX/gateway 0.0.0.0
sanhook  iscsi:192.168.0.242:::1:iqn.2014-06.bootup.mtt:testinstall 
kernel http://192.168.0.242:8080/boot/wimboot
initrd http://192.168.0.242:8080/media/bcd BCD
initrd http://192.168.0.242:8080/media/boot.sdi boot.sdi
initrd http://192.168.0.242:8080/media/boot.wim boot.wim
boot

My nic was perfectly recognized and configured, windows 7 setup was able to see my iscsi drive and installed windows just like it would on a local hdd. But after reboot- same old story. Bootup hangs, BSoD 7e. Tried launching a local VM from the same media, which was used to provide iscsi target- setup finished succesfull, new desktop welcomed me.

At this point I'm out of ideas. What differs installing windows by winpe to iscsi from the same scenario with cdrom? Not to mention there are a number of tutorials on the internet suggesting the second method for client provision.

What am I doing wrong here?

Thanks in advance.
<div><div dir="ltr">
<div>
<div>
<div>Hi,<br><br>Thou this is not technically speaking a ipxe question, but I think this is an appropriate place to get some help with it. <br><br>
</div>So I am developing a Linux/Windows diskless boot system based on ipxe, zfsonlinux and python. Linux part works like a bliss with multiple distros, different hardware e.t.c.<br><br>
</div>At first I made some progress with windows 7 too, using pure cd-rom setup for single station ( a supposed to be&nbsp; a Microsoft supported scenario) and a ccboot client v2.0 for injecting multiple nic drivers for different hardware. <br><br>
</div>
<div>I used the same booting script for both: <br>
</div>
<div>eg:</div>
<br>#!ipxe

set keep-san 1
set netX/gateway 0.0.0.0
sanboot iscsi:192.168.0.242:::1:iqn.2014-06.bootup.mtt:testinstall<div><br></div>But after some time ( maybe some windows updates as well, hard to tell) the whole windows booting sequence broke and I cannot fix it or reproduce it with fresh install. All windows bootups end with hang windows logo followed by <br><div>bsod 7e and a reboot. As far as I can tell, this is because windows couldn't find the driver for main hdd storage. ( basically, it is the lan driver + msicsi)<br><br>
</div>
<div>After some experiments with never ccboot versions, I tried a different approach based on <a href="http://ipxe.org/howto/winpe">http://ipxe.org/howto/winpe</a>. So I made a custom 3.0 winpe, booted it with ipxe script:<br><br>#!ipxe<br><br>set netX/gateway 0.0.0.0<br>sanhook&nbsp; iscsi:192.168.0.242:::1:iqn.2014-06.bootup.mtt:testinstall&nbsp; <br>kernel <a href="http://192.168.0.242:8080/boot/wimboot">http://192.168.0.242:8080/boot/wimboot</a> <br>initrd <a href="http://192.168.0.242:8080/media/bcd">http://192.168.0.242:8080/media/bcd</a> BCD <br>initrd <a href="http://192.168.0.242:8080/media/boot.sdi">http://192.168.0.242:8080/media/boot.sdi</a> boot.sdi<br>initrd <a href="http://192.168.0.242:8080/media/boot.wim">http://192.168.0.242:8080/media/boot.wim</a> boot.wim<br>boot<br><br>
</div>
<div>My nic was perfectly recognized and configured, windows 7 setup was able to see my iscsi drive and installed windows just like it would on a local hdd. But after reboot- same old story. Bootup hangs, BSoD 7e. Tried launching a local VM from the same media, which was used to provide iscsi target- setup finished succesfull, new desktop welcomed me. <br><br>
</div>
<div>At this point I'm out of ideas. What differs installing windows by winpe to iscsi from the same scenario with cdrom? Not to mention there are a number of tutorials on the internet suggesting the second method for client provision.<br><br>
</div>
<div>What am I doing wrong here?<br><br>
</div>
<div>Thanks in advance.<br>
</div>
</div></div>
Ivan Krutskikh | 6 Nov 11:22 2014
Picon

Black screen on Intel NUC after wimboot

Hi,

Thanks for the IPXE project. So far I had no problems with it in various san boot scenarios.

Until I tried http://ipxe.org/howto/winpe deploy scenario with a couple of first generation intel nuc pc's (http://ark.intel.com/products/71484/Intel-NUC-Kit-DCCP847DY).

I launch the latest ipxe.lkrn from syslinux on a local usb key:


label wimboot
    kernel /boot/ipxe.lkrn
    append initrd=/boot/boot.ipxe


boot.ipxe :

#!ipxe

dhcp
set netX/gateway 0.0.0.0
sanhook  iscsi:192.168.0.242:::1:iqn.2014-06.bootup.mtt:winpe 
kernel http://192.168.0.242:8080/boot/wimboot
initrd http://192.168.0.242:8080/media/bcd BCD
initrd http://192.168.0.242:8080/media/boot.sdi boot.sdi
initrd http://192.168.0.242:8080/media/boot.wim boot.wim
boot



This boot option worked on almost any other pc in my office, but on nuc's it downloads all the defined images, flashes black screen and reboots.

What am I doing wrong here and what can be done to get it fixed?

Thanks in advance!

<div><div dir="ltr">
<div>Hi,<br><br>
</div>
<div>Thanks for the IPXE project. So far I had no problems with it in various san boot scenarios.<br><br>
</div>
<div>Until I tried <a href="http://ipxe.org/howto/winpe">http://ipxe.org/howto/winpe</a> deploy scenario with a couple of first generation intel nuc pc's (<a href="http://ark.intel.com/products/71484/Intel-NUC-Kit-DCCP847DY">http://ark.intel.com/products/71484/Intel-NUC-Kit-DCCP847DY</a>).<br><br>
</div>
<div>I launch the latest ipxe.lkrn from syslinux on a local usb key: <br><br><br>label wimboot<br>&nbsp;&nbsp;&nbsp; kernel /boot/ipxe.lkrn<br>&nbsp;&nbsp;&nbsp; append initrd=/boot/boot.ipxe<br><br><br>
</div>
<div>boot.ipxe :<br><br>#!ipxe<br><br>dhcp<br>set netX/gateway 0.0.0.0<br>sanhook&nbsp; iscsi:192.168.0.242:::1:iqn.2014-06.bootup.mtt:winpe&nbsp; <br>kernel <a href="http://192.168.0.242:8080/boot/wimboot">http://192.168.0.242:8080/boot/wimboot</a> <br>initrd <a href="http://192.168.0.242:8080/media/bcd">http://192.168.0.242:8080/media/bcd</a> BCD <br>initrd <a href="http://192.168.0.242:8080/media/boot.sdi">http://192.168.0.242:8080/media/boot.sdi</a> boot.sdi<br>initrd <a href="http://192.168.0.242:8080/media/boot.wim">http://192.168.0.242:8080/media/boot.wim</a> boot.wim<br>boot<br><br><br>
</div>
<div><br></div>
<div>This boot option worked on almost any other pc in my office, but on nuc's it downloads all the defined images, flashes black screen and reboots.<br><br>
</div>
<div>What am I doing wrong here and what can be done to get it fixed?<br><br>
</div>
<div>Thanks in advance!<br>
</div>
<div><br></div>
</div></div>
Wissam Shoukair | 2 Nov 15:32 2014

Closing all net devices in netboot()

Hi,

Does anyone knows what is the purpose of calling close_all_netdevs() in netboot()? Can I remove this call?

one of the main reasons why I’m interested in removing this call is that its disabling me to hook to an empty LUN in iSCSI target via the first port and then installing an OS by downloading an install image via PXE on the second port.

 

Thanks,

Wissam

<div>
<div class="WordSection1">
<p class="MsoNormal">Hi,<p></p></p>
<p class="MsoNormal">Does anyone knows what is the purpose of calling close_all_netdevs() in netboot()? Can I remove this call?<p></p></p>
<p class="MsoNormal">one of the main reasons why I&rsquo;m interested in removing this call is that its disabling me to hook to an empty LUN in iSCSI target via the first port and then installing an OS by downloading an install image via PXE on the second port.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Thanks,<p></p></p>
<p class="MsoNormal">Wissam<p></p></p>
</div>
</div>
Floris Bos | 28 Oct 23:43 2014
Picon

Windows having problems parsing iBFT from recent iPXE versions?

Hi,

I am having problems getting a Windows 2012 iSCSI installation to work 
with recent iPXE versions,
while it does work with an older iPXE version.

Test setup:

- Virtualbox VM as "server to be provisioned"
- Simple Synology NAS device as iSCSI target
- Latest wimboot
- iPXE script that looks like this:

==
set keep-san 1
set skip-san-boot 1
sanboot 
iscsi:192.168.178.99::3260::iqn.2000-01.com.synology:DiskStation.diskless
kernel http://192.168.178.100/wimboot
initrd http://192.168.178.100/bootmgr bootmgr
initrd http://192.168.178.100/bcd bcd
initrd http://192.168.178.100/boot.sdi boot.sdi
initrd http://192.168.178.100/segmono_boot.ttf segmono_boot.ttf
initrd http://192.168.178.100/segoe_slboot.ttf segoe_slboot.ttf
initrd http://192.168.178.100/wgl4_boot.ttf wgl4_boot.ttf
initrd http://192.168.178.100/boot.wim boot.wim
boot
==

With undionly.kkpxe compiled today from git sources:

Windows does not detect the iSCSI disk and network configuration is not 
entirely correct.
Seems Windows was able to obtain the IPv4 IP-address, but not my IPv4 
nameserver from iBFT.

Screenshot of ipconfig/diskpart "show disk": 
http://s29.postimg.org/s8eyhb78n/ipxe_2014.png

With an old undionly.kkpxe I compiled back in September 2012, and 
everything else the same, it does works correctly.

Screenshot: http://s22.postimg.org/hg17r5ug1/ipxe_2012.png

Any idea what might be the issue?

--

-- 
Yours sincerely,

Floris Bos

Christian Stroehmeier | 28 Oct 18:29 2014
Picon

Password parsing

Hi everyone,

I recently discovered that a '?' in your password will cause the
password to be displayed in plain text during imgfetch. After looking
into core/uri.c what was causing this I think the same is true for '#'
and ' <at> '. The parsing simply assumes these characters server their usual
purpose when occurring in an URI.

I tried working around that issue, but I am undecided how to do this
correctly. First thing that comes to mind is starting at the end of the
string searching backwards. Are there any drawbacks on this? If not I
would implement it and send the patch.

Cheers,
Chris

Gmane