Hamish Moffatt wrote:
On Sat, Aug 25, 2001 at 08:52:27PM -0400, Bruno Quesnel wrote:
>     tncport device_file device_speed config_file
>     The first parameter is the same from the original config file, then
> the device file to open (not changed) then the speed associated to the
> device and the config file associated to the TNC or device on the serial
> port.

I don't really understand. What is the file config_file? Why can't
the device_speed be specified in the config_file? Or is config_file
just INIT.TNC ?

The speed IS specified in the config file.  Just on the same line that the device file is specified but appended to the end.

For the config file, it might be useful to specify a different config file per serial port.  The point of doing so is having different TNC type connected to each serial port.  If they are all the same perfect, otherwise, you have the possibility to react to different type of device.

How do you intend for the RF-port program to be started? Will aprsd
spawn it, or will the end user start it themselves after starting
aprsd? I like the possibility of starting it manually, because that
allows it to be run on a separate computer.
My plan was to do two different programs, seperate entities from each other.  A manual startup on the user part or part of a startup script that would be intelligent enough to start which ever that is required (even for both or just one of each)

This way, one or many module could be develop to support different type of interface, i.e. soud card or for the ax25 support.   You then isolate the interface from the main program (aprsd).  This could be easier to maintain.  Issue a release for the interface and not for the whole thing.

The limits of which program does what would need to be determined at a later time.  But the idea is there.

How does aprsd communicate with the port program? Is it by AF_INET
socket? If aprsd is spawning the port program directly, they can
communicate using pipes or stdin/stdout which may be simpler. But
as I said above, I don't think that is the best way to do it.
Using sockets to communicate.  I've included a configuration directive to lookup a host name to connect to (for the serial module).  Then the aprsd program would need an extra port definition to consider any traffic to be "local".  Then the 2rf traffic would then be handled by aprsd using the proper socket number that the station came from.  So a lookup in the history would tell if a station was heard "local" and direct to the proper TCP/IP port.

    Then the serial module would need to transmit the packet to the serial port (or any other typeof device to send to RF).

I removed aprsd-users from the To: list since it is not relevant there.

Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Aprsd-devel mailing list

Bruno Quesnel                         va2bmg@videotron.ca
Genie Electrique                      quesnelb@ve2.ele.etsmtl.ca
Electrical Engineering                VA2BMG
Ecole de Technologies Superieure      http://www.findu.com/cgi-bin/find.cgi?va2bmg