[ipxe-devel] iPXE tftp multicast help requested (connection timeouts)

[andydesheffield]

Erik Jacobson <erikj at ...> writes:

> 
> Some updates in case this inspires anybody's memory...
> 
> I have enabled syslog and have enabled extensive debugging in tftp and
> ipv4. I added some additional debug statements of my own as well. I'm 
using
> syslog because I've noticed wrapping / truncating of messages in my
> serial-over-lan connection to iPXE.
> 
> Observations:
>  - The first 'Sending ACK for block 0' is from tftp_rx_oack()
>  - The other 'Sending ACK for block 0' are sent from 
tftp_timer_expired()
>  - When enabling ipv4 debugging, I'm observing that the multicast 
packets
>    seem to be rejected even though they are relevant for the transfer. 
I
>    know rejecting of irrelevant broadcast/multicast packets is normal 
but
>    I think the good ones are being rejected as well for some reason.
> 
> Here are some lines from iPXE captured by the syslog server. It seems 
to
> show us sending the ACKs for block 0, getting multicast packets from 
the
> atftpd server (239.255.0.0 is the IP used by atftpd, confirmed in 
atfpd
> messages), and iPXE rejecting those. So I'll keep digging further.
> 
> If I had more experience with the network stack I suppose this would 
be
> much easier. I'm sort of learning as I go here :)
> 
> Suggestions welcome.
> 
> Dec 10 09:02:34 service0 service0.head.ice.americas.sgi.com ipxe: TFTP 
0xd11d4 multicast port 1758
> Dec 10 09:02:34 service0 service0.head.ice.americas.sgi.com ipxe: 
erikj in tftp_rx_oack, about to tftp_send_packet
> Dec 10 09:02:34 service0 service0.head.ice.americas.sgi.com ipxe: TFTP 
0xd11d4 sending ACK for block 0
> Dec 10 09:02:34 service0 service0.head.ice.americas.sgi.com ipxe: IPv4 
TX 172.23.0.9->172.23.0.1
> len 32 proto 17 id d0af csum 51e5
> Dec 10 09:02:34 service0 service0.head.ice.americas.sgi.com ipxe: 
erikj in tftp_rx_oack, done with tftp_send_packet
> Dec 10 09:02:34 service0 service0.head.ice.americas.sgi.com ipxe: IPv4 
RX 239.255.0.0<-172.23.0.1
> len 38 proto 17 id 0000 csum ddaf
> Dec 10 09:02:34 service0 service0.head.ice.americas.sgi.com ipxe: IPv4 
received packet rejected by
> stack: The socket is not connected (http://ipxe.org/380f6001)
> Dec 10 09:02:34 service0 service0.head.ice.americas.sgi.com ipxe: 
erikj in tftp_timer_expired,
> about to tftp_send_packet
> Dec 10 09:02:34 service0 service0.head.ice.americas.sgi.com ipxe: TFTP 
0xd11d4 sending ACK for block 0
> Dec 10 09:02:34 service0 service0.head.ice.americas.sgi.com ipxe: IPv4 
TX 172.23.0.9->172.23.0.1
> len 32 proto 17 id d7b0 csum 4ae4
> Dec 10 09:02:34 service0 service0.head.ice.americas.sgi.com ipxe: 
erikj in tftp_timer_expired, done
> with tftp_send_packet
> Dec 10 09:02:34 service0 service0.head.ice.americas.sgi.com ipxe: IPv4 
RX 239.255.0.0<-172.23.0.1
> len 38 proto 17 id 0000 csum ddaf
> Dec 10 09:02:34 service0 service0.head.ice.americas.sgi.com ipxe: IPv4 
received packet rejected by
> stack: The socket is not connected (http://ipxe.org/380f6001)
> 
> 

I know this is an old post but just in case somebody other than me still 
needs this

The problem seems to be that the socket structure declared in 
tftp_process_multicast (tftp.c) is not zeroed out before it is used. As 
such it fails to be found in udp_demux (udp.c) as the memcmp test 
condition fails due to spurious data in local->pad

To make tftm work add in the following line to tftp_process_multicast(

static int tftp_process_multicast ( struct tftp_request *tftp,
				    const char *value ) {
	union {
		struct sockaddr sa;
		struct sockaddr_in sin;
	} socket;
	char buf[ strlen ( value ) + 1 ];
	char *addr;
	char *port;
	char *port_end;
	char *mc;
	char *mc_end;
	int rc;
	//add this line to zero socket structure
	memset(&socket,0,sizeof(socket));
	/* Split value into "addr,port,mc" fields */