nblists@anastigmatix.net said:
> h > s: tftp rrq pxeboot_ia32.bin octet blksize 1456
> s > h: tftp oack blksize 1456
> (timeout) 

1456 might be too big to be transferred.
I didn't check, but RFC2348 mentions that ethernet MTU
minus headers allows for 1428.

So what might happen is that the stupid client requests
for that large blocksize, the stupid server acknowledges
it blindly and the client perhaps tries to allocate a
buffer and fails.

The NetBSD tftpd seems to lack an option to clip the
blocksize, just to test I'd try a patch like:
diff -u -p -r1.30 tftpd.c
--- tftpd.c     9 May 2006 20:18:07 -0000       1.30
+++ tftpd.c     27 May 2006 13:25:16 -0000
@@ -437,7 +437,7 @@ blk_handler(struct tftphdr *tp, char *op
                return 0;
        }

-       tftp_blksize = bsize;
+       tftp_blksize = (bsize < 1428 ? bsize : 1428);
        strcpy(ack + *ackl, "blksize");
        *ackl += 8;
        l = sprintf(ack + *ackl, "%lu", bsize);


best regards
Matthias