Erik Jacobson | 10 Dec 22:43 2014
Picon

multicast tftp working after scary hack made to udp_demux()

I decided to post this in a new thread because I made a bit of a breakthrough
on the multicast tftp problem today and I wanted to be sure the right people
saw my note.

Basically, multicast tftp transport is not working properly in the latest
iPXE code (tftp multicast, I'm not talking about mtftp here).

I have now been able to hack iPXE so that multicast tftp works.

The key was enabling the udp debugging.

When multicast is in play, it appears udp_demux() is returning NULL.
It appears that the st_family and st_port checks are OK. It appears
that the problem is likely this check in udp_demux():

if ( memcmp ( udp->local.pad, empty_sockaddr.pad,sizeof ( udp->local.pad ) ) == 0 )

If that's zero, we return NULL instead of the 'udp' pointer in udp_demux().

Now I don't know what I'm doing at all but if I force the return of the udp
pointer even if the above mentioned check is zero, then multicast tftp works
fine.

I was able to successfully multicast-transfer grub2 core.0 using multicast
tftp in iPXE, then it successfully brought up the grub2 menu.

At this point, I am hoping an expert can take a look to see what the
real fix might be. Since I'm a novice in network programming, I really
don't know what bad side effect my evil hack has.

(Continue reading)

Wissam Shoukair | 10 Dec 16:53 2014

Handling multiple IPv6 addresses in the same prefix

Hi,

We've encountered cases where in an IPv6 network, a router advertisement packet has both the "Managed
address configuration" bit set, telling iPXE to retrieve its IP address through DHCP, and the
"autonomous address-configuration" bit also set, telling iPXE to generate an IP address automatically
from the prefix published in the RA packet. iPXE supports only a single IP address for each subnet/prefix,
so when it receives the second RA packet, it replaces the IP address configured by DHCP with the stateless
address generated with the prefix.

If the RA packet is received in the middle of a TCP transfer, the connection is broken, and the incoming
packets are dropped as they belong to the previous IP address.

This can also happen if a subnet contains two routers, for instance a DHCP server, and a switch, both
publishing conflicting router advertisement packets.

We are not sure whether this is a valid configuration. In any case, we believe the fact that iPXE only
supports a single IP is problematic, because our Linux servers were able to configure both IP address
without a problem.

What do you think should be the right behavior in this case? Perhaps iPXE should store two IP addresses on
each prefix - one from SLAAC and one from DHCPv6?

Regards,
Wissam and Haggai

Erik Jacobson | 9 Dec 21:55 2014
Picon

iPXE tftp multicast help requested (connection timeouts)

I'm hoping someone can help me out here.

I have run in to a problem with getting tftp working in multicast mode
from iPXE. I'm talking here tftp multicast and not mtftp. The transfer
times out.

 - I'm using the latest iPXE from your git repo (as of yesterday).
 - On the same node, if I boot linux and use atftp client in multicast mode,
   the file transfers OK
 - atftpd on the server is in verbose mode and shows a multicast tftp transfer
   is attempted.
 - Both iPXE and the tftpd server show timeouts for the transfer

Here is the iPXE command I use from the command line environment. It happens
to be grub2 core.0 but that's just a handy test file I have around.

iPXE> dhcp                                                                      
Configuring (net0 00:25:90:0c:da:a6)...... ok                                   
iPXE> imgfetch tftm://172.23.0.1/boot/grub2/i386-pc/core.0                      
tftm://172.23.0.1/boot/grub2/i386-pc/core.0... Connection timed out (http://ipxe
.org/4c126035)                                                               

If I switch to normal tftp instead of tftm, all seems well (but it isn't
multicast).

I have tried chainloading both undionly.kpxe and ipxe.pxe (with the
drivers integrated). The behavior is the same.

Here are some lines from the server side atftpd server showing the failed
attempt:
(Continue reading)

PORCHET Jerome | 2 Dec 21:07 2014

Network device not detect

Hello,

 

I have one troubleshot with detection of the network device of my thinclients.

After some reboot of my Thinclient, the ixpe lkrn boot and try to initializing network device. Unfortunately, the ipxe stop here. It doesn’t catch my tftp server to take linux init.

If I try to reboot or halt and start the thinclient after this the troubelshot persist.

The only solution for retrieve a stable state is to unplug AC/DC of thinclient some seconds.

I’m using iPXE ipxe_1.0.0+git-20131111.c3d1e78 but I found also the troubleshot with September 2014 version

They have an Realtek  RTL8169

I try to use this version compile with DEBUG=realtek option and I have this message when the problem appear.

 

iPXE initializing devices… REALTEK 0xa3d84 appears to be an RTL8169

REALTEK 0xa3d84 EEPROM is a 93c46

REALTEK 0xa3d84 EEPROM ID incorrect (0xffff);assuming no EEPROM

REALTEK 0xa3d84 EEPROM timed out waiting for MII read

REALTEK 0xa3d84 EEPROM could not reset MII : Connection time out (http://ipxe.org/4c634035)

OK

                               

Can you help me?

 

Cordialement,

 

Jérôme PORCHET

Alliance Software

Service Systèmes

Tel : 05 49 32 31 43 (STD)

<at> :jerome.porchet <at> alliadis.com

1, impasse des chênes

79026 Niort-Bessines Cedex 9

 

"Pensez à l'environnement avant d'imprimer cet e-mail."

 

<div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hello,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">I have one troubleshot with detection of the network device of my thinclients.
<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">After some reboot of my Thinclient, the ixpe lkrn boot and try to initializing network device. Unfortunately, the ipxe stop here. It doesn&rsquo;t catch my tftp server to take linux init.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">If I try to reboot or halt and start the thinclient after this the troubelshot persist.
<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">The only solution for retrieve a stable state is to unplug AC/DC of thinclient some seconds.
<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">I&rsquo;m using iPXE ipxe_1.0.0+git-20131111.c3d1e78 but I found also the troubleshot with September 2014 version<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">They have an Realtek&nbsp; RTL8169<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">I try to use this version compile with DEBUG=realtek option and I have this message when the problem appear.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">iPXE initializing devices&hellip; REALTEK 0xa3d84 appears to be an RTL8169<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">REALTEK 0xa3d84 EEPROM is a 93c46<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">REALTEK 0xa3d84 EEPROM ID incorrect (0xffff);assuming no EEPROM<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">REALTEK 0xa3d84 EEPROM timed out waiting for MII read<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">REALTEK 0xa3d84 EEPROM could not reset MII : Connection time out (<a href="http://ipxe.org/4c634035">http://ipxe.org/4c634035</a>)<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">OK<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Can you help me?<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>Cordialement,<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>J&eacute;r&ocirc;me PORCHET<p></p></span></p>
<p class="MsoNormal"><span>Alliance Software<p></p></span></p>
<p class="MsoNormal"><span>Service Syst&egrave;mes<p></p></span></p>
<p class="MsoNormal"><span>Tel : 05 49 32 31 43 (STD)<p></p></span></p>
<p class="MsoNormal"><span> <at> :jerome.porchet <at> alliadis.com<p></p></span></p>
<p class="MsoNormal"><span>1, impasse des ch&ecirc;nes<p></p></span></p>
<p class="MsoNormal"><span>79026 Niort-Bessines Cedex 9<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span></span><span>"Pensez
 &agrave; l'environnement avant d'imprimer cet e-mail."</span><span><p></p></span></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
</div>
</div>
Rohan Sehgal | 26 Nov 08:51 2014
Picon

A small patch to the makefile

Hi,

I have been re-purposing the ipxe code to work in harmony with other boot managers without netboot support. In pursuit of that I needed a way to change the default entry point of the efi binary.

Old:
TGT_LD_ENTRY    = _$(TGT_PREFIX)_start

New:
ifndef TGT_LD_ENTRY
TGT_LD_ENTRY    = _$(TGT_PREFIX)_start
endif

Is it possible for me to submit a change that allows me to override the entry point using an ifndef? It would be great if this could go upstream. Thank you.

Regards
Rohan
<div><div dir="ltr">
<div>
<div>
<div>
<div>Hi,<br><br>
</div>I have been re-purposing the ipxe code to work in harmony with other boot managers without netboot support. In pursuit of that I needed a way to change the default entry point of the efi binary.<br><br>Old:<br>TGT_LD_ENTRY&nbsp;&nbsp; &nbsp;= _$(TGT_PREFIX)_start<br><br>New:<br>ifndef TGT_LD_ENTRY<br>TGT_LD_ENTRY&nbsp;&nbsp; &nbsp;= _$(TGT_PREFIX)_start<br>endif <br><br>
</div>Is it possible for me to submit a change that allows me to override the entry point using an ifndef? It would be great if this could go upstream. Thank you.<br><br>
</div>Regards<br>
</div>Rohan<br>
</div></div>
Anton D. Kachalov | 8 Dec 13:20 2014
Picon

Get autoboot device from the network card list

Hello.

I need to get autoboot device while booting as PCI Option ROM to create tagged interface to try to boot from first.

An example iPXE script snippet:

<-- ipxe-cut -->
set idx:int32 0

:loop isset ${net${idx}/mac} || goto fail
  iseq ${net${idx}/autoboot} 0x1 && goto loop_end ||
  inc idx && goto loop

:loop_end

echo Trying VLAN-123 first on net${idx}...
vcreate -t 123 net${idx} ||
ifconf net${idx}-111 && isset ${filename} && chain ${filename} ||

echo ...then access port...
ifconf net${idx} && isset ${filename} && chain ${filename} ||

fail:
</-- ipxe-cut -->

I've hacked a bit and export `autoboot' setting (ipxe-autoboot.patch). But it's a wrong way to do things.
Attachment (ipxe-autoboot.patch): text/x-diff, 3278 bytes
Hello.

I need to get autoboot device while booting as PCI Option ROM to create tagged interface to try to boot from first.

An example iPXE script snippet:

<-- ipxe-cut -->
set idx:int32 0

:loop isset ${net${idx}/mac} || goto fail
  iseq ${net${idx}/autoboot} 0x1 && goto loop_end ||
  inc idx && goto loop

:loop_end

echo Trying VLAN-123 first on net${idx}...
vcreate -t 123 net${idx} ||
ifconf net${idx}-111 && isset ${filename} && chain ${filename} ||

echo ...then access port...
ifconf net${idx} && isset ${filename} && chain ${filename} ||

fail:
</-- ipxe-cut -->

I've hacked a bit and export `autoboot' setting (ipxe-autoboot.patch). But it's a wrong way to do things.
Anton D. Kachalov | 8 Dec 13:12 2014

[ipxe] [interface/smbios] Add `board-product' name setting (#32)

On the most Server's boards it stores actual base-board name while `product' (from System Information) might have vendor or seller's specific name not related to the base-board product.

You can merge this Pull Request by running

git pull https://github.com/ya-mouse/ipxe intelx

Or view, comment on, or merge it at:

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

Commit Summary

  • [drivers/net/intelx] Add 8086:1557 card (Intel 82599 10G ethernet mezz)
  • Merge branch 'master' of https://github.com/ipxe/ipxe into intelx
  • [interface/smbios] Add base board product name setting: `board-product'. On the most Server's boards it stores actual base-board name while `product' (from System Information) might have vendor or seller's specific name not related to the base-board product.

File Changes

Patch Links:


Reply to this email directly or view it on GitHub.

<div>
<p>On the most Server's boards it stores actual base-board name while `product' (from System Information) might have vendor or seller's specific name not related to the base-board product.</p>

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

<h4>Commit Summary</h4>
<ul>
<li>[drivers/net/intelx] Add 8086:1557 card (Intel 82599 10G ethernet mezz)</li>
  <li>Merge branch 'master' of https://github.com/ipxe/ipxe into intelx</li>
  <li>[interface/smbios] Add base board product name setting: `board-product'. On the most Server's boards it stores actual base-board name while `product' (from System Information) might have vendor or seller's specific name not related to the base-board product.</li>
</ul>
<h4>File Changes</h4>
<ul>
<li>
    M
    <a href="https://github.com/ipxe/ipxe/pull/32/files#diff-0">src/interface/smbios/smbios_settings.c</a>
    (12)
  </li>
</ul>
<h4>Patch Links:</h4>
<ul>
<li><a href="https://github.com/ipxe/ipxe/pull/32.patch">https://github.com/ipxe/ipxe/pull/32.patch</a></li>
  <li><a href="https://github.com/ipxe/ipxe/pull/32.diff">https://github.com/ipxe/ipxe/pull/32.diff</a></li>
</ul>
<p>&mdash;<br>Reply to this email directly or <a href="https://github.com/ipxe/ipxe/pull/32">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>
Steven Haber | 5 Dec 01:05 2014

TCP flow control window shrink on discard causes low throughput

Hello!

As the subject states, I'm seeing a situation where the TCP window
shrink logic causes a connection to be throttled indefinitely. I am
downloading a ~600MB ISO image from an internal server using iPXE's
HTTP capabilities. Intermittently I will see the download slow to a
crawl. A packet capture shows the receive side decreasing the TCP
window drastically and permanently, from a reasonable size of ~150k
down to 1k. I can send the capture to you if it'd be useful. The
responsible code lives in src/net/tcp.c:tcp_discard. Below is a patch
that remedies the issue. Obviously this is hack. The correct solution
might involve capping the maximum window size decrease per discard,
and adding complimentary window size increase code to the main rx
path. This way slowdowns wouldn't be as severe and we could recover
from them.

What do you think? Thanks!

Steven Haber
Software Engineer
Qumulo, Inc.

diff --git a/src/net/tcp.c b/src/net/tcp.c
index 987cb63..3c59e46 100644
--- a/src/net/tcp.c
+++ b/src/net/tcp.c
 <at>  <at>  -1331,31 +1331,31  <at>  <at>  static unsigned int tcp_discard ( void ) {
        struct tcp_rx_queued_header *tcpqhdr;
        uint32_t max_win;
        unsigned int discarded = 0;

        /* Try to drop one queued RX packet from each connection */
        list_for_each_entry ( tcp, &tcp_conns, list ) {
                list_for_each_entry_reverse ( iobuf, &tcp->rx_queue, list ) {

                        /* Limit window to prevent future discards */
                        tcpqhdr = iobuf->data;
                        max_win = ( tcpqhdr->seq - tcp->rcv_ack );
                        if ( max_win < tcp->max_rcv_win ) {
                                DBGC ( tcp, "TCP %p reducing maximum window "
                                       "from %d to %d\n",
                                       tcp, tcp->max_rcv_win, max_win );
-                               tcp->max_rcv_win = max_win;
+                               //tcp->max_rcv_win = max_win;
                        }

                        /* Remove packet from queue */
                        list_del ( &iobuf->list );
                        free_iob ( iobuf );

                        /* Report discard */
                        discarded++;
                        break;
                }
        }

        return discarded;
 }
Rohan Sehgal | 30 Nov 12:34 2014
Picon

Small patch to Makefile.housekeeping

Hi,

I have been re-purposing the ipxe code to work with other EFI boot managers without netboot support. In pursuit of that I needed a way to change the default entry point of the efi binary, this allows anyone to create a small "wrapper" that calls only the functionality needed by the frontend (say the ability to discover, rather than boot).

Old:
TGT_LD_ENTRY    = _$(TGT_PREFIX)_start

New:
ifndef TGT_LD_ENTRY
TGT_LD_ENTRY    = _$(TGT_PREFIX)_start
endif

Is it possible for me to submit a change that allows me to override the entry point using an ifndef? It would be great if this could go upstream. Thank you.

Regards
Rohan
<div><div dir="ltr">
<div>
<div>
<div>Hi,<br><br>
</div>I have been re-purposing the ipxe code 
to work with other EFI boot managers without netboot support. In 
pursuit of that I needed a way to change the default entry point of the 
efi binary, this allows anyone to create a small "wrapper" that calls only the functionality needed by the frontend (say the ability to discover, rather than boot).<br><br>Old:<br>TGT_LD_ENTRY&nbsp;&nbsp; &nbsp;= _$(TGT_PREFIX)_start<br><br>New:<br>ifndef TGT_LD_ENTRY<br>TGT_LD_ENTRY&nbsp;&nbsp; &nbsp;= _$(TGT_PREFIX)_start<br>endif <br><br>
</div>Is
 it possible for me to submit a change that allows me to override the 
entry point using an ifndef? It would be great if this could go 
upstream. Thank you.<br><br>
</div>Regards<div class=""><div class="" tabindex="0">Rohan</div></div>
</div></div>
Oliver Rath | 26 Nov 15:33 2014
Picon

Doubling fontsize in high-resolution-menus?

Hi list,

is there a possibility for doubling fontsize in
high-resolution-environments? Some times ago Michael talked about
something like that, but I didnt found something in the documentation.

Tfh!
Oliver

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>

Gmane