- 44net - mailman.ardc.net

experimental LISP
by Jim Alles 16 Aug '13

16 Aug '13

Anybody that knows about BGP & GRE, I was wondering if this would be useful for us to look into (I am not that person). http://www.rfc-base.org/txt/rfc-6836.txt Jim A.

1 0

Re: [44net] rip44d update
by kb9mwr＠gmail.com 15 Aug '13

15 Aug '13

Michael, At this point, ampr-ripd (C implementation) is the best thing out there in my opinion. Hessu, wrote the rip44d, and that required Perl and a multicast package to run. So running this on a WRT54G, for instance was probably not going to happen. I'd like to think with the C implementation, this could be a reality. Also, I am not sure, but do think the C implementation stands the greatest chance to run cross platform. Hessu's perl one was kind of locked to Debian installs. Again, it's all so new, I personally haven't had they time yet to try it on a bunch of different platforms. I actaully am not sure why someone would go with amprd over ampr-ripd. Perhaps others can comment. Steve

2 1

(no subject)
by kb9mwr＠gmail.com 14 Aug '13

14 Aug '13

Here are some random thoughts: It would be interesting or maybe helpful if the ampr.org name server did some statistics collection. These stats could be used to help prune dead records? I am not sure how resource intensive that might be however. It looks like you can use Cacti in conjunction with BIND. It is also important that we have some idea what is on the amprnet, what it used for. The Michigan Digital Radio group has some basic activity polling : http://server1.nuge.com/~drg/network.html Perhaps even something that can be installed on gateways that promiscuously monitors well know ports/services, and can be configured to report activity to a central page? If nothing else can the gateway portion of the portal have some additional text boxes, so folks can explain things a bit more like the old resource.txt?

1 0

??? ignored packet on IPIP Tunnel
by Luc Pernot 14 Aug '13

14 Aug '13

There is a message showing on my RPI gateway 44.135.96.17 tunnel TTY0 saying "ignored packet from 44.131.160.1: 520: 504" every 5 minutes or so. any suggestion how to resolve this... Luc VE3JGL in Ottawa

4 4

Re: [44net] 44Net Digest, Vol 2, Issue 116
by Rob Janssen 13 Aug '13

13 Aug '13

> Subject: > Re: [44net] dd-wrt and ipip > From: > lleachii(a)aol.com > Date: > 08/13/2013 05:04 PM > > To: > 44net(a)hamradio.ucsd.edu > > > All, > > I think the reason that nodes on the 44 Network cannot reach me is that my router is not allowing connections from the Internet to pass through. > > My setup: > > Router 1 > WAN 76.114.216.250 <> LAN 192.168.x.x <> > > Router 2 > WAN 192.168.x.2 <> LAN 192.168.y.x > > AMPRGW > 192.168.y.5 > > In trying to setup IPTABLES commands to allow IPIP traffic, I've had no success thus far. > > On Router1: > iptables -t filter -I INPUT -p ipip -j ACCEPT > iptables -t filter -I FORWARD -p ipip -j ACCEPT > iptables -t nat -I PREROUTING -i vlan1 -p ipip -j DNAT --to-destination 192.168.x.2 > > On Router2: > > iptables -t filter -I INPUT -p ipip -j ACCEPT > iptables -t filter -I FORWARD -p ipip -j ACCEPT > iptables -t nat -I PREROUTING 1 -s 169.228.66.251 -p ipip -i vlan1 -j DNAT --to-destination 192.168.y.5 > iptables -t nat -I PREROUTING 2 -p ipip -i vlan1 -j DNAT --to-destination 192.168.y.5 > > Any ideas? > Your problem is the protocol number used for encapsulation, I think. The "ipip" protocol is protocol 94, the one that was registered mistakenly at a time when protocol 4, which does exactly the same, already existed. Now the protocol 4 is used, which is in /etc/protocols under its name "ip". So use -p ip or just -p 4. Rob

1 0

Cisco/juniper configs?
by Bryan Fields 12 Aug '13

12 Aug '13

Greetings, I've been doing some work to get the IPIP tunnel information into a router on a daily basis, has anyone else automated this? I was wondering how the reachability of this from the global routing table of the public internet works, if at all. Everything I've been reading says this is all separate, but we do interconnect at a couple locations. I must admit I'm new to this, but is 44/8 intended to be totally separate a la the GRX network? Granted my use of this space is for high speed wireless networks on the ham bands, I have little interest in the 9.6 kilobaud TCP/IP packet radio. I've got some of the 900MHz FHSS gear hacked to run in a narrower channel, and I've been experimenting with running some of the 5ghz units in the ham band at 5cm (5mhz channel is able to do about 10mbit/s). My intention is to have it all work across hardware routers, ie cisco/ALU/juniper rather than maintain a bunch of linux boxes. Thoughts? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

5 5

Trouble setting static route with ampr-ripd
by Neil Johnson 12 Aug '13

12 Aug '13

I've been trying add the following route to my "44" table to insure that local packets get sent out the wireless interface. ip route add 44.50.128.0/24 dev wlan0 table 44 However, I can't get it to be added when the system restarts. Any suggestions would be appreciated. Thanks. -Neil -- Neil Johnson -N0SFH http://erudicon.com

3 6

Re: [44net] Trouble setting static route with ampr-ripd
by Pieter Luteijn 11 Aug '13

11 Aug '13

When adding the route statement to the initialization sequence, make sure the wlan0 interface exists; don't put it too early in the sequence. Perhaps best to add it and its 'del' counterpart to the networking scripts that bring the wlan0 interface up and down, not to the rc-scripts? P. Sent from a mobile, sorry for any typoes... -------- Original message -------- From: Neil Johnson <neil.johnson(a)erudicon.com> Date: 2013/08/11 22:07 (GMT+01:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: [44net] Trouble setting static route with ampr-ripd ip route add 44.50.128.0/24 dev wlan0 table 44 However, I can't get it to be added when the system restarts.

1 0

SIP Service on AMPRnet
by Marc, LX1DUC 10 Aug '13

10 Aug '13

Dear YLs and OMs, I have installed a SIP service on sipwise.ampr.org. It allows SIP users to do voice & video calls, instant messaging (via SIP), screen sharing, etc. There is also support for voicemail, call forwarding and call forking (upto 5 user-agents (devices, softphones, etc) per account). The system accepts calls from outside, try sip:lx1duc@sipwise.ampr.org or sip:+883510001204400@sipwise.ampr.org. (I'm using iNUM numbers to provide a globally unique numeric identifier so that hardware phones can make calls to other stations as well, while it's possible to dial "lx1duc" from a numeric keypad, it's more convenient for the user to actually dial a number H-I-H-I.) I'm using it on my mobile via a softphone right now (I didn't have time to configure my hardware phone), but the plan is to use it on hardware phones in our club shacks in LX. You're welcome to test it and if you want/need your own account please contact me off-list. I'm also interested in peering with other SIP services as well, so if you're running one and you're interested in peering, please contact me off-list. 73 de Marc, LX1DUC

2 3

Why rip44d?
by Michael E. Fox - N6MEF 09 Aug '13

09 Aug '13

This is a serious question: Why is everyone so enamored with and focused on using rip44d? Rip44d disadvantages: 1) Rip44d depends on getting the routes from a single source - amprgw, i.e. a single point of failure. 2) If that single source fails (as it did recently, for more than 12 hours), then the routes are gone, even though all of the other gateways may be completely reachable. 3) If you try to avoid that problem by timing out the routes slowly, then you might as well have a static list. It seems to me that periodic downloading of the encaps file, followed by the ip.munge scripts is a far better approach. Advantages: 1) You can define how often you want to download the file, based on how quickly you want to discover new gateways. For me, once nightly is fine. But it could be more often. 2) If the download of encaps fails, I continue using the same routes I had before until the next download attempt. This happens every once in a while - maybe once a month, for whatever reason. But no connectivity is lost. 3) If amprgw fails, the direct tunnels to all other gateways are unaffected. i.e. Single point of failure eliminated. Disadvantages: None that I can see. So I fail to see why everyone is so enamored with rip44d. Please explain. Thanks much, Michael N6MEF

9 10

bad ip address?
by Don Moore 09 Aug '13

09 Aug '13

Whoever is operating (if valid) 176.9.140.86 name = ampr-gw.fks-de.ham.lu please cease and desist sending data using the following encap line. 11:30:13.339166 IP 176.9.140.86 > 192.168.1.150: IP 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 115 (ipip-proto-4) 73, Don - ve3zda

2 1

FW: Ampernet
by Kutche, Jerry (Mitchell) USA 09 Aug '13

09 Aug '13

fyi Looks like we have a another software available that can participate in the Amprnet! coming online soon.. :) 73 Jerry N9LYA Subject: Re: Ampernet On 09/08/13 04:28, Rod McCosker wrote: Paula, We are back from Queensland & XR32 Version D [Alpha Testing] - now works as my Ampernet Gateway 44.136.16.2 - with TinyXP We have to update the Ampernet registery with a few new local entries. There are no AXUDP or IPUDP links setup from the Gateway, only the ENCAP.TXT file It looks like - We may not have a seperate gateway laptop, but integrate the gateway into the main XR32, Will have to think about this. However from VK2DOT-3 the Gateway XR32, we can connect via Ampernet to - ZL2AQY 44.147.38.42 VK6HGR 44.136.204.77 N9LYA 44.48.0.46 regards rod..../// Hi Rod, Are we any closer to seeing the new version ? Regards ..... Peter

2 1

Re: [44net] "Invalid Gateway Address"
by Pieter Luteijn 09 Aug '13

09 Aug '13

How are you trying to use this address? Could it be that your inadvertantly trying to set your default gateway to this address. An off-subnet default gateway is usually 'invalid'.. P. Sent from a mobile, sorry for any typoes... -------- Original message -------- From: Neil Johnson <neil.johnson(a)erudicon.com> Date: 2013/08/08 22:11 (GMT+01:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: [44net] "Invalid Gateway Address" When I try to add it, it says "Invalid Gateway IP Address" Neil Johnson -N0SFH

3 2

"Invalid Gateway Address"
by Neil Johnson 08 Aug '13

08 Aug '13

I just received a static IP from my ISP, but I can't use it for a gateway. When I try to add it, it says "Invalid Gateway P Address" The address is 108.160.233.78. Does it have to be pingable ? Any ideas ? -- Neil Johnson -N0SFH http://erudicon.com

1 0

Re: [44net] Why rip44d?
by Brian Kantor 07 Aug '13

07 Aug '13

Seems to me that encap routes learned by rip44 should be fairly persistant - I'd say they shouldn't expire for a day or three or more. Perhaps a week? Unless replaced by a newer route for the same subnet, of course. That way if the rip sender (amprgw) should happen to go away for a while, things will still function. And you'd have time to switch over to using the encap file if the outage were to be prolonged. There's no harm in having a dormant route in your table for a while when a gateway permanently goes away. What's the maximum rip44 route expiration time setting? You could, of course, decide to NEVER expire them. With daemon modification, they could be persistent across reboots and only purged when manually selected. - Brian

3 4

rip44d / kernel multicast support
by Heikki Hannikainen 07 Aug '13

07 Aug '13

I think the lack of multicast support in some Linux kernel builds makes the Perl rip44d fail for some users. Linux 2.6 certainly supports multicast, it's been in the kernel for a long while (at least in kernel 1.2 it was there, and probably before that). Some distributions apparently haven't compiled in the multicast code. If you're having problems with rip44d not receiving RIP packets, and you're not one of those having a NAT/DMZ router of some sort in front of the gateway, please check if your kernel has multicast enabled: http://unix.stackexchange.com/questions/25872/how-can-i-know-if-ip-multicas… I can probably add raw socket support to rip44d, mimicking what Marius did in his C version, to work around it, if this is indeed a problem. One alternative is to run the C daemon on those systems, of course! - Hessu, OH7LZB On Tue, Aug 6, 2013 at 2:08 AM, Brian Rogers <n1uro(a)n1uro.ampr.org> wrote: > On Sat, 2013-08-03 at 11:46 +0300, Marius Petrescu spake: >> I added an option to use raw sockets instead of multicast to the daemon. >> This is needed on systems that do not support multicast properly. >> On system where it works, there is no need to upgrade. > > Thank you Marius - it's definately now doing what it needs to do! Good > job! With my 10 yr old system running a P-III I'm lucky to have a circa > 2009 setup running. I don't know why on earth though this 2.6 kernel > doesn't support multicast.

10 20

Running on RPi. Still got issues
by Mark Phillips 06 Aug '13

06 Aug '13

Hi folks, So I was able to compile Maiko's latest JNOS code for my RPi and it appears to function correctly. I have one of John Hansen's TNC-Pi's which also seems to work using the I2CKISS stuff. I have the AGW remote modem stuff working. I was even able to get the encap stuff working via my pFsense FW with the aid of this rather useful posting http://forum.pfsense.org/index.php?topic=64060.0 and the encap.txt file. However, whilst I'm receiving UCSD's RIP broadcasts at my FW they are not making it through to JNOS. I've tried forwarding UDP port 520 however that does not seem to work as pFsense traps the RIP session as an IPIP session. This further confuses me as IPIP sessions are correctly sent to JNOS per the above. I have also tried activating the RIP daemon in pFsense and then getting JNOS to ask for a RIP update but that doesn't seem to work either. Ideas? Thanks Mark, G7LTT/NI2O Randolph, NJ

2 1

Thanks IP GURUS
by Demetre SV1UY 06 Aug '13

06 Aug '13

Hi all, KUDOS to all IP Gurus who helped me reinstall our ATHnet AMPRnet GATEWAY in Athens, Greece. Special thanks to Marc, Tom, Brian N1URO and Brian Kantor whose comments and WEB PAGES helped. An easy iptables script would also be a good help to us but I think that I am OK at the moment using UFW and also Brian N1URO's ideas on how to allow IPIP in my LINUX box using 3 IPTABLES commands I found in his WEB PAGES/POSTINGS. Thanks a lot guys. Your help is much appreciated! -- 73 de SV1UY Demetre Ch. Valaris IP Coordinator for AMPRnet in Greece e-mail: demetre.sv1uy(a)gmail.com Radio e-mail: sv1uy(a)winlink.org (to use my radio e-mail put //WL2K in the beginning of the subject line) http://www.qsl.net/sv1uy

4 3

Re: [44net] Tunnel issues with rip44d
by Pieter Luteijn 05 Aug '13

05 Aug '13

By default rip44d is using the interface tunl0, it seems: my $tunnel_if = 'tunl0'; You seem to be using tun0 in your networking scripts, so i suppose you either need to adjust the default, use the -i option to change the interface used by rip44d, or change the tunnel interface name to match so the rip44d is listening on the right interface. Pieter. Sent from a mobile, sorry for any typoes...

8 10

rip44d problem
by Demetre SV1UY 05 Aug '13

05 Aug '13

Hi all, After running ripp44d for about I see in my routing table that my own subnet 44.154/18 is routed to 87.202.40.155 (my ADSL router's dynamic IP) via tunl0 interface. Is this right? -- 73 de SV1UY Demetre Ch. Valaris IP Coordinator for AMPRnet in Greece e-mail: demetre.sv1uy(a)gmail.com Radio e-mail: sv1uy(a)winlink.org (to use my radio e-mail put //WL2K in the beginning of the subject line) http://www.qsl.net/sv1uy

5 9

Anyone know who's using .....
by Mark Phillips 03 Aug '13

03 Aug '13

44.64.192/24 44.64.193/24 I noted that these networks were in the gateways encap list. It would be nice to know whom has them so that I can update my NJ co-ordinator records. Thanks Mark NI2O

3 2

Gateway updates
by Neil Johnson 03 Aug '13

03 Aug '13

How long does it take after updating a gateway for it to take effect ? Just curious. -Neil -- Neil Johnson -N0SFH http://erudicon.com

2 1

Re: [44net] 44Net Digest, Vol 2, Issue 107
by Rob Janssen 03 Aug '13

03 Aug '13

> Subject: > Re: [44net] IP address management > From: > Mark Phillips <g7ltt(a)g7ltt.com> > Date: > 08/02/2013 10:57 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > TeemIP > > > Me like!!!! > > Might grab this for use at work. > > Mark Indeed, this looks like what we need as a module within portal.ampr.org! And it saves a lot of work to have something like this. Rob

1 0

IP address management
by Rob Janssen 02 Aug '13

02 Aug '13

> Subject: > Re: [44net] question regarding amprgw.sysnet.ucsd.edu > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 08/01/2013 03:25 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Wed, Jul 31, 2013 at 06:16:32PM -0700, Blaine Forbort wrote: >> >My DNS request is still waiting for coordinator approval. I guess I'll >> >be waiting for that until I can finish off this first step of my >> >experiment. > Does that mean that you submitted it via the portal.ampr.org DNS > function? I'm sorry, that function isn't working yet. I've asked > for it to be taken off the portal menu until it*is* working as it > confuses people. It also needs to be discussed what functionality is required here for both the users and the coordinator. Sometimes I get requests for approval, and I just looked in the portal.ampr.org again, but it does not really cover the requirements. What we need is a request from a user to get one or more addresses allocated, accompanied by information like region where they live. The coordinator then must be able to look into the already assigned list of addresses and find an available address in the correct region (subnet), assign it, and return the address to the requester. As it is now, I get requests for 44.137.0.0/16 which makes little sense. Until now I have a hosts file and I make the assignment by browsing through it in the editor, and copy/pasting a line. Then I send the corresponding update to the ampraddr robot. How can we do this in the portal when we abandon the hosts files? Rob

6 6

Re: [44net] gateways sunset
by kb9mwr＠gmail.com 02 Aug '13

02 Aug '13

Neil, Can you share these scripts or the links to what you used as a base. I can see myself doing this once the DNS part of the portal is functional. Steve, KB9MWR WI/Upper MI Coordinator ---- Quote ---- Having just volunteered as a coordinator for the state of Iowa (44.50.0.0/16). I went through the amprhost file and: - Pulled out all the IP address entries for the state. - Manually pulled out the call signs from the host names. - Modified a python script I found on github ( called qrz.py) to get as many email addresses as I could from qrz.com, - Used another python script to send a nicely formatted e-mail to each user asking them to register their IP on the portal or tell me if they no longer needed it. Stated in the e-mail that if I didn't hear from them in 90 days. I would reclaim their allocation. - The plan is to send a reminder email at 60, 30, and 7 days. I'm not sure what I will do with those call signs that don't have e-mails associated with them (56 out of 175). Possibly send a post card ? Of the 119 e-mails I sent, I've received 27 responses so far. 20 saying I can reclaim their allocation, and 7 requests through the portal. The previous volunteer did a wonderful job of dividing up the state into regions, sub-regions, and cities, but assumed there would be only one gateway per city. I'll have to understand the existing network topology and see if I can fit them into new subnet boundaries. -Neil

2 1

Re: [44net] question regarding amprgw.sysnet.ucsd.edu
by lleachii＠aol.com 02 Aug '13

02 Aug '13

Blaine, Here are some tools that may be helpful to you in the future for troubleshooting: http://kb3vwg-010.ampr.org/tools/ping/php-ping.php http://kb3vwg-010.ampr.org/tools/trace/php-trace.php http://whatismyip.ampr.org/ http://speedtest.ampr.org/ DNS: dns-mdc.ampr.org (44.60.44.3 kb3vwg-003.ampr.org) Also, I cannot ping you, but traceroue is working: traceroute to 44.4.36.1 (44.4.36.1), 30 hops max, 60 byte packets 1 kb3vwg-001.ampr.org (44.60.44.1) 0.480 ms 0.924 ms 0.889 ms 2 k1qv.ampr.org (44.4.36.1) 91.696 ms 95.844 ms 100.637 ms -Lynwood KB3VWG

3 5

Отн.: Re: ipip tunnel
by Miroslav Nikolov 02 Aug '13

02 Aug '13

2 hurs after my message all to this ip group is Ok. 73, LZ4NY Изпратено от Samsung Mobilelleachii(a)aol.com написа:(Please trim inclusions from previous messages) _______________________________________________ Miro LZ4NY, No problems on my side; is your AMPR firewall blocking ICMP - Echo Reply? > ip route get 44.185.1.1 44.185.1.1 via 109.107.73.62 dev tunl0 src 172.31.255.254 traceroute to 44.185.1.1 (44.185.1.1), 30 hops max, 60 byte packets 1 kb3vwg-001.ampr.org (44.60.44.1) 0.380 ms 0.202 ms 0.108 ms 2 lz4ny.ampr.org (44.185.1.1) 128.304 ms 132.677 ms 137.805 ms PING 44.185.1.1 (44.185.1.1) 56(84) bytes of data. 64 bytes from 44.185.1.1: icmp_req=1 ttl=63 time=130 ms 64 bytes from 44.185.1.1: icmp_req=2 ttl=63 time=128 ms 64 bytes from 44.185.1.1: icmp_req=3 ttl=63 time=131 ms 64 bytes from 44.185.1.1: icmp_req=4 ttl=63 time=133 ms --- 44.185.1.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 128.803/130.923/133.714/1.804 ms -Lynwood KB3VWG _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html

1 0

gateways sunset
by Brian Kantor 01 Aug '13

01 Aug '13

As many of you know, when we set up the portal and moved the gateways maintenance to it, we imported the legacy gateways file which included a significant number of dormant or abandoned gateway entries. Since then we've requested that people operating gateways "take possession" of them by registering their active gateways. I believe the time has come to flush all the gateway entries which have not been registered -- clearly by now if they're not registered they must be abandoned. So I propose that we use the month of August to get the last of the active gateways registered with the portal, and after the last day of the month we remove all unregistered gateways from the gateways files. What will remain are the gateways that are still active and being operated by somebody. This should make the tunnels routing table a bit smaller. Comments? - Brian

6 6

ipip tunnel
by lz4ny＠mail.bg 01 Aug '13

01 Aug '13

Hi, Who is problem ? If ping (or open) to whatismyip.ampr.org (44.60.44.12) direct from internet all is ok , if ping via IPIP (RIP44d update) tunnel from 44.185.1.1 is not ping. To Germany - ampr or Romania -ampr network proble is not. 73, Miro LZ4NY ------------------------------------- Завладей лятото със СуперХостинг.БГ! Само сега 50 GB пространство и неограничен трафик за 6,25 лв. на месец! http://www.superhosting.bg/SummerPromo2013/?utm_source=Mail.BG&utm_medium=S…

1 0

Re: [44net] gateways sunset
by Rob Janssen 01 Aug '13

01 Aug '13

> Subject: > [44net] gateways sunset > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 08/01/2013 03:54 AM > > To: > 44net(a)hamradio.ucsd.edu > > > As many of you know, when we set up the portal and moved the gateways > maintenance to it, we imported the legacy gateways file which included > a significant number of dormant or abandoned gateway entries. > > Since then we've requested that people operating gateways "take > possession" of them by registering their active gateways. > > I believe the time has come to flush all the gateway entries which have > not been registered -- clearly by now if they're not registered they > must be abandoned. > > So I propose that we use the month of August to get the last of the > active gateways registered with the portal, and after the last day of > the month we remove all unregistered gateways from the gateways files. > What will remain are the gateways that are still active and being operated > by somebody. This should make the tunnels routing table a bit smaller. Would it be possible to add the gateway status (actively registered or only imported) somehow in the gateway list? And maybe to list gateways with a subnet within the assigned address range for a coordinator? If so, I could try to contact the gateway operators in my range to get them to register or abandon their gateway entry. Rob

1 0

question regarding amprgw.sysnet.ucsd.edu
by Blaine Forbort 01 Aug '13

01 Aug '13

Hi all, I've just set up my net44 gateway using a Debian machine running in the cloud with a static IP. My plan is to use this machine as an IPIP-to-OpenVPN adapter so that I can run my subnet from home via my LTE connection, with will not support IPIP. I set up the machine with Debian linux and rip44d. I'm currently receiving the routing table from 44.0.0.1, and I'm able to ping several net44 machines in my area (44.4.2.153 and 44.4.50.1 for example), however, my linux machine is not able to ping 44.0.0.1. At first I assumed that this was a security policy, however, I'm also not able to access the ampr.org website from that machine now. in addition, I'm unable to ping my machine's net44 address from the internet. Is this a result of gw.ampr.org not updating it's gateway list, and thus not knowing how to route to me, or have I missed something obvious? Also, if anyone with a properly maintained gateway list could ping me at 44.4.36.1 and let me know the result, I'd appreciate it. Thank you, Blaine -- Blaine Forbort, K1QV Vallejo California

6 12

Re: [44net] gateways sunset
by kb9mwr＠gmail.com 01 Aug '13

01 Aug '13

I am okay with that. When or is someone working on cleaning the DNS up next? Someone mentioned the idea of sorting hosts that are theoretically reachable via a tunnel. Then possibly purging ones that are not, or at least further review of these. I gave it a quick try before, as it seemed simple enough. Look at the encap.txt file, look for hosts in each CIDR... (checking this file: ftp://hamradio.ucsd.edu/pub/amprhosts.) A quick google search yielded this nifty function that is the magic to the whole thing http://stackoverflow.com/questions/594112/matching-an-ip-to-a-cidr-mask-in-… http://pastebin.com/rbFuTeVi It's not quite working, maybe someone who knows more can fix it? If no one else is working on this, and it would seem helpful, please let me know, and I'll try and devote some time to it again. Steve, KB9MWR

3 2

Re: [44net] ampr.org DNS name add and update ?
by Wm Lewis 31 Jul '13

31 Jul '13

Hello Miro: Your local Coordinator can set that up for you. > Hello, > How can you add a name ampr.org as lz4ny.ampr.org be directed to IP > 44.185.1.1 tried by portal.ampr.org but it does not. > We will be happy to direct me where I can find more detailed information about the entry of names in ampr.org or setup dns server in Debian can add and edit names zone Bulgaria - 44.185.xx > > > 73, Miro, LZ4NY

1 0

ampr.org DNS name add and update ?
by lz4ny＠mail.bg 31 Jul '13

31 Jul '13

Hello, How can you add a name ampr.org as lz4ny.ampr.org be directed to IP 44.185.1.1 tried by portal.ampr.org but it does not. We will be happy to direct me where I can find more detailed information about the entry of names in ampr.org or setup dns server in Debian can add and edit names zone Bulgaria - 44.185.xx 73, Miro, LZ4NY ------------------------------------- Mail.BG: Безплатен e-mail адрес. Най-добрите характеристики на българския пазар - 20 GB пощенска кутия, 1 GB прикрепен файл, безплатен POP3, мобилна версия, SMS известяване и други. http://mail.bg

1 0

amprgw bandwidth
by Neil Johnson 30 Jul '13

30 Jul '13

Brian, How much bandwidth do you see coming from the Internet to amprgw on a daily basis ? Thanks. -Neil -- Neil Johnson -N0SFH http://erudicon.com

1 0

Re: [44net] Distributed BGP Announce
by Rob Janssen 29 Jul '13

29 Jul '13

> Subject: > Re: [44net] Distributed BGP Announce > From: > Brian D Heaton <ky9k-lists(a)ky9k.org> > Date: > 07/29/2013 05:54 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > My experience is with Cisco's "ip tcp adjust-mss xxx". It works 100% in all cases I've seen. Some very large deployed networks use that functionality. The only times we have issues is when folks remove that statement thinking it is redundant to > MTU size. (We set both) > > 73-KY9K/Brian > > > On 7/25/2013 8:59 AM, Marc, LX1DUC wrote >>> Also as it only really efficts TCP, I solve it on my GRE tunnels with >>> ip tcp adjust-mss 1436 in cisco >>> set interface $interface ip tcp adjust-mss 1436 in juniper >>> tcp-mss-adjust 1436 under an SDP config in Alcatel-Lucent >> >> What is your experience with that setup? Does it always (99.999% :-D) work? If so, count me in an let's go with it. >> >> 73 de Marc, LX1DUC I probably invented that :-) I introduced it into my version of NET (derived from KA9Q NET) in august of 1995, to avoid the fragmentation that frequently occurred when forwarding IP datagrams over NET/ROM transport. In my version, the MSS was automatically calculated from the MTU of the incoming and outgoing interface in the IP routing code. It worked very well. (MTU discovery did not exist back then) In 2001, Cisco introduced it in IOS and I realized I should have patented it :-) From changelog: PE1CHL.950819: TCP SYN packets are examined when routed, and the MSS option will be adjusted down to the maximum MSS possible on the incoming and outgoing interfaces. Thus, a more optimal end-to-end MSS is chosen, and fragmentation is avoided (e.g. when running IP over NET/ROM somewhere inbetween the endpoints) Rob

2 1

On The Air
by Bill Vodall 29 Jul '13

29 Jul '13

So how are folks actually making use of all this nifty routing technology on the air with Amateur Radio these days? I don't remember the last time I've seen an "ampr.org" email address here on the list. I kinda remember the last time I had one that worked... Bill

15 23

Re: [44net] Distributed BGP Announce
by Bryan Fields 28 Jul '13

28 Jul '13

On 7/25/13 2:59 AM, Marc, LX1DUC wrote: > By defautl GRE provides an Layer3 MTU of 1476 bytes. How will you cope > with packet fragmentation or in case DF=1 with ICMP type=3 code=4 (The > datagram is too big. Packet fragmentation is required but the 'don't > fragment' (DF) flag is on.) filtering. Yes, but this is why we have PMTUD. It works fine so long as ICMP is not blocked. If ICMP is blocked, then some one along the path needs to get some clue. I've only encountered this on private networks (LAN's, and packet cores where IT runs it). Generally it's fixed with me screaming "YOU'RE BREAKING THE INTERNET STUPID!" ;) Also as it only really efficts TCP, I solve it on my GRE tunnels with ip tcp adjust-mss 1436 in cisco set interface $interface ip tcp adjust-mss 1436 in juniper tcp-mss-adjust 1436 under an SDP config in Alcatel-Lucent 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

3 2

Receiving routes with conventional RIP
by Neil Johnson 28 Jul '13

28 Jul '13

Is it possible to get the IPIP routes delivered by conventional routing protocols (RIP, OSPF, etc) rather than running a custom daemon ? Just curious. -Neil -- Neil Johnson -N0SFH http://erudicon.com

6 8

Tunnel issues with rip44d
by Neil Johnson 27 Jul '13

27 Jul '13

I can't seem to get rip44d to hear the routes. I'm sure I'm doing something dumb. Here is my /etc/networking/interfaces configuration: # Tunnel to amprnet auto tun0 iface tun0 inet static address 44.50.128.1 netmask 255.255.255.0 broadcast 44.50.128.255 pre-up iptunnel add tun0 mode ipip local 128.255.134.47 post-down iptunnel del tun0 If I run tcpdump on the tun0 interface I can see the routes coming down, but when I run rip44d it never hears them. I did I miss. I'm running ubuntu 12.04 LTS. Thanks. -Neil -- Neil Johnson -N0SFH http://erudicon.com

2 3

Why is Linux box necessary?
by YT9TP op. Pedja 27 Jul '13

27 Jul '13

Hi, First time posting on this list. I am new to AMPRNet and actually still struggling to make gateway. I realized that I have to download encap file with route definitions and load them into my gateway router so my networks sees all other networks in 44/8. It is suggested that I have to get up Linux box that will do the gateway job. Thing is, I want to use Mikrotik router that I already have in use, and which handles my network. I do not need another box just to play gateway. I do not understand why standard dynamic routing protocol is not used in first place, so we would not have this issue at all as all routers are capable of dynamic routing?!?! I noticed that there is a script made by Marius, YO2LOJ, that reads encap file and then sets Mikrotik up to it. But, to run that script I again need Linux box. I noticed there are other scripts that do the same for other kind of routers. I guess there are number of fellow hams that would like to use already set router and not additional Linux box. Why then such scripts are not run at portal.ampr.org so we can, besides encap file, download prepared files for popular routers, so we do not need to make conversions for ourselves? If such download is provided, I would be able make Mikrotik itself to download file and run it to set routes. I would not need additional Linux box to do that. That would make whole process simpler, easier to implement and even cheaper (in manner not just money, but efforts, physical space, maintenance...) and that could motivate more people to get involved. If resources on portal.ampr.org are limited, mirror copies of those files could be easily established to prevent problems. YT9TP Pedja

10 13

Re: [44net] Distributed BGP Announce
by Bryan Fields 26 Jul '13

26 Jul '13

On 7/25/13 1:40 PM, Marc, LX1DUC wrote: > However I'm not sure I'm able to provide an IS-IS capable router for > the trial... A Juniper O-series might work ;) I think the 2811s from cisco are cheap enough now (under 400 on ebay). The issue with cisco is you need some one to get the code for you now that they've locked down the CCO site. I'd love to use ALU gear, but it's just to expensive on the used market. But this is all just discussion on how we wan to do it at this point. We'll need some detailed proposals and come to a conciseness on it. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

3 6

Newbie issue
by lleachii＠aol.com 26 Jul '13

26 Jul '13

Marc, LX1DUC, Per Brian in a Jan 22 note: 44.0.0.1 responds to pings received from the Internet. It does not respond to pings coming into it over an encap connection to it, for some reason that I've not been able to figure out. I believe it to be a difficulty in getting it to recognize decapped pings. If you are receiving the rip44 announcements, you have properly configured your tunnel to receive IP-in-IP encapsulation from 44.0.0.1. Feel free to use: http://44.60.44.10/tools or http://kb3vwg-010.ampr.org/tools I see your encap as: 44.161.202.0 via 46.29.183.253 dev tunl0 onlink window 840 44.161.203.0 via 46.29.183.253 dev tunl0 onlink window 840 44.161.229.0 via 46.29.183.253 dev tunl0 onlink window 840 Also, I am unable to ping 44.161.229.126. What script/configuration did you use to enable your tunnel; did you specify a local or remote IP (un-needed)? Feel free to look at my script at http://44.60.44.13/startampr 73, Lynwood KB3VWG

15 65

TAPR/ARRL DCC 2013
by Brian Kantor 26 Jul '13

26 Jul '13

Any of you folks planning on attending the TAPR/ARRL Digital Communications Conference in Seattle this September? <http://www.tapr.org/dcc/> I hope to be there. - Brian

4 3

Services That Can Run on 1K2/9K6 RF
by n2nov＠n2nov.ampr.org 25 Jul '13

25 Jul '13

I have been following the conversation on what can we use the modern version of the 44net for other than a futile attempt to compete with cable modems, 4G/LTE or fiber-optic links. The purpose of the 44net/JNOS project that we are putting together for NYC-ARECS is for providing email/telnet services for a served client in case their connection goes down or does not exist in an ad-hoc location. I am wondering if we can expand on the usual email and telnet sessions at 1k2 or even 9k6 to include things like routing our own VoIP/Echolink-type connections? The Echolink manual states that it needs 24K+ data speeds to connect to it's servers and maintain a voice connection. I know that there are other codecs that can work at lower speeds as well as ongoing work with FreeDV operating in 1.5 Khz on 20 meters! Ideas anyone?

1 0

Re: [44net] On The Air
by Bryan Fields 25 Jul '13

25 Jul '13

On 7/25/13 9:27 AM, Brian Rogers wrote: > That's why I completed the work started by Hessu and Marius in regards > to axMail-Fax... however there's already a system out there called > Winlink 2000 that uses HF, FM, and Internet to handle email. When I > query those who run it I get almost always these 3 identical comments: > > 1) It's windows, there's no learning curve of nos or linux involved. > 2) I can use the resources I have already without any _additional > expenses_. > 3) I don't have time to learn amprnet. > > ... then there was the issue raised about 3-party relaying, so now we > have governmental restrictions shying us away from certain applications. > > How we route is all well and good, but if you're not: > - providing useful services, some of which may be unique > - have a user base to use this network > - cost effectiveness (especially to the seniors who may be on fixed > incomes) I have no interest in limiting myself to what some old ignorant hams can understand. This is one of the reasons I got out of radio for a number of years, as it was not new or challenging due to these guys. I want to sit down an study if I don't understand it, not gripe about it (and my angina) on FM. We really have two discussions here. One is global BGP peering and a 44-net back bone, the other is the end user connecting over tunnels or dedicated links to the backbone. The backbone should be based on standard routing protocols and be vendor agnostic (ie ALU/CSCO/JNPR), as I could see having a router and peering link donated, but if we need to rack a linux box, we'll have an issue. The individual backbone POP's can interconnect with the end users over any method they want. (I'd say we need to support IPIP or GRE tunnels as standard at any POP) For an end user wanting a /29 or /31 they would pick a "local" AMPR POP, and link in with them. Thoughts? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

3 2

Re: [44net] Distributed BGP Announce
by Bryan Fields 25 Jul '13

25 Jul '13

On 7/25/13 11:59 AM, Marc, LX1DUC wrote: > What is your experience with that setup? Does it always (99.999% :-D) > work? If so, count me in an let's go with it. I've been running Cisco 1811's and 2800's in my local lan at home connecting me to my datacenter in tampa. (don't tell my day job, lol). I am running the MSS adjust and have no issues with it. Even without it, all major sites on the internet work, only smaller sites have an issue. We should not be limiting ourselves due to other peoples broken network designs. On the internet between peering points, where clue is found, I've never had an issue with icmp blocked. Now on the GRX, yes.... -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

Re: [44net] On The Air
by Bryan Fields 25 Jul '13

25 Jul '13

On 7/24/13 6:33 PM, Eric Fort wrote: > Where are you. I'm trying to get people together in Southern California to > do pretty much exactly the same thing. I'm about as far from San Diego as you can get and still be in the US :) I'm in St Petersburg, FL. Not many local hams here who want to mess with this stuff, I have a few who I know from work and we're playing with some re-purposed Alvarion radios. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] Distributed BGP Announce
by Bryan Fields 25 Jul '13

25 Jul '13

On 7/24/13 6:28 PM, Neil Johnson wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > I like drawings. > > Is this what I gather the concept is ? > > https://dl.dropboxusercontent.com/u/11681146/AMPRnet_Concept_V01.pdf > can you post the visio file? I'd like to revise a couple things. be aware, there is a little man that pops out of a router and punches you in the jaw if you type "router rip" ;) -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

Re: [44net] On The Air
by kb9mwr＠gmail.com 25 Jul '13

25 Jul '13

I guess it will kind of boil down to applications. And a way to advertise them to everyone else who has access to the network. Here are some random ideas Make a mirror of mods.dk or something like it, are their any unlimited mod sites? As far as I know you can only lookup one per day. How about a part-number datasheet lookup service? Or periodical lookup. Or hosting services for ham software development projects. For a good place to start how about someone setup a listserver on the amprnet, perhaps "ampr-services"? It would probably be a good idea if there was a way for the HSMM nodes to have a way to tunnel to other remote nodes. Maybe touch base with the firmware developers?

3 2

BGP / Tunnels / JNOS
by K7VE - John 25 Jul '13

25 Jul '13

My thoughts. The IPIP / JNOS network is an anachronism that is quant but doesn't take advantage of how technology has evolved. I'm a pretty skilled network guy but the current IPIP tunnel system has eluded me. I have gotten close, but finally thrown my hands up each time. (I never get the rip44d to run and find the proper password.) However, I can get a VPN tunnel running in short order which can bring an address range to whatever location is on the full Internet. I have a personal class-C at home that has functioned over a VPN for over a year and I have VPN'ed to another Net-44 gateway with success. (In both cases on inexpensive MikroTik routers.) I think we need to work on connectivity of the gateways to unify Net-44 and treat the "on air" connectivity as a separate task. Whether the on air connectivity is for IP over AX.25 at 1200 bps, WiFi/HSMM, D-STAR Digital Data, or some new transport over RF. It doesn't do a lot of good to have islands of on air activity without interconnectivity of Net-44. Otherwise just use RFC 1918 address space and NAT it to the Internet. My vision is that we have multiple BGP gateways on the Internet. Some may advertise the whole of 44/8 and others may have smaller networks, clear down to 44.x.x.x/24 Some will be multi-homed, some will not, but all would be advertised to the Internet for routing. Any router advertising all of 44/8 would need to know about all routes for anything with a CIDR of less than /8. I don't think we really want all traffic to go to 1 or 2 routers advertising 44/8 or we're back to the everything must go through UCSD scenario of the last couple of decades. My recommendation is to find ISPs who are willing to 'donate' bandwidth and routing for some number of BGP'ed networks, then place routers at those ISPs which will support authenticated VPN service to local networks. Say we had an ISP (or University, etc.) that would donate bandwidth for 44.24.0.0/16 and 44.12.0.0/16,44.26.0.0/16, and 44.40.0.0/16 and BGP advertise those ranges. Let's another data center wanted to BGP 44.24.100.0/24. Traffic would flow to the best gateway for each. If 44.24.10.0/24 didn't have the ability to BGP its own address space, it could VPN to the router at the major gateway (ISP) and that router would tunnel traffic for that network to the gateway for 44.24.10.0/24. Then there might be a small on the air network at 44.24.128.0/28 and its gateway would VPN to the 44.24.10.0/24 router who would route traffic for the small network. This would mean that no special tables need to be passed around. Each router would know the addresses it was responsible for and would route all other 44 traffic to its "upstream" and non-44 network traffic to the Internet through their service provider. This means the "heavy lifting" of BGP and network routing would be handled by those ISPs where the expertise exists and a new member of Net-44 could simply setup a simple router that VPN'ed to an upstream router to get its traffic and to send Net-44 traffic, all other traffic would simply pass over local service provider's network. This is all readily available, off the shelf, technology. For the end user it is very inexpensive to setup a router with VPN. Then the local distribution over RF can happen over whatever technology is available, whether a TNC and FM radio, WiFi dongle, UDR56k-4, Bullet, etc. ________________________________ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223

4 4

Re: [44net] Distributed BGP Announce
by Bryan Fields 25 Jul '13

25 Jul '13

On 7/24/13 1:02 PM, Neil Johnson wrote: > I'm a network engineer at another University in the midwest US and I > *might* be able to convince our routing guru to let us be a BGP peer and I > could setup another tunnel end point box. > > I would need explicit details on how this would work and a the potential > risks and plans for their mitigation before I approach him. > > We don't have earthquakes, just tornados and floods :-) > > No promises however. We have really two networks here. The internal 44-net and the external internet facing net. I'd propose to have a few points around the globe where we can peer the whole 44 internet facing net. Each of these locations would announce 44/8 and more specific routes for what's close to them. Behind this in the 44-net internal the gateway routers would be meshed over GRE tunnels running an IGP (IS-IS). There of course would need to be IBGP sessions between all the BGP speakers, but this would allow end user networks to tunnel to a given 44/net router, and not need to keep a full route table of the 44-net internal space. (I hate end stations needing to do routing, that's why we have routers!) This would provide full access to the 44/net from outside, easy access from the AMPR users, and full visibility between directly routed netblocks and the rest of 44-net with out having to maintain a full mesh. I'd imagine the more specific announcements from the peering points would be statically configured, but there is a way to do a limited redistribution from the IGP into the BGP. I think it would be easier to do it manually (and more stable), but given some time in the lab at work I could get this going. Thoughts? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

8 19

Re: [44net] Distributed BGP Announce
by Bryan Fields 25 Jul '13

25 Jul '13

On 7/24/13 6:15 PM, Marc, LX1DUC wrote: > (BTW IS-IS probably wouldn't work that well over Layer3 tunnels AFAIK, > as it is itself a Layer3 protocol and would need to be transported > over a Layer2 link (please correct me if I'm wrong)) IS-IS will work fine over GRE. GRE forms an interface over which IP/CLNS can function. Multicast and broadcast traffic works over this as well. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

Posting From My AMPR.ORG Address
by n2nov＠n2nov.ampr.org 24 Jul '13

24 Jul '13

Well, I now have my ampr.org address on the mailing list from my JNOS box.

1 0

BGP / Tunnels / JNOS
by K7VE - John 24 Jul '13

24 Jul '13

My thoughts. The IPIP / JNOS network is an anachronism that is quant but doesn't take advantage of how technology has evolved. I'm a pretty skilled network guy but the current IPIP tunnel system has eluded me. I have gotten close, but finally thrown my hands up each time. (I never get the rip44d to run and find the proper password.) However, I can get a VPN tunnel running in short order which can bring an address range to whatever location is on the full Internet. I have a personal class-C at home that has functioned over a VPN for over a year and I have VPN'ed to another Net-44 gateway with success. (In both cases on inexpensive MikroTik routers.) I think we need to work on connectivity of the gateways to unify Net-44 and treat the "on air" connectivity as a separate task. Whether the on air connectivity is for IP over AX.25 at 1200 bps, WiFi/HSMM, D-STAR Digital Data, or some new transport over RF. It doesn't do a lot of good to have islands of on air activity without interconnectivity of Net-44. Otherwise just use RFC 1918 address space and NAT it to the Internet. My vision is that we have multiple BGP gateways on the Internet. Some may advertise the whole of 44/8 and others may have smaller networks, clear down to 44.x.x.x/24 Some will be multi-homed, some will not, but all would be advertised to the Internet for routing. Any router advertising all of 44/8 would need to know about all routes for anything with a CIDR of less than /8. I don't think we really want all traffic to go to 1 or 2 routers advertising 44/8 or we're back to the everything must go through UCSD scenario of the last couple of decades. My recommendation is to find ISPs who are willing to 'donate' bandwidth and routing for some number of BGP'ed networks, then place routers at those ISPs which will support authenticated VPN service to local networks. Say we had an ISP (or University, etc.) that would donate bandwidth for 44.24.0.0/16 and 44.12.0.0/16,44.26.0.0/16, and 44.40.0.0/16 and BGP advertise those ranges. Let's another data center wanted to BGP 44.24.100.0/24. Traffic would flow to the best gateway for each. If 44.24.10.0/24 didn't have the ability to BGP its own address space, it could VPN to the router at the major gateway (ISP) and that router would tunnel traffic for that network to the gateway for 44.24.10.0/24. Then there might be a small on the air network at 44.24.128.0/28 and its gateway would VPN to the 44.24.10.0/24 router who would route traffic for the small network. This would mean that no special tables need to be passed around. Each router would know the addresses it was responsible for and would route all other 44 traffic to its "upstream" and non-44 network traffic to the Internet through their service provider. This means the "heavy lifting" of BGP and network routing would be handled by those ISPs where the expertise exists and a new member of Net-44 could simply setup a simple router that VPN'ed to an upstream router to get its traffic and to send Net-44 traffic, all other traffic would simply pass over local service provider's network. This is all readily available, off the shelf, technology. For the end user it is very inexpensive to setup a router with VPN. Then the local distribution over RF can happen over whatever technology is available, whether a TNC and FM radio, WiFi dongle, UDR56k-4, Bullet, etc. ------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays>

1 0

BGP / Linux / Tunnels / JNOS
by John D. Hays 24 Jul '13

24 Jul '13

My thoughts. The IPIP / JNOS network is an anachronism that is quant but doesn't take advantage of how technology has evolved. I'm a pretty skilled network guy but the current IPIP tunnel system has eluded me. I have gotten close, but finally thrown my hands up each time. (I never get the rip44d to run and find the proper password.) However, I can get a VPN tunnel running in short order which can bring an address range to whatever location is on the full Internet. I have a personal class-C at home that has functioned over a VPN for over a year and I have VPN'ed to another Net-44 gateway with success. (In both cases on inexpensive MikroTik routers.) I think we need to work on connectivity of the gateways to unify Net-44 and treat the "on air" connectivity as a separate task. Whether the on air connectivity is for IP over AX.25 at 1200 bps, WiFi/HSMM, D-STAR Digital Data, or some new transport over RF. It doesn't do a lot of good to have islands of on air activity without interconnectivity of Net-44. Otherwise just use RFC 1918 address space and NAT it to the Internet. My vision is that we have multiple BGP gateways on the Internet. Some may advertise the whole of 44/8 and others may have smaller networks, clear down to 44.x.x.x/24 Some will be multi-homed, some will not, but all would be advertised to the Internet for routing. Any router advertising all of 44/8 would need to know about all routes for anything with a CIDR of less than /8. I don't think we really want all traffic to go to 1 or 2 routers advertising 44/8 or we're back to the everything must go through UCSD scenario of the last couple of decades. My recommendation is to find ISPs who are willing to 'donate' bandwidth and routing for some number of BGP'ed networks, then place routers at those ISPs which will support authenticated VPN service to local networks. Say we had an ISP (or University, etc.) that would donate bandwidth for 44.24.0.0/16 and 44.12.0.0/16, 44.26.0.0/16, and 44.40.0.0/16 and BGP advertise those ranges. Let's another data center wanted to BGP 44.24.100.0/24. Traffic would flow to the best gateway for each. If 44.24.10.0/24 didn't have the ability to BGP its own address space, it could VPN to the router at the major gateway (ISP) and that router would tunnel traffic for that network to the gateway for 44.24.10.0/24. Then there might be a small on the air network at 44.24.128.0/28 and its gateway would VPN to the 44.24.10.0/24 router who would route traffic for the small network. This would mean that no special tables need to be passed around. Each router would know the addresses it was responsible for and would route all other 44 traffic to its "upstream" and non-44 network traffic to the Internet through their service provider. This means the "heavy lifting" of BGP and network routing would be handled by those ISPs where the expertise exists and a new member of Net-44 could simply setup a simple router that VPN'ed to an upstream router to get its traffic and to send Net-44 traffic, all other traffic would simply pass over local service provider's network. This is all readily available, off the shelf, technology. For the end user it is very inexpensive to setup a router with VPN. Then the local distribution over RF can happen over whatever technology is available, whether a TNC and FM radio, WiFi dongle, UDR56k-4, Bullet, etc. ------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays>

1 0

Re: [44net] On The Air
by Bryan Fields 24 Jul '13

24 Jul '13

On 7/24/13 5:19 PM, Brian Kantor wrote: > Yes, I'd like to see more people working on networking over the air > using amateur radio. > > Otherwise we're just another branch of the Internet and there's nothing > new or exciting about that. +1, I'm doing some hacking on getting some gear into the 5 ghz ham band, and removing power limits. It would be point to point or point to multipoint directly into Ethernet. You can find the used units for 200-300 dollars, so a complete 100mbit/s link would be 400 dollars or so. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

Distributed BGP Announce
by Marc, LX1DUC 24 Jul '13

24 Jul '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear YLs and OMs, I would like to restart the discussion about a decentralized BGP setup for the 44net. I have thought about some kind of trial to test several aspects of a non-central gateway approach. So far I have come up with a few "challenges" for the trial. - - AS Number (I can provide one for the trial, we may decide later on what to do if and when this project goes to production) - - IP Network (for the trial the test range 44.128.0.0/16 might be a suitable candidate) - - BGP Peers providing BGP session, bandwidth and a static IP address for the trial (I can provide one peer in LX) - - Inter-Gateway Tunnel setup (which protocol should we use? How do we cope with lowered MTU and filtered ICMP Packet-to-big messages?) - - Downstream tunnels (What kind of tunnel technology/protocols are we offering? Can a subnet have upstream tunnels to several gateways?) - - iBGP setup (How do we handle gateways with different available upstream bandwidth? How do we redistribute routes for connected subnets?) - - Packet filtering (Will we be using the current model of RDNS activates access to/from the Internet? RDNS could be useful even for hosts that shouldn't have access to/from the Internet, eventually access to/from the Internet should be decoupled from RDNS.) - - Test scenarios, how are we going to test different situations? - - probably much more issues to handle (I haven't thought about the details as long as the basics haven't been discussed) What are your thoughts and who is willing (and able) to help with the trial (as a gateway and/or a subnet tunnel server)? 73 de Marc, LX1DUC - -- http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR7v2YAAoJEHFIN1T8ZA8vJSQQAIFoXAKTS7IKJ6SxRavGb0oa ySXvtPQg1TjhU5bGkN46efSQkAhsY7BcOg+3JwNTVEpTW5ZLO3ieN1kRKcgD/uVh fI4z70HeFvQJeE6l2TeZxYkKU45fNEBKNQHqRRn2QU7wOHqvhOtr+jjR4UswbWIG PyFoUEF/T7wd2jpZ6O0hA4buOy+DnMpBUeUQCQIeu7xs5+YpFGc1D21Fbo5b24FG GLTUl4b+ssYdLf+CiFy1TlOu1wLOZorZ3DrYjexxGvpUzEUHjrazNr/pUKIc1WMq zs3cQFTKNyjWf984Ty8WeuKrP/oy5gNFIbTmxlzm4JNYqDjPpQXZ/3Cduu/ij8Yl n1qDAwe+PDFHh1DUVTdgiy+3JSsUy7q2GwItiJG5pOtFasLeoWeLs9iXR5dNBqtD E8O9R7WRL989igv2XXVitwpDaiiDIpZG47kkktljFfhSiY6RtiozQRuuncQzm6bQ 0Ixl0u1Ne0B8aeQqfzUDfs6UqtoRPPoqJbRFimD22tAZg9dn50z180jU3b5oc/xX tD06xi2CwscFLPlRknxxj/TFDfySjOHOJCmGPHUR/uBIs7ABqciY5NVkNpmPklUa A3AW4J0uwVTB3iUpuZXktny/epj6ULg3R/FMU5Ym8Y9XFgp52km+vCvsbg9bPhtv DQ22F6oMccLigj/6h0I+ =8ova -----END PGP SIGNATURE-----

2 3

Re: [44net] Distributed BGP Announce
by Bryan Fields 24 Jul '13

24 Jul '13

On 7/24/13 4:33 PM, Neil Johnson wrote: > How would local gateways connect ? A Tunnel(s) to the global gateways ? > > I'm trying to imagine explaining to someone how to configure an IGP > (especially IS-IS) :-) yes, IPIP tunnels or GRE to their local gateway. If they wanted to have redundancy into the AMPR net they could do IS-IS L1 to the two gateways over these tunnels. The backbone routers would all be L2 routers. We could do OSPF, but I see the whole area 0 thing being a bad architectural limitation. Any design we come up with should be redundant and scalable for all hams to benefit from. Really if you can't configure a link state routing protocol, should you even be trying to setup a redundant connection? Granted it would be optional, but it would give some real protection if one of the border routers goes down. We only have a /8 of space, and even subdivided into /24's it's only 65k routes, so pretty much any router on the core can handle it. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] (no subject)
by kb9mwr＠gmail.com 24 Jul '13

24 Jul '13

Bill, I am not yet. Still using hard routes over the air. When/if the over-the-air network grows in users and capable speed, that would make perfect sense to implement. As for ampr.org email, does anyone care to document setting up a sendmail server for their gateway? Spam control is always a big headache. I have been using a 3rd party mail exchanger, as that seems easier. And since my gateways are somewhat experimental here, I am not subscribed using kb9mwr(a)kb9mwr.ampr.org to this list, as I don't like worrying about bounced mail. But my ampr address does work, and go over RF using pop3 pooling. Steve ------Quote----- So how are folks actually making use of all this nifty routing technology on the air with Amateur Radio these days? I don't remember the last time I've seen an "ampr.org" email address here on the list. I kinda remember the last time I had one that worked... Bill

1 0

Re: [44net] directly connected and tunnel subnets
by Bryan Fields 18 Jul '13

18 Jul '13

On 7/16/13 11:00 AM, Brian Kantor wrote: > A solution would be to have the border router at each of the > directly-connected subnets also have a full set of tunnel routes and > interfaces installed, as it could then participate in the tunnel mesh > and should then be in the encap file. I don't see commercial internet > providers doing that. > > So this means that in order for the the directly-connected subnets to > also participate in the tunnel mesh, there has to be a tunnel-enabled > router downstream of the connection to the commercial Internet. Thus the > only advantage of being directly-connected is simply an independent (quite > possibly higher-bandwidth) connection to the commercial Internet backbone. > It doesn't improve internal connectivity in the AMPRNet at all. We still > need the tunnels for that. Admittedly, I've been a bit tardy in getting my BGP session up with my provider (summer is always busy for me), but perhaps there is a better way to do this. What I envision would be to have a few regional AMPR BGP routers/peering points. AMPR would need and ASN of course (I'd be willing to put up the money for this from ARIN), some hardware and a few friendly providers across the globe. I have one friendly provider, and I'm sure we could find a few more. Hardware is up to us, I'd prefer an actual router (ALU/Cisco/JNPR), but there is no reason openbgpd on a *nix box wouldn't work. So you would have each peering point announcing 44/8 but behind the peering routers would be a set of (GRE) tunnels between all the routers. The 44net BGP routers would run I-BGP across these tunnels (or ISIS/OSPF, but I feel IBGP would make more sense to manage redistribution of routes as it's got more "policy knobs" than OSPF and to a lessor extent ISIS.) The 44net non bgp users would then have IP-IP tunnels to their closest 44net peering router. For optimized routing (as it makes no sense to me for .AU users to tunnel through UCSD) we could have routing between the 44net routers announce more specific routes for directly connected subnets. We'd have to manage this, as I'm sure we don't want to add another 1000 routes to the global table (and then have filtering), but I don't see it being that many routes when a /16 is for a whole continent, which has 1 or 2 peering routers in this design. This also avoids black holes caused by 44net directly connected peers being filtered by sites that filter at less than a /24 block (don't laugh, I've seen large companies filter at a /19) Admittedly this is a very "back of a napkin" design, but it's a start. Thoughts? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

12 18

(no subject)
by kb9mwr＠gmail.com 17 Jul '13

17 Jul '13

k9eam ?

1 0

(no subject)
by kb9mwr＠gmail.com 17 Jul '13

17 Jul '13

k9eam ADD A 138.74.255.4

1 0

Re: [44net] directly connected and tunnel subnets
by kb9mwr＠gmail.com 17 Jul '13

17 Jul '13

Along those lines, Remi, F4ECW had an interesting idea to make PHP interface for remote fldigi. I took some his radio control code and put my receiver online. http://kb9mwr.no-ip.org/control/ Another logical use of the 44 netspace would be for a VOIP ham thing like IRLP. This would eliminate the need for port forwarding ---- Quote ---- Interoperability with the Internet, thanks to the BGP announcements and not using 10/8, *and* at the same time, access to the same services from ham radio networks which are not allowed to access the Internet over ham radio due to local regulations. That'd be cool. Run a nice web service having a net-44 address, but when the visitor comes from within the amprnet with a net-44 address, allow extra features like being able to key a transmitter. - Hessu

2 1

Re: [44net] directly connected and tunnel subnets
by Bryan Fields 16 Jul '13

16 Jul '13

On 7/16/13 4:17 PM, Brian Kantor wrote: > In addition to whatever its activities require, it costs around $500 > a year to just maintain a non-profit corp in California. > > Donations haven't kept up with that, much less to defray the initial > startup costs. We have no money. Why incorporate in Cali? Not to get political here, but it's the least business friendly state in the union. I have 3 LLC's in Florida, and spend less than 400 dollars to matain all 3 LLC's. Cost to incorporate a non-profit is $70, which is about half of a non-profit. I think status with the IRS which would make donations tax deducible is a no-brainier. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

Re Networks in OZ
by VK4FQ/VK4TTT Sam 16 Jul '13

16 Jul '13

Guys I am trying to create a resonable map of ampr ips that are in use in Australia so when people request they canbe given ranges that are not being used. If you have or no of a range of IP's that are being used downunder, could you please let me know by emailing samantha(a)smellyblackdog.com.au Regards Sam Amateur Radio Callsign: VK4FQ / VK4TTT Owner: VK4RCN P25 Repeater Cairns Sysop: APRS Cairns Mobile: VK4FQ-9 (vhf) VK4FQ-15 (Hf)

16 47

portal: database damage
by Brian Kantor 13 Jul '13

13 Jul '13

Chris reports that he's repaired the portal allocations mechanism but that some recent allocation requests were lost and will have to be resubmitted. The cause was apparently an unexpected power failure in the data centre. - Brian ----- Forwarded message from Chris <chris(a)g1fef.co.uk> ----- Looks like some records were corrupted, I've repaired the db by rolling it back, but that means the most recent transactions where lost, so recent allocation requests will have to be re-submitted. Cheers, Chris ----- End forwarded message -----

2 3

Re: [44net] Re Networks in OZ
by Bryan Fields 13 Jul '13

13 Jul '13

On 7/13/13 12:31 PM, Lin Holcomb wrote: > My understanding is that there may be some rouge direct connected > 44 address ranges out there too. This is from a friend at a national > CATV/ISP provider. > I don't remember the specifics but prior to the policy Change by AMPR > regarding this allocation we found some of these in their AS. If memory > serves some were in VK. This is some thing we really need to run down.... > With 16million addresses this is a hard task to police. I am guessing > that ISPs have whole groups that just deal with rouge networks in their IP > space. Just running a scan is not going to work as most ISPs will shut ya > down if you tried to scan a whole class A. It really needs to be looked at > in a AS. Not Brian's at UCSD as his will be correct. Well anyone running BGP with a full feed on their router can see what ASN's announce any netblock. The bigger question I see is how do you reliably link all of 44/8 so everyone can see everyone else. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

Connectivity to AMPRnet and video
by Jesse Hindmarsh 10 Jul '13

10 Jul '13

In one of my last posts, I mentioned about connecting to the AMPRnet via DMVPN or PPTP which seemed to tangent into a hardware/software discussion. I sat quietly and enjoyed the many perspectives that many had to share. I have been connecting via a combination of Linux and DMVPN for the last two weeks and it has worked as expected. A few even used the PPTP service I have setup and had good results. I want to get some services deployed to see how flexible this setup is and if there are any issues before I attempt to extend my network using 2 ghz and 5 ghz links across the valley. Right now I have a videoconference station setup on 44.64.192.2 which anyone is welcome to connect to. Thanks Jesse - WC3XS Sent from my iPhone

3 4

Re: [44net] hardware vs. software
by lleachii＠aol.com 10 Jul '13

10 Jul '13

Regarding a few things mentioned setup/encryption - 802.11 encryption would not be necessary if you use a band not shared with Part 15 Users - 802.11 encryption technically does not obscure the fact that you are transmitting standard 802.11 Wireless Ethernet traffic - also, this debate can extend into HTTPS traffic over Amateur RF, except in an Emergency (transferring Health information for a hospital, for example, REQUIRES encryption in the US [HIPPA]) - even if HTTPS traffic is sent, packet inspection of the frames would reveal it is a HTTPS packet, its source and its destination - making the callsign the SSID is not the only method of complying with station identification rules; but it is the easiest - There are other methods of encrypting a WiFi signal other than a pre-shared key (many stations commented that they key must be posted or announced), user account authentication is another method regulation - regarding sending a music/video file or stream via 802.11 - the communication would be data, in the analog world, I would assume this would be similar to sending the sheet music via snail mail - regarding N6MEF's concern regarding 3rd party email communications, email is not an "automatically forwarded" technology; an amateur does not automatically receive that message through any technology governed by Part 97 (there are two exceptions I can imagine - if the amateur maintains his own email server at the receiving [client] end of the radio link or provides email as a service to non-amateurs) - I'm somewhat lost as to the concerns regarding inbound traffic, the problem only arises if the intent is to run infrastructure (i.e. services) over RF for non-amateur use, otherwise, the requests would initiate from an amateur station and would not be 3rd party - servers and devices on AMPR can be firewalled to only accept traffic from 44.0.0.0/8, in fact my DNS server (44.60.44.3) is configured to only resolve non AMPR IPs and domains for 44/8 traffic - if a non-amateur is reaching a 44/8, they MUST be using commodity Internet, if the services are on the gateway or on a device connected by wire or Part 15 device, that is not governed by Part 97 (Part 97 only governs Amateur RF) - I cannot find 97.109(e) - I'm not certain how 97.115 relates, except for 97.115(c) "(c) No station may transmit third party communications while being automatically controlled except a station transmitting a RTTY or data emission." Since it is a data emission, 3rd party communications can be transmitted - I'm not certain how 97.219 applies, given that email is not a message forwarding system for the 3rd party (email receipt must be initiated by the amateur, that communication is between the Amateur and their email server, not between the Amateur and the 3rd party) This is a good thread, and I'm still reading through, I hope I have not missed anything thus far. 73, Lynwood KB3VWG

3 7

Re: [44net] Use of higher bands
by Michael E. Fox - N6MEF 08 Jul '13

08 Jul '13

Eric, I applaud your intent. But, as far as I can tell, there are several major issues with what you're saying: 1) The FCC rules push me to NOT use amateur bands for data. Any application that is actually useful is going to be something that communicate with non-hams, too. Look at the popularity of WL2K. But Part 97 prohibits traffic from being automatically forwarded if it was originated by a 3rd party. So I can send an email to my grandmother. But she can't send me a message if delivering it would require automatic forwarding (such as between JNOS BBSs) over an amateur frequency to reach me. So that means I need a non-amateur network path to every machine. So we're working on that, including using 5.8G consumer stuff. But, gee whiz, once that's done, and I've got a few Mbps between each system, (and it's encrypted to boot!) why use the amateur frequencies at all? In my mind, studying for and getting an amateur radio license should give you MORE privileges. And sure, we get access to more frequencies, but we're highly restricted on what we can do with them. It's like giving a kid a new bike and then telling him he can only use it in the driveway. What's the point? 2) Can't get there from here. Here in silicon valley, 900 is pretty worthless - much too noisy. 2.4 is very crowded. It's hard to get enough S/N to rise above the noise floor. We shoot point-to-point 5.8G links using 5 degree dishes to give us enough S/N. Sector antennas just didn't work. But we can't use 5.8G at 2 of our locations because trees obstruct the path. Anything higher in frequency would be even worse. 3) COTS is available? I don't think so. Not really in any useful, accessible way. We use the Ubiquity stuff on 5.8G. I don't want to make any modifications that will void a warranty. (Actually, I don't want to dink around with hardware modifications anyway.) But even if that is possible, see problem #1. What would be the point unless it's just to talk to the other hams that have done the same thing? In all of silicon valley -- a few million people -- I can probably count the number of hams with the time and desire to do that on one hand. Now, lest you think I'm just a nay-sayer - you can see what we do here: http://www.scc-ares-races.org/packet.html I'm the sysop for 6 JNOS BBSs, including the gateways and other network stuff. I authored most of the content on the above web page and the pages it links to. (That page doesn't mention the email gateway services we're about to roll out). I think focusing on the technology is the wrong thing to do. Figure out what application you want to enable and then solve that problem. For our county, our application was mostly emcomm and the ability to locate anywhere in the county (literally anywhere, with or without power, with or without Internet) and be able to send/receive text and forms data. The county uses several ICS-type forms. City CERT orgs send damage report summary forms. The hospitals have several forms they use. It's a really big deal for them. That's all made possible by custom software written by several folks here. So, what is the application that will drive more AMPRnet use? Honestly, because of #1 above, I don't think there is one! ;-( But hey, if anyone has ideas, I'm always looking for the next thing. Michael N6MEF -----Original Message----- >Again I ask why are the higher bands not as attractive? Readily available >COTS Gear is available for 900Mhz, 2.4GHz, 3.4Ghz, 5.7Ghz, 10Ghz, & 24Ghz. >We ought to be looking to fill 5.7, 10, & 24 to the point that we can >show value in being there. it is our non use of these bands that makes >them easy targets for reallocation and takeover. Try reallocating for >instance the 2M Band in a major metropolitan city, you'd have an >uproar, but the middle microwave bands, easy chicken, egg. >Eric >AF6EP

6 9

Re: [44net] hardware vs. software
by Michael E. Fox - N6MEF 08 Jul '13

08 Jul '13

Actually, Linux on x86 hardware is just as much of a "hardware-based" solution as any proprietary OS on proprietary hardware is. In fact, Linux on x86 easily outperforms most proprietary hardware solutions up to and beyond the Cisco 7x00 range, especially with the current Intel architecture systems. Vyatta (now part of Brocade) and others have proven that over and over for the last several years. I hope we can establish something that's vendor neutral, rather than any type of single vendor lock-in. Michael N6MEF ---- In the performance class we are operating in, "hardware based" is not really required. A suitable box (processor and ethernet interfaces) and software (e.g. Linux plus some usermode tools) can do the same thing.

7 17

Re: [44net] 44Net Digest, Vol 2, Issue 84
by Rob Janssen 08 Jul '13

08 Jul '13

>Again I ask why are the higher bands not as attractive? Readily available >COTS Gear is available for 900Mhz, 2.4GHz, 3.4Ghz, 5.7Ghz, 10Ghz, & 24Ghz. >We ought to be looking to fill 5.7, 10, & 24 to the point that we can show >value in being there. it is our non use of these bands that makes them >easy targets for reallocation and takeover. Try reallocating for instance >the 2M Band in a major metropolitan city, you'd have an uproar, but the >middle microwave bands, easy chicken, egg. >Eric >AF6EP It may be different in the US, but here "an uproar" (if any) is not going to determine how bands are re-allocated. We have constructive discussion with the license authority, but in the end we are not the ones that decide. VHF/UHF band popularity has gone down anyway, because of license class changes. Until a decade ago, there was a separate "no code" license class that only allowed operation on VHF/UHF, and a "novice" class that allowed a couple of sub-bands and lower power. Then the code requirement was dropped for everyone, so now "no code" licensees (like me) can operate on all HF bands. "novice" class were given access to most of the HF bands as well. The result was that many active amateurs who always wanted to be on HF but were restrained by the code or exam level requirements now went there, and most DX activity the VHF/UHF bands vanished. There now are only repeaters (mostly silent) and a couple of local channels with very little activity. Tuning over the 2M band you may hear 2 or 3 QSOs. This weekend there was a contest but I only heard a German and a UK station, while a decade ago the SSB segment would be filled with activity. As it is now, there are not enough active hams here to setup and sustain something as involved as a data network. We had one in the past, but interest dropped with the availability of internet for everyone. Sure one could experiment with a link to a friend just for fun, but that is no significant band use. Unattended operation is more of a problem as well. We now need a special permit for anything that transmits beyond of the direct control of the operator. Presence of the operator while the gear is operating is no longer sufficient. Such special permits are given only for fixed frequencies and only in certain bands, and they also cost money. Rob PE1CHL

2 1

Re: [44net] a common vendor neutral hardware/software stack for 44net. - was Re: hardware vs. software
by kb9mwr＠gmail.com 07 Jul '13

07 Jul '13

I was thinking the same thing. If it's a data transmission then yes obviously the bandwidth rules apply. If it's an image transmission then a different set of rules apply. If its a spread spectrum transmission then 97.311 applies. The problem is defining what you are transmitting. http://www.qsl.net/kb9mwr/projects/wireless/70cm-ATV-HSMM.html As for chewing the the band. You really have to look at it on a case by case basis, geographically. Where I live, 70cm is pretty dead, so a 5 MHz wide signal isn't a big deal. 15 years ago a guy was playing with analog ATV and that really did rip up the band, as it had no real filtering, and at the time the band was active. >97.307 doesn't apply to FHSS or DSSS. The applicable section is >97.311. Anyway this isn't the place to discuss rules in my opinion. However if we keep connecting slow speed conventional radios to the amprnet, then it will continue to be what is has for the last 20+ years. I am glad to see some people thinking out of the box, and exploring different technologies. Getting back on topic, I read there was a recent presentation titled "Providing authenticated amateur radio services on the Internet", is there a paper or video available for those of us who didn't attend?

3 3

Re: [44net] 44Net Digest, Vol 2, Issue 83
by Bryan Fields 07 Jul '13

07 Jul '13

On 7/7/13 12:13 PM, Bill Vodall wrote: > It should only cost about $1K each node and some hundreds of hours. > Then, when it's working - if you do find the paths, there will be > endless discussions of what can and can't flow on the system and what > keys can or can't be used. > > Compare that to Facebook today with a broadband account that just works. > > It'll be hard enough getting a path with an ID-1 (price reduced - $710 > at HRO) or UDR56K... Then you still have the content and use case > issues... First, most linking repeater systems cost 5-10k for a basic setup, so 1k a node is not out of line. Perhaps it's un-amateur of me, but I'm not so much concerned with potential minor part 97 violations if it means I'm on the air with others and providing a service to hams at large. Much like the legalities of dancing on ATV, I don't care to arm-chair lawyer mp3's over a data link, or logging every frame I send over the air. If something needs to change in part 97, I'll sign whatever petition, or comment on it if need be. I'm an engineer, and building networks is fun for me, not arguing about why we can't do it. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] 44Net Digest, Vol 2, Issue 83
by Rob Janssen 07 Jul '13

07 Jul '13

>I remember hearing about these though I'd consider these to be somewhat of >an oddity. again why 70cm, only 30MHZ wide & already filled with other >users? Why is everyone so damn scared and afraid of moving to the amateur >microwave bands where we have 1555MHZ of mostly unused spectrum from >1.2-47.2GHz? Why must we recreate the wheel so much of the time when it >may be better, faster, easier, & cheaper to use directly or adapt a >solution already in use in another service. >Eric >AF6EP Well, partly because the availability of solutions in other services puts our band in danger. For example, the presence of WiFi in the 13cm band (we have 2320-2450) already resulted in a ban to use 2400-2450 because of WiFi interference. The same will probably happen on the 5.7 GHz band now that it is becoming more popular for WiFi. 70cm is only 10 MHz here and part of that is already allocated to other services and we are only secondary to them. 1240-1300 we are going to lose when Galileo (the European GPS) is becoming deployed. Only a small segment for DX will probably be left (1296) The more a band is attractive for other services, the more likely we are going to lose it soon. The much higher bands will remain availble for now, but they are not as attractive. Rob

3 2

a common vendor neutral hardware/software stack for 44net. - was Re: hardware vs. software
by Eric Fort 06 Jul '13

06 Jul '13

It would seem Linux and Ethernet whatever architecture it's running on would seem to be the best solution available for routing Net44 at the moment and it works well. a standardized plug and play package of hardware sold by your local candy store would be nice but we're only partially there. Being that 44NET/Amprnet is supposed to be a RADIO BASED IP NETWORK (or at least interconnected islands of RADIO BASED IP NETWORK) we seem to only have half of a standardized solution to offer. It seems that we have forgotten the RADIO part. Given a live piece of cat5 with bits on it that I wish to have show up elsewhere what can we offer to the average ham that can go on the tower with Ethernet in one side and an antenna on the other, especially something standard enough that a local group can set up a network with? The only thing I can think of that even comes close is the professional grade 802.11 hardware that's out there. (much of the consumer stuff lacks the configurablity we could really use such as power control and timeouts). I might propose that we standardize the RF interface for AMPRNET on an agreed physical layer (of 802.11 unless something else is proposed and made quickly and cheaply available) and a relatively standard stack of hardware and software be put forth as a package that could be turnkey deployed by interested parties. What would others think of embarking upon such a project as a group? who might be interested? and what might we offer? (PS. I know of at least one manufacture of gear that would be quite happy to mod a standard product or products so as to have them better fit the amateur radio band plan and channels on a couple of our microwave bands as well as make provision for the ability to get significant QRO above the 25-30dbm out that seems standard. This in production batches maybe as low as lots of 100 units) Eric On Fri, Jun 28, 2013 at 1:32 PM, Michael E. Fox - N6MEF <n6mef(a)mefox.org>wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > Actually, Linux on x86 hardware is just as much of a "hardware-based" > solution as any proprietary OS on proprietary hardware is. In fact, Linux > on x86 easily outperforms most proprietary hardware solutions up to and > beyond the Cisco 7x00 range, especially with the current Intel architecture > systems. Vyatta (now part of Brocade) and others have proven that over and > over for the last several years. > > I hope we can establish something that's vendor neutral, rather than any > type of single vendor lock-in. > > Michael > N6MEF > > > ---- > > In the performance class we are operating in, "hardware based" is not > really > required. > A suitable box (processor and ethernet interfaces) and software (e.g. Linux > plus some usermode > tools) can do the same thing. > > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net > http://www.ampr.org/donate.html >

7 11

Hessu
by Brian Rogers 01 Jul '13

01 Jul '13

Hessu; Can you please email me off list? Thanks in advance. -- Brian Rogers Phone: 860-673-4537 Email: n1uro(a)gmx.com Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org/ Platform: Linux URONode/axMail-Fax created here! Coordinator for: 1-land, DE, and N.J AmprNet

1 0

Re: [44net] DMVPN routing for 44/8 subnets
by Bryan Fields 01 Jul '13

01 Jul '13

On 6/27/13 2:26 PM, K7VE - John wrote: > Great idea - wrong platform. Cisco specific solutions aren't reachable for > many. > > Look at Linux (Raspberry Pi) solutions or powerful, affordable routers like > MIkroTik and common tunneling protocols like OpenVPN, L2TP, GRE, etc. I take issue with that. MikroTik is just as much of a closed platform as Cisco/JNPR/ALU/Fond-cade/etc. Cisco is ubiquitous, to a lesser extent Juniper (though I have to favor ALU for MPLS/core!). I'd say what we need is an open standards based solution that works across linux/cisco/jnpr (maybe an o-series? :) Something custom protocol wise to tie the 44net together is not ideal either as we cannot expect the big router vendors to support amprnet protocols. I know I'm able to slap a 1ru router (ie c2[6-9]00) in lots of places with good connectivity I could never put a server. I belive there is a way to do this via NHRP with BGP. I know I have a customer doing something like this. Since we don't need crypto for 44net I suspect it would work for us. just my .02 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

6 10

DMVPN routing for 44/8 subnets
by jesse＠hindmarsh.cc 29 Jun '13

29 Jun '13

I am working on a lab design to add some flexibility and test other connection methods to the 44.0.0.0/8 network. I currently have a Linux gateway running rip44d for my main connectivity to the other 44/8 subnets. I have setup a Cisco based DMVPN where I can route other subnets to and route back to the Linux gateway for access to other subnets. This configuration also allows access from the public Internet to the allocated subnets via a Linux gateway. I have a diagram with a working layout and is in testing now. I am looking to see if anyone might be interested in connecting up to my cloud and see what and if any problems we may encounter. I use a very similar setup with my customers and there are some distinct advantages: - The end user would only need an internet connection and a Cisco DMVPN capable router. I have used 800, 1800, 2800, 3700 series Cisco routers. - The DMVPN works when you plug the Cisco router into a direct Internet or NAT connection. You can plug it in at home behind your Netgear home router, use DHCP and a private address on the router "public" interface. - Many subnets can be routed through a single Linux gateway and distributed easily. - No issues with dynamic IP address from your provider. If you are interested or have any comments or suggestions, take a look at the network diagram I made at http://www.hindmarsh.cc/images/wc3xs-ampr44.png 73 de WC3XS - Jesse

5 7

Re: [44net] 44Net Digest, Vol 2, Issue 78
by Rob Janssen 28 Jun '13

28 Jun '13

Jesse Hindmarsh <jesse(a)hindmarsh.cc> wrote: > > > > > > Rob, > > I like your thinking. Are you a Cisco guy too? I have been for too long :-) > > I am still partial to hardware based solutions. > > Jesse - WC3XS, CCNP Voice, CCNP RS, CCDA I learned networking with the KA9Q software and later when I got a job as a sysadmin I worked with existing Cisco routers and found many things very familiar. I learned the Cisco stuff myself from the manuals, have no CC certifications. I converted our existing network at work from leased lines to VPN some 10 years ago over Internet using DMVPN and it worked very well. (now we have dedicated lines again, but that wasn't affordable at megabit speeds 10 years ago) I suggested DMVPN before on this list, and I still think it could be a good option at least when an open implementation is available. I don't know if it is today, it has been in the works for some time. (the specs are open) In the performance class we are operating in, "hardware based" is not really required. A suitable box (processor and ethernet interfaces) and software (e.g. Linux plus some usermode tools) can do the same thing. I run IPsec tunnels between Ciscos, between Linux boxes, and between Cisco and Linux, and it is all inter-operating well. Of course we don't want to tie outselves to "only Cisco". But a solution where Cisco and open implementations (on systems like Linux and BSD) inter-operate is a very good thing. IMHO we don't need to consider compatibility with DOS (e.g. JNOS on DOS) as critical anymore. Rob

2 1

Re: [44net] 44Net Digest, Vol 2, Issue 77
by Rob Janssen 27 Jun '13

27 Jun '13

K7VE - John <k7ve(a)k7ve.org> wrote: > Great idea - wrong platform. Cisco specific solutions aren't reachable for many. > > Look at Linux (Raspberry Pi) solutions or powerful, affordable routers like MIkroTik and common tunneling protocols like OpenVPN, L2TP, GRE, etc. The big advantage of Cisco DMVPN is that it can create a fully meshed tunnel network with endpoints on dynamic addresses, with only one (or a few) central hubs on static addresses, fully automatically. It is like what you have with a JNOS or Linux route importing encap.txt all the time, but without the hassle. Other VPN solutions are usually hub-and-spoke, where all internode traffic goes through the central hub. It is like connecting to net-44 by tunneling everything to 169.228.66.251 instead of loading a routing table. Rob

3 2

Re: [44net] Basic help needed with Linux and rip44d
by lleachii＠aol.com 27 Jun '13

27 Jun '13

Jesse, Take a look at my startup script at http://44.60.44.13/startampr It seems you have a similar setup, although one line of your configuration seems incorrect: ip route add 44/8 via 169.228.66.251 dev tunl0 onlink src 44.64.192.253 You should remove this route, it's invalid inside AMPR. You should not reach 44.0.0.0/8 via AMPRGW (169.228.66.251), you should reach each subnet via its gateway WAN IP address, as populated by rip44d. The return packet would come in the same manner, via their 44GW that has a route configured for you. My router: @kb3vwg-001:~# ip route get 44.64.192.253 44.64.192.253 via 24.229.88.252 dev tunl0 src 172.31.255.254 My route table shows: 44.64.192.0/24 via 24.229.88.252 dev tunl0 onlink window 840 73, Lynwood KB3VWG

4 5

Contact needed please
by Brian Rogers 26 Jun '13

26 Jun '13

Greetings list; Could the coordinator for 44.135/16 contact me off-list please? Thanks in advance. -- Brian Rogers Phone: 860-673-4537 Email: n1uro(a)gmx.com Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org/ Platform: Linux

1 0

Re: [44net] ampr.org dns zone delegation
by kb9mwr＠gmail.com 25 Jun '13

25 Jun '13

What about someone wanting to setup a dynamic DNS, with rather short lived record TTL's? For many gateway's they rely on an external service (dyndns, no-ip, etc) and many other ham applications (IRLP has it's own dynamic DNS etc) I have often wished the ARRL or QTH/QSL,net would offer a Dyn-DNS service for hams. ------------ >> How can one establish one or more NS records in the ampr.org hierarchy such >> that dns for *.mycallsign.ampr.org could be self managed? >Generally I prefer not to delegate zones in the "forward" lookup; >we're hoping to obviate the need for that with the self-management >of DNS records that the portal will provide. That will also solve the >issues of the 44.in-addr zone being kept in sync. >- Brian

1 0

ampr.org dns zone delegation
by Eric Fort 25 Jun '13

25 Jun '13

How can one establish one or more NS records in the ampr.org hierarchy such that dns for *.mycallsign.ampr.org could be self managed? Eric AF6EP

2 1

address block assignments for groups
by Eric Fort 23 Jun '13

23 Jun '13

Must a block of 44net IP space be assigned to an individual or could it be assigned to a club or other group? Say a club station had the callsign w6xyz assigned. could w6xyz then be assigned a /24 block to build out a lan serving a given geographic area? Eric AF6EP

5 6

Basic help needed with Linux and rip44d
by jesse＠hindmarsh.cc 20 Jun '13

20 Jun '13

I have followed the instructions on the wiki pages to the exact detail, and am having issues with the setup. I am at the point where I can receive routing updates but cannot send any data over the tunnel. I am not the best when it comes to Linux but have a better understanding of networking, routers, and routing (Cisco). I have eth0 on a public address. I have eth1 on 44.64.192.253/24 I have tunl0 on 44.64.192.254/8 I am running Ubuntu 10.04 on VMWare. 1. When I create the tunl0 interface with the class A netmask, how is rip44d using this and where does the tunnel "endpoint" get defined? (remote endpoint address?) 2. I have the Linux machine running rip44d and another linux machine on the same assigned 44.64.192.x subnet. I can ping between them until I bring up the tunl0 interface. If I down and up the tunl0 interface, I can ping as expected. Can anyone explain this behavior? 3. The tunl0 interface is registering collisions equal to the number of packets transmitted. I cannot find a reason why this is happening. Thanks in advance, Jesse

2 2

Re: [44net] Basic help needed with Linux and rip44d
by kb9mwr＠gmail.com 20 Jun '13

20 Jun '13

Jesse, Here are my notes: http://www.qsl.net/k/kb9mwr//wapr/tcpip/rip44d.html The endpoints are populated by the RIP routes that are received. You can run the dameon in verbose mode, and periodically check how the route table is being manipulated with the command "route" As for why you can ping two machines on the same subnet, it sounds like a conflicting route. Again what does "route" show you? Steve, KB9MWR

1 0

rip44d
by sp2lob＠tlen.pl 19 Jun '13

19 Jun '13

Hello, Been curious and just wanted to give a try running rip44d... Downloaded: https://github.com/hessu/rip44d Followed exactly procedure decribed here: http://wiki.ampr.org/index.php/Rip44d Executed: linux~/rip44d$sudo ./rip44d -v found local address: 192.168.0.101 found local address: 44.165.2.1 found local address: 127.0.0.1 found local address: 44.165.2.2 found local address: 44.165.2.2 found local address: 44.165.2.2 found local address: 44.165.2.2 found local address: 44.165.2.2 opening UDP socket 520... entering main loop, waiting for RIPv2 datagrams Waited more than half an hour and... nothing happend at all. According to a/m source, “Amprgw transmits the RIP routing table updates every 5 minutes” Does Amprgw still broadcasts RIPv2 info? Best regards Tom - sp2lob

3 8

Official resource of 44net allocations
by Jann Traschewski 19 Jun '13

19 Jun '13

Hi, what is the official resource of 44net allocations? http://noh.ucsd.edu/~brian/amprnets.txt disappeared and as my understanding http://portal.ampr.org/networks.php is the new source. Are former allocations completely removed? Archive from 2007: http://www.eastnetpacket.net/files/amprnets.txt Even http://portal.ampr.org/networks.php seems not to be the place with latest changes. At least I'm aware of an allocation of 44.188.128.0/20 (Russia D-Star) and 44.168.0.0/16 (France HAMNET). How can we keep track of latest allocations? Thank you, 73, Jann DG8NGN -- Jann Traschewski, Lenbachstr. 6, D-90489 Nuernberg, Germany Tel.: +49-911-696971, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn

2 2

Mikrotik and NET44 ?
by Claudio Chicon 18 Jun '13

18 Jun '13

Hello, Anyone using mikrotik to do with the network encap 44? Tanks and 73/s Claudio PY3NZ

2 1

unable to process Allocation request
by Marc, LX1DUC 18 Jun '13

18 Jun '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good evening, I have been trying to get information about this issue via other channels, unfortunately I don't seem to have the correct contact data. As a "simple" end-user I created an allocation request, which was sent to the manager account for the end-user's location. The email contained this link: https://portal.ampr.org/coord_ip_requests.php?a=edit&id=266 The page request me to login, however after login (using the manager account) no information about the allocation request is shown, instead the regular welcome page is shown. Pasting the URL into the browser URL bar again brings up the request to login again. So somehow I'm unable to process the allocation requests. I have no clue how to solve this issue, could someone point me into the right direction please? 73 de Marc, LX1DUC - -- http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRvO23AAoJEHFIN1T8ZA8vrr8P/jKo+ImFclLPg7QOl+TB8MaI ThcAxxpWqBd1aN5Jv2RSm8Yx4TgpfS+59u3xDnbCqtJw66mSEChTTnt5fUESpYo3 604XYuRxEfL6oyXLPR19bmQWhb1J7dKOcwzTDQvRkqa8IAg7aP1m3R7tN13fvQAV 7GL3F/csxeG7XHxXxwy60V0tR50MFmI7dSeXdGNS7FyzZlzfUwRFuSv0nXMEl6uj 2DdlT0BVQtDkv6d128a2+5xL1UV3IOx8osI4mmUGcK3i9+aS8NhQXp83D9O1j3Wa 6SPo2DlLFfHzqRnEe/wWZ1/ExzBb+CZNx3jheDfm8ULGpprnYcM43xDOObyjN/NS Zx1nL/eVDI6LQa8IlcNIYR/E5I6yDDYwQXoGF5n5mrm0kx3Uqo3PbkE7TwmGmRP+ ld/NMZWHrE5tK5hZ7rvaF392feP6H4ORj68nWCSJhrOZ/BUeTNibwm+c3YDyH7tD R3EAYUkE+Uek+tb47tdpJfstOzAHwlKDMFXT67LSygP4AQs2hdBSaF2NVWIy/Tbb BNGw+qB/SqP+FYWTolKn/FuLdte1yfarZWIfQDLLVWUWF6QtDNct8iY4k/FlYxIw Gfn85KMzciyPzjSWAVRQedAHQKl4Dvfmfxo8I4kSLo+Bn5sXCIaMOZL+xnJ9KK0P rgE4ZH8TrkMVL+M0cypB =cxg6 -----END PGP SIGNATURE-----

2 2

Re: [44net] Cisco/juniper configs?
by Bryan Fields 18 Jun '13

18 Jun '13

On 6/18/13 6:50 AM, Jerald A DeLong wrote: > >> The Florida coordinator said I should be good to go with this once I got the >> assignment completed, is this not the case? > > This *not* at all what I told you and I have all the email I sent you. > We can discuss further off the list. To the list, It was a misunderstanding on my end, Jerry was correct on this. Sorry for the confusion, didn't intend to ruffle any feathers. The process here is a bit different than I'm use to, and I'm still learning all the procedures of 44net. I'm excited to be a part of this, and it's got me excited to be involved with high-speed radio again. Brian's hit me up off list and we have ball rolling. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] Cisco/juniper configs?
by Bryan Fields 18 Jun '13

18 Jun '13

On 6/17/13 8:46 PM, Cory (NQ1E) wrote: > 10 with permission and 10 announcements seen on the net (in addition to the > /8). It's good that nobody is trying to do it without permission ;) This actually brings up a good question, as some point this weekend I'll have 44.98.254.0/24 announced via BGP out of 12083. The Florida coordinator said I should be good to go with this once I got the assignment completed, is this not the case? I'd be willing to put some hardware/bandwidth/colo towards an east coast gateway for the 44net if we have an architecture that would work for distributing our interconnection points. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

3 2

Re: [44net] Cisco/juniper configs?
by kb9mwr＠gmail.com 17 Jun '13

17 Jun '13

bryan at bryanfields.net wrote: >I'd ask, why only one gateway to 44/8? Why not setup some tunnel/peering >points globally? That is a plan. There just needs to be some folks to step forward to make it happen. Until recently, there wasn't a formal way to seek permission from ARDC to have the high level BGP routing changed to support this. I have been curious since ARDC announced that option, how many/which local subnets are not being announced locally. Maybe Brian Kantor can chime in on that. Steve

7 10

Re: [44net] Cisco/juniper configs?
by Bryan Fields 17 Jun '13

17 Jun '13

Awesome, please send me the script. Ill have time tear into it this weekend. As for hardware, I'll bet testing on a 2800 series with 1gb of ram. Jason R Begley <jayray(a)digitalgoat.com> wrote: >(Please trim inclusions from previous messages) >_______________________________________________ >With regard to using Cisco routers for integration into the AMPRNET, if > >you are going to load full tunnels be ready to throw some descent >hardware at the task. The first issue is the config length, you need >config compression on and no less than a 2600 due to nvram size. The >other issue is number of interfaces, you also need at least a 2600 to >configure the number of tunnels needed to be fully meshed. I am >currently running a 2651xm and it does an ok job. Let me know if you >are >interested in a script to convert the encap.txt into a loadable config. >73, >Jason KY9J >_________________________________________ >44Net mailing list >44Net(a)hamradio.ucsd.edu >http://hamradio.ucsd.edu/mailman/listinfo/44net >http://www.ampr.org/donate.html -- Bryan Fields 727-409-1194 http://bryanfields.net

1 0

Re: [44net] Cisco/juniper configs?
by Bryan Fields 17 Jun '13

17 Jun '13

On 6/17/13 2:04 AM, kb9mwr(a)gmail.com wrote: > > Many gateway opperators only allow inbound 44-net IP addresses. > > Maintain a local route table alleviates bandwith issues at ucsd, and > the single point of failure. Thanks, this is good info. I think I can change the "munge" script to generate a working 44/net config. Cisco/etc is going to need a tunnel interface for each destination, but I think it will work. Perhaps a template interface might be the best way. I'll post my results back here. I'd ask, why only one gateway to 44/8? Why not setup some tunnel/peering points globally? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

Re: [44net] Cisco/juniper configs?
by kb9mwr＠gmail.com 17 Jun '13

17 Jun '13

Bryan, I have some archived resources here: http://www.qsl.net/kb9mwr//wapr/tcpip/index.html --- But if I can reach all of 44/8 via ucsd via the internet, why bother with tunnels in the first place? -- Many gateway opperators only allow inbound 44-net IP addresses. Maintain a local route table alleviates bandwith issues at ucsd, and the single point of failure.

1 0

Re: [44net] Cisco/juniper configs?
by Bryan Fields 17 Jun '13

17 Jun '13

On 6/17/13 1:53 AM, C.J. Adams-Collier KF7BMP wrote: > If you decided to go this way, you could use a perl script with Net::SSH > to update the router's config. At least with IOS. I'm not familiar > with JunOS. Yea, I was thinking this. I have RANCID running on all the routers now, so it's trivial to get it to push configs out once a day or so. But if I can reach all of 44/8 via ucsd via the internet, why bother with tunnels in the first place? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net