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 000 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 000: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