[ipxe-devel] multicast tftp working after scary hack made to udp_demux()

[Erik Jacobson]

This patch is not a request for submission. It just shows how I reworked
udp_demux() to enable debugging for this problem and where I put the work
around. Basically, even if both pad checks fail, I return udp anyway.
The original code would have returned NULL meaning a matching udp connection
was not found.

So this gets me going with unknown-to-me side effects.


diff --git a/ipxe-sgi/ipxe-201412080954/src/net/udp.c b/ipxe-sgi/ipxe-201412080954/src/net/udp.c
index 76da67e..e84ed46 100644
--- a/ipxe-sgi/ipxe-201412080954/src/net/udp.c
+++ b/ipxe-sgi/ipxe-201412080954/src/net/udp.c
@@ -228,18 +228,37 @@ static struct udp_connection * udp_demux ( struct sockaddr_tcpip *local ) {
 	static const struct sockaddr_tcpip empty_sockaddr = { .pad = { 0, } };
 	struct udp_connection *udp;
 
+	DBG2 ("udp_demux, trying to find a match for: local st_family: %d, local st_port: %d\n", local->st_family, local->st_port);
 	list_for_each_entry ( udp, &udp_conns, list ) {
-		if ( ( ( udp->local.st_family == local->st_family ) ||
-		       ( udp->local.st_family == 0 ) ) &&
-		     ( ( udp->local.st_port == local->st_port ) ||
-		       ( udp->local.st_port == 0 ) ) &&
-		     ( ( memcmp ( udp->local.pad, local->pad,
-				  sizeof ( udp->local.pad ) ) == 0 ) ||
-		       ( memcmp ( udp->local.pad, empty_sockaddr.pad,
-				  sizeof ( udp->local.pad ) ) == 0 ) ) ) {
+		DBG2 ("udp_demux looking through udp connections, considering: st_family: %d, st_port: %d\n", udp->local.st_family, udp->local.st_port);
+		if (!( ( udp->local.st_family == local->st_family ) ||
+		       ( udp->local.st_family == 0 ) )) {
+			DBG2 ("no match due to st_family checks. continue\n");
+			continue;
+		}
+
+		if (!( ( udp->local.st_port == local->st_port ) ||
+		       ( udp->local.st_port == 0 ) )) {
+			DBG2 ("no match due to st_port checks. Continue\n");
+			continue;
+		}
+		if( memcmp ( udp->local.pad, local->pad,
+                                  sizeof ( udp->local.pad ) ) == 0 ) {
+			DBG2 ("success: local.pad check #1 good, return udp pointer.\n");
 			return udp;
+		} else {
+			DBG2 ("local.pad check #1 failed, trying the 2nd check\n");
+			if ( memcmp ( udp->local.pad, empty_sockaddr.pad,
+				  sizeof ( udp->local.pad ) ) == 0 ) {
+				DBG2 ("success: .pad check #2 good (empty_sockaddr). return udp\n");
+				return udp;
+			} else {
+				DBG2 ("HACK! failed both pad checks. Returning udp anwyay to work around multicast tftp problem!!\n");
+				return udp;
+			}
 		}
 	}
+	DBG2 ("fail: udp_demux returning NULL, no matching connection found\n");
 	return NULL;
 }
 


On Wed, Dec 10, 2014 at 03:43:23PM -0600, Erik Jacobson wrote:
> 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.
> 
> For now, I'll run locally with my evil hack so I can continue experimenting
> with the iPXE multicast tftp-based solution I'm working on.
> 
> Thank you for any help you can provide me.
> 
> Erik