etherboot-developers — Discussion of developer issues

[Etherboot-developers] PXE sniffer

[何闯 <jus...@16...>]

Dear all,


I was just wondering, if is it possible to implement a sniffer in PXE, to capture network packet after windows has been booted?


Thanks in advance! 
yours,
soforth

[Etherboot-developers] gPXE undionly boot failed(PXE BUG report)

[何闯 <jus...@16...>]

Dear all,
 
I tested gPXE on an old motherboad with a Realtek 8111D NIC.
Everything is OK when PC Moniter is connected to the integrated video card, the problem comes out when reconnect it to a independent video card(in PCIe slot): DHCP timed out(0x4c106035).
 
So, I "make bin/undionly.kpxe DEBUG=udp,undinet" or
"make bin/undionly.kkpxe DEBUG=udp,undinet" and added some "printf" to it. I finaly noteiced that in arch/i386/drivers/net/undinet.c:
 
Every time when undinet_poll() (line 224) been called,  undinet_isr_triggered() returns zero, so that undinet_poll() returens without doing anything. Futher more, this is because in arch/i386/drivers/net/undiisr.S (hooked in undinet, right?), undiisr_trigger_count not been triggered. Since I do not familer with AT&T assambly, how can I debug that?(even with a print output? I tried print_message call (found in pxeprefix.S), but without any output in the PC moniter).
 
What is the possible cause of undiisr_trigger_count  not been triggered When connect to an independed video card ?
 
I think this is a BUG of PXE, hopefully some one can help me~
 
Thanks in advance!
 
yours,
soforth

[Etherboot-developers] [PATCH] [ipv4] fragment offset in IPv4 header is in units of 8 bytes

[Michal K. <mku...@su...>]

Multiply header field by 8 before comparing to current buffer length.

Signed-off-by: Michal Kubecek <mku...@su...>
---
 src/net/ipv4.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/net/ipv4.c b/src/net/ipv4.c
index 53048b8..19b90ee 100644
--- a/src/net/ipv4.c
+++ b/src/net/ipv4.c
@@ -232,7 +232,7 @@ static struct io_buffer * ipv4_reassemble ( struct io_buffer * iobuf ) {
 			 * the reassembled I/O buffer
 			 */
 			if ( iob_len ( fragbuf->frag_iob ) == 
-			      ( pkt_frags & IP_MASK_OFFSET ) ) {
+			      ( ( pkt_frags & IP_MASK_OFFSET ) << 3 ) ) {
 				/**
 				 * Append the contents of the fragment to the
 				 * reassembled I/O buffer
-- 
1.7.7

[Etherboot-developers] [PATCH] IPv4 fragmentation fixes - one more

[Michal K. <mku...@su...>]

For the sake of completeness, if some wants to apply the series I posted
last week, one more fix is needed for it to actually work.

Michal Kubecek (1):
  [ipv4] fragment offset in IPv4 header is in units of 8 bytes

 src/net/ipv4.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

-- 
1.7.7

[Etherboot-developers] [PATCH 0/7] IPv4 fragmentation fixes

[Michal K. <mku...@su...>]

These are fixes for some IPv4 fragmentation problems I've found when
investigating problems of one of our customers with PXE boot of a Xen
guest in presence of fragmented packets.

Patches 1-3 are critical, 1 and 2 leading to memory corruption, 3 to
wrong parsing of IPv4 header. Patches 4-6 resolve various memory leaks.
Patch 7 is optional, it limits memory consumption under circumstances
that shouldn't happen but are known to happen from time to time.

Michal Kubecek (7):
  [ipv4] Check for buffer overflow when adding fragment
  [ipv4] Unlink frag_buffer from lists when before freeing
  [ipv4] Convert fragmentation header fields from NBO to HBO
  [ipv4] When freeing frag_buffer, free its io_buffer
  [ipv4] Free packet buffer when fragment isn't matched
  [ipv4] Free frag_buffer when its timer expires
  [ipv4] Limit number of fragment buffers

 src/include/gpxe/ip.h |    4 ++
 src/net/ipv4.c        |   86 ++++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 82 insertions(+), 8 deletions(-)

-- 
1.7.7

[Etherboot-developers] [PATCH 2/7] [ipv4] Unlink frag_buffer from lists when before freeing

[Michal K. <mku...@su...>]

Freeing frag_buffer structure without unlinking it from frag_buffers
linked list may lead to the list being broken when the memory is reused.
The same problem can happen with timers list if frag_buffer is freed
while its embedded retry_timer is still running.

After this change, list_for_each_entry_safe() has to be used in
ipv4_reassemble() as free_fragbuf() is called inside the cycle body.

Signed-off-by: Michal Kubecek <mku...@su...>
---
 src/net/ipv4.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/net/ipv4.c b/src/net/ipv4.c
index 30c1541..bd41978 100644
--- a/src/net/ipv4.c
+++ b/src/net/ipv4.c
@@ -148,11 +148,13 @@ static void ipv4_frag_expired ( struct retry_timer *timer __unused,
 }
 
 /**
- * Free fragment buffer
+ * Unlink and free fragment buffer
  *
  * @v fragbug	Fragment buffer
  */
 static void free_fragbuf ( struct frag_buffer *fragbuf ) {
+	list_del ( &fragbuf->list );
+	stop_timer ( &fragbuf->frag_timer );
 	free ( fragbuf );
 }
 
@@ -165,11 +167,12 @@ static void free_fragbuf ( struct frag_buffer *fragbuf ) {
 static struct io_buffer * ipv4_reassemble ( struct io_buffer * iobuf ) {
 	struct iphdr *iphdr = iobuf->data;
 	struct frag_buffer *fragbuf;
+	struct frag_buffer *fragtmp;
 	
 	/**
 	 * Check if the fragment belongs to any fragment series
 	 */
-	list_for_each_entry ( fragbuf, &frag_buffers, list ) {
+	list_for_each_entry_safe ( fragbuf, fragtmp, &frag_buffers, list ) {
 		if ( fragbuf->ident == iphdr->ident &&
 		     fragbuf->src.s_addr == iphdr->src.s_addr ) {
 			/**
-- 
1.7.7

[Etherboot-developers] [PATCH 1/7] [ipv4] Check for buffer overflow when adding fragment

[Michal K. <mku...@su...>]

Check whether there is space enough for new fragment to prevent buffer
overflow if fragmented packet larger than IPV4_FRAG_IOB_SIZE (1500 bytes)
is received.

Signed-off-by: Michal Kubecek <mku...@su...>
---
 src/net/ipv4.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/src/net/ipv4.c b/src/net/ipv4.c
index 92d0684..30c1541 100644
--- a/src/net/ipv4.c
+++ b/src/net/ipv4.c
@@ -186,6 +186,14 @@ static struct io_buffer * ipv4_reassemble ( struct io_buffer * iobuf ) {
 				 * reassembled I/O buffer
 				 */
 				iob_pull ( iobuf, sizeof ( *iphdr ) );
+				if ( iob_tailroom ( fragbuf->frag_iob ) <
+					iob_len ( iobuf ) )
+				{
+					/* Fragmented packet is too long */
+					free_fragbuf ( fragbuf );
+					free_iob ( iobuf );
+					return NULL;
+				}
 				memcpy ( iob_put ( fragbuf->frag_iob,
 							iob_len ( iobuf ) ),
 					 iobuf->data, iob_len ( iobuf ) );
-- 
1.7.7

[Etherboot-developers] [PATCH 6/7] [ipv4] Free frag_buffer when its timer expires

[Michal K. <mku...@su...>]

In the frag_buffer timer expiry function, there was comment "Free the
fragment buffer" but no attempt to free it was actually done.

Signed-off-by: Michal Kubecek <mku...@su...>
---
 src/include/gpxe/ip.h |    3 +++
 src/net/ipv4.c        |   26 ++++++++++++++++++++++++--
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/src/include/gpxe/ip.h b/src/include/gpxe/ip.h
index 4342a0c..29def10 100644
--- a/src/include/gpxe/ip.h
+++ b/src/include/gpxe/ip.h
@@ -34,6 +34,7 @@ struct net_protocol;
 
 #define IP_FRAG_IOB_SIZE	1500
 #define IP_FRAG_TIMEOUT		50
+#define IP_FRAG_EXPIRED		0x0001
 
 /** An IPv4 packet header */
 struct iphdr {
@@ -86,6 +87,8 @@ struct frag_buffer {
 	struct io_buffer *frag_iob;
 	/* Reassembly timer */
 	struct retry_timer frag_timer;
+	/* Flags */
+	uint16_t frag_flags;
 	/* List of fragment reassembly buffers */
 	struct list_head list;
 };
diff --git a/src/net/ipv4.c b/src/net/ipv4.c
index d698318..f20762f 100644
--- a/src/net/ipv4.c
+++ b/src/net/ipv4.c
@@ -139,11 +139,14 @@ static struct ipv4_miniroute * ipv4_route ( struct in_addr *dest ) {
  * @v timer	Retry timer
  * @v over	If asserted, the timer is greater than @c MAX_TIMEOUT 
  */
-static void ipv4_frag_expired ( struct retry_timer *timer __unused,
+static void ipv4_frag_expired ( struct retry_timer *timer,
 				int over ) {
 	if ( over ) {
+		struct frag_buffer *fragbuf;
 		DBG ( "Fragment reassembly timeout" );
-		/* Free the fragment buffer */
+		/* Mark the fragment buffer for cleanup */
+		fragbuf = container_of(timer, struct frag_buffer, frag_timer);
+		fragbuf->frag_flags |= IP_FRAG_EXPIRED;
 	}
 }
 
@@ -161,6 +164,21 @@ static void free_fragbuf ( struct frag_buffer *fragbuf ) {
 }
 
 /**
+ * Remove all expired fragment buffers
+ *
+ */
+static void ipv4_frag_cleanup ()
+{
+	struct frag_buffer *fragbuf;
+	struct frag_buffer *fragtmp;
+
+	list_for_each_entry_safe ( fragbuf, fragtmp, &frag_buffers, list ) {
+		if ( fragbuf->frag_flags & IP_FRAG_EXPIRED )
+			free_fragbuf ( fragbuf );
+	}
+}
+
+/**
  * Fragment reassembler
  *
  * @v iobuf		I/O buffer, fragment of the datagram
@@ -172,6 +190,9 @@ static struct io_buffer * ipv4_reassemble ( struct io_buffer * iobuf ) {
 	struct frag_buffer *fragbuf;
 	struct frag_buffer *fragtmp;
 	
+	/* Remove expired fragment buffers */
+	ipv4_frag_cleanup();
+
 	/**
 	 * Check if the fragment belongs to any fragment series
 	 */
@@ -228,6 +249,7 @@ static struct io_buffer * ipv4_reassemble ( struct io_buffer * iobuf ) {
 	
 		/** Create a new fragment buffer */
 		fragbuf = ( struct frag_buffer* ) malloc ( sizeof( *fragbuf ) );
+		fragbuf->frag_flags = 0;
 		fragbuf->ident = iphdr->ident;
 		fragbuf->src = iphdr->src;
 
-- 
1.7.7

[Etherboot-developers] [PATCH 7/7] [ipv4] Limit number of fragment buffers

[Michal K. <mku...@su...>]

For every (first) IPv4 fragment received, a buffer of size
IPV4_FRAG_IOB_SIZE (currently 1500 bytes) is allocated. Limiting the
number of fragment buffers prevents memory exhaustion if too many
fragments are received without being assembled (e.g. because of wrongly
configured firewall).

Signed-off-by: Michal Kubecek <mku...@su...>
---
 src/include/gpxe/ip.h |    1 +
 src/net/ipv4.c        |   30 ++++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/src/include/gpxe/ip.h b/src/include/gpxe/ip.h
index 29def10..55854ca 100644
--- a/src/include/gpxe/ip.h
+++ b/src/include/gpxe/ip.h
@@ -34,6 +34,7 @@ struct net_protocol;
 
 #define IP_FRAG_IOB_SIZE	1500
 #define IP_FRAG_TIMEOUT		50
+#define IP_FRAG_MAXBUFS		128
 #define IP_FRAG_EXPIRED		0x0001
 
 /** An IPv4 packet header */
diff --git a/src/net/ipv4.c b/src/net/ipv4.c
index f20762f..53048b8 100644
--- a/src/net/ipv4.c
+++ b/src/net/ipv4.c
@@ -34,6 +34,9 @@ struct list_head ipv4_miniroutes = LIST_HEAD_INIT ( ipv4_miniroutes );
 /** List of fragment reassembly buffers */
 static LIST_HEAD ( frag_buffers );
 
+/** Current number of fragment reassembly buffers */
+static int frag_buffer_count = 0;
+
 /**
  * Add IPv4 minirouting table entry
  *
@@ -157,6 +160,7 @@ static void ipv4_frag_expired ( struct retry_timer *timer,
  */
 static void free_fragbuf ( struct frag_buffer *fragbuf ) {
 	list_del ( &fragbuf->list );
+	frag_buffer_count--;
 	stop_timer ( &fragbuf->frag_timer );
 	if ( fragbuf->frag_iob )
 		free_iob ( fragbuf->frag_iob );
@@ -179,6 +183,27 @@ static void ipv4_frag_cleanup ()
 }
 
 /**
+ * Remove oldest fragment buffer
+ *
+ */
+static void ipv4_frag_remove_oldest ()
+{
+	struct frag_buffer *fragbuf;
+	struct frag_buffer *oldest = NULL;
+	unsigned long oldest_start = 0;
+
+	list_for_each_entry ( fragbuf, &frag_buffers, list ) {
+		if ( !oldest || (fragbuf->frag_timer.start < oldest_start) ) {
+			oldest = fragbuf;
+			oldest_start = fragbuf->frag_timer.start;
+		}
+	}
+
+	if ( oldest )
+		free_fragbuf ( oldest );
+}
+
+/**
  * Fragment reassembler
  *
  * @v iobuf		I/O buffer, fragment of the datagram
@@ -246,6 +271,10 @@ static struct io_buffer * ipv4_reassemble ( struct io_buffer * iobuf ) {
 	/** Check if the fragment is the first in the fragment series */
 	if ( ( pkt_frags & IP_MASK_MOREFRAGS ) &&
 			( ( pkt_frags & IP_MASK_OFFSET ) == 0 ) ) {
+
+		/* If there are too many buffers, remove the oldest */
+		if ( frag_buffer_count >= IP_FRAG_MAXBUFS )
+			ipv4_frag_remove_oldest();
 	
 		/** Create a new fragment buffer */
 		fragbuf = ( struct frag_buffer* ) malloc ( sizeof( *fragbuf ) );
@@ -266,6 +295,7 @@ static struct io_buffer * ipv4_reassemble ( struct io_buffer * iobuf ) {
 
 		/* Add the fragment buffer to the list of fragment buffers */
 		list_add ( &fragbuf->list, &frag_buffers );
+		frag_buffer_count++;
 	} else {
 		/* Doesn't match anything but it's not first fragment */
 		free_iob ( iobuf );
-- 
1.7.7

[Etherboot-developers] [PATCH 5/7] [ipv4] Free packet buffer when fragment isn't matched

[Michal K. <mku...@su...>]

When fragment doesn't match any frag_buffer and it isn't a first fragment,
free its io_buffer structure.

Signed-off-by: Michal Kubecek <mku...@su...>
---
 src/net/ipv4.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/net/ipv4.c b/src/net/ipv4.c
index 6c38d70..d698318 100644
--- a/src/net/ipv4.c
+++ b/src/net/ipv4.c
@@ -244,6 +244,9 @@ static struct io_buffer * ipv4_reassemble ( struct io_buffer * iobuf ) {
 
 		/* Add the fragment buffer to the list of fragment buffers */
 		list_add ( &fragbuf->list, &frag_buffers );
+	} else {
+		/* Doesn't match anything but it's not first fragment */
+		free_iob ( iobuf );
 	}
 	
 	return NULL;
-- 
1.7.7

[Etherboot-developers] [PATCH 4/7] [ipv4] When freeing frag_buffer, free its io_buffer

[Michal K. <mku...@su...>]

When frag_buffer is freed, we should free its io_buffer structure as well.
However, we don't want to free it when the io_buffer was passed as return
value of ipv4_reassemble().

Signed-off-by: Michal Kubecek <mku...@su...>
---
 src/net/ipv4.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/net/ipv4.c b/src/net/ipv4.c
index a63738f..6c38d70 100644
--- a/src/net/ipv4.c
+++ b/src/net/ipv4.c
@@ -155,6 +155,8 @@ static void ipv4_frag_expired ( struct retry_timer *timer __unused,
 static void free_fragbuf ( struct frag_buffer *fragbuf ) {
 	list_del ( &fragbuf->list );
 	stop_timer ( &fragbuf->frag_timer );
+	if ( fragbuf->frag_iob )
+		free_iob ( fragbuf->frag_iob );
 	free ( fragbuf );
 }
 
@@ -206,6 +208,7 @@ static struct io_buffer * ipv4_reassemble ( struct io_buffer * iobuf ) {
 				/** Check if the fragment series is over */
 				if ( ! ( pkt_frags & IP_MASK_MOREFRAGS ) ) {
 					iobuf = fragbuf->frag_iob;
+					fragbuf->frag_iob = NULL;
 					free_fragbuf ( fragbuf );
 					return iobuf;
 				}
-- 
1.7.7

[Etherboot-developers] [PATCH 3/7] [ipv4] Convert fragmentation header fields from NBO to HBO

[Michal K. <mku...@su...>]

Fragmentation fields of IPv4 header need to be converted from network
byte ordering to host byte ordering to be compatible with IP_MASK_*
constants.

Signed-off-by: Michal Kubecek <mku...@su...>
---
 src/net/ipv4.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/net/ipv4.c b/src/net/ipv4.c
index bd41978..a63738f 100644
--- a/src/net/ipv4.c
+++ b/src/net/ipv4.c
@@ -166,6 +166,7 @@ static void free_fragbuf ( struct frag_buffer *fragbuf ) {
  */
 static struct io_buffer * ipv4_reassemble ( struct io_buffer * iobuf ) {
 	struct iphdr *iphdr = iobuf->data;
+	uint16_t pkt_frags = ntohs ( iphdr->frags );
 	struct frag_buffer *fragbuf;
 	struct frag_buffer *fragtmp;
 	
@@ -183,7 +184,7 @@ static struct io_buffer * ipv4_reassemble ( struct io_buffer * iobuf ) {
 			 * the reassembled I/O buffer
 			 */
 			if ( iob_len ( fragbuf->frag_iob ) == 
-			      ( iphdr->frags & IP_MASK_OFFSET ) ) {
+			      ( pkt_frags & IP_MASK_OFFSET ) ) {
 				/**
 				 * Append the contents of the fragment to the
 				 * reassembled I/O buffer
@@ -203,7 +204,7 @@ static struct io_buffer * ipv4_reassemble ( struct io_buffer * iobuf ) {
 				free_iob ( iobuf );
 
 				/** Check if the fragment series is over */
-				if ( ! ( iphdr->frags & IP_MASK_MOREFRAGS ) ) {
+				if ( ! ( pkt_frags & IP_MASK_MOREFRAGS ) ) {
 					iobuf = fragbuf->frag_iob;
 					free_fragbuf ( fragbuf );
 					return iobuf;
@@ -219,8 +220,8 @@ static struct io_buffer * ipv4_reassemble ( struct io_buffer * iobuf ) {
 	}
 	
 	/** Check if the fragment is the first in the fragment series */
-	if ( iphdr->frags & IP_MASK_MOREFRAGS &&
-			( ( iphdr->frags & IP_MASK_OFFSET ) == 0 ) ) {
+	if ( ( pkt_frags & IP_MASK_MOREFRAGS ) &&
+			( ( pkt_frags & IP_MASK_OFFSET ) == 0 ) ) {
 	
 		/** Create a new fragment buffer */
 		fragbuf = ( struct frag_buffer* ) malloc ( sizeof( *fragbuf ) );
-- 
1.7.7

[Etherboot-developers] [IPXE PATCH] [dhcp] Use random transaction ID to associate messages

[Amos K. <ak...@re...>]

RFC2131.txt:
xid 4  Transaction ID, a random number chosen by the
       client, used by the client and server to associate
       messages and responses between a client and a
       server.
The 'xid' field is used by the client to match incoming DHCP messages
with pending requests.  A DHCP client MUST choose 'xid's in such a
way as to minimize the chance of using an 'xid' identical to one used
by another client. For example, a client may choose a different,
random initial 'xid' each time the client is rebooted, and
subsequently use sequential 'xid's until the next reboot.  Selecting
a new 'xid' for each retransmission is an implementation decision.  A
client may choose to reuse the same 'xid' or select a new 'xid' for
each retransmitted message.

Users may boot up a QEMU guest without default mac address, it's easy to
repeat, it always to be failed to get IP with PXE boot.
RFC suggests us to use random xid, it's necessary. This patch generates
random id when start dhcp, and record it to netdev struct.

Signed-off-by: Amos Kong <ak...@re...>
CC: Eduardo Habkost <eha...@re...>
CC: Michael Brown <mc...@ip...>
---
 src/include/ipxe/netdevice.h |    3 +++
 src/net/udp/dhcp.c           |   23 ++++-------------------
 2 files changed, 7 insertions(+), 19 deletions(-)

diff --git a/src/include/ipxe/netdevice.h b/src/include/ipxe/netdevice.h
index 3633a16..cd68dd0 100644
--- a/src/include/ipxe/netdevice.h
+++ b/src/include/ipxe/netdevice.h
@@ -319,6 +319,9 @@ struct net_device {
 	/** Link-layer broadcast address */
 	const uint8_t *ll_broadcast;
 
+	/* DHCP Transaction ID */
+	uint32_t xid;
+
 	/** Current device state
 	 *
 	 * This is the bitwise-OR of zero or more NETDEV_XXX constants.
diff --git a/src/net/udp/dhcp.c b/src/net/udp/dhcp.c
index a0b74df..ed104a7 100644
--- a/src/net/udp/dhcp.c
+++ b/src/net/udp/dhcp.c
@@ -137,23 +137,6 @@ static inline const char * dhcp_msgtype_name ( unsigned int msgtype ) {
 	}
 }
 
-/**
- * Calculate DHCP transaction ID for a network device
- *
- * @v netdev		Network device
- * @ret xid		DHCP XID
- *
- * Extract the least significant bits of the hardware address for use
- * as the transaction ID.
- */
-static uint32_t dhcp_xid ( struct net_device *netdev ) {
-	uint32_t xid;
-
-	memcpy ( &xid, ( netdev->ll_addr + netdev->ll_protocol->ll_addr_len
-			 - sizeof ( xid ) ), sizeof ( xid ) );
-	return xid;
-}
-
 /****************************************************************************
  *
  * DHCP session
@@ -938,7 +921,7 @@ int dhcp_create_packet ( struct dhcp_packet *dhcppkt,
 
 	/* Initialise DHCP packet content */
 	memset ( dhcphdr, 0, max_len );
-	dhcphdr->xid = dhcp_xid ( netdev );
+	dhcphdr->xid = netdev->xid;
 	dhcphdr->magic = htonl ( DHCP_MAGIC_COOKIE );
 	dhcphdr->htype = ntohs ( netdev->ll_protocol->ll_proto );
 	dhcphdr->op = dhcp_op[msgtype];
@@ -1187,7 +1170,8 @@ static int dhcp_deliver ( struct dhcp_session *dhcp,
 			&server_id, sizeof ( server_id ) );
 
 	/* Check for matching transaction ID */
-	if ( dhcphdr->xid != dhcp_xid ( dhcp->netdev ) ) {
+	if ( dhcphdr->xid != dhcp->netdev->xid ) {
+
 		DBGC ( dhcp, "DHCP %p %s from %s:%d has bad transaction "
 		       "ID\n", dhcp, dhcp_msgtype_name ( msgtype ),
 		       inet_ntoa ( peer->sin_addr ),
@@ -1304,6 +1288,7 @@ int start_dhcp ( struct interface *job, struct net_device *netdev ) {
 	dhcp = zalloc ( sizeof ( *dhcp ) );
 	if ( ! dhcp )
 		return -ENOMEM;
+	netdev->xid = random();
 	ref_init ( &dhcp->refcnt, dhcp_free );
 	intf_init ( &dhcp->job, &dhcp_job_desc, &dhcp->refcnt );
 	intf_init ( &dhcp->xfer, &dhcp_xfer_desc, &dhcp->refcnt );

Re: [Etherboot-developers] [PATCH] [dhcp] Use random transaction ID to associate messages

[Amos K. <ak...@re...>]

----- Original Message -----
> Whole Archive: http://marc.info/?l=kvm&m=131609166918121&w=2
> 
> ----- Original Message -----
> > On Thu, 2011-09-15 at 10:43 -0400, Amos Kong wrote:
> > > ----- Original Message -----
> > > > ----- Original Message -----
> > > > > On Thu, 15 Sep 2011 21:00:38 +0800, Amos Kong
> > > > > <ak...@re...>
> > > > > wrote:
> > > > >
> > > > > > + netdev->xid = random();
> > > > >
> > > > > This will not work for reboots. The decision that the
> > > > > hardware
> > > > > address
> > > > > is
> > > > > choosen was not accidental. Not sure if some DHCP server will
> > > > > count
> > > > > on
> > > > > the
> > > > > ID. (RFC 2131 "Retain DHCP client configuration across server
> > > > > reboots,
> > > > > and,
> > > > > whenever possible, a DHCP client should be assigned the same
> > > > > configuration
> > > > > parameters despite restarts of the DHCP mechanism"). If not
> > > > > so I
> > > > > am
> > > > > fine
> > > > > with the patch.
> > >
> > > Hi Hagen,
> > >
> > > rfc2131 clearly describes that we need a random xid,
> > > I don't think xid is a port of "DHCP client configuration",
> > > it only be used to associate messages and responses between
> > > client
> > > and server.
> > >
> > > I would post a patch to ipxe maillist later if it's ok.
> > 
> > rfc2131 only required that "A DHCP client MUST choose 'xid's in
> > such a
> > way as to minimize the chance of using an 'xid' identical to one
> > used
> > by another client.".
> > 
> > The 'random xid' suggestion is listed merely as an example.
> > 
> > The way I see it using a xid based on MAC instead of a random
> > number
> > is
> > safer since the odds for same MAC on the same network are pretty
> > slim
> > since it would cause problems on other layers in the network.
> 
> Users may boot up a QEMU guest without default mac address, it's easy
> to repeat.
> 
> Yaniv, what real problem do you touched? only not in accordance to
> the RFC?

Answer from Yaniv:
Indeed. I saw some people complaining on inability to get a DHCP address, and
from the network capture saw that. We have no idea why the failed most of the
times to get an IP address with PXE boot.

Re: [Etherboot-developers] [PATCH] [dhcp] Use random transaction ID to associate messages

[Amos K. <ak...@re...>]

----- Original Message -----
> On Thu, 2011-09-15 at 10:43 -0400, Amos Kong wrote:
> > ----- Original Message -----
> > > ----- Original Message -----
> > > > On Thu, 15 Sep 2011 21:00:38 +0800, Amos Kong <ak...@re...>
> > > > wrote:
> > > >
> > > > > + netdev->xid = random();
> > > >
> > > > This will not work for reboots. The decision that the hardware
> > > > address
> > > > is
> > > > choosen was not accidental. Not sure if some DHCP server will
> > > > count
> > > > on
> > > > the
> > > > ID. (RFC 2131 "Retain DHCP client configuration across server
> > > > reboots,
> > > > and,
> > > > whenever possible, a DHCP client should be assigned the same
> > > > configuration
> > > > parameters despite restarts of the DHCP mechanism"). If not so I
> > > > am
> > > > fine
> > > > with the patch.
> >
> > Hi Hagen,
> >
> > rfc2131 clearly describes that we need a random xid,
> > I don't think xid is a port of "DHCP client configuration",
> > it only be used to associate messages and responses between client
> > and server.
> >
> > I would post a patch to ipxe maillist later if it's ok.
> 
> rfc2131 only required that "A DHCP client MUST choose 'xid's in such a
> way as to minimize the chance of using an 'xid' identical to one used
> by another client.".
> 
> The 'random xid' suggestion is listed merely as an example.

|   For example, a client may choose a different,
|   random initial 'xid' each time the client is rebooted, and
|   subsequently use sequential 'xid's until the next reboot. 

This example is not suggesting us use random xid, but give us an example
of how to use random xid.


|   xid           4  Transaction ID, a random number chosen by the
|                    client, used by the client and server to associate
|                    messages and responses between a client and a
|                    server.

This description doesn't mention random is an option.
So I think rfc suggests us to use random xid, it's necessary.

CC: dr...@bu...

Amos

Re: [Etherboot-developers] [PATCH] [dhcp] Use random transaction ID to associate messages

[Eduardo H. <eha...@re...>]

On Thu, Sep 15, 2011 at 05:53:02PM +0300, Sasha Levin wrote:
[...]
> The 'random xid' suggestion is listed merely as an example.
> 
> The way I see it using a xid based on MAC instead of a random number is
> safer since the odds for same MAC on the same network are pretty slim
> since it would cause problems on other layers in the network.

I would agree with you if the current code didn't use just the last 4
bytes of the MAC address. So clients could have completely different MAC
addresses (as expected), have no problems communicating in the network,
but share the same final 4 bytes in the MAC address and end up
generating the same xid.

Probably a hash function that used all bytes of the MAC address as input
would work too, but using a random number seems to be good enough (and
simpler, IMO).


> 
> Whats the reason behind this patch? Whats wrong with current selection
> of xid?

I'm not sure what issue made Amos investigate the xid generation code,
but the current selection of xid is wrong as it uses just the last 4
bytes of the MAC address.

-- 
Eduardo

Re: [Etherboot-developers] [PATCH] [dhcp] Use random transaction ID to associate messages

[Amos K. <ak...@re...>]

Whole Archive: http://marc.info/?l=kvm&m=131609166918121&w=2

----- Original Message -----
> On Thu, 2011-09-15 at 10:43 -0400, Amos Kong wrote:
> > ----- Original Message -----
> > > ----- Original Message -----
> > > > On Thu, 15 Sep 2011 21:00:38 +0800, Amos Kong <ak...@re...>
> > > > wrote:
> > > >
> > > > > + netdev->xid = random();
> > > >
> > > > This will not work for reboots. The decision that the hardware
> > > > address
> > > > is
> > > > choosen was not accidental. Not sure if some DHCP server will
> > > > count
> > > > on
> > > > the
> > > > ID. (RFC 2131 "Retain DHCP client configuration across server
> > > > reboots,
> > > > and,
> > > > whenever possible, a DHCP client should be assigned the same
> > > > configuration
> > > > parameters despite restarts of the DHCP mechanism"). If not so I
> > > > am
> > > > fine
> > > > with the patch.
> >
> > Hi Hagen,
> >
> > rfc2131 clearly describes that we need a random xid,
> > I don't think xid is a port of "DHCP client configuration",
> > it only be used to associate messages and responses between client
> > and server.
> >
> > I would post a patch to ipxe maillist later if it's ok.
> 
> rfc2131 only required that "A DHCP client MUST choose 'xid's in such a
> way as to minimize the chance of using an 'xid' identical to one used
> by another client.".
> 
> The 'random xid' suggestion is listed merely as an example.
> 
> The way I see it using a xid based on MAC instead of a random number
> is
> safer since the odds for same MAC on the same network are pretty slim
> since it would cause problems on other layers in the network.

Users may boot up a QEMU guest without default mac address, it's easy to repeat.

Yaniv, what real problem do you touched? only not in accordance to the RFC?

Try to re-start host network, I can capture random dhcp idx, it's not fixed.

Amos

> Whats the reason behind this patch? Whats wrong with current selection
> of xid?

Re: [Etherboot-developers] [PATCH] [dhcp] Use random transaction ID to associate messages

[Amos K. <ak...@re...>]

----- Original Message -----
> ----- Original Message -----
> > On Thu, 15 Sep 2011 21:00:38 +0800, Amos Kong <ak...@re...>
> > wrote:
> >
> > > + netdev->xid = random();
> >
> > This will not work for reboots. The decision that the hardware
> > address
> > is
> > choosen was not accidental. Not sure if some DHCP server will count
> > on
> > the
> > ID. (RFC 2131 "Retain DHCP client configuration across server
> > reboots,
> > and,
> > whenever possible, a DHCP client should be assigned the same
> > configuration
> > parameters despite restarts of the DHCP mechanism"). If not so I am
> > fine
> > with the patch.

Hi Hagen,

rfc2131 clearly describes that we need a random xid,
I don't think xid is a port of "DHCP client configuration",
it only be used to associate messages and responses between client and server.

I would post a patch to ipxe maillist later if it's ok.

Thanks,
Amos

> But a DHCP client should be identified by its MAC, not the xid.
> Y.

Re: [Etherboot-developers] [PATCH] forcedeth driver - very bad transfer rate / missing register update

[Marty C. <md...@et...>]

Nice work, Yann!  Thanks for contributing this patch.
We will apply it to gPXE.

/ Marty /

On 3/20/11 8:06 AM, Yann Cézard wrote:
> Hi (g/i)pxe developpers,
>
> Playing recently with a new toy with an MCP79 chipset (0x10DE, 0x0AB0) 
> in it and iSCSI, I found that the transfer rate were anormaly slow 
> (about 15 seconds to load about 15MB of kernel + initrd, on a Gb 
> network) in the (g/i)pxe phase, transfer rate were then OK (~50MB/s) 
> after the linux code has taken the control.
> After having test with TFTP and HTTP tranfer, I found that the problem 
> was the same, so it had to be in the forcedeth driver.
>
> Enabling debugging mode show me that the driver didn't stop calling
> forcedeth_link_status and as a consequence nv_update_linkspeed when 
> polling (and each time it just found that there is no link change, so 
> it was just a big waste of time).
> Same problem with gpxe and ipxe.
>
> After having a look at the linux forcedeth driver, I found that the 
> (g/i)pxe forcedeth driver code was missing a NVREG_MIISTAT_LINKCHANGE 
> register update, which made the poll method thinking that a link 
> change as occured every time it was called.
> Updating this register and testing it in forcedeth_link_status just 
> did the trick !
>
> Here are some tests that I have done :
> ####################################
> Embedded scripts used to test perfs :
> ===========
> #!gpxe
> dhcp net0
> time imgfetch http://192.168.1.10/some.iso
> ===========
> or :
> ===========
> #!ipxe
> dhcp net0
> time imgfetch http://192.168.1.10/some.iso
> ===========
>
> The image size (in bytes) is :
> 434065408 some.iso
>
> In every case :
> - 1st and 2nd run are done "the classic way"
> - 3rd run is done with an unplug/replug of the cable to test reconnection
>
> <--------  GPXE  ---------->
> Test1 : gpxe / no fix
> ======================
> 1st run : 253s / 1.64 MB/s
> 2nd run : 252s / 1.64 MB/s
> 3rd run : 260s - reconnection OK
>
> Test2 : gpxe / fix
> ===================
> 1st run : 13s / 31.84 MB/s
> 2nd run : 14s / 29.57 MB/s
> 3rd run : 18s - reconnection OK
>
> <--------  IPXE  ---------->
> Test3 : ipxe / no fix
> ======================
> 1st run : 250s / 1.66 MB/s
> 2nd run : 251s / 1.65 MB/s
> 3rd run : 257s - reconnection OK
>
> Test4 : ipxe / fix
> ===================
> 1st run : 10s / 41.40 MB/s
> 2nd run : 10s / 41.40 MB/s
> 3rd run : 17s - reconnection OK
> ####################################
>
> I am not a network driver hacker, nor a C hacker at all, so perhaps 
> the code is not at the better possible place, but you got the idea ;)
> Looking at how it is done in the linux kernel driver code, I don't 
> think that this will break other chipsets support.
>
> If you need further tests, just ask.
>
> Cheers,
>
> Yann
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
>
>
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

[Etherboot-developers] [PATCH] forcedeth driver - very bad transfer rate / missing register update

[Yann C. <yan...@fr...>]

Hi (g/i)pxe developpers,

Playing recently with a new toy with an MCP79 chipset (0x10DE, 0x0AB0) 
in it and iSCSI, I found that the transfer rate were anormaly slow 
(about 15 seconds to load about 15MB of kernel + initrd, on a Gb 
network) in the (g/i)pxe phase, transfer rate were then OK (~50MB/s) 
after the linux code has taken the control.
After having test with TFTP and HTTP tranfer, I found that the problem 
was the same, so it had to be in the forcedeth driver.

Enabling debugging mode show me that the driver didn't stop calling
forcedeth_link_status and as a consequence nv_update_linkspeed when 
polling (and each time it just found that there is no link change, so it 
was just a big waste of time).
Same problem with gpxe and ipxe.

After having a look at the linux forcedeth driver, I found that the 
(g/i)pxe forcedeth driver code was missing a NVREG_MIISTAT_LINKCHANGE 
register update, which made the poll method thinking that a link change 
as occured every time it was called.
Updating this register and testing it in forcedeth_link_status just did 
the trick !

Here are some tests that I have done :
####################################
Embedded scripts used to test perfs :
===========
#!gpxe
dhcp net0
time imgfetch http://192.168.1.10/some.iso
===========
or :
===========
#!ipxe
dhcp net0
time imgfetch http://192.168.1.10/some.iso
===========

The image size (in bytes) is :
434065408 some.iso

In every case :
- 1st and 2nd run are done "the classic way"
- 3rd run is done with an unplug/replug of the cable to test reconnection

<--------  GPXE  ---------->
Test1 : gpxe / no fix
======================
1st run : 253s / 1.64 MB/s
2nd run : 252s / 1.64 MB/s
3rd run : 260s - reconnection OK

Test2 : gpxe / fix
===================
1st run : 13s / 31.84 MB/s
2nd run : 14s / 29.57 MB/s
3rd run : 18s - reconnection OK

<--------  IPXE  ---------->
Test3 : ipxe / no fix
======================
1st run : 250s / 1.66 MB/s
2nd run : 251s / 1.65 MB/s
3rd run : 257s - reconnection OK

Test4 : ipxe / fix
===================
1st run : 10s / 41.40 MB/s
2nd run : 10s / 41.40 MB/s
3rd run : 17s - reconnection OK
####################################

I am not a network driver hacker, nor a C hacker at all, so perhaps the 
code is not at the better possible place, but you got the idea ;)
Looking at how it is done in the linux kernel driver code, I don't think 
that this will break other chipsets support.

If you need further tests, just ask.

Cheers,

Yann

[Etherboot-developers] Does gPXE support Unicode output?

[何闯 <jus...@16...>]

Dear All,


For example, How to output Chinese simplified characters ?


Regards,

[Etherboot-developers] Etherboot.org hardware issues

[Marty C. <md...@et...>]

Hello Everyone,

This is a brief message to let you know that we are working on getting 
etherboot.org and rom-o-matic.net back up as soon as possible.

Over the years we have been fortunate to have so very little downtime, 
and we have made sure that we do nightly backups so that we can recover 
from problems.  Our data and history are secure.

Thanks to those of you who have offered support to help us get things 
working again.  It means a lot to me.

We're working with the great folks at http://osuosl.org/ (who rock!) and 
who host our servers to help us migrate onto new hardware.

I'll keep you updated on how things are going.  Feel free to ask 
questions and offer ideas, and let's talk.

I remember a time before rom-o-matic.net, and before we had so many 
users and services. This downtime has reminded me how far we've come 
over the 11 years since I joined the project, and how fortunate we are 
to have each other.

Let's take this time to reflect, as we find our way forward.

With a grateful heart,

/ Marty /

Re: [Etherboot-developers] [gPXE] Patch to gPXE-1.0.1 UNDI code for Interrupt Vs Polling

[Marty C. <md...@et...>]

Cool, thanks.  We'll get this in the gPXE-1.0.2 queue.  Thanks for your 
testing and confirmation.

Regards,

/ Marty /

On 11/30/10 1:27 PM, Silver, Geoffrey wrote:
> Marty,
>
> I can confirm that the original patch is reversed.  I applied the following, and it resolves my gPXE failures for both HP G7 servers using the Emulex (ServerEngines) NICs as well as Xsigo HCAs.  Presumably this affects other polling NICs as well.
>
>
> --- gpxe.orig/src/arch/i386/drivers/net//undinet.c     2010-11-16 07:47:29.000000000 -0800
> +++ gpxe.new/src/arch/i386/drivers/net//undinet.c       2010-11-16 07:53:07.000000000 -0800
> @@ -49,6 +49,8 @@
>          int isr_processing;
>          /** Bug workarounds */
>          int hacks;
> +       /** Flag to indicate device supports IRQ or not */
> +       int irq_supported;
>   };
>
>   /**
> @@ -252,7 +254,7 @@
>
>          if ( ! undinic->isr_processing ) {
>                  /* Do nothing unless ISR has been triggered */
> -               if ( ! undinet_isr_triggered() ) {
> +               if ( undinic->irq_supported&&  ! undinet_isr_triggered() ) {
>                          /* Allow interrupt to occur */
>                          __asm__ __volatile__ ( REAL_CODE ( "sti\n\t"
>                                                             "nop\n\t"
> @@ -357,10 +359,12 @@
>          struct s_PXENV_UNDI_OPEN undi_open;
>          int rc;
>
> -       /* Hook interrupt service routine and enable interrupt */
> -       undinet_hook_isr ( undinic->irq );
> -       enable_irq ( undinic->irq );
> -       send_eoi ( undinic->irq );
> +       /* Hook interrupt service routine and enable interrupt if supported */
> +        if (undinic->irq_supported) {
> +          undinet_hook_isr ( undinic->irq );
> +          enable_irq ( undinic->irq );
> +          send_eoi ( undinic->irq );
> +        }
>
>          /* Set station address.  Required for some PXE stacks; will
>           * spuriously fail on others.  Ignore failures.  We only ever
> @@ -425,9 +429,11 @@
>          pxeparent_call ( undinet_entry, PXENV_UNDI_CLOSE,
>                           &undi_close, sizeof ( undi_close ) );
>
> -       /* Disable interrupt and unhook ISR */
> -       disable_irq ( undinic->irq );
> -       undinet_unhook_isr ( undinic->irq );
> +       /* Disable interrupt and unhook ISR if supported */
> +        if (undinic->irq_supported) {
> +          disable_irq ( undinic->irq );
> +          undinet_unhook_isr ( undinic->irq );
> +        }
>
>          DBGC ( undinic, "UNDINIC %p closed\n", undinic );
>   }
> @@ -548,6 +554,7 @@
>                  undinic->hacks |= UNDI_HACK_EB54;
>          }
>
> +        undinic->irq_supported = undi_iface.ServiceFlags&  SUPPORTED_IRQ ? 1 : 0;
>          /* Mark as link up; we don't handle link state */
>          netdev_link_up ( netdev );
>
> --
> Geoffrey Silver
> Global Infrastructure
> CITADEL
>
> -----Original Message-----
> From: gpx...@et... [mailto:gpx...@et...] On Behalf Of Marty Connor
> Sent: Saturday, November 20, 2010 2:55 PM
> To: Mur...@em...
> Cc: gp...@et...; eth...@li...
> Subject: Re: [gPXE] Patch to gPXE-1.0.1 UNDI code for Interrupt Vs Polling
>
> Hi Muralidhar,
>
> Your patch looks interesting, but I think you may have inverted the diff (new->old instead of old->new).  Can you verify this?
>
> Thanks,
>
> / Marty /
>
> On 11/18/10 3:03 PM, Mur...@em... wrote:
>> Hi,
>>
>> Problem Description: We have noticed that gPXE UNDI code is always
>> expecting interrupt(s) to be generated by the underlying NIC HW to
>> process the receive path in undinet_poll() routine. This is causing
>> problem on some of the PCI NIC controllers where though the NIC device
>> supports IRQ and able to generate interrupts,  during PXE UNDI code
>> some devices do not enable interrupts on their device and run in
>> polling mode. Those devices expect upper layer UNDI drivers to poll
>> for the receive packets instead of waiting for interrupt from the
>> device. But in undinet_poll() routine the code checks for ISR
>> triggered or not if not it just returns. [(please check "if
>> (undinet_isr_triggered)" statement ) in undinet_poll()]
>>
>> Solution Description: I have attached a patch here to take care of
>> this so that gPXE UNDI code will work on both types of devices
>> (interrupt&  polling supported devices). The patch is to check whether
>> the device supports IRQ or not in "ServiceFlags" returned by the API
>> call PXENV_UNDI_GET_IFACE_INFO in undinet_probe() routine. If the
>> underlying device supports IRQ  then enable the newly introduced flag
>> "irq_supported" in undi_nic structure. Later in  undinet_open()&
>> undinet_close() routines check this flag (irq_supported) to decide to
>> hook the interrupts or to unhook the interrupts. Also in
>> undinet_poll() routine check whether interrupt got generated or not,
>> only if the device supports interrupts otherwise get the packet from
>> underlying UNDI NIC drivers by calling PXENV_UNDI_ISR using FuncFlag
>> PXEENV_UNDI_ISR_GET_NEXT.
>>
>> I am attaching here the patch for review and acceptance.
>>
>> Muralidhar Appalla
>> Engineer Principal
>> 2560 N.First Street
>> Sanjose,CA
>> Emulex Corporation
>> (408)678-3472 (work)
>
> _______________________________________________
> gPXE mailing list
> gP...@et...
> http://etherboot.org/mailman/listinfo/gpxe
>
>
> CONFIDENTIALITY AND SECURITY NOTICE
>
> The contents of this message and any attachments may be confidential and proprietary and also may be covered by the Electronic Communications Privacy Act. This message is not intended to be used by, and should not be relied upon in any way, by any third party.  If you are not an intended recipient, please inform the sender of the transmission error and delete this message immediately without reading, disseminating, distributing or copying the contents. Citadel makes no assurances that this e-mail and any attachments are free of viruses and other harmful code.

Re: [Etherboot-developers] [gPXE] Patch to gPXE-1.0.1 UNDI code for Interrupt Vs Polling

[Marty C. <md...@et...>]

Hi Muralidhar,

Your patch looks interesting, but I think you may have inverted the diff
(new->old instead of old->new).  Can you verify this?

Thanks,

/ Marty /

On 11/18/10 3:03 PM, Mur...@em... wrote:
> Hi,
> 
> Problem Description: We have noticed that gPXE UNDI code is always
> expecting interrupt(s) to be generated by the underlying NIC HW to
> process the receive path in undinet_poll() routine. This is causing
> problem on some of the PCI NIC controllers where though the NIC
> device supports IRQ and able to generate interrupts,  during PXE UNDI
> code some devices do not enable interrupts on their device and run in
> polling mode. Those devices expect upper layer UNDI drivers to poll
> for the receive packets instead of waiting for interrupt from the
> device. But in undinet_poll() routine the code checks for ISR
> triggered or not if not it just returns. [(please check "if
> (undinet_isr_triggered)" statement ) in undinet_poll()]
> 
> Solution Description: I have attached a patch here to take care of
> this so that gPXE UNDI code will work on both types of devices
> (interrupt & polling supported devices). The patch is to check
> whether the device supports IRQ or not in "ServiceFlags" returned by
> the API call PXENV_UNDI_GET_IFACE_INFO in undinet_probe() routine. If
> the underlying device supports IRQ  then enable the newly introduced
> flag "irq_supported" in undi_nic structure. Later in  undinet_open()
> & undinet_close() routines check this flag (irq_supported) to decide
> to hook the interrupts or to unhook the interrupts. Also in
> undinet_poll() routine check whether interrupt got generated or not,
> only if the device supports interrupts otherwise get the packet from
> underlying UNDI NIC drivers by calling PXENV_UNDI_ISR using FuncFlag
> PXEENV_UNDI_ISR_GET_NEXT.
> 
> I am attaching here the patch for review and acceptance.
> 
> Muralidhar Appalla
> Engineer Principal
> 2560 N.First Street
> Sanjose,CA
> Emulex Corporation
> (408)678-3472 (work)

[Etherboot-developers] Attempting to add support for Broadcom BCM5755M (14e4:1673) ethernet adapter

[Quinn P. <qi...@gm...>]

Hi,

I am attempting to add support to gpxe the Broadcom BCM5755M (14e4:1673)
ethernet adapter.
I have confirmed that the adapter works under linux with kernel 2.6.32.
Here is some of my attempts:

I first identified the pci vendor and device id via linux's "lspci -n"
command which gave me 14e4:1673
I then added it to tg3.c file:
-------------------------
@@ -3400,6 +3402,7 @@
 PCI_ROM(0x14e4, 0x165e, "tg3-5705M_2",     "Broadcom Tigon 3 5705M_2", 0),
 PCI_ROM(0x14e4, 0x1677, "tg3-5751",        "Broadcom Tigon 3 5751", 0),
 PCI_ROM(0x14e4, 0x167a, "tg3-5754",        "Broadcom Tigon 3 5754", 0),
+PCI_ROM(0x14e4, 0x1673, "tg3-5755",        "Broadcom Tigon 3 5755", 0),
 PCI_ROM(0x14e4, 0x1693, "tg3-5787",       "Broadcom Tigon 3 5787", 0),
 PCI_ROM(0x14e4, 0x1696, "tg3-5782",        "Broadcom Tigon 3 5782", 0),
 PCI_ROM(0x14e4, 0x169a, "tg3-5786",        "Broadcom Tigon 3 5786", 0),
--------------------

This enabled gpxe to attempt to initialize the adapter instead of ignoring
it.  But it gives this error so far:

-----------------
phy probe failed, err -741097531
Problem fetching invariants of chip, aborting.
-----------------

Ok, then I though, the phy id must not match, so what about forcing it?  I
added the following to tg3.c to identify the phy id:

------------------------
@@ -2543,6 +2543,8 @@

     hw_phy_id_masked = hw_phy_id & PHY_ID_MASK;

+   printf("phy id: %X\n", hw_phy_id);
+
     if (!err && KNOWN_PHY_ID(hw_phy_id_masked)) {
         tp->phy_id = hw_phy_id;
     } else {
--------------------------

This gave me 0xbc050cc0, so I added it to tg3.h:

--------------------------
@@ -2038,6 +2038,7 @@
 #define PHY_ID_BCM5704            0x60008190
 #define PHY_ID_BCM5705            0x600081a0
 #define PHY_ID_BCM5750            0x60008180
+#define PHY_ID_BCM5755            0xbc050cc0
 #define PHY_ID_BCM5787            0xbc050ce0
 #define PHY_ID_BCM8002            0x60010140
 #define PHY_ID_BCM5751            0x00206180
--------------------------

Unfortunately, this is as far as a i got.  The error messages is still the
same.  I haven't been able to figure out what to do next.  I have tried to
enable debugging by "make DEBUG=tg3" and also enabling the serial console in

console.h but the I just get a bunch of "?" instead of proper strings on the
serial port and I did configure my terminal emulator to 9600n81.  Any clues
there?  The terminal works fine with picocom under linux with the same
serial settings.

I feel I am so close in getting this card to work because the tg3 code is
there but it just needs to identify and use the hardware.  Just so you know
I have also downloaded the latest git release, but unfortunately, there is
no support for BCM5755M yet.
I found this page
http://www.broadcom.com/support/ethernet_nic/determine_driver.php which
helped me identify the adapter as a model type NetXtreme Desktop/Mobile
adapter.  There is already support in gpxe for that type adapter such as the
BCM5751M.

Any suggestions?

Quinn