* nr0 doesn't show up (netrom) [not found] <S1752195AbZK3HxQ/20091130075316Z+372@vger.kernel.org> @ 2009-11-30 20:38 ` Cathryn Mataga 2009-11-30 21:13 ` Cathryn Mataga 0 siblings, 1 reply; 14+ messages in thread From: Cathryn Mataga @ 2009-11-30 20:38 UTC (permalink / raw) To: Linux Hams Mailing list 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: nr0 doesn't show up (netrom) 2009-11-30 20:38 ` nr0 doesn't show up (netrom) Cathryn Mataga @ 2009-11-30 21:13 ` Cathryn Mataga 2009-11-30 21:48 ` Cathryn Mataga 0 siblings, 1 reply; 14+ messages in thread From: Cathryn Mataga @ 2009-11-30 21:13 UTC (permalink / raw) To: Linux Hams Mailing list 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" ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: nr0 doesn't show up (netrom) 2009-11-30 21:13 ` Cathryn Mataga @ 2009-11-30 21:48 ` Cathryn Mataga 2009-12-01 6:05 ` Cathryn Mataga 0 siblings, 1 reply; 14+ messages in thread From: Cathryn Mataga @ 2009-11-30 21:48 UTC (permalink / raw) To: Linux Hams Mailing list 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.) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: nr0 doesn't show up (netrom) 2009-11-30 21:48 ` Cathryn Mataga @ 2009-12-01 6:05 ` Cathryn Mataga 2009-12-07 10:30 ` ax25ipd.c routing Cathryn Mataga 0 siblings, 1 reply; 14+ messages in thread From: Cathryn Mataga @ 2009-12-01 6:05 UTC (permalink / raw) To: Linux Hams Mailing list 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* ax25ipd.c routing 2009-12-01 6:05 ` Cathryn Mataga @ 2009-12-07 10:30 ` Cathryn Mataga 2009-12-07 16:25 ` Thomas Osterried 0 siblings, 1 reply; 14+ messages in thread From: Cathryn Mataga @ 2009-12-07 10:30 UTC (permalink / raw) To: Linux Hams Mailing list 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ax25ipd.c routing 2009-12-07 10:30 ` ax25ipd.c routing Cathryn Mataga @ 2009-12-07 16:25 ` Thomas Osterried 2009-12-07 20:02 ` Cathryn Mataga 0 siblings, 1 reply; 14+ messages in thread From: Thomas Osterried @ 2009-12-07 16:25 UTC (permalink / raw) To: Cathryn Mataga; +Cc: linux-hams 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ax25ipd.c routing 2009-12-07 16:25 ` Thomas Osterried @ 2009-12-07 20:02 ` Cathryn Mataga 2009-12-07 20:26 ` Thomas Osterried 0 siblings, 1 reply; 14+ messages in thread From: Cathryn Mataga @ 2009-12-07 20:02 UTC (permalink / raw) To: Thomas Osterried; +Cc: linux-hams > 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ax25ipd.c routing 2009-12-07 20:02 ` Cathryn Mataga @ 2009-12-07 20:26 ` Thomas Osterried 2009-12-07 23:30 ` Ray Wells [not found] ` <4B1D84C4.8000206@exemail.com.au> 0 siblings, 2 replies; 14+ messages in thread From: Thomas Osterried @ 2009-12-07 20:26 UTC (permalink / raw) To: Cathryn Mataga; +Cc: linux-hams 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ax25ipd.c routing 2009-12-07 20:26 ` Thomas Osterried @ 2009-12-07 23:30 ` Ray Wells [not found] ` <4B1D84C4.8000206@exemail.com.au> 1 sibling, 0 replies; 14+ messages in thread From: Ray Wells @ 2009-12-07 23:30 UTC (permalink / raw) To: Thomas Osterried; +Cc: Cathryn Mataga, linux-hams 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 > > ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <4B1D84C4.8000206@exemail.com.au>]
[parent not found: <20091207235111.GS19524@x-berg.in-berlin.de>]
* Re: ax25ipd.c routing [not found] ` <20091207235111.GS19524@x-berg.in-berlin.de> @ 2009-12-08 1:45 ` Cathryn Mataga 2009-12-08 5:11 ` Cathryn Mataga 2009-12-08 22:15 ` Cathryn Mataga 2 siblings, 0 replies; 14+ messages in thread From: Cathryn Mataga @ 2009-12-08 1:45 UTC (permalink / raw) To: Thomas Osterried; +Cc: Ray Wells, linux-hams > 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ax25ipd.c routing [not found] ` <20091207235111.GS19524@x-berg.in-berlin.de> 2009-12-08 1:45 ` Cathryn Mataga @ 2009-12-08 5:11 ` Cathryn Mataga 2009-12-08 22:15 ` Cathryn Mataga 2 siblings, 0 replies; 14+ messages in thread From: Cathryn Mataga @ 2009-12-08 5:11 UTC (permalink / raw) To: Thomas Osterried; +Cc: linux-hams 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ax25ipd.c routing [not found] ` <20091207235111.GS19524@x-berg.in-berlin.de> 2009-12-08 1:45 ` Cathryn Mataga 2009-12-08 5:11 ` Cathryn Mataga @ 2009-12-08 22:15 ` Cathryn Mataga 2009-12-15 23:14 ` [PATCH] ax25ipd Cathryn Mataga 2 siblings, 1 reply; 14+ messages in thread From: Cathryn Mataga @ 2009-12-08 22:15 UTC (permalink / raw) To: Thomas Osterried; +Cc: linux-hams 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] ax25ipd 2009-12-08 22:15 ` Cathryn Mataga @ 2009-12-15 23:14 ` Cathryn Mataga 2009-12-25 11:35 ` [PATCH] call.c Cathryn Mataga 0 siblings, 1 reply; 14+ messages in thread From: Cathryn Mataga @ 2009-12-15 23:14 UTC (permalink / raw) To: Thomas Osterried; +Cc: linux-hams [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] call.c 2009-12-15 23:14 ` [PATCH] ax25ipd Cathryn Mataga @ 2009-12-25 11:35 ` Cathryn Mataga 0 siblings, 0 replies; 14+ messages in thread From: Cathryn Mataga @ 2009-12-25 11:35 UTC (permalink / raw) To: Thomas Osterried; +Cc: linux-hams [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-12-25 11:35 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <S1752195AbZK3HxQ/20091130075316Z+372@vger.kernel.org>
2009-11-30 20:38 ` nr0 doesn't show up (netrom) Cathryn Mataga
2009-11-30 21:13 ` Cathryn Mataga
2009-11-30 21:48 ` Cathryn Mataga
2009-12-01 6:05 ` Cathryn Mataga
2009-12-07 10:30 ` ax25ipd.c routing Cathryn Mataga
2009-12-07 16:25 ` Thomas Osterried
2009-12-07 20:02 ` Cathryn Mataga
2009-12-07 20:26 ` Thomas Osterried
2009-12-07 23:30 ` Ray Wells
[not found] ` <4B1D84C4.8000206@exemail.com.au>
[not found] ` <20091207235111.GS19524@x-berg.in-berlin.de>
2009-12-08 1:45 ` Cathryn Mataga
2009-12-08 5:11 ` Cathryn Mataga
2009-12-08 22:15 ` Cathryn Mataga
2009-12-15 23:14 ` [PATCH] ax25ipd Cathryn Mataga
2009-12-25 11:35 ` [PATCH] call.c Cathryn Mataga
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.