nr0 doesn't show up (netrom)

nr0 doesn't show up (netrom)

[Cathryn Mataga]

On Fedora 12.  Kernel 2.6.31.5-127.fc12.i686  I install
libax25,ax25-apps, and ax25-tools via yum. I created my
nrports file as follows.  nrattach says it's creating
nr0, but then it says it creates nr0 again.  ifconfig
never shows nr0.

(Actually, otherwise this combination of software is working
correctly so far, and I am able to connect to ax25 stations
over actual RF.)


[root@junglevision ax25]# modprobe netrom
[root@junglevision ax25]# cat nrports
netrom KE6I-10 BERK 236 Berkeley
netrom2 KE6I-11 BRKBBS 236 Berkeley BBS
[root@junglevision ax25]# nrattach -i 192.168.0.10 netrom
NET/ROM port netrom bound to device nr0
[root@junglevision ax25]# nrattach -i 192.168.0.11 netrom2
NET/ROM port netrom2 bound to device nr0
[root@junglevision ax25]# /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:13:20:12:68:A4
           inet addr:75.101.49.34  Bcast:75.101.49.63  Mask:255.255.255.224
           inet6 addr: fe80::213:20ff:fe12:68a4/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:2572078 errors:0 dropped:0 overruns:0 frame:0
           TX packets:4287069 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:682027869 (650.4 MiB)  TX bytes:4048632775 (3.7 GiB)

lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           inet6 addr: ::1/128 Scope:Host
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:2318600 errors:0 dropped:0 overruns:0 frame:0
           TX packets:2318600 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:3228300929 (3.0 GiB)  TX bytes:3228300929 (3.0 GiB)

virbr0    Link encap:Ethernet  HWaddr 5A:7F:B7:E8:BC:C4
           inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:5517 (5.3 KiB)

[root@junglevision ax25]#


Messages doesn't show much.  Just

NET: Registered protocol family 3
NET: Registered protocol family 6

Re: nr0 doesn't show up (netrom)

[Cathryn Mataga]

A little bit more information.

I can bring up a nr0 device by doing

/sbin/ifconfig nr0 up 192.168.0.10

But any attempts to set the hardware address fail.

/sbin/ifconfig nr0 hw ax25 KE6I-10 192.168.0.10

Give me

SIOCSIFHWADDR: Invalid argument


I don't think it works this way, because netromd then
tells me "no NET/ROM ports defined"

Re: nr0 doesn't show up (netrom)

[Cathryn Mataga]

Oops.  Looking through the proper archive of linux hams I found this.

 >nrattach.c
 >
 >#ifndef notdef
 >	if (!startiface(dev, hp))
 >		return 1;		
 >#endif
 >	printf("NET/ROM port %s bound to device %s\n", argv[optind], dev);

 >However, if notdef is defined somewhere, there will be again no netrom device
 >created, but a false success message will still be displayed.

 >I don't really understand the purpose of this.

I think somebody just screwed up and committed this by accident.
Just remove that ifdef and endif. (I suggest.)

Re: nr0 doesn't show up (netrom)

[Cathryn Mataga]

For the record, I actually managed to connect to another NETROM
site over actual RF after fixing nrattach.c and recompiling.  It's acting
kind of slow but I need to do some conventional AX25 tweaking
first before I can claim anything is actually broken here. This is
a new install, using the rc2 files on the site.

I'm still dependent on the BSD style pty's, and it looks like
the utilities have been updated to get around this, so I have to
put in some time to see if I can run a completely stock
kernel from Fedora, which would be nice.

Generally, it's looking good so far though.

ax25ipd.c routing

[Cathryn Mataga]

How does this work with multiple connections?

Suppose I have two incoming connections
My call is K1BBS.

route K1PAR 1.0.0.0
route K2PAR 2.0.0.0 d

Then suppose K1USR at K1PAR does a connect to K1BBS.

What seems to happen is I see packets come in from K1USR  to K1BBS.
But then when packets go back out, they go back to K2PAR, even though
he's at K1PAR.   At least that's what I think is happening.

Shouldn't ax25d.c keep a record of which IP callsigns came from, so that
way when it needs to send a packet back they go to the right place?
I'm not 100% sure of this, but it seems like the lookup only checks
the route commands.   I only see one call to route_add in config.c.

Shouldn't it 'route_add' every time a callsign comes in axip?
Or the only way to make this work is to run a separate
ax25ipd for every connection.

Re: ax25ipd.c routing

[Thomas Osterried]

On 2009-12-07 02:30:27 -0800, Cathryn Mataga <cathryn@junglevision.com>
wrote in <4B1CD943.6030808@junglevision.com>:
> How does this work with multiple connections?
>
> Suppose I have two incoming connections
> My call is K1BBS.
>
> route K1PAR 1.0.0.0
> route K2PAR 2.0.0.0 d
>
> Then suppose K1USR at K1PAR does a connect to K1BBS.
>
> What seems to happen is I see packets come in from K1USR  to K1BBS.
> But then when packets go back out, they go back to K2PAR, even though
> he's at K1PAR.   At least that's what I think is happening.
>
> Shouldn't ax25d.c keep a record of which IP callsigns came from, so that
> way when it needs to send a packet back they go to the right place?
> I'm not 100% sure of this, but it seems like the lookup only checks
> the route commands.   I only see one call to route_add in config.c.

ax25ipd in it's current version does not learn routes.
In fact, route_add() is only being called from the config file.
.../ax25-apps/ax25ipd$ grep route_add *.c
config.c:               route_add(tip, tcall, uport, flags);
routing.c:void route_add(unsigned char *ip, unsigned char *call, int udpport,
.../ax25-apps/ax25ipd$ 

That's why your packet goes out via the default connection (route K2PAR
2.0.0.0 d).


At db0fhn we have since several years a modified version:
...ax25ipd-test/ax25ipd$ grep route_add *.c
config.c:               route_add(&tip, htonl(tmask), fqdn, tcall, (flags | AXRT_FORCE_LEARN | (match_all_ssids ? AXRT_MATCH_ALL_SSIDS : 0)));
process.c:              if (route_add(ip_addr, 0xffffffffUL, 0, f, 0) < 0) {
process.c:fprintf(stderr, "debug: route_add %s failed\n", call_to_a(from_addr(buf)));
process.c:fprintf(stderr, "debug: route_add %s ok\n", call_to_a(from_addr(buf)));
routing.c:int route_add(ip, netmask, fqdn, call, flags)
...ax25ipd-test/ax25ipd$ 

The code I wrote is highly stable. But I personaly found the code quite
ugly: ax25ipd became a monster. That's the reason why it did not enter
the main stream yet.

From the example ax25ipd.conf:
[..]
# route <destcall> [<destaddr>|<network>] [udp dst-port] [flags]
#
# Users behind NAT routers may hav a different source-port.
#
# Valid flags are:
#         b  - allow broadcasts to be transmitted via this route
#         d  - this route is the default route
#         p  - permanent
#
#route vk2sut-0 44.136.8.68 b
#route vk5xxx 44.136.188.221 b
#route vk2abc 44.1.1.1
#route db0aaa 127.0.0.1 p
#route db0aab 10.1.2.3 udp 20005
# For dyndns hosts: IP may change, but resolving of the hostname
# has to point to the same IP address where IP frames come from.
# If flag "p" is set, the host is static (resolved once, on startup).
#route db0abc db0abc.de
#
# Autolearn new (not configured) hosts.
# Valid flags in this case: "b", "p" (learn once).
#route db0abc db0abc.de
#
# Autolearn new (not configured) hosts.
# Valid flags in this case: "b", "p" (learn once).
#route * 0.0.0.0/0 b
#route * 10.1.0.0/16
#route * 10.2.2.2/32
# accept db0yyy only when coming vom 10.3.3.0/24
#route db0yyy 10.3.3.0/24


At db0fhn, that ax25ipd version is used for various purposes:
root      2648  0.1  0.0   1692   240 ?        S    Aug19 262:49 /usr/sbin/ax25ipd --nofork -c /etc/ax25/ax25ipd-xnet.conf
root      3199  0.0  0.0   3488   732 ?        Ss   Aug19 101:58 /usr/bin/SCREEN -dmS ax25ipd -c /etc/ax25/ax25ipd.screen
root      3201  0.0  0.0   1692   248 pts/1    Ss+  Aug19  31:42 /usr/sbin/ax25ipd --nofork -c /etc/ax25/ax25ipd-pptpvpn.conf
root      3202  0.0  0.0   1696   252 pts/2    Ss+  Aug19  68:27 /usr/sbin/ax25ipd --nofork -c /etc/ax25/ax25ipd-openvpn.conf
root      3203  0.0  0.0   1696   272 pts/3    Ss+  Aug19 120:03 /usr/sbin/ax25ipd --nofork -c /etc/ax25/ax25ipd-echolink.conf
root      3643  0.0  0.0   1692   236 pts/4    Ss+  Aug19  15:45 ax25ipd --nofork -c /etc/ax25/ax25ipd-aprs-db0vox.conf
root      3644  0.0  0.0   1692   232 pts/5    Ss+  Aug19   2:12 ax25ipd --nofork -c /etc/ax25/ax25ipd-aprs-db0sao.conf
root      3645  0.0  0.0   1692   236 pts/6    Ss+  Aug19   3:16 ax25ipd --nofork -c /etc/ax25/ax25ipd-aprs-db0prt.conf
root      3649  0.0  0.0   1692   236 pts/7    Ss+  Aug19  11:33 ax25ipd --nofork -c /etc/ax25/ax25ipd-aprs-db0zka.conf


Btw, the dyndns feature which Bernard Pidoux f6bvp reminded to a few weeks ago
is still the my queue.
I've -mostly theoretical- problems with it because it resolves on a
periodical basis, which means that if the dns currently is broken,
it even affects LAN connections served by ax25ipd by introducing periodical
delays.
Bernard changed route_add(), as also my test-version does, but in a slightly
different way.
The test-code also implements periodical dyndns resolving, but iirc, it does
not work correctly (can't remember).

For informational purpose, I did a diff between the current cvs head
and the test version. The test-version startet on an older ax25ipd
version and only fixes but no cosmetic changes have been manually applied
(also i.e. still not the unix98 pty support). Here it is:
  http://db0fhn.efi.fh-nuernberg.de/~dl9sau/ax25ipd-current-to-test--2009-12-07.diff

73,
	- Thomas  dl9sau

Re: ax25ipd.c routing

[Cathryn Mataga]

> ax25ipd in it's current version does not learn routes.
> In fact, route_add() is only being called from the config file.
> .../ax25-apps/ax25ipd$ grep route_add *.c
> config.c:               route_add(tip, tcall, uport, flags);
> routing.c:void route_add(unsigned char *ip, unsigned char *call, int udpport,
> .../ax25-apps/ax25ipd$ 
> 
> That's why your packet goes out via the default connection (route K2PAR
> 2.0.0.0 d).
> 


Thank you.  This confirms my understanding of the current issue.


> 
> Btw, the dyndns feature which Bernard Pidoux f6bvp reminded to a few weeks ago
> is still the my queue.
> I've -mostly theoretical- problems with it because it resolves on a
> periodical basis, which means that if the dns currently is broken,
> it even affects LAN connections served by ax25ipd by introducing periodical
> delays.
> Bernard changed route_add(), as also my test-version does, but in a slightly
> different way.
> The test-code also implements periodical dyndns resolving, but iirc, it does
> not work correctly (can't remember).

Hmm.

What about this for both my and Bernard's issue.

1.  If a callsign is received from the ip of a known route
but is not the callsign of a known route, or the callsign
of the local station, then add this callsign
and the route pointer to a binary tree.  If the callsign
was previously in the tree, then the new route replaces
the old one, if different.
2.  in call_to_ip, before it checks the default route,
it checks this binary tree for this callsign, and returns the
route it came from.  If the callsign is not found, the default
route is used.
3.  Callsigns never expire.  The tree just grows.
4.  SSID's are matched as unique callsigns.
5.  If the callsign is that of a ddns route,
Fork, check dns, and if the ip matches the dns,
update the route_table_entry->ip_addr
6.  If a process is already forked for updating the ip of
a particular route, do not fork another one.  Add
a variable to route_table_entry to verify this.

Does this make sense?  Or are there other issues I'm unaware
of?


> 
> For informational purpose, I did a diff between the current cvs head
> and the test version. The test-version startet on an older ax25ipd
> version and only fixes but no cosmetic changes have been manually applied
> (also i.e. still not the unix98 pty support). Here it is:
>   http://db0fhn.efi.fh-nuernberg.de/~dl9sau/ax25ipd-current-to-test--2009-12-07.diff

Alright, thanks.  I'll take a look.

Re: ax25ipd.c routing

[Thomas Osterried]

Hello,

> What about this for both my and Bernard's issue.
>
> 1.  If a callsign is received from the ip of a known route
> but is not the callsign of a known route, or the callsign
> of the local station, then add this callsign
> and the route pointer to a binary tree.  If the callsign
> was previously in the tree, then the new route replaces
> the old one, if different.

yes. And if not set to "permanent" (p).

> 2.  in call_to_ip, before it checks the default route,
> it checks this binary tree for this callsign, and returns the
> route it came from.  If the callsign is not found, the default
> route is used.

yes.

> 3.  Callsigns never expire.  The tree just grows.

yes.

> 4.  SSID's are matched as unique callsigns.

call + same-ssid unique.
If you like to route i.E. ssid 0 to 15 permanently to a specific host,
it's only 16 lines. That's ok.

> 5.  If the callsign is that of a ddns route,
> Fork, check dns, and if the ip matches the dns,
> update the route_table_entry->ip_addr

No. Don't fork.
The best solution is a posix thread, which does periodicaly the resolving,
and to use a mutex-lock in the special case an IP address is currently being
looked up.

> 6.  If a process is already forked for updating the ip of
> a particular route, do not fork another one.  Add
> a variable to route_table_entry to verify this.

A single thread is sufficient.

73,
	- Thomas

Re: ax25ipd.c routing

[Ray Wells]

Hi,

Excuse me if I'm barking up the wrong tree.

I've been using ax25ipd for many years and haven't observed any routing 
problems.  For many years the system ran fbb (40 ports - ax25, rose and 
telnet) and fpacnode, as well as xastir (aprs).

I was a beta tester for some modifications implemented by vk5asf back in 
2005 and haven't used the stock sources since then. I know that f6bvp 
has also introduced some fixes. I always get my sources from the f6bvp 
web site.

Also, I don't remember how far back it was introduced, or by whom, but 
specifying an ssid of zero causes that route to respond to any ssid from 
that callsign. I used a mixture of generic (-0) and directed ssid's.

 >From my ax25ipd.conf.

route vk2tv-3 gizmo udp 10093 d
route vk2tv-8 gizmo udp 10093 b
route kp4djt-0 w4bgh.no-ip.org udp 10095 b
route k4gbb-9 k4gbb.serveftp.com udp 10093
route k4gbb-12 k4gbb.serveftp.com udp 10094
route k4gbb-14 k4gbb.serveftp.com udp 10093 b
route f6bvp-0 82.66.61.83 udp 10093 b
route gb7yb-0 62.49.59.169 udp 10093 b
route gb7ydx-1 gb7ydx.ath.cx udp 10093 b
#route kd4yal-0 kd4yal.servebbs.org udp 10093 b
route kd4yal-0 97.97.181.223 udp 10093 b
route f4bwt-0 62.147.157.243 udp 10093 b
route vk2dot-0 220.245.50.125 udp 93 b
route vk2xb-0 122.252.16.174 udp 10093 b
route vk7hdm-0 203.55.215.234 udp 93 b
route g3ldi-0 84.92.112.67 udp 10093 b
route ti2has-0 201.200.228.134 udp 10093 b
route w4min-0 74.174.224.115 udp 10093 b
route vk2wet-0 tankremote.no-ip.org udp 10093 b
#route vk2bvo 44.1.1.1

Ray vk2tv


Thomas Osterried wrote:
> Hello,
>
>   
>> What about this for both my and Bernard's issue.
>>
>> 1.  If a callsign is received from the ip of a known route
>> but is not the callsign of a known route, or the callsign
>> of the local station, then add this callsign
>> and the route pointer to a binary tree.  If the callsign
>> was previously in the tree, then the new route replaces
>> the old one, if different.
>>     
>
> yes. And if not set to "permanent" (p).
>
>   
>> 2.  in call_to_ip, before it checks the default route,
>> it checks this binary tree for this callsign, and returns the
>> route it came from.  If the callsign is not found, the default
>> route is used.
>>     
>
> yes.
>
>   
>> 3.  Callsigns never expire.  The tree just grows.
>>     
>
> yes.
>
>   
>> 4.  SSID's are matched as unique callsigns.
>>     
>
> call + same-ssid unique.
> If you like to route i.E. ssid 0 to 15 permanently to a specific host,
> it's only 16 lines. That's ok.
>
>   
>> 5.  If the callsign is that of a ddns route,
>> Fork, check dns, and if the ip matches the dns,
>> update the route_table_entry->ip_addr
>>     
>
> No. Don't fork.
> The best solution is a posix thread, which does periodicaly the resolving,
> and to use a mutex-lock in the special case an IP address is currently being
> looked up.
>
>   
>> 6.  If a process is already forked for updating the ip of
>> a particular route, do not fork another one.  Add
>> a variable to route_table_entry to verify this.
>>     
>
> A single thread is sufficient.
>
> 73,
> 	- Thomas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   

Re: ax25ipd.c routing

[Cathryn Mataga]

> Cathryn, do you have the possibility to do a packet-trace?
> 

Alright, here's a case where it doesn't work.  I connect to
my partner's system at gvcity.ampr.org. His callsign is KG6BAJ.
I log into his system via telnet with my call KE6I.  He's running
"Xrouter v186b".  I'm connected to 'port 6' on his system, so
I do the command.

C 6 KE6I-9

This is a trace from my side with stock ax25ipd.  His site
connects to mine using my call KE6I-15.  My side is trying
to send the packet back, but they're all going to the default
route, so it keeps trying and never gets a response.  On the
connecting side, I just see a timeout.  From gvcity.ampr.org
I never see the 'uronode' message.


axip: fm KE6I-15 to KE6I-9 ctl SABM+
axip: fm KE6I-9 to KE6I-15 ctl UA-
axip: fm KE6I-9 to KE6I-15 ctl I00^ pid=F0(Text) len 102
0000  URONode v1.0.7 - Welcome to XX#XX-#.Welcome KE6I in Berkeley Cal
0040  ifornia.  Type 'CONV' for live chat...
axip: fm KE6I-9 to KE6I-15 ctl I01+ pid=F0(Text) len 4
0000  .=>
axip: fm KE6I-15 to KE6I-9 ctl SABM+
axip: fm KE6I-9 to KE6I-15 ctl UA-
axip: fm KE6I-9 to KE6I-15 ctl I00^ pid=F0(Text) len 102
0000  URONode v1.0.7 - Welcome to XX#XX-#.Welcome KE6I in Berkeley Cal
0040  ifornia.  Type 'CONV' for live chat...
axip: fm KE6I-9 to KE6I-15 ctl I01+ pid=F0(Text) len 4
0000  .=>
axip: fm KE6I-15 to KE6I-9 ctl SABM+
axip: fm KE6I-9 to KE6I-15 ctl UA-
axip: fm KE6I-9 to KE6I-15 ctl I00^ pid=F0(Text) len 102
0000  URONode v1.0.7 - Welcome to XX#XX-#.Welcome KE6I in Berkeley Cal
0040  ifornia.  Type 'CONV' for live chat...
axip: fm KE6I-9 to KE6I-15 ctl I01+ pid=F0(Text) len 4
0000  .=>
axip: fm KE6I-15 to KE6I-9 ctl SABM+
axip: fm KE6I-9 to KE6I-15 ctl UA-
axip: fm KE6I-9 to KE6I-15 ctl I00^ pid=F0(Text) len 102
0000  URONode v1.0.7 - Welcome to XX#XX-#.Welcome KE6I in Berkeley Cal
0040  ifornia.  Type 'CONV' for live chat...
axip: fm KE6I-9 to KE6I-15 ctl I01+ pid=F0(Text) len 4
0000  .=>
axip: fm KE6I-15 to KE6I-9 ctl SABM+
axip: fm KE6I-9 to KE6I-15 ctl UA-
axip: fm KE6I-9 to KE6I-15 ctl I00^ pid=F0(Text) len 102
0000  URONode v1.0.7 - Welcome to XX#XX-#.Welcome KE6I in Berkeley Cal
0040  ifornia.  Type 'CONV' for live chat...
axip: fm KE6I-9 to KE6I-15 ctl I01+ pid=F0(Text) len 4
0000  .=>
axip: fm KE6I-15 to KE6I-9 ctl SABM+
axip: fm KE6I-9 to KE6I-15 ctl UA-
axip: fm KE6I-9 to KE6I-15 ctl I00^ pid=F0(Text) len 102
0000  URONode v1.0.7 - Welcome to XX#XX-#.Welcome KE6I in Berkeley Cal
0040  ifornia.  Type 'CONV' for live chat...
axip: fm KE6I-9 to KE6I-15 ctl I01+ pid=F0(Text) len 4
0000  .=>
axip: fm KE6I-15 to KE6I-9 ctl SABM+
axip: fm KE6I-9 to KE6I-15 ctl UA-
axip: fm KE6I-9 to KE6I-15 ctl I00^ pid=F0(Text) len 102
0000  URONode v1.0.7 - Welcome to XX#XX-#.Welcome KE6I in Berkeley Cal
0040  ifornia.  Type 'CONV' for live chat...
axip: fm KE6I-9 to KE6I-15 ctl I01+ pid=F0(Text) len 4
0000  .=>
axip: fm KE6I-15 to KE6I-9 ctl SABM+
axip: fm KE6I-9 to KE6I-15 ctl UA-
axip: fm KE6I-9 to KE6I-15 ctl I00^ pid=F0(Text) len 102
0000  URONode v1.0.7 - Welcome to XX#XX-#.Welcome KE6I in Berkeley Cal
0040  ifornia.  Type 'CONV' for live chat...
axip: fm KE6I-9 to KE6I-15 ctl I01+ pid=F0(Text) len 4
0000  .=>
axip: fm KE6I-15 to KE6I-9 ctl SABM+
axip: fm KE6I-9 to KE6I-15 ctl UA-
axip: fm KE6I-9 to KE6I-15 ctl I00^ pid=F0(Text) len 102
0000  URONode v1.0.7 - Welcome to XX#XX-#.Welcome KE6I in Berkeley Cal
0040  ifornia.  Type 'CONV' for live chat...
axip: fm KE6I-9 to KE6I-15 ctl I01+ pid=F0(Text) len 4
0000  .=>
axip: fm KE6I-15 to KE6I-9 ctl SABM+
axip: fm KE6I-9 to KE6I-15 ctl UA-
axip: fm KE6I-9 to KE6I-15 ctl I00^ pid=F0(Text) len 102
0000  URONode v1.0.7 - Welcome to XX#XX-#.Welcome KE6I in Berkeley Cal
0040  ifornia.  Type 'CONV' for live chat...
axip: fm KE6I-9 to KE6I-15 ctl I01+ pid=F0(Text) len 4
0000  .=>


I did make the change as I mentioned.  It's not too difficult
as most of the bits and pieces already exist in the test version.

In this case, the connection works because the return packets
go to the right place.   I see the 'uronode' message and am
able to disconnect without error.

axip: fm KE6I-15 to KE6I-9 ctl SABM+
axip: fm KE6I-9 to KE6I-15 ctl UA-
axip: fm KE6I-9 to KE6I-15 ctl I00^ pid=F0(Text) len 102
0000  URONode v1.0.7 - Welcome to XX#XX-#.Welcome KE6I in Berkeley Cal
0040  ifornia.  Type 'CONV' for live chat...
axip: fm KE6I-9 to KE6I-15 ctl I01+ pid=F0(Text) len 4
0000  .=>
axip: fm KE6I-15 to KE6I-9 ctl RR2-
axip: fm KE6I-15 to KE6I-9 ctl I20^ pid=F0(Text) len 2
0000  ?.
axip: fm KE6I-9 to KE6I-15 ctl I12^ pid=F0(Text) len 177
0000  Commands:.?, BBS, Bye, Connect, CONVers, Escape, Finger, Help, H
0040  Ost, Info.INTerfaces, Links, MHeard, MSg, Nodes, Ping, Quit, Rou
0080  tes, SEssions, Status.Telnet, Users, Version, Who
axip: fm KE6I-9 to KE6I-15 ctl I13+ pid=F0(Text) len 4
0000  .=>
axip: fm KE6I-15 to KE6I-9 ctl RR4-
axip: fm KE6I-15 to KE6I-9 ctl I41^ pid=F0(Text) len 2
0000  b.
axip: fm KE6I-9 to KE6I-15 ctl I24^ pid=F0(Text) len 24
0000  KE6I-15 de XX#XX-#.73!
axip: fm KE6I-9 to KE6I-15 ctl DISC+
axip: fm KE6I-15 to KE6I-9 ctl UA-

Here's my ax25ipd.conf file

socket ip
mode tnc
device /dev/ttyq7
#device /dev/ptyad
mycall KE6I-9
speed 9600
loglevel 4
broadcast QST-0 NODES-0
# route WH6IO 71.198.33.249
# route WH6IO-8 71.198.33.249 d
route WH6IO-8 75.106.121.56
route WH6IO 75.106.121.56
route AA6HF-4 44.17.0.128*
route AA6HF 44.17.0.128 d
route KG6BAJ-2 44.2.14.1
route KG6BAJ-1 44.2.14.1
route KG6BAJ 44.2.14.1


Stock ax25ipd works for all outgoing connections from Linux.  Also if
kg6baj connects to me from his system using his callsign it works
correctly because the return packets go back to him.  It's only the
users his system that have trouble connecting.  That's the problem
I see here.

Re: ax25ipd.c routing

[Cathryn Mataga]

http://www.mataga.net/mataga/ax25ipdke6i.diff

Here's a link to the change I made to ax25ipd.  This is a diff
versus the rc2 version.   It hasn't been tested that much,
but it does work for me.

It's pretty basic.  It reads ip addresses and callsigns
using code taken from the test version.  But then it stores the
matching route/Callsign in a btree, and uses this btree to
retrieve the correct ip during sending.  It does fix the issue
shown in the logs I created earlier.

It doesn't deal with the route IP's changing.  Currently, I just
print a message when this happens.  It only addresses the issue
of user callsigns.

Re: ax25ipd.c routing

[Cathryn Mataga]

http://hamradio.ke6i.com/ax25ipddyn.patch

I made another patch.  This one against 0.0.8.rc2 again.
This combines my original change with the dynamic DNS patch.

I know this is one of those 'big patches' that everyone hates,
so, sorry.  I tested this a bit, but I think I'll let this run
on my AX25 system for about a week before I try to make it official.

Mostly, I'm posting this in case anyone is curious.  This does
the change, as requested for the DNS patch, to make it use a
thread.  I use pthread_create to create the thread.  Also when
IP's are changed or referenced, the code uses pthread_mutex_lock
to protect the change.  I had to touch a few places in the code
for this.

This is my idea for the 'when to check dns' issue.

1.  If a packet comes in with the callsign of a listed route, that
does not match the expected IP, trigger a DNS lookup, provided
a DNS lookup has not happened within 5 minutes.
2.  Otherwise check DNS every hour.  60*60 seconds.
3.  If the 'P' flag is set never check DNS.

This is not really well-tested, though I have seen IP's update via DNS
in the log.  I believe that a packet should come in relatively soon
after an ip change and this should allow for a relatively quick
response.   The 5 minute delay is to prevent DNS from getting
hit too hard if a lot of these packets arrive.

The 1 hour check is a fallback, in the event that both systems are
set to Dynamic DNS, and both change at about the same time, or if
other mysterious circumstances occur.

I tried to save the idea of the original dyndns patch of checking DNS
later if DNS fails on startup. In this situation, I set the IP to 0.
A check is added to prevent packets from being sent to ip=0.

[PATCH] ax25ipd

[Cathryn Mataga]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

I've been sitting on this code for about a week, and it's
been running fine here.  I've made a few small changes, mostly
to the comments.

1. This patch adds the ability to route packets over axip
links that are not from the gateway callsign.

2.  Integrates the Dynamic DNS patch and uses mutex and
a thread as suggested.

3.   If DNS fails during startup for a route, the IP of a route is set
to 0. Then later, after about an hour or so, DNS for the
route is checked again.

4.  ax25ipd.conf has two new flags for routes.  l and p.

route KE6I-1 0.0.0.0 l

The route to KE6I-1 will be updated based on the IP
addresses of incoming packets.

route KE6I-2 ke6i.ampr.org p

the 'p' flag forces the code to not recheck DNS later for
this route.   If DNS fails at startup, however, DNS will
be checked until it succeeds, and then DNS will not be checked
again.


ax25ipd should route as before, except in the case when packets
not from the callsign of the route but from the same IP
would have gone to the default route, they now will go to the
ip from which they originate. (Ugh, that's an awkward sentence.)


Anyway, let me know what you think, good or bad.

[-- Attachment #2: ax25ipddyn.patch --]
[-- Type: application/x-itunes-itlp, Size: 18732 bytes --]

[PATCH] call.c

[Cathryn Mataga]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

This is a patch to call.c.  This is against ax25-apps-0.0.8-rc2.
Only one file is changed, call.c

1.  Now supports UTF8 or IBM850 as the encoding style over AX25.
1a.  Attention was paid to make sure that wide characters worked
with East Asian fonts.
2.  Now the screen can be resized.
correctly.   The program no longer crashes when it is resized.
3.  Added a scrollback buffer.  Use the up and down arrow keys
or the page up/page down keys to scroll through history.
After the screen begins scrolling, press 'up arrow' to view
history.
4.  Many visual quirks have been fixed.

I tested with East-Asian fonts myself, and I tested with
international latin characters by dragging from charmap.
My US keyboard has no Alt-GR key, so I'm not sure
how to type them directly here.   I've been using
this myself for the last week or so, and I can't
find anything wrong, but, you know how that goes.

I did check on gnome-terminal, and xterm, and also konsole.
It seems to behave about the same on all of these, though,
the keyboard is mapped slightly different with the number
pad with some terminal emulators.  This was compiled on
a Fedora 12 system everything updated by me.

This version is now dependent on iconv and wide character
versions of ncurses, which I think should be everywhere these
days.

[-- Attachment #2: callintl.patch --]
[-- Type: application/x-itunes-itlp, Size: 37496 bytes --]