Issue Details (XML | Word | Printable)

Key: NET-161
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Peter Schmid
Votes: 1
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Commons Net

TFTP TFTPClient.sendFile() just doesen't work

Created: 24/May/07 08:26 AM   Updated: 19/Feb/08 10:41 PM
Component/s: None
Affects Version/s: 1.4
Fix Version/s: 2.0, 1.5

Time Tracking:
Not Specified

File Attachments:
  Size
File Licensed for inclusion in ASF works TFTPClient-1.4.1-fix.diff 2008-01-17 05:27 PM Dan Armbrust 4 kB
Environment: Win xp, all java versions tested.
Issue Links:
Blocker
 

Resolution Date: 19/Feb/08 10:41 PM


 Description  « Hide
sendFile() in TFTP sendFile() method does not work. It does not causes an error.
Looks like there is a bug in the communication.
I testet it with a sniffer.
1. write request looks ok
2. aknowlege from server
3. aknowlege from server
4. aknowlege from server
and so on.
I replaced the lib with version 1.1 and it works now.

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dan Armbrust added a comment - 17/Jan/08 12:35 AM
This is because issue NET-68 STILL has not been fixed. Someone provided a working patch in that bug report, but it was never applied to the 1.4 trunk. The TFTP sendFile method remains useless in the current released version.

Dan Armbrust added a comment - 17/Jan/08 12:36 AM
This fix needs to be applied!

Dan Armbrust added a comment - 17/Jan/08 05:25 PM
I think that there is some confusion as to which patch needs to be applied. The TFTPClient send file method had numerous errors in the implementation, I doubt that it has ever worked right. NET-68 contains a patch, which has already been applied - but does not fix all of the problems.

NET-68 contains a zip (TFTPStuff.zip) file, which does fix the problem, and makes the method work properly.
I have created a diff of the new TFTPClient that Jennifer Hodgdon wrote in her attached TFTPStuff.zip - diffed against 1.4.1.

Would someone please apply this patch, and perhaps we can get a 1.4.2 build? This is a serious lack of functionality.
This is the patch that needs to be applied to 1.4.1:

— TFTPClient.java.orig 2005-12-03 10:05:48.000000000 -0600
+++ TFTPClient.java 2008-01-17 10:55:07.000000000 -0600
@@ -360,7 +360,7 @@
public void sendFile(String filename, int mode, InputStream input,
InetAddress host, int port) throws IOException
{

  • int bytesRead, timeouts, lastBlock, block, hostPort, dataLength, offset;
    + int bytesRead, timeouts, lastBlock, block, hostPort, dataLength, offset, totalThisPacket;
    TFTPPacket sent, received = null;
    TFTPErrorPacket error;
    TFTPDataPacket data =
    @@ -368,9 +368,11 @@
    ;
    TFTPAckPacket ack;

+ boolean justStarted = true;
+
beginBufferedOps();

  • dataLength = lastBlock = hostPort = bytesRead = 0;
    + dataLength = lastBlock = hostPort = bytesRead = totalThisPacket = 0;
    block = 0;
    boolean lastAckWait = false;

@@ -383,11 +385,16 @@
_sendPacket:
do
{
+ // first time: block is 0, lastBlock is 0, send a request packet.
+ // subsequent: block is integer starting at 1, send data packet.
bufferedSend(sent);
-
+
+ // this is trying to receive an ACK
_receivePacket:
while (true)
{
+
+
timeouts = 0;
while (timeouts < __maxTimeouts)

{ @@ -419,12 +426,13 @@ endBufferedOps(); throw new IOException("Bad packet: " + e.getMessage()); }
  • }
    + } // end of while loop over tries to receive

// The first time we receive we get the port number and
// answering host address (for hosts with multiple IPs)

  • if (lastBlock == 0)
    + if (justStarted)
    {
    + justStarted = false;
    hostPort = received.getPort();
    data.setPort(hostPort);
    if(!host.equals(received.getAddress()))
    @@ -456,10 +464,13 @@
    if (lastBlock == block)
    {
    ++block;
  • if (lastAckWait)
    + if (lastAckWait) { + break _sendPacket; - else + }
    + else { break _receivePacket; + }
    }
    else { @@ -492,21 +503,33 @@ //break; }

+ // OK, we have just gotten ACK about the last data we sent. Make another
+ // and send it
+
dataLength = TFTPPacket.SEGMENT_SIZE;
offset = 4;
+ totalThisPacket = 0;
while (dataLength > 0 &&
(bytesRead = input.read(_sendBuffer, offset, dataLength)) > 0)

{ offset += bytesRead; dataLength -= bytesRead; + totalThisPacket += bytesRead; }

+ if( totalThisPacket < TFTPPacket.SEGMENT_SIZE ) { + /* this will be our last packet -- send, wait for ack, stop */ + lastAckWait = true; + }
data.setBlockNumber(block);

  • data.setData(_sendBuffer, 4, offset - 4);
    + data.setData(_sendBuffer, 4, totalThisPacket);
    sent = data;
    }
  • while (dataLength == 0 || lastAckWait);
    -
    + while ( totalThisPacket > 0 || lastAckWait );
    + // Note: this was looping while dataLength == 0 || lastAckWait,
    + // which was discarding the last packet if it was not full size
    + // Should send the packet.
    +
    endBufferedOps();
    }

Dan Armbrust added a comment - 17/Jan/08 05:27 PM
Looks like Jira doesn't like inline patches - so I've attached the patch that I pasted into the previous comment.