Syslinux - Aug 2015 - A few questions for the braintrust

I have a few questions to throw out to the collective braintrust.

1. in core/fs/pxe/tftp.c, when communicating using udp, in connecting, 
transmitting and receiving functions, errors are not communicated to the 
user. In fact the comment after transmit specifies "/* If the WRITE call 
fails, we let the timeout take care of it... */"

The question is: Should we notify the user that there has been a problem? 
In our scenario, there was just a very long pause (all of the retries) and 
nothing hitting the wire. Since we have a watchdog in our system, it 
reboots prior to completing all of the timeouts due to prolonged 
inactivity. Is there a better, timelier or more user friendly way to 
handle the errors? 

2. Just curious as to why the decision was made to create new udp 
connection instead of using the existing pxebc? udp is already set up and 
configured. The reason I ask is we were having problems in our customer 
environment with the routetable. We modified the code to use pxebc 
protocol and it works perfectly. This environment consists of three 
separate subnets, client on one, dhcp server on a second and proxy and 
tftp servers on the third. This scenario was causing problems with routing 
so the udp connection failed and the transmit never hit the wire. Of 
course, the receive also failed.

If anyone would like to see the changes we made to use pxebc, I would be 
happy to post but thought there is probably a very good reason in other 
environments to recreate the udp connections and didn't want to muddy the 
waters. I also think it may not be a complete solution.

Gene, I just pulled down the latest commit and will try it in both my 
standalone environment (subnet 1 dhcp server, subnet 2 client, proxy and 
tftp server) as well as my customer's environment, mentioned above. I'll
post the results.


Jeff Sloan
jeff_sloan at selinc.com

On 08/18/2015 01:13 PM, Jeff via Syslinux wrote:
> I have a few questions to throw out to the collective braintrust.
> 
> 1. in core/fs/pxe/tftp.c, when communicating using udp, in connecting, 
> transmitting and receiving functions, errors are not communicated to the 
> user. In fact the comment after transmit specifies "/* If the WRITE
call
> fails, we let the timeout take care of it... */"
> 
> The question is: Should we notify the user that there has been a problem? 
> In our scenario, there was just a very long pause (all of the retries) and 
> nothing hitting the wire. Since we have a watchdog in our system, it 
> reboots prior to completing all of the timeouts due to prolonged 
> inactivity. Is there a better, timelier or more user friendly way to 
> handle the errors? 
> 
> 2. Just curious as to why the decision was made to create new udp 
> connection instead of using the existing pxebc? udp is already set up and 
> configured. The reason I ask is we were having problems in our customer 
> environment with the routetable. We modified the code to use pxebc 
> protocol and it works perfectly. This environment consists of three 
> separate subnets, client on one, dhcp server on a second and proxy and 
> tftp servers on the third. This scenario was causing problems with routing 
> so the udp connection failed and the transmit never hit the wire. Of 
> course, the receive also failed.
> 
> If anyone would like to see the changes we made to use pxebc, I would be 
> happy to post but thought there is probably a very good reason in other 
> environments to recreate the udp connections and didn't want to muddy
the
> waters. I also think it may not be a complete solution.
> 
The problem with the pxebc is that it only supports one concurrent TFTP
connection, and Syslinux expects to be able to keep multiple files open
at the same time.

	-hpa