Folks, In https://issues.apache.org/jira/browse/NET-414 we introduced a check that the source port of a TFTP reply is not identical to the control port.
Which by itself is not a bad idea. As it allows a server to handle multiple, parallel connections. It uses the port number as a session identifier (see * excerp below from Stevens, TCP/IP Illustrated, Vol1, p212). Unfortunately - this seems to break quite a few IoT implementations that bare based on LWIP, Arduino and MBed examples that do not actually pick a new/random source port. But re-use the control port (as they are only capable of one connection at the time). As they lack the memory to keep multiple bound sockets open. One example I am currently struggling with are Grbl, Saur and LAOS based laser-cutters. Now closely reading the RFC - it seems to lack the usual SHOULD or MUST (as per rfc 2119 parlance) statements around having to pick a unique/new source port that is not identical to the control port. So it seems we're a bit more strict that we should. So I am wondering if this change should be reverted; or, at the very least, be subject to a property value the end user can set system wide to `disable'. With kind regards, Dw. *: ... TFTP, the protocol is different since there is a longer term relationship between the client and server (which we said could be seconds or minutes). If one server process used the well-known port for the duration of the file transfer, it would either have to refuse any further requests that arrived from other clients, or that one server process would have to multiplex file transfers with multiple clients at the same time, on the same port (69). The simplest solution is to have the server obtain a new port after it receives the RRQ or WRQ. Naturally the client must detect this new port when it receives the first data packet and then send all further acknowledgments to that new port. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
