- 44net - mailman.ardc.net

by Heikki Hannikainen

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.

11 years, 11 months

10
20
0 0

Running on RPi. Still got issues

by Mark Phillips

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

11 years, 11 months

2
1
0 0

Thanks IP GURUS

by Demetre SV1UY

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

11 years, 11 months

4
3
0 0

Re: [44net] Tunnel issues with rip44d

by Pieter Luteijn

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...

11 years, 11 months

8
10
0 0

rip44d problem

by Demetre SV1UY

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

11 years, 11 months

5
9
0 0

Anyone know who's using .....

by Mark Phillips

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

11 years, 11 months

3
2
0 0

Gateway updates

by Neil Johnson

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

11 years, 11 months

2
1
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 107

by Rob Janssen

> 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

11 years, 11 months

1
0
0 0

IP address management

by Rob Janssen

> 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

11 years, 11 months

6
6
0 0

Re: [44net] gateways sunset

by kb9mwr＠gmail.com

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

11 years, 11 months

2
1
0 0

Re: [44net] question regarding amprgw.sysnet.ucsd.edu

by lleachii＠aol.com

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

11 years, 11 months

3
5
0 0

Отн.: Re: ipip tunnel

by Miroslav Nikolov

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

11 years, 11 months

1
0
0 0

gateways sunset

by Brian Kantor

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

11 years, 11 months

6
6
0 0

ipip tunnel

by lz4ny＠mail.bg

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…

11 years, 11 months

1
0
0 0

Re: [44net] gateways sunset

by Rob Janssen

> 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

11 years, 11 months

1
0
0 0

question regarding amprgw.sysnet.ucsd.edu

by Blaine Forbort

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

11 years, 11 months

6
12
0 0

Re: [44net] gateways sunset

by kb9mwr＠gmail.com

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

11 years, 11 months

3
2
0 0

Re: [44net] ampr.org DNS name add and update ?

by Wm Lewis

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

11 years, 11 months

1
0
0 0

ampr.org DNS name add and update ?

by lz4ny＠mail.bg

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

11 years, 11 months

1
0
0 0

amprgw bandwidth

by Neil Johnson

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

11 years, 11 months

1
0
0 0

Re: [44net] Distributed BGP Announce

by Rob Janssen

> 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

11 years, 11 months

2
1
0 0

On The Air

by Bill Vodall

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

11 years, 11 months

15
23
0 0

Re: [44net] Distributed BGP Announce

by Bryan Fields

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

11 years, 11 months

3
2
0 0

Receiving routes with conventional RIP

by Neil Johnson

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

11 years, 11 months

6
8
0 0

Tunnel issues with rip44d

by Neil Johnson

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

11 years, 11 months

2
3
0 0

Why is Linux box necessary?

by YT9TP op. Pedja

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

11 years, 11 months

10
13
0 0

Re: [44net] Distributed BGP Announce

by Bryan Fields

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

11 years, 11 months

3
6
0 0

Newbie issue

by lleachii＠aol.com

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

11 years, 11 months

15
65
0 0

TAPR/ARRL DCC 2013

by Brian Kantor

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

11 years, 11 months

4
3
0 0

Services That Can Run on 1K2/9K6 RF

by n2nov＠n2nov.ampr.org

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?

11 years, 11 months

1
0
0 0

Re: [44net] On The Air

by Bryan Fields

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

11 years, 11 months

3
2
0 0

Re: [44net] Distributed BGP Announce

by Bryan Fields

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

11 years, 11 months

2
1
0 0

Re: [44net] On The Air

by Bryan Fields

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

11 years, 11 months

1
0
0 0

Re: [44net] Distributed BGP Announce

by Bryan Fields

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

11 years, 11 months

2
1
0 0

Re: [44net] On The Air

by kb9mwr＠gmail.com

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?

11 years, 11 months

3
2
0 0

BGP / Tunnels / JNOS

by K7VE - John

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

11 years, 11 months

4
4
0 0

Re: [44net] Distributed BGP Announce

by Bryan Fields

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

11 years, 11 months

8
19
0 0

Re: [44net] Distributed BGP Announce

by Bryan Fields

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

11 years, 11 months

2
1
0 0

Posting From My AMPR.ORG Address

by n2nov＠n2nov.ampr.org

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

11 years, 11 months

1
0
0 0

BGP / Tunnels / JNOS

by K7VE - John

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>

11 years, 11 months

1
0
0 0

BGP / Linux / Tunnels / JNOS

by John D. Hays

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>

11 years, 11 months

1
0
0 0

Re: [44net] On The Air

by Bryan Fields

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

11 years, 11 months

2
1
0 0

Distributed BGP Announce

by Marc, LX1DUC

-----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-----

11 years, 11 months

2
3
0 0

Re: [44net] Distributed BGP Announce

by Bryan Fields

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

11 years, 11 months

1
0
0 0

Re: [44net] (no subject)

by kb9mwr＠gmail.com

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

11 years, 11 months

1
0
0 0

Re: [44net] directly connected and tunnel subnets

by Bryan Fields

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

11 years, 11 months

12
18
0 0

(no subject)

by kb9mwr＠gmail.com

k9eam ?

11 years, 11 months

1
0
0 0

(no subject)

by kb9mwr＠gmail.com

k9eam ADD A 138.74.255.4

11 years, 11 months

1
0
0 0

Re: [44net] directly connected and tunnel subnets

by kb9mwr＠gmail.com

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

11 years, 11 months

2
1
0 0

Re: [44net] directly connected and tunnel subnets

by Bryan Fields

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

11 years, 11 months

2
1
0 0

Re Networks in OZ

by VK4FQ/VK4TTT Sam

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)

11 years, 11 months

16
47
0 0

portal: database damage

by Brian Kantor

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 -----

11 years, 12 months

2
3
0 0

Re: [44net] Re Networks in OZ

by Bryan Fields

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

11 years, 12 months

2
1
0 0

Connectivity to AMPRnet and video

by Jesse Hindmarsh

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

12 years

3
4
0 0

Re: [44net] hardware vs. software

by lleachii＠aol.com

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

12 years

3
7
0 0

Re: [44net] Use of higher bands

by Michael E. Fox - N6MEF

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

12 years

6
9
0 0

Re: [44net] hardware vs. software

by Michael E. Fox - N6MEF

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.

12 years

7
17
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 84

by Rob Janssen

>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

12 years

2
1
0 0

Re: [44net] a common vendor neutral hardware/software stack for 44net. - was Re: hardware vs. software

by kb9mwr＠gmail.com

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?

12 years

3
3
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 83

by Bryan Fields

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

12 years

1
0
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 83

by Rob Janssen

>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

12 years

3
2
0 0

a common vendor neutral hardware/software stack for 44net. - was Re: hardware vs. software

by Eric Fort

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 >

12 years

7
11
0 0

Hessu

by Brian Rogers

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

12 years

1
0
0 0

Re: [44net] DMVPN routing for 44/8 subnets

by Bryan Fields

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

12 years

6
10
0 0

DMVPN routing for 44/8 subnets

by jesse＠hindmarsh.cc

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

12 years

5
7
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 78

by Rob Janssen

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

12 years

2
1
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 77

by Rob Janssen

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

12 years

3
2
0 0

Re: [44net] Basic help needed with Linux and rip44d

by lleachii＠aol.com

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

12 years

4
5
0 0

Contact needed please

by Brian Rogers

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

12 years

1
0
0 0

Re: [44net] ampr.org dns zone delegation

by kb9mwr＠gmail.com

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

12 years

1
0
0 0

ampr.org dns zone delegation

by Eric Fort

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

12 years

2
1
0 0

address block assignments for groups

by Eric Fort

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

12 years

5
6
0 0

Basic help needed with Linux and rip44d

by jesse＠hindmarsh.cc

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

12 years

2
2
0 0

Re: [44net] Basic help needed with Linux and rip44d

by kb9mwr＠gmail.com

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

12 years

1
0
0 0

rip44d

by sp2lob＠tlen.pl

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

12 years

3
8
0 0

Official resource of 44net allocations

by Jann Traschewski

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

12 years

2
2
0 0

Mikrotik and NET44 ?

by Claudio Chicon

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

12 years

2
1
0 0

unable to process Allocation request

by Marc, LX1DUC

-----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-----

12 years

2
2
0 0

Re: [44net] Cisco/juniper configs?

by Bryan Fields

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

12 years

1
0
0 0

Re: [44net] Cisco/juniper configs?

by Bryan Fields

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

12 years

3
2
0 0

Re: [44net] Cisco/juniper configs?

by kb9mwr＠gmail.com

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

12 years

7
10
0 0

Re: [44net] Cisco/juniper configs?

by Bryan Fields

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

12 years

1
0
0 0

Re: [44net] Cisco/juniper configs?

by Bryan Fields

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

12 years

2
1
0 0

Re: [44net] Cisco/juniper configs?

by kb9mwr＠gmail.com

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.

12 years

1
0
0 0

Re: [44net] Cisco/juniper configs?

by Bryan Fields

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

12 years

2
1
0 0

Re: [44net] Cisco/juniper configs?

by Bryan Fields

On 6/17/13 1:25 AM, Heikki Hannikainen wrote: > It's intended to be totally separate, but there's a single gateway in > the US announcing all of 44/8 and relaying packets from the Internet > to amprnet hosts which have an ampr.org DNS entry in place. Also, a > few local subnets are announced locally by the gateways using BGP, > after signing the TOS (http://www.ampr.org/tos.txt) and obtaining > permission documents from ARDC. > > Upstream amprnet->internet packets should be routed, if possible, from > the local gateway directly to the Internet, but ISP anti-spoofing > filters / uRPF typically prohibit it these days (which is a very good > thing in the botnet/DDOS respect). Unless, of course, you've arranged > a BGP peering and announcing the subnet yourself, in which case you > can send packets out from that subnet. My intention was just to use a VRF on my main colo router for the 44net space, and keep it separate from everything else. I'm routing this over a tunnel back to my home and from there out to my wireless links. Right now I have 5 links all running with 172.17/16 space and thought it would be cool to link it all with "real" IP's. So for the exception of the 44/net space directly announced, can everything be reached via the gateway at ucsd? Does this gateway have tunnels to the rest of the network behind it? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

12 years

1
0
0 0

CentOS 5-Baycom-Card I/O Help please

by Janusz Przybylski SP1LOP

POL: Potrzebuje pomocy. Jak modem podłączę pod ttyS0 (iobase 3f8 irq 4) na płycie głównej modem działa idealnie nadaje i odbiera. A jak podłączę go do ttyS1 (iobase 2400 irq 177) na karcie I/O to tylko odbiera nie chce nadawać ENG: I need help. How do I plug the modem into ttyS0 (iobase 3f8 irq 4) on the main board modem works perfectly transmits and receives. And when I connect it to ttyS1 (iobase 2400 irq 177) on the I/O just does not want to give answers ------ POL: Mam komputer z 2 modemami Baycom Linux CentOS 5, Kernel 2.6.18-274.18.1.el5ax25.2, używam sterownik: baycom_ser_fdx ENG: I have a computer with two modems Baycom Linux CentOS 5 Kernel 2.6.18-274.18.1.el5ax25.2, I use the driver: baycom_ser_fdx ------ POL: Używam modemów Baycom, podłączone do karty I/O PCI Modemy tylko odbierają (Rx) ale nie nadają (not Tx) ENG: I use Baycom modems, connected to the I/O PCI Modems only receive (Rx), but does not transmit (Tx not) ------ POL: A to konfiguracja karty I/O z komendy: lspci -vvv ENG: And this is the configuration I/O card with the command: lspci-vvv Serial controller: Device 4348:3253 (rev 10) (prog-if 02 [16550]) Subsystem: Device 4348:3253 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 177 Region 0: I/O ports at 2400 [size=8] Region 1: I/O ports at 2000 [size=8] Kernel driver in use: serial ------ ttyS0, iobase: 0x03f8, irq: 4 (mainboard) ttyS1, iobase: 0x2400, irq: 177 (Card I/O) ttyS2, iobase: 0x2000, irq: 177 (Card I/O) ------ baycom_ser_fdx: version 0.10 compiled hdlcdrv: version 0.8 compiled POL: Może ktoś mi powie dlaczego na ttyS0 działa idealnie a na karcie I/O tylko odbiera .... Gdzie mam błąd. Może w baycom_ser_fdx.c ??? ENG: Can someone tell me why the ttyS0 works perfectly and on the I/O only .... Where do I receive an error. Maybe baycom_ser_fdx.c??? -- 73 de Janusz / SP1LOP ===== Janusz J. Przybylski, SP1LOP ================== Poland AMPRNet Co-ordinator [44.165/16] from Mar 2003 =====================================================

12 years, 1 month

3
4
0 0

VPN access to AMPRNet using amateur X.509 certificates

by Heikki Hannikainen

Hi, The AMPRNet might be more useful if it had: (1) more services which would be interesting to hams (2) more access to the AMPRNet Tonight I tried to attack (2) a bit. Access to the AMPRNet over the Internet could maybe be made easier to hams by allowing them to connect over VPNs instead of setting up their own IPIP tunnels at home, or trying to find a working radio gateway. After getting a VPN running it might be easier for them to set up a radio gateway, or some services. As discussed on the other mailing list, VPNs are easier to get up on NATed residential networks than IPIP tunnels. Setting up VPN user accounts and maintaining them can be a pain. It doesn't take a lot of weekly or monthly maintenance work to run a VPN service, but it can be a major pain to manage an user account database for thousands of hams and check if your users around the Internet are, in fact, licensed. It turns out that ARRL's Logbook of the World has already given out cryptographic X.509 certificates to 57334 amateur users, after verifying their license status against the FCC database (they send a postcard with a random token code to the FCC-listed snail-mail address to make sure they give the certificate to the right guy) or after looking at a paper photocopy of a license + a photo ID. I had to physically mail in a photo of my ham license and my driver's license and wait a couple weeks to get the cert. If they can get 50k contesters and DXers to work with certificates, maybe certs can work for the AMPRnet, too. Technically, we can validate if a VPN user is in possession of one of those certificates and the respective private key. Politically, K4JH asked the ARRL guys, and they said that they don't mind if we use them for other ham authentication needs. We can start accepting other CAs too once they come around. I plan to help SRAL, the Finnish amateur radio union, to set up a CA within their web site (they already have user accounts for members). I know ARRL isn't for everyone, but smaller clubs could set up CAs too, or even commercial entities - as long as we trust them to do the license validation in a proper manner. Tonight I hacked up an OpenVPN setup which authenticates users with LoTW certs, and wrote a little documentation: http://wiki.ampr.org/index.php/AMPRNet_VPN What do you think? Technically, it seems to work - try it out if you like. It's not very straightforward to set up, but the license validation is pretty strong, and running the service shouldn't be a lot of work. There can be many VPN servers around the world, serving the whole customer base (VPN servers do not need access to any central user database, they just need the certificates of the trusted CAs). With a little Dynamic DNS magic, you could get a oh7lzb.vpn.ampr.org hostname on DNS within a few seconds after connecting (I've got code for that in another project). (Yes, eventually certificates need to be revoked after they accidentally get into wrong hands, or ham licenses are revoked. Technically that can be done using CRLs and/or OCSP, but ARRL apparently does not do those yet. Maybe they will, if the need arises. We can also set up a blocked certificates list of our own.) - Hessu, OH7LZB

12 years, 1 month

5
5
0 0

Fwd: JNOS / RIP

by kd6oat

It's been a while since I encountered this problem I have forgotten the fix. My JNOS has stopped populating routes broadcast by the rip server. I've verified that I am receiving the broadcasts through tun0 and there have been no changes to my autoexec.nos file in a long time. I think routing via rip stopped sometime within the past few days. Any ideas ? tx ~Ken

12 years, 1 month

2
2
0 0

[newbie] So I'm all connected...

by Matt Grice

...I have my machine all set up to route packets through my local gateway(I was originally going to tinker with high speed mesh networks but an equipment supplier let me down) and I got thinking: what kind of services are intended to run over the new improved 44net? I've being lurking, and I see are discussions on VPNs, routing and stuff but nothing higher up the stack. Web servers? Twitter-like services? Bulletin boards? POP3? What can we *do* with it? Please forgive me for asking this question! I get the feeling everyone else is up to speed except me! 73 de Matt M0ZAI

12 years, 1 month

2
1
0 0

Re: [44net] dd-wrt and ipip

by kb9mwr＠gmail.com

I am using the standard, gateway mode. I assume yours is set to Router?

12 years, 1 month

1
0
0 0

dd-wrt and ipip

by kb9mwr＠gmail.com

Well I don't know what to tell you. I should really try DD-WRT on other hardware to see if it behaves differently (I can't imagine so) I have the standard dd-wrt build, Firmware: DD-WRT v24-sp2 (08/07/10) std on a Ubiquiti Router Station pro. With two terminals open on my linux server, one running rip44d -v and the other running tcpdump, and an entry in the portal, I see nothing. Shortly after I enable DMZ, set to 192.168.1.100 (my linux servers inside address) I see them. I logged into the DD-WRT terminal and ran iptables -L, before and after enabling DMZ in the GUI to see what it changes. the magic appears to be this line: target prot opt source destination ACCEPT 0 -- anywhere 192.168.1.100 This is under the Chain FORWARD (policy ACCEPT) That line is absent without DMZ enabled. I have no rules that specify a broadcast address. That is really the only way I can imagine IPIP reaching a machine on the inside of a network, without a specific forwarding rule directing it to a specific inside IP address. Lynwood, could you share a dump of your iptables -L (sanitize as needed) Curiosity has the best of me at this point. Steve, KB9MWR

12 years, 1 month

1
0
0 0

(no subject)

by kb9mwr＠gmail.com

Lynwood, Thanks for the info. It must have something to do with the mega version of DD-WRT that you are using. I am using the standard version, and it does not pass, even with the VPN passthough options enabled. I see the mega version has IPV6 support. Since that is usually tunneled, I suspect that is what makes it work for you. - Question for anyone. Is there anyway to use the ampr.org name service as a dynamic dns? For my IPIP gateway, and other ham radio related things, I have have been using dyn.com to provide a dynamic dns name. With the new http://dyn.com update policy,, makes me think the ham community could use a dynamic dns of their own.. anyone?

12 years, 1 month

1
0
0 0

Mikrotik and NET44

by Claudio Chicon

Hello good evening Would you like to receive examples of configuration of network mikrotik to 44 73/s Claudio PY3NZ

12 years, 1 month

2
1
0 0

(no subject)

by kb9mwr＠gmail.com

Lynwood, Please tell me more about your version of DD-WRT. I have: Firmware: DD-WRT v24-sp2 (08/07/10) std, and it does not pass IPIP rip packets, unless I enable DMZ. ------Clip---- It's noted that IPIP does not traverse firewalls, that is not the case with me, as I am traversing two firewalls to reach my Gateway server, both devices using using DD-WRT, and it appears to broadcast any packet that is not UDP or TCP. ......

12 years, 1 month

1
0
0 0

Re: [44net] VPN access to AMPRNet using amateur X.509 certificates

by kb9mwr＠gmail.com

Thanks for sharing that note about DD-WRT broadcasting any packet that is not UDP or TCP. I wouldn't mind compiling a list of other home grade gateway/modems that do or don't do the same, if anyone else has that info to share. To clarify my note about securing with IPtables, I was referring to the outside addresses. As in dropping all (non-44) inbound IP's that are not listed as a gateway. ------Quote------ All, A few points and questions: 1.) It's noted that IPIP does not traverse firewalls, that is not the case with me, as I am traversing two firewalls to reach my Gateway server, both devices using using DD-WRT, and it appears to broadcast any packet that is not UDP or TCP. In fact, I also run a IPv6 tunnel on a Vyatta instance in the same manner. Also, depending on the firewall's NOS, it can be permitted through configuration (granted, you must have control of that network device). 2.) KB9MWR asked if anyone was using a firewall or IPtables, I do firewall my 44 Network, and only permit forwarding on that network for 44 hosts (i.e. someone could send an enscapsulated packet for any AMPR subnet and it will be forwarded via my GW, all other IP addresses are dropped at the firewall). I also restrict/permit services to certain /32 IP addresses, etc. In addition, some hosts on my network are only available on AMPR and/or ACLs only permitting 44 hosts to use those services (e.g. my DNS ACL permits full recursion for 44 hosts and allows only 44.in-addr.arpa and ampr.org resolution for all others). 3.) Would this VPN system allow me to use my 44Net allocation, or only the allocation located at the VPN server itself? 4.) It is my understanding that the ARRL CA is not online, this would require manual revocations, manual trusts (I'm not very familiar with VPN via certificate)? 73, Lynwood KB3VWG

12 years, 1 month

1
0
0 0

(no subject)

by kb9mwr＠gmail.com

OpenVPN does this by default. It always assigns the same IP based on the client certificate. That mapping is stored in /etc/openvpn/ipp.txt Here is some documentation I have been working on. I see I didn't explain that part very well. http://www.qsl.net/kb9mwr/wapr/tcpip/openvpn.html 73' Steve, KB9MWR ------Quote------ I was wondering if it were possible for a VPN server package to consistently assign a specific, reserved IP address to a VPN client based on the authenticating certificate. The scope of the VPN server would be subject to the region/subnet coordinating contact, such as a portion of: Gateway area: 44.80.32/24 Central Pennsylvania Thanks for your consideration. 73, Jim A. KB3TBX

12 years, 1 month

2
1
0 0

Assigning IP addresses

by Jim Alles

I was wondering if it were possible for a VPN server package to consistently assign a specific, reserved IP address to a VPN client based on the authenticating certificate. The scope of the VPN server would be subject to the region/subnet coordinating contact, such as a portion of: Gateway area: 44.80.32/24 Central Pennsylvania Thanks for your consideration. 73, Jim A. KB3TBX

12 years, 1 month

2
2
0 0

R: Re: VPN access to AMPRNet using amateur X.509 certificates

by renzorossi＠libero.it

Ciao Hessu,To answer shortly...a) Connecting via OpenVPN we permit to access to all of 44/8 amprnet, to all our "private" management network 10/8; we are vorking just these days to publish to big Internet radioham services reaching CisarNet via OpenVPN, using static 44.208/16 ip addresses directly routed to big Internet (under amprnet agreement);b) More or less we are using the same verify procedure around amprnet...We could not say that it is a strong authentication or biometrics solution, but it's working ;-): are you interested on ?c) We are using 44.208/16 addresses also directly on radio link, for radioham purpose but exposed on big Internet. In some case VPN links are used to backup radio link (using OSPF routing protocol with different weighted routes), and we are simply considering big Internet as Radio...so, same rules! Full compliance to regulatories and amprnet policy. Concluding, at the beginning we supported OpenVPN extension to try to find an easy "workaround" when you have not radio connection to CisarNet/amprnet, nor a public ip address for tunneling using ip2ip, but at the same time you'd like to connect to CisarNet and/or amprnet. Now, in a classic solution, you have a main gateway using OpenVPN client connect to CisarNet backbone, and your "local" ham wireless network around you covering your near towns. In this way we consolidated new isolated wireless radioham small networks, using ready-to-connect CisarNet ip addressing, rules, services, and so on. Ciao from Italy. Thank you for this opportunity to "compare" different approach, I believe anyway both of them are interesting. IW0SAB Renzo. I'm not sure if I understood right... just to check, are you allowing access to all of 44/8 amprnet via this VPN? Or just to your local 10.x network over there? Are you giving VPN access to anyone with a common signed key? Do you somehow verify that those users are amateurs, or can anyone download the key+certificate from somewhere? Our regulations over here prevent us from using crypto on radio, which is good and fine. The regulations don't prohibit using crypto on the Internet. The VPN provides strong authentication, the encryption is a side-effect which does not really matter much to one direction or the other. We need to do authentication and license verification to prevent non-ham access to the radio channels - looking up from logs afterwards isn't of much use. - Hessu

12 years, 1 month

1
0
0 0

Re: [44net] VPN access to AMPRNet using amateur X.509 certificates

by kb9mwr＠gmail.com

I never really had an interest in log book of the world till now. So I just signed up, and awaiting their postcard or whatever. Using those certificates sure seems like a logical way to keep the network secure. I have been wondering if anyone running a IPIP gateway applies any security by locking it down with iptables to only the other known gateways. Perhaps this could be worked into rip44d as an option? This is essentially what D-Star the dssecd D-STAR Gateway security enhancement application/daemon does. At that point the only issue is who is allowed to create a gateway in the portal. And perhaps that is where this ham verification technique could be applied.

12 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net