Packet Radio with Linux?
 

G'day,

a few years ago I used to run my Baycom PR modem with DOS which was
pretty easy, all I needed was tfpcr and GraphicPacket.

Now that I am a Linux convert I thought it should be nearly equally easy
to get on the air, considering AX.25 is already included in the kernel.
So what do I need? Not really being proficient with the technical
details, I figured all I need is to compile the ax25 and baycom modules,
and install a (console) terminal on my system.
The box is an old but trusty 386/25, 16MB RAM with RedHat 6.2 and a
2.2.25 kernel. Although it takes almost half a day to compile the
kernel, I still like to give the machine a useful application near the
end of it's service life :-)

After reading all the HowTos and hints I could find on the net, I
compiled the ax25-libs and linpac and tried to start the application.
This is where trouble begins. I get an error with sethdlc:
#sethdlc -p -i bc0 mode "ser12*" io 0x3f8 irq 4
sethdlc: Error No such device (19), cannot ioctl SIOCGIFFLAGS bc0

I don't really know what I am doing here, since the AX25-Howto seems to
take knowledge about the intrinsics for granted and the sethdlc man page
also didn't get me any further.
Shouldn't I find the bc[0-3] devices in /dev? There is nothing. There is
also nothing in /proc/sys/net/ax25.
Also, the compiled baycom modules are called baycom_ser_hdx and
baycom_ser_fdx, not baycom as mentioned in the AX25-HowTo. How to
diagnose the error and requirements?
This is all very confusing, and the fact that most of the documentation
I could find is outdated, some of it written for 2.0.x kernels adds to
this confusion.

I know that in times of mobile phones and the internet PR is basically
dead, but I'm still hoping to find a kind soul to lend me a hand and
explain what I need to do to get it working...

73,
Michael
DC1RN

Michael,

I use a program called linkt. it will work fine with a port like ax0. I'm
not sure how it will work with your setup.

I use an mfj tnc in kiss mode and run a program called kissattach (comes
with SUSE linux) to provide the ax0 port to the computer. I don't know if
your baycom is capable of kiss mode.

Good luck with your endeavors to get this going. While packet seems to be
mostly dead in my part of the country, there are a few die-hards using it
for comm support in emergency situations.

73,

tim



Michael Hofmann wrote:



Bob Nielsen wrote:

On Thu, 15 Jan 2004 09:40:51 +0100, Michael Hofmann wrote:
Shouldn't I find the bc[0-3] devices in /dev? There is nothing.

With the newer drivers, the device is called bcfs0, etc. See
/usr/src/linux/Documentation/networking/baycom.txt (at least that is
where the file is for 2.4 kernels) for updated documentation.



Thanks Bob, now I got the bcsf0 device up and with a a bit of reading in
/usr/src/linux/Documentation/networking/baycom.txt I realized what module
I had to use. I can read PR traffic on the console now with the sethdlc -i
bcsf0 command, but I still didn't manage to run linpac (both 0.17-pre3 and
1.0pre4) successfully, so I can not transmit for the time being.
Do you have any more hints? Are there any other Packet terminals for the
console besides linpac? Unfortunately the ax25-tools and ax25-apps do not
compile on my machine.

73,
Michael

Michael,

I use a program called linkt. it will work fine with a port like ax0. I'm
not sure how it will work with your setup.

I use an mfj tnc in kiss mode and run a program called kissattach (comes
with SUSE linux) to provide the ax0 port to the computer. I don't know if
your baycom is capable of kiss mode.

Good luck with your endeavors to get this going. While packet seems to be
mostly dead in my part of the country, there are a few die-hards using it
for comm support in emergency situations.

73,

tim



Michael Hofmann wrote:



Bob Nielsen wrote:

On Thu, 15 Jan 2004 09:40:51 +0100, Michael Hofmann wrote:
Shouldn't I find the bc[0-3] devices in /dev? There is nothing.

With the newer drivers, the device is called bcfs0, etc. See
/usr/src/linux/Documentation/networking/baycom.txt (at least that is
where the file is for 2.4 kernels) for updated documentation.



Thanks Bob, now I got the bcsf0 device up and with a a bit of reading in
/usr/src/linux/Documentation/networking/baycom.txt I realized what module
I had to use. I can read PR traffic on the console now with the sethdlc -i
bcsf0 command, but I still didn't manage to run linpac (both 0.17-pre3 and
1.0pre4) successfully, so I can not transmit for the time being.
Do you have any more hints? Are there any other Packet terminals for the
console besides linpac? Unfortunately the ax25-tools and ax25-apps do not
compile on my machine.

73,
Michael

"tim gorman" wrote in message
...

snip

Good luck with your endeavors to get this going. While packet seems to be
mostly dead in my part of the country, there are a few die-hards using it
for comm support in emergency situations.

In the interest of accuracy, I'll have to correct Tim's characterization of
packet users in the US as "a few die-hards", as if packet had been replaced
by something better and only a few weirdos would still bother with it in
these modern times.

The fact is that nothing either better or worse has come along to replace
packet radio, and there are thousands of enthusiastic packet users in the US
today, with more hams becoming involved (or re-involved) with packet every
day.

Packet operation in the US is growing very fast right now, with old networks
being refurbished or upgraded, and new ones showing up where none have been
before. One packet net in the northeastern US has installed over 140 nodes
in the last five years or so, another packet net started more or less from
scratch a few years ago and now covers an entire state. Another new packet
net in the central US is just getting started.

There has been an upsurge in interest in emergency digital communications
since the terrorist attacks, partly because of interest generated by federal
grant money that is available for some of these efforts, but the renewed
growth and interest we are seeing in packet today pre-dates the terrorist
attacks by several years. Hams across the US have been dusting off their
TNC's, or getting on the air with the new TNC's and the soundcard packet
stuff in ever greater numbers for several years now, and the trend has been
speeding up, not slowing down.

Tell us about your network!

Charles Brabham, N5PVL
Director: USPacket.Net
http://www.uspacket.net

"tim gorman" wrote in message
...

snip

Good luck with your endeavors to get this going. While packet seems to be
mostly dead in my part of the country, there are a few die-hards using it
for comm support in emergency situations.

In the interest of accuracy, I'll have to correct Tim's characterization of
packet users in the US as "a few die-hards", as if packet had been replaced
by something better and only a few weirdos would still bother with it in
these modern times.

The fact is that nothing either better or worse has come along to replace
packet radio, and there are thousands of enthusiastic packet users in the US
today, with more hams becoming involved (or re-involved) with packet every
day.

Packet operation in the US is growing very fast right now, with old networks
being refurbished or upgraded, and new ones showing up where none have been
before. One packet net in the northeastern US has installed over 140 nodes
in the last five years or so, another packet net started more or less from
scratch a few years ago and now covers an entire state. Another new packet
net in the central US is just getting started.

There has been an upsurge in interest in emergency digital communications
since the terrorist attacks, partly because of interest generated by federal
grant money that is available for some of these efforts, but the renewed
growth and interest we are seeing in packet today pre-dates the terrorist
attacks by several years. Hams across the US have been dusting off their
TNC's, or getting on the air with the new TNC's and the soundcard packet
stuff in ever greater numbers for several years now, and the trend has been
speeding up, not slowing down.

Tell us about your network!

Charles Brabham, N5PVL
Director: USPacket.Net
http://www.uspacket.net

Hi Michael

I *think* that linpac has to run as root. Pls dont quote me on this
because I didnt try to research it, only tried it succesfuly when it
didnt work as a std user. Something about direct access to the interface...

If you just want to test the TX operation trying pinging a host in the
same subnet as to what you setup. The AX25 stack creates an interface in
s similar manner as a ppp (dial-in) or ethernet and you can pass IP
traffic over it. (same subnet means, if you setup the ip address as
44.136.0.1 and the netmask of 255.255.255.0 then just trying "ping -c 1
44.136.0.2" from a console window - you can check the ip address/netmask
by "ifconfig" as root)

I think that the ax25tools also came with "call", a simple packet pgm.
Simply do a "call bcsf0 callsign" in a console window. Its pretty
clunky but it will prove or disprove the AX25 stack. (verify the name of
the interface by running as root, "ifconfig" or looking at
/etc/ax25/axports. I can never remember which one has the port name!)

BTW Linpac has the hooks to receive broadcast mail direct from your
local BBS. Give me a shout if you want to set that up as there is
another package you need.

Hope this helps

Cheers Bob VK2YQA


Michael Hofmann wrote:
Bob Nielsen wrote:


On Thu, 15 Jan 2004 09:40:51 +0100, Michael Hofmann wrote:

Shouldn't I find the bc[0-3] devices in /dev? There is nothing.

With the newer drivers, the device is called bcfs0, etc. See
/usr/src/linux/Documentation/networking/baycom.txt (at least that is
where the file is for 2.4 kernels) for updated documentation.


Thanks Bob, now I got the bcsf0 device up and with a a bit of reading in
/usr/src/linux/Documentation/networking/baycom.txt I realized what module I
had to use. I can read PR traffic on the console now with the sethdlc -i
bcsf0 command, but I still didn't manage to run linpac (both 0.17-pre3 and
1.0pre4) successfully, so I can not transmit for the time being.
Do you have any more hints? Are there any other Packet terminals for the
console besides linpac? Unfortunately the ax25-tools and ax25-apps do not
compile on my machine.

73,
Michael

Hi Michael

I *think* that linpac has to run as root. Pls dont quote me on this
because I didnt try to research it, only tried it succesfuly when it
didnt work as a std user. Something about direct access to the interface...

If you just want to test the TX operation trying pinging a host in the
same subnet as to what you setup. The AX25 stack creates an interface in
s similar manner as a ppp (dial-in) or ethernet and you can pass IP
traffic over it. (same subnet means, if you setup the ip address as
44.136.0.1 and the netmask of 255.255.255.0 then just trying "ping -c 1
44.136.0.2" from a console window - you can check the ip address/netmask
by "ifconfig" as root)

I think that the ax25tools also came with "call", a simple packet pgm.
Simply do a "call bcsf0 callsign" in a console window. Its pretty
clunky but it will prove or disprove the AX25 stack. (verify the name of
the interface by running as root, "ifconfig" or looking at
/etc/ax25/axports. I can never remember which one has the port name!)

BTW Linpac has the hooks to receive broadcast mail direct from your
local BBS. Give me a shout if you want to set that up as there is
another package you need.

Hope this helps

Cheers Bob VK2YQA


Michael Hofmann wrote:
Bob Nielsen wrote:


On Thu, 15 Jan 2004 09:40:51 +0100, Michael Hofmann wrote:

Shouldn't I find the bc[0-3] devices in /dev? There is nothing.

With the newer drivers, the device is called bcfs0, etc. See
/usr/src/linux/Documentation/networking/baycom.txt (at least that is
where the file is for 2.4 kernels) for updated documentation.


Thanks Bob, now I got the bcsf0 device up and with a a bit of reading in
/usr/src/linux/Documentation/networking/baycom.txt I realized what module I
had to use. I can read PR traffic on the console now with the sethdlc -i
bcsf0 command, but I still didn't manage to run linpac (both 0.17-pre3 and
1.0pre4) successfully, so I can not transmit for the time being.
Do you have any more hints? Are there any other Packet terminals for the
console besides linpac? Unfortunately the ax25-tools and ax25-apps do not
compile on my machine.

73,
Michael

Hi Michael

If you just want to test the TX operation trying pinging a host in the
same subnet as to what you setup.

I do not understand why I would need to assign an IP address. I have done so
nevertheless, and it's pingable.

Well, When AX25 came out under Linux and even the NOS/KA9Q
implementations is was really meant to allow TCP/IP over packet radio.
In its heyday in Australia maybe 10 years ago you could do FTP, SMTP
mail transfers and so on. Our local gateway (tunnel to internet) also
picked up the NOS newsgroup and allowed users to POP3 get the articles
and so on. (This is the protocol most people use nowadays to receive
internet email)

It is really only of use to you if other amateurs in your area are
running TCP/IP on packet. I am actually playing with the userspace
soundmodem driver under Linux. It allows all types of different
modulation methods including the Q15X25 2500bps HF/SSB one. It just
comes up as another port/interface under Linux. Handy when the amateur I
am experimenting with doesnt have a telephone/modem!

----

Like I said, the latest ax25-apps and ax25-tools tarballs did not compile. I
found rpms specifically made for RH6.2 and installed them. After lots of
fiddling with the configuration, I tried "call bcsf0 callsign" just to
get an error message:
call: invalid port setting

I never had a huge problem but make sure that you also build libax25 as
well. Lots of its subroutines are used by "tools" and "apps". There is a
good chance that either the libax25 that is in the RH distro is out of
date or doesnt include the .h headers needed to compile apps and tools.

I am personally very wary of source RPM's and more often build direct
from tar.gz source.

Well you answered the call problem lower down with your axports comment
and the "call 1 callsign" grin

None of the available documents described how and where to assign a port
designator. I can tell you, after 6 hrs of trying in vain I was so mad and
ready to throw out the PC and modem and forget about PR once and for all.
Fortunately I didn't. This morning I found that I had to use "call 1
callsign", the "1" being the port number from /etc/axports. All of the
docs I read are describing this wrong.

Yes I found the AX25-HOWTO pretty limited as well. I can however see
where the port number (1 in your case is assigned) in my old KISS setup.
There is a command "kissparam" thats sets up the relationship between
the linux interface and the portname in /etc/axports. In my later
soundmodem setup both the linux interface and axports "port" has the
same name. I had thought that "sethdlc" also setup this relationship but
havent checked.

-----

Just one brief example: the AX25-HowTo talks about "insmod"ing modules

You should be able to get around this by the correct setup in
/etc/modules.conf. insmod is really only used for manual loading of
modules where the dependencies havent been defined in modules.conf. In
short when you try to run an AX25 app all the right modules should load
in the correct order. Most distros that have AX25 in the kernel already
have this setup. I have only needed to use module commands when I
totally wrecked modules.conf!

I should mention that if you want to use the kernel soundmodem driver
(as distinct from the userspace soundmodem driver) you will need to do a
bit of module fiddling. One has to remove the ordinary soundcard drivers
(ie to play music) to use it for packet. From memory this driver is also
not unloadable so to get your ordinary sound back a cold boot is needed.

BTW Linpac has the hooks to receive broadcast mail direct from your
local BBS. Give me a shout if you want to set that up as there is
another package you need.

I may come back for this when I feel comfortable with my setup.

I actually stopped using mine as the articles were mainly a lot of
recycled you know what. My packet use nowadays is pretty well restricted
to file tranfers direct from me to another amatuer.

Cheers Bob VK2YQA

Hi Michael

If you just want to test the TX operation trying pinging a host in the
same subnet as to what you setup.

I do not understand why I would need to assign an IP address. I have done so
nevertheless, and it's pingable.

Well, When AX25 came out under Linux and even the NOS/KA9Q
implementations is was really meant to allow TCP/IP over packet radio.
In its heyday in Australia maybe 10 years ago you could do FTP, SMTP
mail transfers and so on. Our local gateway (tunnel to internet) also
picked up the NOS newsgroup and allowed users to POP3 get the articles
and so on. (This is the protocol most people use nowadays to receive
internet email)

It is really only of use to you if other amateurs in your area are
running TCP/IP on packet. I am actually playing with the userspace
soundmodem driver under Linux. It allows all types of different
modulation methods including the Q15X25 2500bps HF/SSB one. It just
comes up as another port/interface under Linux. Handy when the amateur I
am experimenting with doesnt have a telephone/modem!

----

Like I said, the latest ax25-apps and ax25-tools tarballs did not compile. I
found rpms specifically made for RH6.2 and installed them. After lots of
fiddling with the configuration, I tried "call bcsf0 callsign" just to
get an error message:
call: invalid port setting

I never had a huge problem but make sure that you also build libax25 as
well. Lots of its subroutines are used by "tools" and "apps". There is a
good chance that either the libax25 that is in the RH distro is out of
date or doesnt include the .h headers needed to compile apps and tools.

I am personally very wary of source RPM's and more often build direct
from tar.gz source.

Well you answered the call problem lower down with your axports comment
and the "call 1 callsign" grin

None of the available documents described how and where to assign a port
designator. I can tell you, after 6 hrs of trying in vain I was so mad and
ready to throw out the PC and modem and forget about PR once and for all.
Fortunately I didn't. This morning I found that I had to use "call 1
callsign", the "1" being the port number from /etc/axports. All of the
docs I read are describing this wrong.

Yes I found the AX25-HOWTO pretty limited as well. I can however see
where the port number (1 in your case is assigned) in my old KISS setup.
There is a command "kissparam" thats sets up the relationship between
the linux interface and the portname in /etc/axports. In my later
soundmodem setup both the linux interface and axports "port" has the
same name. I had thought that "sethdlc" also setup this relationship but
havent checked.

-----

Just one brief example: the AX25-HowTo talks about "insmod"ing modules

You should be able to get around this by the correct setup in
/etc/modules.conf. insmod is really only used for manual loading of
modules where the dependencies havent been defined in modules.conf. In
short when you try to run an AX25 app all the right modules should load
in the correct order. Most distros that have AX25 in the kernel already
have this setup. I have only needed to use module commands when I
totally wrecked modules.conf!

I should mention that if you want to use the kernel soundmodem driver
(as distinct from the userspace soundmodem driver) you will need to do a
bit of module fiddling. One has to remove the ordinary soundcard drivers
(ie to play music) to use it for packet. From memory this driver is also
not unloadable so to get your ordinary sound back a cold boot is needed.

BTW Linpac has the hooks to receive broadcast mail direct from your
local BBS. Give me a shout if you want to set that up as there is
another package you need.

I may come back for this when I feel comfortable with my setup.

I actually stopped using mine as the articles were mainly a lot of
recycled you know what. My packet use nowadays is pretty well restricted
to file tranfers direct from me to another amatuer.

Cheers Bob VK2YQA

Re Correlation between axports portname and interface name..

I hope I have this right, I kind of just arrived at the notion it may be!

- As mentioned AX25 on Linux is a TCP/IP implementation. TCP/IP is in
fact part of the OSI 7 layer model. You can regard the first layer as
being physical hardware, the second as one having "hardware addresses",
the third having "IP" addressing, the 4th TCP and so on.

- In ethernet networking the physical hardware is pretty obvious, as is
the packet world. The hardware addressing layer in the ethernet world is
the MAC address of the interface. (HWAddr) See my "ifconfig" dump below.
(Its that 00:D0 etc number)

- In the AX25 world for amateurs the hardware address is the callsign
plus SSID. eg VK2YQA-3. On my packet box I actually have three packet
ports (sm0, 1 & 2) and their associated hardware addresses (VK2YQA-1,
VK2YQA-2, VK2YQA-3)

- When you start/setup the hardware interface whether it be a kiss TNC,
baycom device or soundcard modem you define the low level interface, the
IP address and the hardware address. The hardware address is also
visible in /etc/ax25/axports as this contains the lookup table for the
"pure/standard" AX25 connect mode port to use. The port name you use for
linpac/call is not an IP port.You can think of the "normal" AX25 mode
working at the HWAddr layer only and IP sits on top of that. If you want
to run IP over AX25 you use the standard internetworking stuff available
on the Linux box. You could web browse over AX25 but boy would it be slow!

- And again on my packet box I also have three IP address ranges and
subnets for the interfces (44.136.0.1/255.255.255.0,
44.136.0.2/255.255.255.0, 44.136.0.3/255.255.255.0) and the associated
names in axports being the same as the low level names (sm0-2). They
equally could have been "AFSK1200", "Q15X25" & "AFSK300"

- Different hardware devices have different initial setup. kissattach
and kissparams are used for KISS TNCs, sethdlc for baycom and so on. The
userspace soundmodem is preconfigured using a confoguration file. Along
with defining hardware params like ports and interrupts, these kind of
startup the low level linux interface and may or may not contain IP and
hardware address/name information. Using "ifconfig" then allows you to
specify or re-specify the hwaddr and IP address as needed. It also
finally "brings up" or enables the interface. I would guess that if you
werent interested in IP you maybe able to leave it unconfigured but be
aware of the correlation between the AX25 hardware address
(callsign+ssid) in /etc/ax25/axports and the port name/naumber used by
linpac etc.

I am prepared to be shot down on this but so far it looks good to me!

Cheers Bob



eth0
Link encap:Ethernet HWaddr 00:D0:B7:B2:C3:B0
inet addr:192.168.0.250 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::2d0:b7ff:feb2:c3b0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8335407 errors:2 dropped:0 overruns:0 frame:2
TX packets:8471881 errors:72 dropped:0 overruns:0 carrier:72
collisions:147699 txqueuelen:100
RX bytes:772321466 (736.5 Mb) TX bytes:1379313960 (1315.4 Mb)
Interrupt:9 Base address:0xb800 Memory:e0800000-e0800038

Re Correlation between axports portname and interface name..

I hope I have this right, I kind of just arrived at the notion it may be!

- As mentioned AX25 on Linux is a TCP/IP implementation. TCP/IP is in
fact part of the OSI 7 layer model. You can regard the first layer as
being physical hardware, the second as one having "hardware addresses",
the third having "IP" addressing, the 4th TCP and so on.

- In ethernet networking the physical hardware is pretty obvious, as is
the packet world. The hardware addressing layer in the ethernet world is
the MAC address of the interface. (HWAddr) See my "ifconfig" dump below.
(Its that 00:D0 etc number)

- In the AX25 world for amateurs the hardware address is the callsign
plus SSID. eg VK2YQA-3. On my packet box I actually have three packet
ports (sm0, 1 & 2) and their associated hardware addresses (VK2YQA-1,
VK2YQA-2, VK2YQA-3)

- When you start/setup the hardware interface whether it be a kiss TNC,
baycom device or soundcard modem you define the low level interface, the
IP address and the hardware address. The hardware address is also
visible in /etc/ax25/axports as this contains the lookup table for the
"pure/standard" AX25 connect mode port to use. The port name you use for
linpac/call is not an IP port.You can think of the "normal" AX25 mode
working at the HWAddr layer only and IP sits on top of that. If you want
to run IP over AX25 you use the standard internetworking stuff available
on the Linux box. You could web browse over AX25 but boy would it be slow!

- And again on my packet box I also have three IP address ranges and
subnets for the interfces (44.136.0.1/255.255.255.0,
44.136.0.2/255.255.255.0, 44.136.0.3/255.255.255.0) and the associated
names in axports being the same as the low level names (sm0-2). They
equally could have been "AFSK1200", "Q15X25" & "AFSK300"

- Different hardware devices have different initial setup. kissattach
and kissparams are used for KISS TNCs, sethdlc for baycom and so on. The
userspace soundmodem is preconfigured using a confoguration file. Along
with defining hardware params like ports and interrupts, these kind of
startup the low level linux interface and may or may not contain IP and
hardware address/name information. Using "ifconfig" then allows you to
specify or re-specify the hwaddr and IP address as needed. It also
finally "brings up" or enables the interface. I would guess that if you
werent interested in IP you maybe able to leave it unconfigured but be
aware of the correlation between the AX25 hardware address
(callsign+ssid) in /etc/ax25/axports and the port name/naumber used by
linpac etc.

I am prepared to be shot down on this but so far it looks good to me!

Cheers Bob



eth0
Link encap:Ethernet HWaddr 00:D0:B7:B2:C3:B0
inet addr:192.168.0.250 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::2d0:b7ff:feb2:c3b0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8335407 errors:2 dropped:0 overruns:0 frame:2
TX packets:8471881 errors:72 dropped:0 overruns:0 carrier:72
collisions:147699 txqueuelen:100
RX bytes:772321466 (736.5 Mb) TX bytes:1379313960 (1315.4 Mb)
Interrupt:9 Base address:0xb800 Memory:e0800000-e0800038

"Bob Nielsen" wrote

As of kernel 2.6.0 (actually as of 2.5.something), the kernel
soundmodem driver no longer exists.

Oh my God! Next thing you know they are going to take out the
kitchen sink!!

"Bob Nielsen" wrote

As of kernel 2.6.0 (actually as of 2.5.something), the kernel
soundmodem driver no longer exists.

Oh my God! Next thing you know they are going to take out the
kitchen sink!!

Bob Nielsen wrote:

On Sun, 18 Jan 2004 06:24:55 +1100, Bob Bob wrote:


I should mention that if you want to use the kernel soundmodem driver
(as distinct from the userspace soundmodem driver) you will need to do a
bit of module fiddling. One has to remove the ordinary soundcard drivers
(ie to play music) to use it for packet. From memory this driver is also
not unloadable so to get your ordinary sound back a cold boot is needed.

As of kernel 2.6.0 (actually as of 2.5.something), the kernel
soundmodem driver no longer exists.

Bob, N7XY

Have a look at the Baycom website, the soundmodem driver is alive
and well, having moved from a driver to userspace (this means it
works with a lot more soundcards). I've had the newer version
up with many of the recent RedHat versions. As far as soundcards,
I'm partial to the ES1371/ES1373 based cards these days...

regards
-Willy
KC0JFQ

Bob Nielsen wrote:

On Sun, 18 Jan 2004 06:24:55 +1100, Bob Bob wrote:


I should mention that if you want to use the kernel soundmodem driver
(as distinct from the userspace soundmodem driver) you will need to do a
bit of module fiddling. One has to remove the ordinary soundcard drivers
(ie to play music) to use it for packet. From memory this driver is also
not unloadable so to get your ordinary sound back a cold boot is needed.

As of kernel 2.6.0 (actually as of 2.5.something), the kernel
soundmodem driver no longer exists.

Bob, N7XY

Have a look at the Baycom website, the soundmodem driver is alive
and well, having moved from a driver to userspace (this means it
works with a lot more soundcards). I've had the newer version
up with many of the recent RedHat versions. As far as soundcards,
I'm partial to the ES1371/ES1373 based cards these days...

regards
-Willy
KC0JFQ

Bob Bob wrote:

[snipped]

I seem to have the software tamed so that PR basically works, but I get
very low and flaky connection quality - tons of RR-/RR+ packets, but few
"payload" packets. I think I remember from my earlier packet days that
these are reject/acknowledge packets, indicating some sort of
misunderstanding between my station and the digi. Next thing I will
check at the weekend is the modulation deviation of my Kenwood transceiver.
Other than that, is there a document describing the ax25 parameters (Tn,
N2, idle, window) and useful values? Again the Ax25-HowTo is very
unprecise about those.

TIA,
Michael

Bob Bob wrote:

[snipped]

I seem to have the software tamed so that PR basically works, but I get
very low and flaky connection quality - tons of RR-/RR+ packets, but few
"payload" packets. I think I remember from my earlier packet days that
these are reject/acknowledge packets, indicating some sort of
misunderstanding between my station and the digi. Next thing I will
check at the weekend is the modulation deviation of my Kenwood transceiver.
Other than that, is there a document describing the ax25 parameters (Tn,
N2, idle, window) and useful values? Again the Ax25-HowTo is very
unprecise about those.

TIA,
Michael

Hi Michael

Will be off newsgroups for about a month from tomorrow..

As I recall packet neds a very good signal to noise. I have found that
even a S3 copy on 2m FM will be noisy enough for retries. If your RIT
works on FM check if you are on the digis exact freq.

The original NOS docs (wherever they may be) had discussions on these
parameters I think.

Shortening the max packet length gives better results in flakey
conditions because there is less time for the packet to be corrupted in.
Ensuring that the TXDelay and TXtail is both long enough and short
enough is also important. I remember setting my TXD by changing the
number dynamically as a ping job was in progress, then adding about 10%
when errors occurred. My old IC2A use to run at around 30mS but an older
relay based XTAL clunker needed 400mS. If you think it maybe a problem
(and remember that the time also helpds the other guys squelch open) set
it to something ridiculous like 1 second and see if the throughput improves.

The other timers (and persist/slottime) are more of use in crowded
channels so initially it probably isnt worth fiddling with. As a general
rule of thumb you would use what the local group are using so you had a
fair chance as them. Biggest problem is to ensure that you can hear
every other TX on your channel and they can hear you. Not a good idea to
use a yagi and low power because your (and their) collision rate will
skyrocket, despite any settings you use.

I'd accept the default settings as they appear in the proc filesystem,
set TXD and TXT by experiment, use the persist/slot that the local group
uses (or leave it as default), MaxFrame/window at 1 and thats it. If you
specifically want to use point to point with another station, make
persist/slot more agressive, fine tune the TXD, Maxframe/window to 7 and
make the packet length as long as possible.

I thought the howto actually described the params well enough for me..

Cheers Bob VK2YQA


Michael Hofmann wrote:
Bob Bob wrote:

[snipped]


I seem to have the software tamed so that PR basically works, but I get
very low and flaky connection quality - tons of RR-/RR+ packets, but few
"payload" packets. I think I remember from my earlier packet days that
these are reject/acknowledge packets, indicating some sort of
misunderstanding between my station and the digi. Next thing I will
check at the weekend is the modulation deviation of my Kenwood transceiver.
Other than that, is there a document describing the ax25 parameters (Tn,
N2, idle, window) and useful values? Again the Ax25-HowTo is very
unprecise about those.

TIA,
Michael

Hi Michael

Will be off newsgroups for about a month from tomorrow..

As I recall packet neds a very good signal to noise. I have found that
even a S3 copy on 2m FM will be noisy enough for retries. If your RIT
works on FM check if you are on the digis exact freq.

The original NOS docs (wherever they may be) had discussions on these
parameters I think.

Shortening the max packet length gives better results in flakey
conditions because there is less time for the packet to be corrupted in.
Ensuring that the TXDelay and TXtail is both long enough and short
enough is also important. I remember setting my TXD by changing the
number dynamically as a ping job was in progress, then adding about 10%
when errors occurred. My old IC2A use to run at around 30mS but an older
relay based XTAL clunker needed 400mS. If you think it maybe a problem
(and remember that the time also helpds the other guys squelch open) set
it to something ridiculous like 1 second and see if the throughput improves.

The other timers (and persist/slottime) are more of use in crowded
channels so initially it probably isnt worth fiddling with. As a general
rule of thumb you would use what the local group are using so you had a
fair chance as them. Biggest problem is to ensure that you can hear
every other TX on your channel and they can hear you. Not a good idea to
use a yagi and low power because your (and their) collision rate will
skyrocket, despite any settings you use.

I'd accept the default settings as they appear in the proc filesystem,
set TXD and TXT by experiment, use the persist/slot that the local group
uses (or leave it as default), MaxFrame/window at 1 and thats it. If you
specifically want to use point to point with another station, make
persist/slot more agressive, fine tune the TXD, Maxframe/window to 7 and
make the packet length as long as possible.

I thought the howto actually described the params well enough for me..

Cheers Bob VK2YQA


Michael Hofmann wrote:
Bob Bob wrote:

[snipped]


I seem to have the software tamed so that PR basically works, but I get
very low and flaky connection quality - tons of RR-/RR+ packets, but few
"payload" packets. I think I remember from my earlier packet days that
these are reject/acknowledge packets, indicating some sort of
misunderstanding between my station and the digi. Next thing I will
check at the weekend is the modulation deviation of my Kenwood transceiver.
Other than that, is there a document describing the ax25 parameters (Tn,
N2, idle, window) and useful values? Again the Ax25-HowTo is very
unprecise about those.

TIA,
Michael