Thank you to everyone that has contacted me privately.
Last night I installed Windows 7 32-bits and WISP on a virtual machine and to my surprise, the problem I have been having persisted. After a lot of hair pulling (not much left anyway) and investigation, I found that the culprit was neither Windows nor WISP. It was the serial to TCP bridge HW VSP software. If the NVT option of HW VSP is enabled, it inserts some control data in the data stream when it finds some pattern on the input data stream. In the case of a dir fill, it was introducing three 0xFF bytes right in middle of the KISS frame. This was being sent over AX.25 to Falconsat-3 and was the cause of the "NO -5" error.
I've tested requesting a dir fill during the last pass here and Falconsat-3 replied with a nice "OK PY2SDR"! Now let's grab some headers and try to upload a small file.
73, Edson PY2SDR
On Thu, Oct 19, 2017 at 4:26 PM, Edson W. R. Pereira ewpereira@gmail.com wrote:
Has anyone successfully requested directory fill from Falconsat-3 using Windows 64-bits? It seems that WISP sends a corrupt request to the satellite on Windows 64-bits. I have tried running WISP on two different machines. Both with Windows 64-bits -- one running Windows 7 64-bits and the other running Windows 10 64-bits. On both, every time MSPE requests a directory fill, I get a "NO -5 PY2SDR" response from the satellite. Roland PY4ZBZ tried on his 32-bits Windows 10 system and the satellite replies with a OK.
Comparing the directory fill request packet sent to the satellite by my station and Roland's, it seems that, on my station, WISP is corrupting the directory hole pair data and also introducing one more byte to the request.
This is PY4ZBZ (good) request:
10 F4 00 42 8F E5 59 FF FF FF 7F 0D 0A
This is PY2SDR (bad) request:
10 F4 00 BF 12 E0 59 FF FF FF FF FF FF 7F
73, Edson PY2SDR