1. Prerequisites

This project supposes you have a working AX25 configuration on your linux system. Since this is about APRS, I suppose you have at least one ax25 interface running on the local APRS frequency.

More to find on the ldsped V1.00 page.

2. Aprsd

Aprsd is not needed for ldsped. But if you are using aprsd, beware !

There is an aprsd bug : look on the ldsped V1.00 page

Please, please check if your aprsd needs to be patched.

3. Frames, frames, frames

The communication between agwpe and the application uses a TCP connection. The application sends what the agwpe author calls' a frame' to the packet engine, and the engine answers with one or more frames. More to find on the ldsped V1.00 page.
Version 1.0x functions well if you use only unconnected AX25 connections.

NS7C is using Outpost, and wanted to use ldsped, but its seems Outpost is using frames which are not supported by ldsped.
So I did set up a test environment and started to code the missing frame-support.

3.1 X and x frame

The test setup permits me to log the outpost TCP traffic. So a complete outpost session can be monitored. The first unsupported frame outpost uses is the X frame (to register a call) and the counterpart x (to unregister the call).

Agwpe docs say it is permitted to register as many calls as one wants to. I use an array of 50 elements. That should do. Calls are registered for a TCP connection, see also C frame.

IMPORTANT !

For the moment, however, no incomming connections have been implemented. Registering a call does not (yet) open a listening AX25 socket. Outgoing connections (terminal programs, outpost, ...) do function well !

3.2 C frame

Then there is the difficult part : the C frame. This frame asks to initiate an AX25 connection.

First I have to construct the address, not easy but browsing some other code did the trick. Next, making the connection isn't hard, the linux kernel will take care of that.
The difficult part is finding a way to connect without blocking. First connection attempts would block ldsped completely while connecting, and did not release when connecting failed.

It took me some time, but eventually after many hours I succeded. As I mentioned before, I'm not a system-programmer and I better should buy some good book about interfacing with kernel functions. Internet did help a bit, but not without a lot of searching. Not every answer lies there waiting for you ...

To make it more easy to test the connecting/disconnecting, I made a windows application to send individual frames to agwpe or ldsped and to see the answers they send.

Agwpe will time out a connection after 15 seconds. My test setup was not always quick to connect (the TNC's aren't tuned, I wanted to spend not to much time there since I already spent quite some time setting up the linux system and all the interfacing) so for ldsped I added another 5 seconds.
One radio amateur user, however, did rather extensive tests and found it better to let linux go all the way. So I changed the connection-timeout system. ldsped now asks the kernel to connect and monitors the connection attempt to know when the OS gives up. More kernel interfacing had to be done to accompish this (I had to monitor the /proc filesystem to know what was going on).

3.3 d frame

The companion of the C frame is the d frame : to disconnect. When disconnecting, agwpe sends a disconnect status frame. When there is no connection, and the application sends a d frame, agwpe also sends a similar status frame, so I also implemented one.

3.4 D frame

Once connected, data is exchanged via the D frame. This was not that difficult, as with the TCP connections : just read and write to the right socket.

3.5 v frame

The v frame is like the C frame, but permits to add VIA stations to the connection setup. I tried to implement this the way the linux axcall program does. But axcall allocates memory that will be released exiting the program. I cannot do this, since I'm writing a daemon and I hve to neatly release the memory. After suffering from a memory leak, I finally got there.

3.6 Y frame

The Y frame gives the outstanding frames for a connection. I did not found a good way to check this, but thanks to a sugestion from NS7C, I'm using the outstanding bytes (not acknowledged) as found in /proc/net/ax25. After some substracting and dividing, ldsped generates a fairly good answering frame.

3.7 H frame

The basics of the H frame can be read in item 4.6 on the V1.00 page.
This moment there are 0..20 heard stations sent, depending on what is available in the mheard datafile.
The agwpe specifications say I always have to send 20 frames response frames :

Upon a single ‘H’ frame sent by the application AGWPE would produce 20 sucessive ‘H’ frames, one for each station heard. If on a given port more than 20 stations were heard only the 20 most recently heard would be sent, if less than 20 stations were heard AGWPE would send as many “empty” ‘H’ frames as required to make the total number sent as 20.

But some test with AGWPE and agwmontcp shows this program is not entirely following the specs itsself (empty H-frames seem to contain pieces of garbage).

So I decided to leave it as is, until someone uses a program needing the 20 frames answer (if you do, please contact me).

4. Conclusion / supported programs

The ldsped 1.10 beta versions have been tested by different people, but the most stress on it is placed by NS7C.
Thanks to NS7C for all the good work !

On top of the programs mentioned in the first page, here is a list of programs which use connected oriented AX25 connections that now work with the new ldsped version.

Outpost seems to work, as does Paclink.

You might also check the blog of KM5VY, who is putting AX25 in a SheevaPlug plug computer. He has ldsped running on this device.
Paclink, however, was a difficult one. It uses frames that where not yet implemented. And with my current tranceiver/antenna setup, I'm not able to connect to a winlink server myself to check what is going on during the connections - so again I thank NS7C who does all the testing.

VE1FIS is putting ldsped inside a WiFi router with OpenWRT. You can check his site on how to do this or contact him to get a router compatible binary.

You are welcome, to use/experiment with the existing version.
If you have some more questions/remarks/corrections/ ... , please tell me about it.