TFTP Write Request (WRQ) failure, Client sends ACK 0xFFFF instead of DATA

[DiTBho]

hi
I am developing a custom TFTP server to support an old NCD NC900 X-Terminal (from 2003).
While Read Requests (RRQ) work perfectly, I am having issues with Write Requests (WRQ) specifically triggered by Netscape (used for saving preferences and cache).

The Setup:

• Server: Custom C implementation (running on gnu/Linux).
• Client: Netscape running on NCD NC900 X-Terminal.

Behavior with other clients: Standard gnu/Linux tftp client works fine (put command succeeds).

The Issue:
When the NCD terminal sends a WRQ, my server follows the standard TFTP flow:

• Receives WRQ on port 69.
• Creates a new socket and calls connect() to the client's TID.
• Sends the initial ACK for Block 0.
• Waits for DATA Block 1.

However, instead of receiving DATA Block 1, the NCD terminal immediately responds with a packet that looks like an ACK with Block 0xFFFF { 00 04 ff ff }.
After this, the client stops responding or sends a timeout error.

Debug Info:
There are no TFTP options (RFC 2347) in the WRQ header; it's a standard "filename/octet" request.
The connect() call is performed before sending the first ACK to ensure the TID is correctly bound.

I've verified the struct alignment and endianness (as RRQ works fine).

The server seems to be "too slow" or there is a specific timing/protocol expectation from the NCD stack that I'm missing.

but dunno 

Has anyone encountered this ACK 0xFFFF behavior with old X-Terminals?
Is it a known way for the NCD/Tektronix stack to signal a TID error or a protocol violation during a WRQ handshake?

[DiTBho]

The client (NCD NC900) sends an ACK (Opcode 4) with Block Number 0xFFFF.
This happens exactly after my server sends the ACK 0 in response to a WRQ.
It's not a standard TFTP Error (Opcode 5), but seems to be a 'Session Reset' or 'Abort' signal specific to this terminal's stack...

[DiTBho]

NetScape sends a RDRQ to check if its home folder exists.

The problem is: how to reply to confirm? It's a folder!