Unable to Transfer Files With Autobin or YAPP
Amateur Radio AX.25 chat and PBBS program using Linux's AX.25 stack
Brought to you by:
dranch
Menu
▾
▴
#31 Unable to Transfer Files With Autobin or YAPP
Issue description:
After making a connection between two 1200baud linpac instances I am unable to complete a file transfer with YAPP or Autobin. Initiating an Autobin transfer results in a few bytes of progress being made before the other station sends "#OK#" despite the transfer being incomplete. The transfer will never complete and nothing else happens, typically I can continue using normal functions, but no file. The transmitter will count up bytes at high speed despite not actually transmitting and the receiver will be stuck at near 0 progress.
YAPP will also initiate, not transfer a single byte. Sending station will send the header, RX station will accept the header and display a file name, then the TX station again rapidly counts up bytes and says "transfer finished" while the RX stays at 0 out of 10267. Eventually "Transfer aborted by peer: Timeout" appears in the console (usually take 1-2 minutes to happen). However, despite this, the sending station will continue sending a packet every few seconds and terminal will not display any text sent by the receiving station until linpac is closed, re-opened and re-connected. Basically initiating a YAPP transfer bricks the sending terminal, and no file is transferred.
Setup:
I have confirmed this issue using on two separate machines (Raspberry Pi 4 B 4GB and Ubuntu 20.04 x86 laptop) with two radios (Kenwood TM-D700 with built-in TNC/KISS and Icom IC-7100 with Direwolf TNC). As far as I can tell, this issue also persists across versions 0.24 (apt), 0.24 (patched source), 0.25, 0.28, and the current develop branch (0.28/0.29). I have tried all these versions on both machines and was never able to complete a file transfer. I was using a 10kB JPG as the payload. All other traffic functions normally. TCP/IP works, text in Linpac works, axcall shells work. Only file transfers through Linpac fail.
Steps to recreate:
1. Open LinPac on two machines
2. Connect both sessions using ":C CALLSIGN"
3. Initiate file transfer with ":rprg FILE", "//rprg FILE", "//YPUT FILE", or ":YPUT FILE"
4. transfers will not ever complete
Help would be appreciated, let me know what else I can provide.
I will try to reproduce your issue this weekend and report back what I find.
Any luck or findings? I appreciate your time on this. I imagine I could be doing something wrong, but I'm not sure what.
I had to work (day job) over the weekend but I did make some progress here. I hope to troubleshoot this during the week.
I've done some testing and while things work (with issues), I'm seeing some strange behaviors:
Plain text transfer: If I issue the command:
//read services-1k.txt-test4
I am only getting the last 2.5 lines from the end of the source file. I've seen something similar to this when issuing the //mheard command to the remote Linpac station. There seems to be some sort of a buffering issue but it's rather rare and I think it might be due to larger amounts of data coming in at a fast rate. This needs more investigation.
YAPP: Seeing an intermittent issue where the first file request using say:
//YPUT services-1k.txt-test3
will work but if I request the file again, it doesn't do anything. If I try yet again, it works! I'm not quite sure why it's behaving like this. I'm curious if you see this behavior if you try multiple times.
Autobin: If I initiate a remote file transfer like:
//RPRG services-1k.txt-test3
I will receive the follow text text on the receiver side:
but nothing happens after that. I see on the Linpac transmitter side, it shows
Autobin TX: request sent
in the Linpac status bar but nothing happens. I believe that the receiver side is actually supposed to ACK the reception request or something like that. If I requested the file AGAIN, it actually started the transfer, showed a status of the bytes in transfer, and completed with an #OK# but the resulting file is 0 bytes on the receiver. On the transmitting Linpac station, I actually see multple "Autobin TX: request text" lines which shouldn't happen. After that, it seems the receiving Linpac station is no longer receiving data (won't display any chat strings from the remote station, won't receive files, etc.) like you stated. The Linpac program needs to be restarted to resume any real function and this is reproducible.
I need to research these a bit more to understand how these two protocols are supposed to function.
As to some of your seen issues on your Linpac receiver, are you sure the username that is running Linpac has write permissions into the LinPac/user directory?
David,
Very interesting findings, thanks for doing this.
It's interesting to me that you seem to have been able to transfer a file
at all with YAPP. I have never been able to get it to transfer a file no
matter how many times I requested or tried to send it.
Your Auto in results however, exactly mirror mine.
In any case, as before, I've never been able to transfer a file with
linpac. Save for text maybe.
As for the user permission issue, it could be a problem. I've given up
running linpac as a regular user and actually tend to run it with sudo,
because despite the Linpac dir being created in my user directory I usually
end up with some kind of error from the AXport or file system. In any case,
running with sudo should allow Linpac to do whatever it likes, and that's
how I've been typically using it.
I've actually tried looking into the YAPP and Auto in protocols myself, and
have found shockingly little information. Maybe I'm just looking in the
wrong places?
Anyway, keep me posted on this and let me know how I can help.
Best,
Vlad F.
KX4TH
On Fri, Jul 16, 2021, 7:30 PM David Ranch dranch@users.sourceforge.net
wrote:
Related
Bugs: #31
The autobin protocol seems to have some deeper issues with the client and also the server is doing some form of file truncation that also needs investigation.
YAPP transfers seem to work 100% but in an "alternating" way. Please try again on your setup as it should work:
YAPP protocol
1. The requesting client will request a file using the command: //yput services-1k.txt-test4
The server will respond with what seems a binary string that's displayed on the client as the string "EA" in inverted colored text. This "EA" response seems to work for first request but trying the transfer a second time is seemingly ignored by the remote server as there isn't an "EA" response but trying a third time works. This alternating works / doesnt-work behavior seems to be reproducible
the server UI will change the status line to two lines thick and show "YAPP: starting transfer"
the requesting client will update the status line with "YAPP: waiting for file header"
the server update it's status line with "YAPP: header sent" and then will send a payload like:
--
.$services-1k.txt-test4
1081
52F0912F
and then sends the COMPLETE file. There isn't any server side buffering / file truncation issue being seen here!
The client updates it's status line with "YAPP: RX services-1k.txt-test4 : 1081 of 1081" and spawns an external process:
--
ps aux | grep yapp
root 5981 0.0 0.0 1940 404 pts/4 S+ 11:12 0:00 /bin/sh -c ./bin/yapp
root 5982 0.6 0.2 9144 2588 pts/4 S+ 11:12 0:00 ./bin/yapp
The client updates it's status line with "YAPP: waiting for next file header"
The server updates the status line with "YAPP: transfer finished" and then status line goes to one line thick
The client goes back to a one line thick status line and both the client and server Linpacs return to working as expected
For your Transfer "aborted by peer" error, are you seeing any interesting errors in the LinPac/error.log file on the client or server? Can you confirm the "yapp" process is running on your client when the transfer is supposedly going? Does the yapp program have the right permissions and binary details? Here is an example running on a Raspberry Pi system:
ls -la /usr/libexec/linpac/yapp
-rwxr-xr-x 1 root root 13976 Jul 7 14:59 /usr/libexec/linpac/yapp
file /usr/libexec/linpac/yapp
/usr/libexec/linpac/yapp: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=fc81cba62ce8be3d20b4e0ac47b647425f860a1a, stripped