James A. Peltier | 29 Jan 20:26 2015
Picon
Picon

Problem with SSL connections

Hi All,

I've been using iPXE for quite some time, however, lately I've had trouble with SSL support compiled in. 
When attempting to connect to my HTTPS server I get the error 

  Connection Reset (http://ipxe.org/0f0a6039)

Now looking at the code outlined in net/tcp.c#105{3,6} it would indicate that the server connection
failed and my question is why?  When connecting to the server via a web browser or from the command line the
file downloads just fine.  Only with iPXE does the process fail.  I look at the HTTPS server and the settings
for SSL seem to be fine, the certificate is still valid, etc.  In fact, if I connect from the same machine that
I'm trying to download the file to using HTTPS outside of iPXE it works.  I'm really at a loss here so any
pointers would be greatly appreciated.

--

-- 
James A. Peltier
IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone   : 778-782-6573
Fax     : 778-782-3045
E-Mail  : jpeltier@...
Website : http://www.sfu.ca/itservices
Twitter :  <at> sfu_rcg
Powering Engagement Through Technology
"Build upon strengths and weaknesses will generally take care of themselves" - Joyce C. Lock
Patrick Agrain | 27 Jan 15:20 2015

How to submit a patch ?

Hello,

I was able to patch the iPXE source tree to use the SGMII interface on a
Mohon Peak CRB to boot through PXE.
The driver is based on the igb driver with support of the Marvell PHY
M88E1543.

Could you please tell me how to share this with the community ?

Thanks.
Kind regards,
Patrick Agrain

Laszlo Ersek | 27 Jan 11:06 2015
Picon

[PATCH] efi_snp: improve compliance with the EFI_SIMPLE_NETWORK_PROTOCOL spec

The efi_snp interface dates back to 2008, when the GetStatus() interface
must have been seriously under-specified. The UEFI Specification (2.4)
specifies EFI_SIMPLE_NETWORK_PROTOCOL in detail however. In short:

- the Transmit() interface is assumed to link (not copy) the SNP client's
  buffer and return at once (without blocking), taking ownership of the
  buffer temporarily;

- the GetStatus() interface releases one of the completed (transmitted or
  internally copied) buffers back to the caller. If there are several
  completed buffers, it is unspecified which one is returned.

The EFI build of the grub boot loader actually verifies the buffer address
returned by GetStatus(), therefore in efi_snp we must at least fake the
queueing of client buffers. This patch doesn't track client buffers
together with the internally queued io_buffer structures, we consider a
client buffer recyclable as soon as we make a deep copy of it and queue
the copy internally.

Signed-off-by: Laszlo Ersek <lersek@...>
---
 src/include/ipxe/efi/efi_snp.h |  6 +++++
 src/interface/efi/efi_snp.c    | 54 ++++++++++++++++++++++++------------------
 2 files changed, 37 insertions(+), 23 deletions(-)

diff --git a/src/include/ipxe/efi/efi_snp.h b/src/include/ipxe/efi/efi_snp.h
index 6d67912..5843eec 100644
--- a/src/include/ipxe/efi/efi_snp.h
+++ b/src/include/ipxe/efi/efi_snp.h
 <at>  <at>  -17,6 +17,8  <at>  <at> 
(Continue reading)

Alex Williamson | 26 Jan 18:54 2015
Picon

[PATCH] [dhcp] Extract timing parameters out to header and document

iPXE uses DHCP timeouts loosely based on values recommended by the
specification, but often abbreviated to reduce timeouts for reliable
and/or simple network topologies.  Previous attempts to change the
defaults to more spec-compliant values have met resistance and
apathy, therefore this patch simply tries to extract the timing
parameters to a config file and document them.  The resulting default
iPXE behavior is exactly the same, but downstreams are now afforded
the opportunity to implement spec compliant behavior via config file
overrides.

I believe the following overrides defined in config/local/general.h
provide sufficiently spec compliant DHCP timeouts:

/*
 * PXE spec defines timeouts of 4, 8, 16, 32 seconds
 */
#undef DHCP_DISC_START_TIMEOUT_SEC
#define DHCP_DISC_START_TIMEOUT_SEC	4
#undef DHCP_DISC_END_TIMEOUT_SEC
#define DHCP_DISC_END_TIMEOUT_SEC	32

/*
 * Elapsed time used for early break waiting for ProxyDHCP, this therefore
 * needs to be less than the cumulative time for the first 2 timeouts.
 */
#undef DHCP_DISC_PROXY_TIMEOUT_SEC
#define DHCP_DISC_PROXY_TIMEOUT_SEC	11

/*
 * Approximate PXE spec requirement using minimum timeout (0.25s) for
(Continue reading)

Malte Starostik | 24 Jan 13:45 2015
Picon

snponly.efi won't find any interfaces

Hi,

I compiled snponly.efi from git master (d38bac0) with a default config and if won't find any interfaces. 
With a serial console enabled and DEBUG=efi_driver,efi_pci,snp,snpnet,snponly I get this:

===================
CHAINED 0x72a21798
PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(0017A4770002,0x0)/IPv4(0.0.0.0) found
SimpleNetwork on 0x72a21798 PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(0017A4770002,0x0)/IPv4(0.0.0.0)
CHAINED 0x72a21798
PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(0017A4770002,0x0)/IPv4(0.0.0.0) found Nii31 on
0x72ca7918 PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(0017A4770002,0x0)
iPXE initialising devices...EFIDRV connecting our drivers
EFIPCI 0x730a2a18 PciRoot(0x0)/Pci(0x5,0x6) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x730a2818 PciRoot(0x0)/Pci(0x6,0x0) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x730a2618 PciRoot(0x0)/Pci(0x6,0x1) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x730a2418 PciRoot(0x0)/Pci(0x6,0x2) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x730a2218 PciRoot(0x0)/Pci(0x6,0x3) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x730a2018 PciRoot(0x0)/Pci(0x6,0x4) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x730a0e18 PciRoot(0x0)/Pci(0x6,0x5) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x730a0c18 PciRoot(0x0)/Pci(0x6,0x6) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x730a0a18 PciRoot(0x0)/Pci(0x6,0x7) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x730a0818 PciRoot(0x0)/Pci(0x7,0x0) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x730a0618 PciRoot(0x0)/Pci(0x7,0x1) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x730a0418 PciRoot(0x0)/Pci(0x7,0x2) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x730a0218 PciRoot(0x0)/Pci(0x7,0x3) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x730a0018 PciRoot(0x0)/Pci(0x7,0x4) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x7309ea18 PciRoot(0x0)/Pci(0x16,0x0) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x7309e818 PciRoot(0x0)/Pci(0x16,0x1) cannot read PCI configuration: No such device
(http://ipxe.org/2c044087)                                                                                                                                                          
(Continue reading)

Anton D. Kachalov | 24 Jan 00:23 2015

Re: [ipxe] ConnectX3 support from Mellanox Flexboot (#20)

Regarding to the License header in Mellanox drivers, it licensed under GPLv2 without exceptions.


Reply to this email directly or view it on GitHub.

<div>
<p>Regarding to the License header in Mellanox drivers, it licensed under GPLv2 without exceptions.</p>

<p>&mdash;<br>Reply to this email directly or <a href="https://github.com/ipxe/ipxe/pull/20#issuecomment-71283964">view it on GitHub</a>.</p>
<div itemscope itemtype="http://schema.org/EmailMessage">
  <div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
    </div>
  </div>
</div>
Robin Smidsrød | 23 Jan 23:05 2015

Re: [ipxe] ConnectX3 support from Mellanox Flexboot (#20)

I guess it all depends on licensing. What kind of license is FlexBoot under, and how does it interface with/use iPXE? If it is practically a fork of iPXE with some extra drivers I don't see why not. But licensing is always a tricky subject.


Reply to this email directly or view it on GitHub.

<div>
<p>I guess it all depends on licensing. What kind of license is FlexBoot under, and how does it interface with/use iPXE? If it is practically a fork of iPXE with some extra drivers I don't see why not. But licensing is always a tricky subject.</p>

<p>&mdash;<br>Reply to this email directly or <a href="https://github.com/ipxe/ipxe/pull/20#issuecomment-71274578">view it on GitHub</a>.</p>
<div itemscope itemtype="http://schema.org/EmailMessage">
  <div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
    </div>
  </div>
</div>
Anton D. Kachalov | 23 Jan 11:37 2015

Re: [ipxe] ConnectX3 support from Mellanox Flexboot (#20)

Here it is:
http://www.mellanox.com/downloads/Drivers/PXE/FlexBoot-3.4.460_SRC.tar.gz
Looks like a new iPXE codebase. Is it acceptable to merge drivers from FlexBoot to upstream?


Reply to this email directly or view it on GitHub.

<div>
<p>Here it is:<br><a href="http://www.mellanox.com/downloads/Drivers/PXE/FlexBoot-3.4.460_SRC.tar.gz">http://www.mellanox.com/downloads/Drivers/PXE/FlexBoot-3.4.460_SRC.tar.gz</a><br>
Looks like a new iPXE codebase. Is it acceptable to merge drivers from FlexBoot to upstream?</p>

<p>&mdash;<br>Reply to this email directly or <a href="https://github.com/ipxe/ipxe/pull/20#issuecomment-71175624">view it on GitHub</a>.</p>
<div itemscope itemtype="http://schema.org/EmailMessage">
  <div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
    </div>
  </div>
</div>
Wissam Shoukair | 13 Jan 12:02 2015

[PATCH] [ipoib] Fix cache discarder

Hi,
We found an issue in ipoib_discard_remac().
1. IPoIB discarder is not valid for non-Infiniband devices.
2. owner data in ibdev is netdev struct pointer and not ipoib struct pointer.

This bug made some servers hang when trying to do HTTP boot over IB.

Thanks,
Wissam Shoukair
Mellanox Technologies IT

Issue: 466447
Signed-off-by: Wissam Shoukair <wissams@...>
---
 src/drivers/net/ipoib.c | 33 ++++++++++++++++++++++++---------
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/src/drivers/net/ipoib.c b/src/drivers/net/ipoib.c index b18c6d5..679cbff 100644
--- a/src/drivers/net/ipoib.c
+++ b/src/drivers/net/ipoib.c
 <at>  <at>  -98,6 +98,20  <at>  <at>  struct errortab ipoib_errors[] __errortab = {
 	__einfo_errortab ( EINFO_EINPROGRESS_JOINING ),  };

+static int ipoib_open ( struct net_device *netdev ); static void 
+ipoib_close ( struct net_device *netdev ); static int ipoib_transmit ( 
+struct net_device *netdev,
+			    struct io_buffer *iobuf );
+static void ipoib_poll ( struct net_device *netdev );
+
+/** IPoIB network device operations */
+static struct net_device_operations ipoib_operations = {
+	.open		= ipoib_open,
+	.close		= ipoib_close,
+	.transmit	= ipoib_transmit,
+	.poll		= ipoib_poll,
+};
+
 /****************************************************************************
  *
  * IPoIB REMAC cache
 <at>  <at>  -205,13 +219,22  <at>  <at>  static void ipoib_flush_remac ( struct ipoib_device *ipoib ) {
  */
 static unsigned int ipoib_discard_remac ( void ) {
 	struct ib_device *ibdev;
+	struct net_device *netdev;
 	struct ipoib_device *ipoib;
 	struct ipoib_peer *peer, *tmp;
 	unsigned int discarded = 0;

 	/* Try to discard one cache entry for each IPoIB device */
 	for_each_ibdev ( ibdev ) {
-		ipoib = ib_get_ownerdata ( ibdev );
+		netdev = ib_get_ownerdata ( ibdev );
+		/* Skip non-Infiniband ports */
+		if ( netdev->op != &ipoib_operations )
+			continue;
+
+		ipoib = netdev->priv;
+		if ( list_empty ( &ipoib->peers ) )
+			return 0;
+
 		list_for_each_entry_reverse_safe ( peer, tmp, &ipoib->peers, list ) {
 			list_del ( &peer->list );
 			free ( peer );
 <at>  <at>  -900,14 +923,6  <at>  <at>  static void ipoib_close ( struct net_device *netdev ) {
 	ib_close ( ibdev );
 }

-/** IPoIB network device operations */
-static struct net_device_operations ipoib_operations = {
-	.open		= ipoib_open,
-	.close		= ipoib_close,
-	.transmit	= ipoib_transmit,
-	.poll		= ipoib_poll,
-};
-
 uint8_t mellanox_general_client_id[MAX_LL_ADDR_LEN] = {255,0,0,0,0,0,2,0,0,2,0xC9,0,0,0,0,0,0,0,0,0};
 /**
  * Probe IPoIB device
--
1.7.11.1

Chris Taylor | 9 Jan 13:19 2015
Picon

'Ctrl' as Prompt Key

Hi All,

 

Is there any way I can set the ctrl key alone as the prompt key? I can see combinations with Ctrl but would prefer to just have the Ctrl key.

 

 

 

Chris Taylor

University of Portsmouth

 

<div><div class="WordSection1">
<p class="MsoNormal">Hi All,</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">Is there any way I can set the ctrl key alone as the prompt key? I can see combinations with Ctrl but would prefer to just have the Ctrl key.</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal"><span>Chris Taylor</span></p>
<p class="MsoNormal"><span>University of Portsmouth</span></p>
<p class="MsoNormal">&nbsp;</p>
</div></div>
Brandon Penglase | 7 Jan 14:52 2015

[ipxe] Reverts changes to src/net/udp/tftp.c made in commit 76675365271291beb9d... (#33)

...daeec10da14f4faa55ecc on 02/27/14.

This allows tftp to load from a Windows/Microsoft TFTP server.
This should also fix pull request #31: #31
Without this, when you try to load from a Windows/Microsoft TFTP server,
you get error 3d1260 "Inappropriate I/O control operation", as there is a leading "/".

You can merge this Pull Request by running

git pull https://github.com/bpenglase/ipxe master

Or view, comment on, or merge it at:

  https://github.com/ipxe/ipxe/pull/33

Commit Summary

  • Reverts changes to src/net/udp/tftp.c made in commit 76675365271291beb9ddaeec10da14f4faa55ecc on 02/27/14.

File Changes

Patch Links:


Reply to this email directly or view it on GitHub.

<div>
<p>...daeec10da14f4faa55ecc on 02/27/14.</p>

<p>This allows tftp to load from a Windows/Microsoft TFTP server.<br>
This should also fix pull request <a href="https://github.com/ipxe/ipxe/pull/31" class="issue-link" title="tftp booting from a windows TFTP server gives issues.">#31</a>: <a href="https://github.com/ipxe/ipxe/pull/31" class="issue-link" title="tftp booting from a windows TFTP server gives issues.">#31</a><br>
Without this, when you try to load from a Windows/Microsoft TFTP server,<br>
you get error 3d1260 "Inappropriate I/O control operation", as there is a leading "/".</p>

<h4>You can merge this Pull Request by running</h4>
  git pull https://github.com/bpenglase/ipxe master
<p>Or view, comment on, or merge it at:</p>
<p>&nbsp;&nbsp;<a href="https://github.com/ipxe/ipxe/pull/33">https://github.com/ipxe/ipxe/pull/33</a></p>

<h4>Commit Summary</h4>
<ul>
<li>Reverts changes to src/net/udp/tftp.c made in commit 76675365271291beb9ddaeec10da14f4faa55ecc on 02/27/14.</li>
</ul>
<h4>File Changes</h4>
<ul>
<li>
    M
    <a href="https://github.com/ipxe/ipxe/pull/33/files#diff-0">src/net/udp/tftp.c</a>
    (14)
  </li>
</ul>
<h4>Patch Links:</h4>
<ul>
<li><a href="https://github.com/ipxe/ipxe/pull/33.patch">https://github.com/ipxe/ipxe/pull/33.patch</a></li>
  <li><a href="https://github.com/ipxe/ipxe/pull/33.diff">https://github.com/ipxe/ipxe/pull/33.diff</a></li>
</ul>
<p>&mdash;<br>Reply to this email directly or <a href="https://github.com/ipxe/ipxe/pull/33">view it on GitHub</a>.</p>
<div itemscope itemtype="http://schema.org/EmailMessage">
  <div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
    </div>
  </div>
</div>

Gmane