44net

44net@mailman.ampr.org

3194 discussions

Power outage
by Jerry Kutche 22 Jun '15

22 Jun '15

Today's power outage seems to have left my net 44 link DOA... If so I wanted everyone to know I may be back.. No time to fix right now.. Just spent over a week getting everything working after a virus attack. And was not really done still had two systems down.. Now I have this.. I need a break, also.. May pick this back up in July... May not. Anyone linked to me I will be back eventually.. Maybe Maybe not. But now I have to figure out a few things. Why does my Pi lose all its free space within 30 minutes of boot up. Went from 73% to 100% cannot connect to it without rebooting over and over... So until I feel like being a slave to linux and the PI I am off line. 73 Jerry N9LYA

6 8

K3MMB
by Brian 21 Jun '15

21 Jun '15

Does anyone know the status of K3MMB? His system appears to be offline and has been for a couple weeks or so. -- A computer once beat me at chess, but it was no match against me in kick-boxing - Emo Phillips 73 de Brian Rogers - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

1 0

Re: [44net] portal purge
by Rob Janssen 21 Jun '15

21 Jun '15

> Subject: > Re: [44net] portal purge > From: > Don Fanning <don(a)00100100.net> > Date: > 06/20/2015 01:40 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > There is so much cruft in the DNS tables > that I imported the information into a database and ran the FCC > database against it. There were roughly 1800 entries out of 3700-ish > that matched expired/cancelled/revoked callsigns. And that's just for > the US alone - not including active licensees who just lost interest > in 44net. As BrianK would point out, there is no way that the DNS > table should be this big. I do regular checks of the registered addresses in the 44.137.0.0/16 subnet against the list of callsigns published by our local authority. I also delete registrations when "silent key" announcements appear in the club magazine. And a few weeks ago I deleted all dangling MX and CNAME records, most of them for US hams. (see discussion on the list) It appears to have been standard practice to create MX records for new registered addresses, and to not delete them when addresses are deleted. Do you have valid "callsign change" tables in the US? A problem for me is that there is no official information on that from our authority, apparently for privacy reasons. So sometimes I delete an address because the callsign is no longer valid, to find later that the operator has changed to a higher license class or vanity callsign. And not everyone changing their callsign notifies me. Rob

4 5

Re: [44net] Model gateway system
by Rob Janssen 20 Jun '15

20 Jun '15

> Subject: > Re: [44net] Model gateway system > From: > Steve L <kb9mwr(a)gmail.com> > Date: > 06/19/2015 10:06 PM > > To: > "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu> > > > IPIP gateways should not use amprgw default route. > Ex: ip route add default dev tunl0 via 169.228.66.251 onlink .... That is incorrect. Such a route is OK as long as it is in an alternative routing table for AMPRnet traffic. It can be to amprgw or to a more local gateway. Such a route is required when you are on a source-address filtered internet connection and want to be reachable on your AMPRnet address from other internet systems. Rob

1 0

Model gateway system
by Michael E Fox (N6MEF) 20 Jun '15

20 Jun '15

So is the architectural debate over, or are people just tired of arguing? Frankly, there's been so much back and forth that I don't know what's expected any more. As I understand it, some nodes are on the IPIP mesh, some not. Some are reachable through amprgw, some not. What a mess. If the debate is over and there is consensus on a standard gateway architecture, then someone needs to publish it. I'm thinking the design should include a diagram of how to address the interfaces (which tunnels need AMPR addresses, which don't), where NATing occurs, what the ampr routing table should look like, what the ip rules should look like, etc. Otherwise, I guess it's up to each individual person to parse through the last 100 or so emails to figure out what they're going to do. Maybe I'll find time to do that . Someday. And folks wonder why there's not more participation . Michael N6MEF

3 2

portal purge
by Brian Kantor 19 Jun '15

19 Jun '15

At my request, we're cleaning out obsolete entries from the portal. A reminder is sent after 3 and 6 months with no login. A warning is sent after 9 months with no login. A notice is sent after 12 months with no login. After 15 months, the user, their network allocations, and any gateways belonging to them are deleted. At the current time, there are 3 gateways and 70 allocations to be so deleted. - Brian

8 20

Re: [44net] Model gateway system
by Steve L 19 Jun '15

19 Jun '15

IPIP gateways should not use amprgw default route. Ex: ip route add default dev tunl0 via 169.228.66.251 onlink .... IPIP gateways and the Wireless LAN's behind them will then be able to reach the BGP'd portions. I think that only leaves this scenario: BPG gateways and the wireless LAN's behind them will not be able to reach IPIP gateways and the LAN's behind them, as UCSD can't get a reply back to them. >From what I gathered Brian is seeking to hand off IPIP gateway destined traffic an intermediary ISP to fix this. Again from what I understand. The problem stems from a routing loop in the architecture at UCSD, when traffic leaves amprgw destine for a BGP'd chunk of the network. Others can correct me if I am wrong. Steve, KB9MWR ---- Quote ---- So is the architectural debate over, or are people just tired of arguing? Frankly, there's been so much back and forth that I don't know what's expected any more. As I understand it, some nodes are on the IPIP mesh, some not. Some are reachable through amprgw, some not. What a mess. If the debate is over and there is consensus on a standard gateway architecture, then someone needs to publish it. I'm thinking the design should include a diagram of how to address the interfaces (which tunnels need AMPR addresses, which don't), where NATing occurs, what the ampr routing table should look like, what the ip rules should look like, etc. Otherwise, I guess it's up to each individual person to parse through the last 100 or so emails to figure out what they're going to do. Maybe I'll find time to do that . Someday. And folks wonder why there's not more participation . Michael N6MEF

1 0

Re: [44net] AMPRNet Interoperability with BGP
by Rob Janssen 19 Jun '15

19 Jun '15

> Subject: > Re: [44net] AMPRNet Interoperability with BGP > From: > "Cory (NQ1E)" <cory(a)nq1e.hm> > Date: > 06/18/2015 11:59 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Bingo!!! There's the use-case I was missing in my head: > YourGWHost(Forcing44SourceIP) -> OtherIPIPLANs That is right! Note that this config was constructed for an all-in-one system that functions as the IPIP tunnel host, as a host for running services on AMPRnet (potentially reachable from all internet addresses), as a host to make outgoing connections to other amprnet systems, and as a general work machine for the owner (to browse, mail etc). The same browser session would automatically use the tunnels to reach other systems on AMPRnet, but it would use the direct path via the ISP for google and youtube. > The correct way to do that is obviously to tell the program you're using > that you want to bind to the specific 44 network interface. Forcing it to > happen for all traffic with a 44/8 destination is an easy workaround to > make that work, but as you can see it can have unintended consequences. Unfortunately this is not really practical. Sure you can set the source address on many common commandline utilities (like ping, telnet, traceroute, ftp) but not on many other networking programs like web browsers. Even an amateur radio oriented program like the Echolink client I use (QTEL) cannot set the source address. I made a request for enhancement for it, but that kind of thing had better be handled in a universal way. > > My recommended solution for those who want to be able to connect to as many > 44 nets as possible is: > Remove the 'to 44/8' rule and if you want to talk to a 44 host from a 44 > IP, use a host behind your gateway, not the gateway host itself. I have more or less done that already, as I now have a separate router between the host and the network, but even that does not solve this problem when that host again has to be on both networks. My main PC now has 2 addresses (each on a VLAN) to talk to the outside world, one is used (via NAT) to talk to internet, the other is 44.137.41.97 and is used when talking amprnet. But of course both can in fact communicate to any address, the decision which one to use is always a bit tricky. So my rule still is that "all traffic from my own subnet to anywhere, and all traffic from my hist to 44.0.0.0/8" is using the amprnet and goes out from 44.137.41.97 and without NAT, all other traffic is using the ISP internet and is NATted by the router. And again I have those "ip rules" in my system to achieve that: 0: from all lookup local 1: from all to 44.137.41.96/28 lookup main 44: from 44.137.41.96/28 lookup amprnet 44: from all to 44.0.0.0/8 lookup amprnet 32766: from all lookup main 32767: from all lookup default I am open to better solutions, as long as they are not "make sure that every program you use can bind an explicit local address". Of course now that I am behind a router the immediate problem of sending tunnel traffic to net-44 endpoints is no longer there, also because I am no longer directly on IPIP but only via our gateway, but still this source address selection issue remains. It may be that a suggestion I received from Jann can fully remedy the problem at least on a dedicated router/gateway. His approach is to make an unconditional rule that first sends the outgoing traffic through a table with only the IPIP tunnels. When that matches, the system will of course set the 44.x.x.x source address. Then, a rule follows that matches on "from 44.137.41.96/28" and refers to a table with only a default route pointing to the gateway (UCSD or another) that will forward the outside-44 traffic back to internet. Then finally everything else is looked up in the main routing table which has the default route going out via the ISP. I have not tested yet how well that works in practice. As mentioned, I no longer have the setup running that this config was originally created for. But it looks good. Rob

1 0

Re: [44net] AMPRNet Interoperability with BGP
by Steve L 19 Jun '15

19 Jun '15

I am in the same boat as Bob. Home connection with limited inbound speed. So the DNS filtering is nice. It also lets my wireless LAN end users easily decide if they want inbound internet connectivity or not (when that portion of the portal gets done) without having to get a hold of me to set a firewall rule for them. I also like the idea of other VPN technologies being an option. One being stateful for those in uncool firewall situations . Sometime back I though maybe one day there would be multiple regional portals (connected with BGP and all running the open portal code/web interface) where end gateways could connect using a couple different vpn technologies. I understand the problem at hand with the fragmentation between the BGP vs IPIP segments. Or I think I do, from my end I know hamwan is BGP connected and have problems reaching it: I use the AMPR RIPv2 daemon 1.11by Marius, YO2LOJ And it appears if the 44 address you are trying to reach isn't in the RIP list, like hamwan is, it defaults to route it to UCSD. That doesn't work for me, as you will see below. But when I override that, and tell it to go out eth0 like all non 44net traffic it then works. Or is there something special I can do in my configs to fix this? root@44.92.21.1:~# ip route show table 44 | grep 44.24 44.24.0.0/20 via 66.114.139.158 dev tunl0 proto 44 onlink window 840 44.24.10.0/24 via 192.231.186.20 dev tunl0 proto 44 onlink window 840 44.24.192.0/24 via 38.104.126.22 dev tunl0 proto 44 onlink window 840 44.24.194.0/24 via 216.161.250.189 dev tunl0 proto 44 onlink window 840 44.24.196.0/24 via 24.113.42.14 dev tunl0 proto 44 onlink window 840 root@44.92.21.35:~# ping hamwan.org PING hamwan.org (44.24.241.98) 56(84) bytes of data. >From ebu-3b-720-vl441-cse-sysnet-gw-222-1.ucsd.edu (137.110.222.1) icmp_seq=2 Time to live exceeded >From ebu-3b-720-vl441-cse-sysnet-gw-222-1.ucsd.edu (137.110.222.1) icmp_seq=3 Time to live exceeded ^C --- hamwan.org ping statistics --- 6 packets transmitted, 0 received, +2 errors, 100% packet loss, time 5002ms root@44.92.21.35:~# ping hambook.de.ampr.org PING hambook.de.ampr.org (44.225.56.138) 56(84) bytes of data. 64 bytes from hambook.db0sda.as64634.de.ampr.org (44.225.56.138): icmp_req=1 ttl=55 time=189 ms 64 bytes from hambook.db0sda.as64634.de.ampr.org (44.225.56.138): icmp_req=2 ttl=55 time=175 ms ^C --- hambook.de.ampr.org ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 175.383/182.595/189.808/7.225 ms ---- Quote ---- I appreciate especially the filtering out of 44 addresses who are not in the dns by ucsd. I hate to loose that when it goes to another ISP. I remember well the days when that extra garbage was not filtered out and I will hate it when that is lost. My gateway is presently just at a home connection with a static ip. I object when that stuff is moved and no filtering will be in place whatsoever. With other words: UCSD is working fine. So why is it that those BGP subnets have no mandatory IPIP entries in the list also? They don't have to route back over IPIP, only need to receive IPIP. Easy solution, nothing drastic, KISS, and done in no time.. Bob VE3TOK

10 18

(no subject)
by Steve L 19 Jun '15

19 Jun '15

That occurred to me after I sent my last message. Part of my startup script included this default route: ip rule add to 44.0.0.0/8 table 44 priority 44 So I commented that out, and then could reach hamwan.org, but wasn't able to reach hambook.de.ampr.org and other hosts. I also upgraded to ampr-ripd 1.13 If someone can reach both from their IPIP gateway I'd be most grateful if you'd share your startup script with me. Here is my script: http://www.qsl.net/kb9mwr/wapr/tcpip/startampr ---- Quote ---- NO GATEWAY SHOULD EVER HAVE A DEFAULT 44/8 ROUTE TO UCSD BECAUSE IT DOESN'T WORK AND IS POINTLESS. Marius, YO2LOJ

4 10

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net