I've been running the ConnexLink 900 Mhz serial modems for over a year
now to connect my house network to my business network in a rural area.
The networks are Windows based and the link runs PPP using the
radio's full duplex setting.

The link is clean for ping, telnet, ftp, and email. Unfortunately, I
never was able to get any browser to work without it coming to a
screeching halt with lots of TCP/IP retransmissions. I contacted
Aerocomm tech support (Sean) about this several times, but it appears
that no one else really uses the ConnexLinks on TCP/IP (they have a
newer product ConnexNet that does).

I really don't have a clue why the link fails with a browser, except
that some piece of the hardware/software path must be failing with the
heavy full duplex traffic created by browser and then snowballs with
the TCP/IP retransmissions.

I am curious if you are able to get PPP to work reliably with a browser
to web sites with a lot of graphics that result in multiple
simultaneous connections. If you are (and I would not be surprised if
your link would work, given the different hardware/software pieces),
then it gives me hope that one day I might be able to get my link to
work properly when I have the time to fix it. And if you get the
radios to run faster on AX.25, then that is even a greater achievement.

By the way, my radio link is solid (no problem there). There are two
yagi antennas pointing at each other and the signal is great even
through the trees.


wrote:
Hi all,

I'm trying to setup a wireless link between two Linux using ConnexLink
900 MHz serial modems (http://www.aerocomm.com/Devices/link.htm). One
side (ali) is a regular PC running Debian Linux testing and the other
side (SLUG) is a NSLU2 running N7IPB's OpenSlug mod
(http://wetnet.net/).

The AX.25 link seem to work fine, I'm able to communicate between the
two sides with "call", but I can't figure out how to pass TCP/IP
through the link.

Anyone idea about what's going on?

Here's the relevant (I think) data from both hosts:
========================================
root@SLUG:~# cat /etc/ax25/axports
#Name Callsign baudrate paclen window Description
connex VA2JF-0 115200 1500 1 ConnexLink 900 MHz
root@SLUG:/etc/ax25# /usr/sbin/kissattach -l /dev/ttyUSB0 connex
172.25.25.2
AX.25 port connex bound to device ax0
root@SLUG:~# ifconfig ax0
ax0 Link encap:UNSPEC HWaddr
AC-82-64-94-8C-40-00-FF-00-00-00-00-00-00-00-00
inet addr:172.25.25.2 Bcast:172.25.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:301 errors:0 dropped:0 overruns:0 frame:0
TX packets:61 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:17345 (16.9 KiB) TX bytes:2788 (2.7 KiB)
root@SLUG:~# /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
172.25.25.0 0.0.0.0 255.255.255.0 U 0 0 0
ax0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
172.25.0.0 0.0.0.0 255.255.0.0 U 0 0 0
ax0
0.0.0.0 192.168.0.3 0.0.0.0 UG 0 0 0
eth0
root@SLUG:~# mheard
Callsign Port Packets Last Heard
VA2JF-1 connex 463 Mon Dec 19 21:08:44
root@SLUG:~# axparms -route list
callsign dev mode digipeaters

root@SLUG:~# ping -c 10 172.25.25.1
PING 172.25.25.1 (172.25.25.1): 56 data bytes

--- 172.25.25.1 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
========================================
root@ali:~# cat /etc/ax25/axports
# name callsign speed paclen window description
connex VA2JF-1 115200 1500 1 ConnexLink 900 MHz
root@ali:# kissattach -l /dev/ttyS1 connex 172.25.25.1
AX.25 port connex bound to device ax0
gfk@ali:~$ /sbin/ifconfig ax0
ax0 Link encap:AMPR AX.25 HWaddr VA2JF-1
inet addr:172.25.25.1 Bcast:172.25.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:165 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 b) TX bytes:8085 (7.8 KiB)

gfk@ali:~$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
172.25.25.0 0.0.0.0 255.255.255.0 U 0 0 0
ax0
10.10.16.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
172.25.0.0 0.0.0.0 255.255.0.0 U 0 0 0
ax0
0.0.0.0 192.168.0.3 0.0.0.0 UG 0 0 0
eth0
gfk@ali:~$ mheard
Callsign Port Packets Last Heard
VA2JF connex 118 Sat Jan 28 16:44:54
gfk@ali:~$ sudo axparms -route list
callsign dev mode digipeaters

gfk@ali:~$ ping -c 10 172.25.25.2
PING 172.25.25.2 (172.25.25.2) 56(84) bytes of data.
From 172.25.25.1 icmp_seq=1 Destination Host Unreachable
From 172.25.25.1 icmp_seq=2 Destination Host Unreachable
From 172.25.25.1 icmp_seq=3 Destination Host Unreachable
From 172.25.25.1 icmp_seq=4 Destination Host Unreachable
From 172.25.25.1 icmp_seq=5 Destination Host Unreachable
From 172.25.25.1 icmp_seq=6 Destination Host Unreachable
From 172.25.25.1 icmp_seq=7 Destination Host Unreachable
From 172.25.25.1 icmp_seq=8 Destination Host Unreachable
From 172.25.25.1 icmp_seq=9 Destination Host Unreachable
From 172.25.25.1 icmp_seq=10 Destination Host Unreachable

--- 172.25.25.2 ping statistics ---
10 packets transmitted, 0 received, +10 errors, 100% packet loss, time
9020ms
, pipe 4
========================================

Thanks a lot and 73,
GFK's

PS: I was able to make the link work with PPP, but PPP requires a
full-duplex link. So I had to enable the full-duplex simulation of the
modem. This cut the available bandwidth in half. I'm trying to see if
AX.25 would perform better since it doesn't require full duplex.

--
Guillaume Filion, ing. jr
Logidac Tech., Beaumont, Québec, Canada - http://logidac.com/
PGP Key and mo http://guillaume.filion.org/

If I may answer first...

TCP/IP is suppose to self calculate retry etc periods based on the first
few packet failures. I am surprised you are having problems with the
link at all. Perhaps some massaging of the TCP retry parameters might be
in order. I'll admit I dont know where to do that in Windows without
looking it up. It will be as registry setting.

I wonder if you are also using plain serial ports at each end or some
kind of ethernet converter. That can mess things up as TCP/IP thinks it
has a faster throughput speed than it really doesnt. The other
possibility is that serial hardware handshaking is broken although FTP
would be affected by that. (Depends on the direction and which end has
failed though) Lowering your DTE speed may also help.

As a simple workaround you can limit the number of concurrent http
requests your browser will allow. Once again I dont know how this is
done in IE but Firefox has a about:config parameter
network.http.maximum.connections or similar. The end effect will be that
web pages with lots of internal lnks (eg pictures) will tend to load
more one after the other than bits at the same time. Email, FTP and
telnet use a port for each direction whereas web browsers can use 100+
source ports to get a web page.

If you wish to try this and dont have Firefox, download it and gimee a
shout and I'll walk you through the config changes.

I have also heard the SLIP might be a better way to go over these links
because of the half duplex factor. I'll admit I havent tried this but it
wont hurt to try. W2K and above have SLIP available if you want to play
with it.

Strangely I am thinking of using a 900MHz serial link to my mother in
laws house. The reason I am not using 802.11 Ethernet is path obstructions.

One option by the way, if you want to throw lots of money at it, is to
setup a second link such that the whole things runs a "real" fullduplex.

Lastly I havent checked around on the web on this topic. Perhaps others
have had this issue and found a solution.

Cheers Bob

Braath Waate wrote:

I've been running the ConnexLink 900 Mhz serial modems for over a year
now to connect my house network to my business network in a rural area.
The networks are Windows based and the link runs PPP using the
radio's full duplex setting.

Thanks Bob for all of your good suggestions.

I've tried playing around with some of the TCP/IP tuning. I also
played around with the max-connections in Explorer and Firefox. Not
much difference in performance. I did swap a unshielded serial cable
(the radios are directly connected to the computers' serial ports) with
a shielded cable, and that seemed to improve the performance. The
serial lines are fairly long (60') to get to the antennas which are
colocated with the radios. I would say the system is usable (slow)
with a browser, but not good with heavy traffic, which results in
significantly more retransmissions and reset connections.

The reason why the link is disappointingly slow is that it only runs at
19 kbps. According to the Aerocomm AC4490 manual, the maximum
throughput of the radio in stream mode is 57.6 kbps, acknowledge mode
is 38k and acknowledge with full/duplex is 19k (full/duplex is only
supported in acknowledge mode). Running PPP or SLIP requires the
full/duplex hardware, so 19k is all I can get.

I'm in the market for better but inexpensive 900 Mhz radios to replace
the Aerocomms, if anyone has any suggestions.

That RS232/serial run is in my view way too long if you are running at
115K2, even when shielded. I would suspect that noise is being
introduced into the circuit. RS232 isnt a balanced system like RS485 or
XBaseT ethernet so you dont gain the benefits of common mode rejection.
You may even have earth loops occurring in your computer/mains/ground
setup that puts main noise onto the cable shield. The simple test is to
reduce the DTE rate from the computer to the radio to the next step down
to see if that helps. If the modems offer hardware compression you might
lose your peak speed but gain a higher reliability. Generally speaking
the slower the bit rate the longer the cable can be.

The data rate problem is the same thing that gfilion was fighting on. I
understand the Aerocomm fixes the TX/RX ratio at 50% to make PPP work
and thus you get the low data rate. You may of course also be suffering
from radio interference. I remember the Cisco Aironet boxes use to keep
stats as to their performance. If the Aerocomm boxes do that may be a
place to check. One simple thing you can do if you think it is another
transmitter is to change to horizontal polarisation in the hope that
most other users will be on vertical.

I have had a look around for Ethernet radios on 900MHz and they arent
real cheap (like USD700/pair etc). The serial offerrings all seem to
have the same rate limitations you have encountered and as yet I havent
seen a USB connected one (to gain a higher rate than 115K2). They seem
to be more for telemetry/SCADA use rather than a FDX internet link.

My flippant suggestion to get another Aerocomm pair and connected them
for full duplex operation might be cost viable for you. You'll need to
play with the hardware a bit but I dont see any problems if you can tell
the modems to stay in the right mode. I get the impression that this
will then get you 57K6.

I am seriously thinking of taking some of my works 2.4GHz RF modules for
TX and RX and supplying my own QAM modulation scheme to them. The idea
being to run maybe 1MB/sec via the USB port. I can do that as a radio
amateur but will need to check whether I can use the ISM band in that
manner. I can certainly tune it to the FCC spec but dont know if I have
to go through a type approval process. A very long term project I am
afraid. In that vein I am also looking for AX25/packet QAM I/Q modems
that would do that part for me.

Good luck!

Cheers Bob

Braath Waate wrote:

Thanks Bob for all of your good suggestions.

Yes, good suggestion. I am running the serial lines at 115K, I will try
to run at 57 or 38 or even 19 and see if that improves the link.

Connexlink does have a signal strength register (report last RSSI) and
has some DOS software to manage it, but I have been reluctant to spend
the time on the radio section because the 19K limit is disappointing
enough for web access, even if it were reliable.

I'm sorry I don't understand the radio pair suggestion; wouldn't the
pair of radios just interfere with each other? Is the idea to hook the
tx lead of the serial port to one radio and the rx lead to the other?
How would they hook to the antenna?

-- Braath

Hi Braath

The kind of stats I am talking about is more the bit error rate one. ie
what percentage of the radio packects are mangled or not getting
through. It is common in a radio system to have some percentage of
failure. I use to administer two non licensed links, one on 2.4Ghz and
the other on 5.7. Towards the end of its useful life the 2.4GHz link had
about 90% retries mainly from interferring sources. In that case we got
much better reliability limiting it to the 1MB speed (as against 11).
The newer less populated 5.7GHz link ran about 20% retries.

The fullduplex radio pair configuration I suggested would use separate
frequencies and maybe even antenna polarisation/space separation to
reduce interference. ie two antennas at each end. Using a diplexor to
allow two boxes on the one antenna is probably a bit cost wasteful. The
idea is that at one end you force one box into transmit mode and the
other to receive. You also have to specify a fixed channel instead of
allowing automatic operation. The node names would also have to be
paired. Connection to the computer is as you stated but some
configuration of the handshaking lines (RTS, CTS, DTR etc) would also be
needed. I expect that Connexlink would have already done this with their
equipment so there may even be an application note on it available. It
would of course be smart to run all lines back to the PC and do the
patching there, in case you want to send commands to the unit itself and
need both TX/RX lines available.

Cheers Bob


Braath Waate wrote:
--

I'm sorry I don't understand the radio pair suggestion; wouldn't the
pair of radios just interfere with each other? Is the idea to hook the
tx lead of the serial port to one radio and the rx lead to the other?
How would they hook to the antenna?