- 44net - mailman.ardc.net

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

17 Jun '13

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

1 0

CentOS 5-Baycom-Card I/O Help please
by Janusz Przybylski SP1LOP 09 Jun '13

09 Jun '13

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

3 4

VPN access to AMPRNet using amateur X.509 certificates
by Heikki Hannikainen 07 Jun '13

07 Jun '13

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

5 5

Fwd: JNOS / RIP
by kd6oat 31 May '13

31 May '13

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

2 2

[newbie] So I'm all connected...
by Matt Grice 28 May '13

28 May '13

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

2 1

Re: [44net] dd-wrt and ipip
by kb9mwr＠gmail.com 20 May '13

20 May '13

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

1 0

dd-wrt and ipip
by kb9mwr＠gmail.com 19 May '13

19 May '13

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

1 0

(no subject)
by kb9mwr＠gmail.com 18 May '13

18 May '13

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?

1 0

Mikrotik and NET44
by Claudio Chicon 18 May '13

18 May '13

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

2 1

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

17 May '13

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

1 0

Re: [44net] VPN access to AMPRNet using amateur X.509 certificates
by kb9mwr＠gmail.com 15 May '13

15 May '13

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

1 0

(no subject)
by kb9mwr＠gmail.com 15 May '13

15 May '13

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

2 1

Assigning IP addresses
by Jim Alles 15 May '13

15 May '13

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

2 2

R: Re: VPN access to AMPRNet using amateur X.509 certificates
by renzorossi＠libero.it 14 May '13

14 May '13

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

1 0

Re: [44net] VPN access to AMPRNet using amateur X.509 certificates
by kb9mwr＠gmail.com 14 May '13

14 May '13

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.

1 0

Re: [44net] private tunnel?
by kb9mwr＠gmail.com 14 May '13

14 May '13

I realized it was a return route issue on my way to work yesterday. It's all working now. Thanks again ------------ Quote ------------ One thing to check would be if the VPN client has a route for 44/8 pointing through the VPN ("ip route" on the client). The VPN server should give the client the route using a directive in the server config: push "route 44.0.0.0 255.0.0.0"

1 0

R: VPN access to AMPRNet using amateur X.509 certificates
by renzorossi＠libero.it 14 May '13

14 May '13

Ciao Hessu, just to share our experience in using OpenVPN solution to access CisarNet (http://wifi.cisar.it for the map, http://www.cisarnet.it for other services, ...), Before to setup the solution (about three years ago), inside our working group we discussed about using named certificates, Certification Authority, user registration process, crypto and so on... At the end, we decided just to share one only common signed key, and also permit free guest access without user identification (just as equivalence to radio Push-To-Talk button), no crypto (for regulatory compliance in several country for radio ham radio communication, Italy included). Storing logs permit us to be compliant to law about taking care of timestamp, ip source of the VPN client peer and destination ip public address. Also, in this way we are extending in Italy the usage of amprnet, by managing directly the CIDR 44.208/16 subnet as Internet IP public Address. I hope this help you to know our point of view, a little different from yours, but also useful for share several experiences (thanks to your well done guide on ampr wikis). We'd like also to know your (and others) opinion about Italian Cisar association approach to OpenVPN access. Ciao from Italy. IW0SAB Renzo. >----Messaggio originale---- >Da: hessu(a)hes.iki.fi >Data: 08/05/2013 0.42 >A: "AMPRNet working group"<44net(a)hamradio.ucsd.edu> >Ogg: [44net] VPN access to AMPRNet using amateur X.509 certificates > >(Please trim inclusions from previous messages) >_______________________________________________ > >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 > >_________________________________________ >44Net mailing list >44Net(a)hamradio.ucsd.edu >http://hamradio.ucsd.edu/mailman/listinfo/44net >http://www.ampr.org/donate.html >

1 0

Re: [44net] private tunnel?
by kb9mwr＠gmail.com 14 May '13

14 May '13

Thanks for refreshing my memory. I am really rusty at this, since they have made home networking plug and play. I have IP forwarding enabled. root@ampr-test:~# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Could you give an example of what I need for iptables forwarding rules.? Steve

2 1

Dayton
by Donald Jacob 13 May '13

13 May '13

Anybody going to Dayton. Maybe we can have a quick(!) meetup Don Jacob WB5EKU

2 2

Re: [44net] private tunnel?
by kb9mwr＠gmail.com 13 May '13

13 May '13

I have been playing with openvpn. Works great to establish a connection to a remote firewalled host. Problem: I have a rip IPIP gateway. I have subnets 44.92.20.0/24 and 44.92.21.0/24 set in the portal 44.92.20.1 is my ampr gateway address. That is working, pingable. tunl0 Link encap:IPIP Tunnel HWaddr inet addr:44.92.21.1 Mask:255.0.0.0 UP RUNNING NOARP MULTICAST MTU:1480 Metric:1 RX packets:138952 errors:0 dropped:0 overruns:0 frame:0 TX packets:89710 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:37916347 (36.1 MiB) TX bytes:15979452 (15.2 MiB) I have a openvpn server also running on this box. It's address is 44.92.20.1. The client connecting is: 44.92.20.6 The server can ping the client, the client can ping the server. tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:44.92.20.1 P-t-P:44.92.20.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:12 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1184 (1.1 KiB) TX bytes:756 (756.0 B) I don't understand why 44.92.20.6 is not reachable from the outside world? (If nothing else, you'd think some simple route add command would make is so) And yes I have these routes for the IPIP gateway: /sbin/ip route add default via 169.228.66.251 dev tunl0 proto static onlink table 10 /sbin/ip rule add from 44.92.21.0/24 table 10 /sbin/ip rule add from 44.92.20.0/24 table 10 Can anyone see anything I am overlooking?

3 3

domain cleanup idea
by kb9mwr＠gmail.com 09 May '13

09 May '13

First, Hessu your VPN idea looks interesting. Hopefully I'll have some time in the coming weeks to give it a try. Thanks for your efforts. Regarding cleaning up the DNS. 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. So we gave it a shot, 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/CCiX4Upd It's not quite working, maybe someone who knows more can fix it? I get some errors about Undefined offsets. Steve, KB9MWR

1 0

use of 44-net behind NAT
by Jim Alles 01 May '13

01 May '13

from the wiki at http://en.wikipedia.org/wiki/AMPRNet: *44.128.0.0/16* *44.128.x.x is the testing subnet and consists of 65,536 (216) addresses. Much akin to 10.0.0.0/8, 172.16.0.0/12, 169.254.0.0/16 or 192.168.0.0/16, this is an unroutable private IP block<http://en.wikipedia.org/wiki/Private_network>. Connectivity to the rest of the network should be given through router gateways <http://en.wikipedia.org/wiki/Gateway_(telecommunications)> much as one would do with Network address translation<http://en.wikipedia.org/wiki/Network_address_translation> in any other private IP block.* There is no attribution to that statement, and nothing I could find at AMPR.org Is this the best way to address devices when doing NAT into a private network? Any issues? Or are there advantages to requesting assigned numbers? thanks & 73, Jim Alles

9 17

How to update DNS?
by Matt VK2RQ 01 May '13

01 May '13

I just made some requests via the AMPRNet portal to create some DNS records in the ampr.org domain, and the requests were rejected with the following remark: "DNS is not active yet, please subscribe to the 44-Net mailing list to keep advised of progress." I presume they are referring to this mail list. So, how do I get DNS records created in the ampr.org domain? I understand that in the past, there was an email robot, but I have been unable to find any details on how to use it. Can anyone point me in the right direction? Many thanks, Matt VK2RQ

7 7

Going Forward: IPv6
by Jim Alles 01 May '13

01 May '13

What are your thoughts about where do we go with IPv6? We (PSARC) are about to request a backbone connection with IPv6 addressing. What if I wanted to map an assigned 44net address to a IPv6 address? Or, is tunneling the answer? It looks like the possibilities are endless http://en.wikipedia.org/wiki/IPv6_transition_mechanisms Jim A.

1 0

tunnel alternates
by Jim Alles 30 Apr '13

30 Apr '13

Brian K.: *"This is precisely the situation that our longstanding method of tunnel gateways is designed to overcome. You do this by setting up a Linux host that is assigned a single PSU address, probably something that isn't too hard to do. You shouldn't need to have them open any holes in the firewall or ask for special treatment as long as the existing firewall allows IPIP (internet protocol #4) through, which most do because the firewall managers never thought to block it, and also because some VPN schemes used to use it. The PSU folks don't have to do anything about network 44 routing or BGP or whatever. You then get a subnet allocation from your regional AMPRNet IP address coordinator and register a gateway for that subnet (via the PSU address) on the portal. Voila', you now have a subnet of AMPRNet routed to your Linux host via IP-IP encapsulation, and through the technique of tunnel gatewaying that Linux host is now connected to the AMPRNet, albeit at a somewhat limited bandwidth."* * * I am not opposed to this, especially since I have not tried it yet. However, PSU has resources, that if they can be tapped, might enable PSARC do something equivalant to what USC is doing, but for the state of Pennsylvania. For one, to further experiment, and also to improve the bandwidth limitations down the road. The 'Backbone" connection I expect to get through PSU will be 1 gigabit/sec. If co-located w/ PennREN, we would be sitting on a statewide 10Gb/s middle mile network. And, that is IPv6 now. It would be a heck of a way to learn! 73, Jim A.

1 1

Re: [44net] use of 44-net behind NAT
by kb9mwr＠gmail.com 30 Apr '13

30 Apr '13

Jim, Your question sounds similar to one I just asked last week. In my case, convincing the IT department to forward IPIP to our internal address isn't likely. So I have been playing with OpenVpn, and started documenting things. It looks like it will do what I want. Requests will come to my IPIP Rip gateway, which will also double as an OpenVPN server, and I'll route the traffic though that statefull connection. I have been trying to track down notes/papers/documents that might be of use: http://www.qsl.net/k/kb9mwr//wapr/tcpip/index.html Speaking of which, does anyone else have any recommendations on things that have been written over the years? I swear I am the only ham in my local club that has at least a basic understanding of TCP/IP. So anything I can use to help explain things to newbies would be helpful. I usually just reference the O'Reilly Books, TCP/IP Administration comes to mind. Has anything ever been written explaining DNS records with a ham slant?

2 1

interesting problem
by Don Moore 24 Apr '13

24 Apr '13

A gateway had his internet address change yesterday and the new address was changed to the new address at the gateway successfully.. We've noticed that the RIP process has the correct address but the encap.txt file does not. Is there a problem at the gateway with the way it is handling the encap.txt file when data is changed? It appears that the old file is sent and not the new one.. 73, Don - ve3zda

3 4

Re: [44net] private tunnel?
by kb9mwr＠gmail.com 19 Apr '13

19 Apr '13

Excellent explanation Marius. So how does PPTP compare to openvpn? I have tried to find a good explanation for the various VPN types, hamachi, openvpn, pptp, etc.. haven't really found such yet.

3 2

Re: [44net] private tunnel?
by kb9mwr＠gmail.com 19 Apr '13

19 Apr '13

C.J. thanks for the examples. I think I know the answer to what I am going to ask, but.. Could an IPIP tunnel accomplish the same thing that OpenVPN can for the situation I described (NAT and no modification to a remote firewall)? Why not?

4 3

portal registration issue
by Geoff Armstrong VA7CWD 18 Apr '13

18 Apr '13

Hello, I have tried on a number of occasions to register on the Portal. I have not received a confirmation email once. Anyone else having this issue? Thanks, Geoff VA7CWD / VE7KA

2 2

private tunnel?
by kb9mwr＠gmail.com 18 Apr '13

18 Apr '13

I am running a gateway using rip, etc. I really only have wifi radio range to a couple other hosts. And that is working well. We have a couple other small wireless networks in town that I can't reach by radio. They could be connected to the internet but unfortunately would be behind firewalls that we cannot control. So till we get things realigned and such, I am looking for examples on how to create a private tunnel from my gateway to those locations. It doesn't really make sense to put another gateway in the portal, as I doubt the rip packets will pass though.

5 6

Re: [44net] private tunnel?
by kb9mwr＠gmail.com 17 Apr '13

17 Apr '13

Yes the separate clusters each have separate NAT/firewalls protecting them. Again, I am not going to be able to convince the people donating that bandwidth to set our internal ip on their network as a DMZ host. I plan to write about it, if I ever figure out how to punch a two way tunnel from me (a place where I have control over such things) to these places. What I envision is from the rest of the amprnet, 44.92.21.0/24 comes here via an IPIP tunnel; and various smaller chunks /29 or /28 go back out from here via some other capable tunnel to these remote sites till we convince folks we need to get something up on a decent tower. It doesn't need to be encrypted or authenticated, whatever is easiest and will do the job. --Quote-- I'm unclear on the topology of your network; I'm going to assume that the separate clusters each have a separate NAT/firewall protecting them. In that case, I believe you may get the IPIP traffic to pass through the NAT/firewall to the internal host by designating the internal host as a DMZ host. You would then register the NAT/firewall's public IP address as the gateway host. I'd wager it depends on the software in the NAT/firewall so some may do it and others may not. I heard that OpenWRT does handle IPIP encapsulation. I've not tried that myself so others who have done so should comment on whether this approach actually works. I'd much appreciate you writing up what you wind up doing and publish it on the wiki so others may share your experience. - Brian

6 6

Re: [44net] private tunnel?
by kb9mwr＠gmail.com 17 Apr '13

17 Apr '13

First off I don't claim to know much about VPNs and encapsulation. Everyone I talk to tells me openvpn should do what I want. I take it that is a state full type of connection? Brian, the problem I see if if I setup another rip44 listener gateway, how do I direct the encapped traffic to our natted, internal IP? An entry in the portal will get it to their router (outside address), but having them place a forwarding rule to get it from there to out 192 internet address probably won't happen. ---- Quote------ On Wed, Apr 17, 2013 at 12:38:01AM -0500, kb9mwr at gmail.com <http://hamradio.ucsd.edu/mailman/listinfo/44net> wrote: >* It doesn't really make sense to put another gateway in the portal, as I*>* doubt the rip packets will pass though.* The AMPRNet internal RIP packets from 'amprgw' are sent encapsulated, so if you can do IP-IP tunnels at all, the RIP should get through too. One way to see whether a firewall will pass IP-IP tunnels is to add its address as a gateway and see if you get tunnel traffic on the other side. Since the internal RIP is sent every 5 minutes, it can be a simple test of your incoming connectivity. - Brian

3 2

RIP44d issue/bug
by Marc, LX1DUC 12 Apr '13

12 Apr '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good morning, I saw some odd routing during my tests. So I analyzed the routes added by RIP44d. I modified the code to log the command string to add routes, my suspicions where confirmed: rip44d v1.2 adds every route with a prefix length of /32: (examples) Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.161.0.0/32 via 141.75.245.225 dev tunl0 window 840 onlink table 44 Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.129.0.0/32 via 118.22.1.194 dev tunl0 window 840 onlink table 44 Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.147.0.0/32 via 121.99.232.227 dev tunl0 window 840 onlink table 44 Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.183.0.0/32 via 130.208.168.63 dev tunl0 window 840 onlink table 44 Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.94.0.0/32 via 141.224.128.8 dev tunl0 window 840 onlink table 44 All these routes should be /16 I'm trying to figure where the issue comes from, but I'm not a perl addict, so any help is welcome. I have already confirmed that the RIP message contains the correct netmask: IP Address: 44.161.0.0, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.161.0.0 (44.161.0.0) Netmask: 255.255.0.0 (255.255.0.0) Next Hop: 141.75.245.225 (141.75.245.225) Metric: 1 73 de Marc - -- http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRVNjWAAoJEHFIN1T8ZA8vteEP/2oD1ic40dvnuZSOOdvS+NNw BZEaIlI9gmIZ6P2FqJO4ZOs/kXLdKnxDa9hNgAV5+4bZAZyiGQIHFd1+rwIAaZKN quzJ1h7SzYKOJYDRiMIQO8nYdDzNMYKb4H5GhSpCiDWGHnt+OJA+uV8ZXHClj7QV y2AvJDKgrcRaf3Lr4kwghVnIHlmqibxPI2fFv8DuG8sBvIkxjtUJ21MOUq6nJD8z HaCpJRS8169Syl3jq/8DogEvKfjkehaNmczyxWfWcN1t93Lxh+pPGu88iDhh1pNS 3CpVw7nY1aV88fQUURMNRJqB5IEDLyL9z/A6oU8t4u095SS6wj3wbzs7HpY37Oc4 UsLbqLlH88wkc1AnW5PrrzNLNyjEX4/3y1zywhwJFaVWUGRTAVKC3fB8Q4hhg0/M r6q5LfjbFJzvZYppvsoqDMCAYHsAcg5lTP92+I1/86avntSW1Kj8bIJnrr/wGfZz zbURMk+9U2WJlX6mnmm/Z0a/Lo+l3/T74CzXDDmr8dvEaMB9r7AeTx3M7h6H/jBi yNrFZtwCg/ZMDcCR8jtAN8dqNOYht5uL/+N9dPZy50cyMhLjxVItl6BXrUYdXGqD 2p8zXKjwc8iPLuirvXs3cFK4dioDyJviMDTPSXss01zMBpLqj80UVltIV+xmMRf9 x6fcW9WXhFYoLN56hrti =0CVp -----END PGP SIGNATURE-----

3 2

Re: [44net] Gateways Unreachable after Dynamic IP Update
by Marc, LX1DUC 11 Apr '13

11 Apr '13

It seems that you have found the very same issue I have already documented: http://hamradio.ucsd.edu/mailman/private/44net/2013-March/000848.html https://github.com/hessu/rip44d/issues/7 Unfortunately I haven't heard back from the author or someone else and I'm not a perl developer, so I cannot fix it myself. Best regards, Marc Quoting lleachii(a)aol.com: The populated route reads: 44.182.21.0 via 89.122.215.236 dev tunl0 onlink window 840 44.182.21.0 is a valid IP address on the ICANN Internet and does not imply a subnet in any form. It should contain a /24 notation as in the AMPRPortal: 44.182.21.0/24 via 89.122.215.236 dev tunl0 onlink window 840 No AMPR networks on my routing table (populated by RIP44d) contain the proper CIDR notations.

2 3

Re: [44net] Gateways Unreachable after Dynamic IP Update
by lleachii＠aol.com 07 Apr '13

07 Apr '13

Dear Bob VE3TOK (and thanks to VE3ZDA and N2NOV), Your entry is on my route table, I'm using rip44d (not encap), so my updates are live. The IP of my gateway is correct in the Portal. I use the -a switch to remove my own route (and have updated it to the correct IP); and I still receive rip44d updates over AMPR (showing that I have not lost connectivity to the Main AMPRGW). From testing connectivity to your subnet, I have determined that my 44GW is operational; and that some gateways may not have yet updated their encap. Thanks for your help; I waited a few days to to be sure that was not the case; as I know all stations do not have dynamic routing updates, I'll wait longer next time. 73, Lynwood KB3VWG http://44.60.44.10/tools @kb3vwg-015:~$ ping 44.135.85.1 -c 10 PING 44.135.85.1 (44.135.85.1) 56(84) bytes of data. From 44.135.85.30: icmp_seq=7 Source Quench From 44.135.85.30: icmp_seq=8 Source Quench From 44.135.85.30: icmp_seq=9 Source Quench From 44.135.85.30: icmp_seq=10 Source Quench --- 44.135.85.1 ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 9003ms @kb3vwg-015:~$ traceroute 44.135.85.30 traceroute to 44.135.85.30 (44.135.85.30), 30 hops max, 60 byte packets 1 kb3vwg-001.ampr.org (44.60.44.1) 0.724 ms 0.238 ms 0.218 ms 2 linux.ve3mch.ampr.org (44.135.85.151) 51.890 ms 55.835 ms 60.720 ms 3 port.ve3mch.ampr.org (44.135.85.30) 63.642 ms 62.613 ms 66.477 ms @kb3vwg-015:~$ ping 44.135.85.30 -c 5 PING 44.135.85.30 (44.135.85.30) 56(84) bytes of data. 64 bytes from 44.135.85.30: icmp_req=1 ttl=39 time=53.9 ms 64 bytes from 44.135.85.30: icmp_req=2 ttl=39 time=51.8 ms 64 bytes from 44.135.85.30: icmp_req=3 ttl=39 time=87.4 ms 64 bytes from 44.135.85.30: icmp_req=4 ttl=39 time=52.7 ms 64 bytes from 44.135.85.30: icmp_req=5 ttl=39 time=51.9 ms --- 44.135.85.30 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 51.899/59.607/87.406/13.919 ms

5 6

Overlapping gateway subnets
by Michael Fox - N6MEF 30 Mar '13

30 Mar '13

I know this is fine in regular IP routing, but is it o.k. with the AMPRgw? I have a gateway that serves a /28 address space. I'd like to do some testing using a couple of the addresses in that space on a different gateway. So, I'd like to add another gateway entry for just those two addresses without modifying the existing gateway entry for the /28. Regular IP longest match should prefer the /32 matches for the new gateway over the longer /28 match for the existing gateway. But before I implement, I wanted to verify whether or not this would be o.k. with the portal database, the amprgw RIP routing mechanism, etc. BTW, this would be a nice, generalized solution for a backup gateway. That is, if the more specific route goes away, the more general route could be used. So, is this o.k. to do or not? If not, why not? Thanks much, Michael N6MEF

4 5

Newbie issue
by Marc, LX1DUC 27 Mar '13

27 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello and sorry to bother you with this. I have added a gateway (46.29.183.253) via the portal and I have added subnets to it. I can see the encap.txt has been updated and I do receive RIPv2 Multicast Messages from 44.0.0.1. I have setup rip44d and it is populating my routing table. Example: #ip route get 44.0.0.1 44.0.0.1 via 169.228.66.251 dev tunl0 src 44.161.229.126 cache window 840 However when trying to ping 44.0.0.1 from 44.161.229.126 I don't get any replies. I have followed the outgoing ICMP packets, they get encapsulated on my gateway and the outer IP destination address is 169.228.66.251. The packet travels without troubles thru AS51405 (the home network of 46.29.183.253) and I can actually see the packet going out to the transit network (currently AS5577, in case you're interested). So I'm really really sure that the IPIP packet containing the ICMP echo request makes it out into the Internet. I have also ran traces on all of the ingress connections towards AS51405 and I cannot see a single coming back from 169.228.66.251. Is there anything I'm missing? I really appreciate your help. BTW I'm allowing inbound packets carrying protocol 4 and ICMP on the gateway, but as I don't see packets addresses towards my gateway in the upstream network, I'm guessing it's not the firewall on my gateway H-i. vy 73 de Marc, LX1DUC - -- http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRUrArAAoJEHFIN1T8ZA8vXkUP/38puOAwTWz38Y9UEinjz+HM kBLQKzeYUkVH/f1xjjVuqaiqzXss37XeAL9XeRIqkJ8znanWac8LznYl42Zvyrph BVaRvp6+M3m4CRnNpy7LuRFfTW+DVNIS88TR+jiD+GYxXFiXc7sQSL98ozPPHYSu QUl2pb4qqXXkVOmwjbcUami4HsBj18oCtcwE+qVwv73EBlW/S0ff6HiYawnuJPzK yznMEeStR58K1+9IfX+o6S406JT8VnBJDQ7W6WHU0aHv3qLA+FM7Mk5DBEtHJRE5 5lwkqFwq71XSmQAX2oGWaC1rTk6pBJoSgjGAEssioP7D1hqJAHuc2fR15zDQkxXW L7z39xc/J2z7sZleqlqldjeY9+7pA+w6opJTaZFjdMdf+yq/zuJPpWv36Pm616xy zPnNorLHwe2WJL79+4ZPzDZamp355ATO7LFF38sx8rHJiXGuP+wb1Udi2fSG9J1O 5jYM4XHKWQnVRdTeit2WkUoEW0c+pgN0nsQ4iReXEragXdmhnpXmQhagKZP10/S5 0TMplR1D/3LLVTMRnjhxyUfY9ZtA6dw1S9DyZQadeJh6Y0KD5QoistEOgXqMnoZS a+c5GN/cc/BSxdHrLnc+yk9FxjL+I2fuU6bwuf27fjcXuTSoGglqZMCMM636Rkj1 scOCTXhoQdfwIeA5aV/z =Yi7/ -----END PGP SIGNATURE-----

2 1

Questions
by Marc, LX1DUC 24 Mar '13

24 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good evening dear OMs, I'm really new to this Mailing-List. I have been reading through the information available online but I have a few remaining questions: - - Can there be more than 1 coordinator for one single area (e.g. 2 OMs handling a country conjointly)? - - Do the former tunnels still exist for delegations which haven't been moved/migrated to the new portal? (Or are they offline from the Internet side of things?) - - The new system/portal seems to favor a mesh network of tunnels, are intra-country tunnels (no directly connected to the AMPR gateway but connected via a local gateway (which in turn is connected to the AMPR gateway)) depreciated or unrecommended? - - When I checked a few years ago, very very few networks within 44.0.0.0/8 were announced in the DFZ (like 1 or 2), this seems to have increased. Is it recommended today to announce a delegation or parts of it directly? I'm sorry if these questions have been answered before, I really tried finding them, but I might have searched using the wrong terms/words. vy 73 de Marc, LX1DUC - -- http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRTip1AAoJEHFIN1T8ZA8vRPAP/0oCcMWjMfOnlvdYxsp3+wUY WVlwG92jKXVxrdXMKDVA+bqqyW6S5+xfMAA/nry0p+m/BbVOALLskcGeZncVspzu MjZzmC+9ueO1hRRiQ9F6gFN0X+tTHDCHJRdJo83J0W4acw8WgFTQv/hxk9DuvySt zzMJp7K0YKfh6bHsyvML4iePh4+Ra0B+3xyW8Dp0hnoesasRuCDBUSuENyp3NGL3 4fRH0FUYB29B+hbXH6aWZlbYe1DhwkrX7V/azeRmbDdgkTFBnfb/uj/+Sqp/H7d/ 80nznr/su/ylxiGgW+fmBcoosbXcGlCzQ75/wT2Hf54k40zOeCPLI37Chc8CRVGd /XgL/UyodGzg/SyJg0bQ/T63v969y/7xvdvUaXH182JyObNextPN+m5Ur6evMjIq s6KhiGoJoLTfFEv/pEIDPPnITSwyx7dWw8IzAUp+UbscbaRNGbywp/T/GuhYpKhR N3z2JJmrKXULp3rW/SYhSuYiMi72VVy83I/vnkVzK8J7CM09b06oenPLpt6Af8r8 2AEVbTKI0nmjBcg7lR9t+FxQSzMC+N3Jglt0RTjI76Uq5PpOdcBHL6/ISmXkYwk9 2H8yBkDz6suy1g5QPxu2WjCntIcgOZYYGNMAYxHRU69XbQMk/9x1BScGmhSMKIeR U8de5N0G64S6JxdgtovR =AKXa -----END PGP SIGNATURE-----

2 2

encap.txt
by Jann Traschewski 13 Mar '13

13 Mar '13

Hi guys, there are some "suspicious" entries in encap.txt: route addprivate 44.131.192/29 encap 44.131.192.1 route addprivate 44.24.115.17/32 encap 44.24.115.17 There are even some other gateways listed with IP-addresses out of 44/8. 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

9 13

Re: [44net] Portal registrations
by lleachii＠aol.com 13 Mar '13

13 Mar '13

Bill, WA7NWP, I'm not sure this is best suggestion for many reasons: - There was a discussion a few weeks back where it was determined that all stations do not necessarily run telnet (while having others test connectivity to my station, some were attempting to telnet to me). For example, my station is not a TNOS/JNOS based router, and therefore does not provide Converse (the telnet-based service we're referring to) by default. Under that guideline, my allocation would be purged. - We also determined that, while all stations should make their IP addresses ping-able, that was not necessarily the case (either by intent or error). - For various reasons, AMPRNet allocations may not necessarily be online or available through AMPR - A Station does not necessarily have to download the encap to have a working allocation (one could manually add static routes from the portal list or use RIP44, for example) - It would be impossible to use the download guideline for those using the RIP44 routing protocol, as it is multicast; and doesn't know what stations are receiving it or using it We have to be mindful that all stations may not be identically configured, use the same Operating Systems, routing protocols nor system configurations to accomplish connectivity to AMPRNet. 73, Lynwood KB3VWG On 03/12/2013 03:00 PM, 44net-request(a)hamradio.ucsd.edu wrote: > Automate it for now and the future... If a client doesn't > ping/poke/telnet/download or whatever within 30days/3months/whatever - > purge the entry. You know - just like DHCP but at a higher level.. > :) > > Bill, WA7NWP

5 5

Just a sugestion.. a beginning..
by Jerry 13 Mar '13

13 Mar '13

Just have them login once a year and reup their registration.. Like they make you do for repeater coordination.. Allow a 90 day grace period and then lock it for 30 days if still no contact they obviously have abandon it.. or will return when they realize it is down.. Time frames I suggest are just that. That way no notice, no email reminders, no bother to the system or anyone.. They must login or get booted... Not trying to be mean.. but lets say ham A has died.. The portal may never know this... Lets say they changed email, no email reminder will ever reach them.. Let's say they lost interest, even an email or post card could simply get ignored.. If it's simple and the system can send an email to the Last Known Good email at say 11 Months... Fine.. Or make it a rolling 12 months from last login to the portal.. But no need to make it any more than simple.. Let's keep its K.I.S.S 73 Sorry working late and bored.. lol -----Original Message----- From: 44net-bounces+n9lya=blueriver.net(a)hamradio.ucsd.edu [mailto:44net-bounces+n9lya=blueriver.net@hamradio.ucsd.edu] On Behalf Of lleachii(a)aol.com Sent: Tuesday, March 12, 2013 4:37 PM To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] Portal registrations (Please trim inclusions from previous messages) _______________________________________________ Bill, WA7NWP, I'm not sure this is best suggestion for many reasons: - There was a discussion a few weeks back where it was determined that all stations do not necessarily run telnet (while having others test connectivity to my station, some were attempting to telnet to me). For example, my station is not a TNOS/JNOS based router, and therefore does not provide Converse (the telnet-based service we're referring to) by default. Under that guideline, my allocation would be purged. - We also determined that, while all stations should make their IP addresses ping-able, that was not necessarily the case (either by intent or error). - For various reasons, AMPRNet allocations may not necessarily be online or available through AMPR - A Station does not necessarily have to download the encap to have a working allocation (one could manually add static routes from the portal list or use RIP44, for example) - It would be impossible to use the download guideline for those using the RIP44 routing protocol, as it is multicast; and doesn't know what stations are receiving it or using it We have to be mindful that all stations may not be identically configured, use the same Operating Systems, routing protocols nor system configurations to accomplish connectivity to AMPRNet. 73, Lynwood KB3VWG On 03/12/2013 03:00 PM, 44net-request(a)hamradio.ucsd.edu wrote: > Automate it for now and the future... If a client doesn't > ping/poke/telnet/download or whatever within 30days/3months/whatever - > purge the entry. You know - just like DHCP but at a higher level.. > :) > > Bill, WA7NWP _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html

3 2

DNS entries
by Michael Fox - N6MEF 12 Mar '13

12 Mar '13

I've lost track of the status of the portal functionality. We have a block of addresses allocated to our county network (44.4.50.0/28). I also have two addresses allocated for my personal machines (44.4.2.152, 44.4.2.153) But when I log into the portal I see no active records. At some point will the existing records appear in the portal when I log in? Thanks N6MEF

10 17

Re: [44net] Portal registrations
by lpernot＠magma.ca 12 Mar '13

12 Mar '13

I don't understand how I can allocate anything out of 44.135.0.0/16 Since I still can allocate host out of Ampr host robot at UCSD. You need a guide for this website ----- Reply message ----- From: "Brian Kantor" <Brian(a)ucsd.edu> To: "AMPRNet working group" <44net(a)hamradio.ucsd.edu> Subject: [44net] Portal registrations Date: Mon, Mar 11, 2013 13:20 (Please trim inclusions from previous messages) _______________________________________________ It's especially important for the area coordinators to get themselves registered as such with the portal. I think that in a few months we'll just have to consider any regions with no registered coordinator as abandoned by their former coordinators. Similarly with gateways: at some time in the future gateways which aren't registered with the portal will have to be dropped from the encap file. People with existing allocations should make sure that their own allocation is registered with the portal, if necessary by going through the portal allocation process. If you do this, be sure to include a note that it's a re-registration of an existing allocation. - Brian _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html

11 16

encamp file emailed on change
by Chris Smith 10 Mar '13

10 Mar '13

Hi All, FYI - There was a bug in the code that emailed out the encap file to anyone that had the "only when changed" option set, resulting in the encap file not being emailed at all to them. The bug has now been identified and fixed, so if anyone wants to receive an emailed copy of the encap file only when anything has changed, please login to the portal and click on: "Gateways" -> "Options" and alter the "Frequency" to "Only when changed". If you do not wish to receive an email copy of the encap file, please ensure that the "Email" field on this same page is blank. Thanks, Chris

2 1

Co-ordinators new functionality on the portal
by Chris Smith 04 Mar '13

04 Mar '13

Following requests from co-ordinators, I have added some additional functionality to the portal. If you are a country or regional co-ordinator you now have an extra menu link "IP Allocations" from where you can view / edit all the subnets you have allocated. 73 Chris - G1FEF

5 6

Unsubscribe Un-subscribe
by vk1zqr＠netspace.net.au 03 Mar '13

03 Mar '13

unsubscribe

1 0

Re: [44net] encap.txt
by Tim Osburn 01 Mar '13

01 Mar '13

Here are "all" the IANA assigned numbers, if we're gonna get technical :) "Private-Use" being really the important ones. http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia… Tim Osburn www.osburn.com 206.812.6214 W7RSZ On Fri, 1 Mar 2013, Jann Traschewski wrote: > Date: Fri, 01 Mar 2013 22:41:34 +0100 > From: Jann Traschewski <jann(a)gmx.de> > Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > Subject: Re: [44net] encap.txt > > (Please trim inclusions from previous messages) > _______________________________________________ >> For now I have block most of the bogons plus 44/8 thusly: >> >> /^(0.|10.|44.|127.|169.154.|192.168.|224.)/ > > Isn't it 169.254. ? > >> When I have more time I will create a more elegant table based filter, so we >> can allow/deny subnets. > > Maybe it is worth to put 172.16.|172.17.|...|172.31. into the list (if > it will not "break" the line :D) > > 73, > Jann > > > -- > 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 > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net > http://www.ampr.org/donate.html >

3 2

Portal languages
by Chris Smith 01 Mar '13

01 Mar '13

The portal has all the visible text in a separate language file, so can very easily be translated into other languages, but I need some willing volunteers! So, if anyone is willing to create and maintain alternative languages for the portal, please could they drop me an email. I know a couple of people did mention this in the past, but if you could get in touch again, I am now ready to deploy the language files. Thanks, Chris

1 0

Attention KK6CND
by Geoff Joy 01 Mar '13

01 Mar '13

KK6CND [Chris Foreman], Please resubmit your allocation request to the AMPR portal. I forgot to allocate a proper IP address to your previous request. -- Geoff Joy - ke6qh - AmprNet IP Address Coordinator for San Bernardino & Riverside Counties. geoff(a)windomeister.com

1 0

Re: [44net] gateway file
by lleachii＠aol.com 10 Feb '13

10 Feb '13

Steve, I am running EchoLink Proxies at 44.60.44.253:443 and 44:60.44.254:80 I am woking on a SIP based VoIP system, it is not up at this time. ~Lynwood KB3VWG

3 4

BGP feed
by C.J. Adams-Collier KF7BMP 10 Feb '13

10 Feb '13

Hey folks, I'm going to stand up a quagga server over at 44net-tunnel-endpoint.org in the next week or so. Would any of you be willing to give me a private feed of the v4 table (and v6 if you've got it) using a reserved AS number on my end? It's been a while since I've done this, so be gentle with me ;-) From http://tools.ietf.org/html/rfc1930: 10. Reserved AS Numbers The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet): 64512 through 65535 Thanks much! C.J.

1 0

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

07 Feb '13

44net-request(a)hamradio.ucsd.edu wrote: > Last time I tried doing > whois on a name it failed. The spammers have made it impossible to put up a > whois because they mined them all for valid emails so organizations had to > abandon it. Maybe it varies between TLDs. I never got much spam that I could trace to .nl domain name registration (note that .nl now no longer reveals contact info via whois, but they used to in the past). On the other hand, what really buried me in spam is registering for some port numbers and a organization unique ID at IANA. They published the requester's mail in a text file on their site, and for port numbers it is in /etc/services. I have had to abandon some mail addresses because of it. Rob

1 0

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

07 Feb '13

44net-request(a)hamradio.ucsd.eduwrote: > Rob, > > I have a dutch licence and there is nothing in there about host names. > > Is this only a requirement for unattended gateways as these need a > separate licence > from the government there? > > Bob (Boudewijn) VE3TOK I reply to this item only to avoid posting several messages, but I have read the other replies as well. Back in the days when we were still doing a packet network, the situation was like this: The license said "each packet should be identified by the callsigns of the station where the traffic originates from, and the station that is actually transmitting the packet". This made point-to-point packet legal, as well as digipeated packet. Both comply to that requirement. The method used by NET/ROM was illegal. It transmitted packets from the nodes using a modified originator callsign. The packets had the callsign of the original source, but not the callsign of the node that was transmitting them. When I adapted NET/ROM into NET, I created a system where the exit node transmitted a "faked" digipeated packet that looked like if the node had actually digipeated a packet (while it in fact was making a downlink connection). That made it formally compliant to the license requirements, and was also more convenient for the users as it showed where the traffic was actually coming from. The same thing was done in Germany, in other software. Then look at IP. An IP packet transmitted via the network and sent by a node/router has the AX.25 callsign of the node transmitting it, but does not carry the callsign of the original source. Someone consulted the authorities about it. He got the assertion that it would be accepted as identification if there would be a publicly available mapping between IP address and callsign, so they could consult that when wanting to determine the source of the traffic. All the time after that, the hosts file for the Netherlands has been publicly available both on the BBS system and on telephone BBS (in those days) and Internet (later). And there was the Internet DNS with this information. It may be that the current license no longer explicitly states the callsign requirements, there have been changes. I just have continued to always use the callsign as part of all hostnames assigned to allocated IP addresses within 44.137... (callsign.ampr.org or label.callsign.ampr.org) Note that all this is only the situation in the Netherlands, I have no idea how regulations are in the US or elsewhere. Also note that all this is mostly academic, as packet radio is now formally illegal in the Netherlands except for stations with a "notice of variation" for unattended operation. Why that, you ask? Well, it went like this. There has always been a NOV requirement for unattended stations. Nodes, repeaters, BBSes etc required such a notice from the authorities to allow operation without the operator being present. User's packet stations did not require this NOV as long as the operator was present during use of the station. And many operated on the edges of what was really allowed, it wasn't really enforcible anyway. (e.g. the station transmitting a file while you are watching TV or sleeping, is that "attended"?) Of course an unattended phone repeater also requires a NOV. To get one, one needs to fulfill certain criteria like a minimal distance to another repeater on the same band. And there is co-ordination to distribute the limited number of channels. There are always some people do not want to play within those rules and started operating "attended repeaters" on all kinds of imaginable channels, and D-STAR hotspots, sometimes after a request for an NOV was denied to them. It somehow irritated the authorities and they redefined the "attended" requirement: it must be the operator himself, either directly or via some authenticated link guaranteeing it to be only him, who keys the transmitter. A repeater or hotspot, where the transmitter is keyed by the reception of a signal not from the operator, is now declared to be in requirement of an NOV no matter if the operator is actually present or not. And it is also stated that there will be increased effort to monitor and effectuate this regulation. Unfortunately, a packet station, even with the operator sitting at the keyboard, is now outside these bounds. The transmitter is keyed as a result of someone transmitting towards you, if only to transmit an acknowledgement. And this is explicitly no longer allowed in the definition. I have no idea if this has been the intention and what they now actually think about packet. It is very likely that we are only the victim of the desire to regulate the phone repeater mess, and it was not the intention to disallow point-to-point packet or user-to-node packet as well. Rob

1 0

Re IPv6 for www.ampr.org
by Daniel Curry 07 Feb '13

07 Feb '13

I am glad to see that IPv6 being available Looking forward on the progress. K6DLC -- Daniel Curry PGP: AD5A 96DC 7556 A020 B8E7 0E4D 5D5E 9BA5 C83E 8C92 IPv6 Sage Certified San Francisco/Silicon Valley AmprNet Co-coordinator [44.4.0.0/16]

5 6

Windows Based AMPR Router
by lleachii＠aol.com 07 Feb '13

07 Feb '13

All, Has anyone attempted to setup an AMPR gateway using Microsoft Windows (http://technet.microsoft.com/en-us/library/cc940485.aspx)? I surmise that the tunnel setup is straightforward; and ActiveState ActivePerl (http://www.activestate.com/activeperl) can be used to run RIP44d, I have not reviewed the RIP44d file as of yet; but I assume editing the line that adds routes to the Routing Table would be all that is needed. The Perl Packages 'interface' and 'IO-Socket-Multicast' are available through ActivePerl for Windows, has anyone tried a Microsoft setup before; did you have success/failure? I wanted to make sure no one has already tried the Windows OS before I explore; and if they have, can they provide some insight and instructions. 73, Lynwood KB3VWG

1 0

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

07 Feb '13

44net-request(a)hamradio.ucsd.edu wrote: > the DNS functionality is a separate module and is not tied to the name of the IP/subnet, not everyone uses their callsign as the DNS name But that is a license requirement! We need a mapping between IP address and callsign for legal use of IP on amateur radio.... (ID requirement) Rob

16 21

IPv6 for www.ampr.org
by Brian Kantor 07 Feb '13

07 Feb '13

Tony, AH6BW, has set up an IPv6 proxy to enable IPv6ers to reach www.ampr.org. This should have no effect on ordinary IPv4 access to the site, but if you have any trouble reaching it, please let me know. FYI, the entry in the nameserver to implement this is www IN AAAA 2605:b00:0:2:211:2fff:fef6:4287 which is how the address for an IPv6 host is entered in the the 'bind' nameserver. - Brian

7 9

Re: [44net] 44Net Digest, Vol 2, Issue 21
by Rob Janssen 06 Feb '13

06 Feb '13

44net-request(a)hamradio.ucsd.edu wrote: >> >But it has the disadvantage that you spread the rarely occurring task over many >> >people who do it only once and do not have the knowledge and skills to perform >> >it well. I'm afraid this will lead to many wrong subnet specifications (already seen), >> >strange names in the DNS, questions, etc. > That's just a learning curve which is easily fixed. I think it is better to have the learning curve once and not for every user. It is already very unclear to me (as an expert in IP addressing and a long-time co-ordinator) what the system will exactly do when I perform certain actions, and I think it will be nothing short of a mystery to those that just want an address and have no idea how IP addresses are structured, what subnets are, and how DNS fits in. > >> >I prefer to handle the task for the entire country and have the system only >> >administer what has been assigned, not delegate the subassignments. It is >> >a small country and I get only a couple of requests per year these days. > The system is flexible, if that is how you want to administer the subnet you are responsible for, then go ahead, all your allocations will therefore be to end users instead of regional co-ordinators and it will be your responsibility to keep the portal up to date and if there are any problems, you will be the point of contact to respond and fix the problem. It's more work for you, but if that is how you prefer to manage your subnet I don't see a problem. > > I guess what we need is a facility for co-ordinators to enter allocations to end users manually, I can sort that out. > > Regards, > Chris > I don't mind if users can submit requests for subnets via the system, as long as that does not automatically mean that they become the co-ordinator for that subnet. They get the adressing space, submit the requests for names within that space, and I validate them. That is how it has always worked, and it has served well to prevent silly stuff like non-callsign entries directly under ampr.org from appearing within the 44.137 subnet. For single adresses, it would be preferable if there is a single request form that supplies both the name and desired subnet, and leaves the assignment of the address to the co-ordinator, who approves the entire request in a single action. But if that is too much programming work and it is more convenient to leave the separation between address assignment and DNS mapping, that is not a real problem because of the current rate of requests. Rob

4 5

amprnet dns zones
by Eric Fort 06 Feb '13

06 Feb '13

I'm seeing a lot of good things in the works in the reforming of amprNET/net44 including how ip address assignments and allocations are to be handled and managed, routing info exchanged dynamically via rip and other protocols, and the moving away from a single central point which all traffic has to essentially tunnel to as address space can now once allocated be tied to the appropriate AS and routed via BGP. all great things being done. there are a few things though I have not heard happening that I'll ask if they have been considered and what others thoughts may be. This for the most part deals with a gateway operator being able to manage the DNS zones pertaining to the operation of their gateway and it's users. for the sake of discussion lets say we have a gateway operator with a /24 block assigned to their gateway and let's say that block is 44.128.128.0/24and lets say their call was gw4opr: I would propose that along with the allocation of that block that gateway operator have the option to host and manage the 128.128.44.in-addr.arpa zone on their DNS servers. I would also propose that those who would choose to could host and manage their own DNS zones, in this instance *.gw4opr.ampr.org. It seems to just make sense that reverse dns would be managed by the ones responsible for and closest to the address space assigned and that one ought to be able to manage their own DNS zone without having to go through their address coordinator for every last dns update as long as they are willing to accept delegation of responsibility for their zone. what are the thoughts on this from others on this list? Personally I think delegation of zones is a great idea, but perhaps I missed something. it would seem to further lighten the load on local coordinators. That said, why should we or why should we not plan for, allow, and even encourage, delegation and self management of DNS zones directly by those closest connected to and most responsible for them? AF6EP

3 2

Re: [44net] 44Net Digest, Vol 2, Issue 20
by Rob Janssen 05 Feb '13

05 Feb '13

44net-request(a)hamradio.ucsd.edu wrote: > An example: if I'm the San Diego county coordinator, and I assign a /24 > to AA6ZZ for a gateway in the Santee city area, he can become the > coordinator for that /24, and assign addresses from his block of 256 > addresses to the clients of his gateway. > > Likewise: > 44.0.0.0/9 is assigned to the USA, with me as the current USA coordinator, > 44.124.0.0/16 is assigned to Arizona and handled by the AZ coordinator > 44.124.128.0/24 might be assigned to a gateway in Phoenix who would then > handle address assignments for the clients of that gateway. > > So by registering gateway operators as coordinators for their gateway's > subnet, we localize the network management to the people who are the > best situated to handle it. But it has the disadvantage that you spread the rarely occurring task over many people who do it only once and do not have the knowledge and skills to perform it well. I'm afraid this will lead to many wrong subnet specifications (already seen), strange names in the DNS, questions, etc. I prefer to handle the task for the entire country and have the system only administer what has been assigned, not delegate the subassignments. It is a small country and I get only a couple of requests per year these days. Rob

2 1

network management
by Brian Kantor 03 Feb '13

03 Feb '13

> User registration and network management are separate functions. I think > that after a user registers, any network (address, LAN, etc.) requests go > to the coordinator for that address space. An example: if I'm the San Diego county coordinator, and I assign a /24 to AA6ZZ for a gateway in the Santee city area, he can become the coordinator for that /24, and assign addresses from his block of 256 addresses to the clients of his gateway. Likewise: 44.0.0.0/9 is assigned to the USA, with me as the current USA coordinator, 44.124.0.0/16 is assigned to Arizona and handled by the AZ coordinator 44.124.128.0/24 might be assigned to a gateway in Phoenix who would then handle address assignments for the clients of that gateway. So by registering gateway operators as coordinators for their gateway's subnet, we localize the network management to the people who are the best situated to handle it. A new ham in Phoenix who wants to get on AMPRNet registers, goes to the networks section, clicks on USA, clicks on Arizona, sees the gateway registered in his area, and clicks on that to request an allocation. The gateway operator picks an available address, say 44.124.128.17, registers it and things are good to go. No need to wait for the state or national coordinator. You don't have to register nor log in just to view the network allocations and who the coordinator is, so folks who just want to know if there's a subnet or gateway in their area can see. - Brian

1 0

Problem with France
by ze.bot＠free.fr 03 Feb '13

03 Feb '13

I think that there is a problem with a new allocation inside France 44.151.0.0. https://portal.ampr.org/networks.php?a=region&id=295 There is a declaration of one single user (not a network) with a /16 at the end... > Network Country Region Allocated to > 44.151.67.22/16 FR Alsace F6EQN [Michel BELLEZIT] Furtheremore, on his website, F5PBG invites all french users to register individually their IP on the "ampr.org" website. This will induce a lot of useless declarations. http://inforadio.free.fr/articles.php?lng=fr&pg=85 > # Changement de fonctionnement du réseau AMPR : > # INSCRIPTION OBLIGATOIRE POUR ETRE PRIS EN COMPTE > # à cette adresse : https://portal.ampr.org/ (Onglet "Register") > # puis après connexion réalisez votre demande (Onglet "Networks") Translation of this extract : > The AMPR network has changed > Registration is compulsory > at this adress : https://portal.ampr.org/ > click on "register", > and then after connexion, > put your request, click on "network". I think that an admin could delete this declaration, and put a reminder about what is an allocation, and what is a network, a subnet, etc... Thanks.

6 7

Dynamic IP GATEWAYS?
by Demetre SV1UY 02 Feb '13

02 Feb '13

Hi, Any news about support for Dynamic IP Gateways yet without having to pester other Gateways having static IPs via AXUDP links? -- 73 de SV1UY Demetre Ch. Valaris e-mail: demetre.sv1uy(a)gmail.com Radio e-mail: sv1uy(a)winlink.org http://www.qsl.net/sv1uy

5 6

ip updating
by K7ILO 02 Feb '13

02 Feb '13

Hello gang. Could an ip coordinator send me via direct email the email robot's address for adding and updating amprnet ip addresses? Thanks Harold K7ilo (formerly KB7RSI) Southern Nevada Ip Coordinator

13 25

AMPRNET Donations
by Paul Delaney - K6HR 02 Feb '13

02 Feb '13

Exactly how will any donated funds be used, accounted for etc? Paul Delaney - K6HR paul.hamradio(a)verizon.net http://k6hr.dyndns.org:8080

2 1

Re: [44net] gateway file
by kb9mwr＠gmail.com 01 Feb '13

01 Feb '13

What you have for a network over there makes me jealous. I guess I'd like to know what in terms of content is on the amprnet. I know there are some AXIP BBS style feeds and that sort of thing. Is anyone running a mailman mailing list of anything interesting? For higher speed radio connections are there any SIP/Asterisk conference servers, or at least FTP repositories of ham stuff? Stuff that is exclusive to the network. I have some point to point 802.11 links over here that I have been using 44 addresses on for a few years. But they haven't been connected to the rest of the amprnet. Is there a compelling reason to setup a gateway to the rest of the amprnet. 73' Steve ----Original--- Btw: We are currently deploying our IP management system for the HAMNET network: http://hamnetdb.net/?m=as&q=&as=-All-&tab=map You should be able to do a traceroute to all "green" sites... Click on a site and you get the description. 73, Jann DG8NGN On 31.01.2013 21:09, kb9mwr at gmail.com wrote: > I have one from Sept 2012 if anyone wants it. > > I second the importance of the data in that file. It's really the > only thing we had to tell what is on the amprnet, in terms of > services, and the speeds of the connected radio subnets, etc.

1 0

Re: [44net] gateway file
by kb9mwr＠gmail.com 31 Jan '13

31 Jan '13

I have one from Sept 2012 if anyone wants it. I second the importance of the data in that file. It's really the only thing we had to tell what is on the amprnet, in terms of services, and the speeds of the connected radio subnets, etc. > Date: Thu, 31 Jan 2013 11:05:14 -0800 > From: Jack Eifer <jeifer(a)cwo.com> > To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > Subject: Re: [44net] ip updating > > Chris, > > While we're on the subject of TODO's, > Has any consideration or thought been given to resurrecting the 'GATEWAY' file that Fuller maintained ? > > I found the information in file useful and easy to access. Perhaps the new website has the same info embedded, but somewhere I've yet to discover. > > Jack, AA6HF

2 1

reminders
by Brian Kantor 31 Jan '13

31 Jan '13

Just a reminder for everyone, especially address coordinators, to please register with the portal. https://portal.ampr.org/ And a big thank you to those thoughtful folks who have donated to keeping the organization running. If you haven't yet sent in a donation, it's as easy as clicking on the donate link at the bottom of this message or on our web page. Even $25 would be a great help. Thank you! - Brian

1 0

the next step in portal deployment
by Brian Kantor 27 Jan '13

27 Jan '13

As the next step in deployment of the AMPRNet Portal, we're going to begin using it to refer people to their coordinators. How this works is this: A ham wanting an address assignment will register with the portal and click on the NETWORKS selection. He'll be presented with a list of countries; for some countries, clicking on that entry will get him to a list of regions within the country, etc. If there isn't a coordinator registered with the portal for his particular area (or country), he'll have to pick the enclosing region. Eg, if there isn't an entry for say, Alabama, he'll pick the USA entry and I'll get the request. I can then allocate a block for Alabama (rather, I'll use the one that's already set aside for that state) and assign him an address from that block. I'll probably ask him if he'd like to become the coordinator too. (Always looking for volunteers.) Once his region is selected, he'll be presented with a simple form that asks what netwidth he wants (/32 for a single host, /24 for the typical 256 host subnet, etc), how he's planning on connecting to the greater internet, and a Notes area in which he can explain anything special about his request. This will generate an email to the coordinator registered for the subnet he clicked on above, who can request further particulars if needed. The above procedure is mentioned in the FAQ on the www.ampr.org website. What's the advantage to doing it this way? Among other things, it means that there is no longer the problem of finding the email address of a coordinator from an always-outdated list. It's less work for me to handle referrals, and the portal mechanism will ensure that there is consistent data for everyone. It's very important that every coordinator get registered with the portal for this system to work. I urge everyone on this mailing list to register, and those of you who are coordinators should contact Chris to get your registration listed as the coordinator for your region. Thank you! - Brian To replay Chris's instructions: _______________________________________________ Now is probably a good time to ask everyone that is currently using an IP or IPs from the 44/8 to register on the portal: https://portal.ampr.org Click on the "Register" link to the right of "Home" in the top menu. Fill in the details requested and hit the "Register" button, you will be sent an email with a link you need to click on to verify your email address. When you click the link the web page will ask you to enter the username you entered on the original request, click the "Confirm" button and your login details will be emailed back to you. Use the details to login to https://portal.ampr.org Your first job should be to change your password to something secure that you will remember: Click on the "Profile" menu link, to the right of "Allocations". Here you can update your details, including your login password. If you already operate a gateway, please drop me an email and I can assign it to your account. If you already have subnets allocated to you within the 44/8 please drop me an email and, as per the gateways, I can assign them to your account. If you are a country co-ordinator or a regional co-ordinator, please get in touch asap, so you can be setup on the portal to manage the allocations of your subnets. Thanks, Chris - G1FEF _________________________________________

7 10

AMPRNet Logo
by Chris Smith 25 Jan '13

25 Jan '13

A plea to all you graphic design artists out there... It would be good if we could come up with a logo to use across the main ampr.org website, the portal, the wiki, etc. I've attached one I did and one derived from one that Jim Fullers had on his site when it was active. Food for thought, but if anyone can come up with a really cool logo that we all like... Thanks, Chris

1 0

Re: [44net] Gateways Unreachable after Dynamic IP Update
by lleachii＠aol.com 24 Jan '13

24 Jan '13

Don and Marius, I can reach you both, with no issues. From those who have offered their Subnet information: - I can reach all 3 of you (Don, Bob and Marius) [from 44.60.44.0/24 to you] therefore, encapsulation must be working at all stations, and our routes are up-to-date - Don 44.135.90.0/24 is unable to reach me or Bob - Marius 44.182.21.0/24 can reach Bob; he cannot reach me Don and Marius, defnately keep us up-to-date about why you cannot ping me. What Network OS are you using for AMPRnet (*nix/rip44, JNOS, TNOS)? ~Lynwood

11 33

Re: [44net] 44Net Digest, Vol 2, Issue 8
by kb9mwr＠gmail.com 20 Jan '13

20 Jan '13

I have noticed there is something with 44 addresses and Windows too. I have never been able to ping a 44 address from Windows, while they work proper from a Linux terminal. All pings to 44 address from Windows result in "Destination host unreachable" (even 44.0.0.1) It's no big deal for me, but have never really figured out why this is. > Date: Sun, 20 Jan 2013 00:34:06 +0200 > From: "Marius Petrescu" <marius(a)yo2loj.ro> > To: <n2nov(a)n2nov.net>, "'AMPRNet working group'" > <44net(a)hamradio.ucsd.edu> > Subject: Re: [44net] Gateways Unreachable after Dynamic IP Update > > Hi, > > I'm running debian 6, updates via RIP. Working from a windows PC behind the > server acting as router. > > Check the route your response packets take on their way out. > If you initiate the ping you get the response correctly back due to > connection tracking mechanisms. > This doesn't mean that responses to icmp requests necessarely do the same. > E.g. responses may go via a default gateway which is not correct. > Make sure your answers go out on the same interface they came in. > > sooo... > > Pinging 44.2.10.1 with 32 bytes of data: > Reply from 44.2.10.1: bytes=32 time=226ms TTL=222 > > Pinging 44.68.41.1 with 32 bytes of data: > Reply from 44.68.41.1: bytes=32 time=160ms TTL=28 > > But then... > > C:\Users\Marius>ping 44.60.44.1 > > Pinging 44.60.44.1 with 32 bytes of data: > Request timed out. > Request timed out. > Request timed out. > Request timed out. > > Ping statistics for 44.60.44.1: > Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), > > 73's > Marius, yo2loj

2 1

Gateways Unreachable after Dynamic IP Update
by lleachii＠aol.com 18 Jan '13

18 Jan '13

All, I'm experiencing a technical issue that began when my dynamic WAN address obtained a new lease. I am no longer able to communicate with other 44 subnets after my WAN obtained a new IP address. My gateway is saved in the Portal with a dynamic domain name, and the IP is correctly displayed on the portal.ampr.org website. In addition, I have also updated my IP under the rip44d -a parameter. I am still able to receive the RIP44 announcements from 44.0.0.1 and communicate with the Internet via the tunnel thru AMPRGW; but I am no longer able to reach other AMPR networks. My WAN IP changed on 11JAN2013. Please feel free to perform any of the following, or let me know if I am reachable via AMPR: Ping/traceroute Router 44.60.44.1 Ping and DNS 44.60.44.3 Ping and HTTP at 44.60.44.10, 44.60.44.11 and 44.60.44.12 Regards, Lynwood KB3VWG 44.60.44.0/24

4 4

AMPRNet Wiki
by Chris Smith 16 Jan '13

16 Jan '13

Hi Folks, A new Wiki was setup a little while ago: http://wiki.ampr.org Unfortunately it got vandalised and there were only a couple of minor contributions. I've reset it, this time with restricted edit rights. If you wish to contribute ( and the hope is that many will ), please drop me an email and I will set you up a login. All I need is your preferred username and email address, I will assign a random password and email it back to you. Thanks, Chris - G1FEF

1 0

Zconvers Map
by Kutche, Jerry (Mitchell) USA 11 Jan '13

11 Jan '13

I was lost and now I am found! 73 Thanks everyone for the help.. And push to try again.. Jerry Kutche Electrical Supervisor Lehigh Cement Company LLC 180 N. Meridian Road Mitchell, IN 47446 Phone: (812) 849-2191 ext. 251 Fax: (812) 849-5007 Cell: (812) 583-0445 jkutche(a)lehighcement.com<mailto:jkutche@lehighcement.com> www.lehighcement.com<file:///C:\Documents%20and%20Settings\kmundy\Application%20Data\Microsoft\S…> This e-mail may contain confidential and/or legally privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

1 0

WWconvers Node Registry
by Charles Hargrove 10 Jan '13

10 Jan '13

The sysops of the following WWconvers nodes need to contact SP1LOP, by registering at http://www.wwconvers.ampr.org/wwcbook/addwwc.html, with station details to be accurately placed on the map at http://www.wwconvers.ampr.org (or else your station will be lost at sea in the South Pacific). :-) BWATER_NS LAXNET_US N9LYA WARDCOVE2 -- Charles J. Hargrove - N2NOV NYC ARECS/RACES Citywide Radio Officer/Skywarn Coord. NYC-ARECS/RACES Net Mon. @ 8:30PM 147.360/107.2 PL http://www.nyc-arecs.org and http://www.nyc-skywarn.org NYDXA SWL & Scanner Net Wed. @ 9PM 147.360/107.2 PL http://www.n2nov.net "Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan "The more corrupt the state, the more it legislates." - Tacitus "Molann an obair an fear" - Irish Saying (The work praises the man.) "No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan

5 5

[cisarnet.ampr.org] - Filtering OSPF Hellos from CisarNet solved
by renzorossi＠libero.it 01 Jan '13

01 Jan '13

Ciao Don, we are tuning CisarNet for managing directly delegated CIDR 44.208/16...So I missconfigured our main gateway.. Now it should be OK. Please let us know. Sorry ;-) Ciao from Italy. IW0SAB Renzo. >----Messaggio originale---- >Da: ve3zda(a)gmail.com >Data: 31/12/2012 17.51 >A: <44net(a)hamradio.ucsd.edu> >Ogg: [44net] (no subject) > >(Please trim inclusions from previous messages) >_______________________________________________ >Whoever owns station iq0rf.cisarnet.ampr.org. please top transmitting >to ve3zda.ampr.org. >It's been repeatedly sending encapped lines since yesterday and getting >nowhere of course.... > >here's an example of the line I'm getting...ever second or two..... > >16:37:34.478957 IP 94.101.48.134 > 192.168.1.150: IP 44.208.0.1 > >224.0.0.5: OSPFv2, Hello, length: 56 (ipip-proto-4) > >73, Don - ve3zda >_________________________________________ >44Net mailing list >44Net(a)hamradio.ucsd.edu >http://hamradio.ucsd.edu/mailman/listinfo/44net >

1 0

(no subject)
by Don Moore 31 Dec '12

31 Dec '12

Whoever owns station iq0rf.cisarnet.ampr.org. please top transmitting to ve3zda.ampr.org. It's been repeatedly sending encapped lines since yesterday and getting nowhere of course.... here's an example of the line I'm getting...ever second or two..... 16:37:34.478957 IP 94.101.48.134 > 192.168.1.150: IP 44.208.0.1 > 224.0.0.5: OSPFv2, Hello, length: 56 (ipip-proto-4) 73, Don - ve3zda

1 0

Discussion about JNOS 'slowness' ...
by Maiko Langelaar 28 Dec '12

28 Dec '12

Just something I've noticed, I'm sure there are gurus on here that can add to it, or totally take it apart - I'd like to hear your thoughts. > First of all, I hope everyone had an okay christmas. As well, I > would like to wish everyone the best for the upcoming new year. > > Has JNOS always been 'slow' ? > > This might be hard for me to explain, but when you are connected > to a JNOS station and you hit enter to send a command, you may have > noticed it might take a 'second' for it to be 'processed'. It's not > a lightning fast response time is it now. I noticed this while trying > to connect to my own JNOS via a 3 'wire' led/phototransistor dummy > serial load (bounces data right back at the same interface). And to > be frank, I've noticed it in many other occasions. Forwarding should > never take so long, netrom is always painfully slow, and so on. > > Was it always like this (for the linux version) ? > > Or did this start happening back when I did the kernel change, back > when I was somewhat forced to use the setcontext() functions instead > of setjmp() calls and such. Version 2.0e and earlier use setjmp() > methodology, 2.0f and older use the setcontext() functions. > > Was the DOS version the same too ? > > SOOOO - Want to see JNOS go like lightning ? It's easy enough : > > edit timer.h, change MSPTICK to 1 (normally it's 55) > > rm domain.o main.o rspf.o timer.o unix.o > > make > > CONSEQUENCES - your timers will expire much faster now, but the system > clock will be fine. But as an experiment, give it a try, tell me what you > think. Not sure if this was always the way it was, perhaps due to inadequate > CPU for it's time, I don't know. > > I'm going to play with this a bit, a patch will be released in the near > future so that the timers behave, but JNOS will suddenly come to life ! > > I've known about this for some time, but my experimenting that I've been > doing over the christmas holidays kinda brought it up again. Never thought > how noticing the delay between laser diode flashes can refresh one's memory > on the topic. > > Maiko Langelaar / VE4KLM >

1 0

Re: [44net] INP3 recent work?
by Matt VK2RQ 19 Dec '12

19 Dec '12

> howdy all, have been looking into inter-operability of INP3 with netrom > quality-based routing, and see there has been work done for older > kernels but cannot find anything recent: > > http://sharon.pi8zaa.ampr.org/users/pe1rxq/inp3.html > > > Maiko has ported this code to jnos I believe, but I don't see any > linux-native ports of the code more recent than kernel 2.6.4...I'm > running linux mint 10 and > mint 13 in my machines, and the kernel is much newer, haven't tried the > patch yet on the newer 3.0+ kernels, anyone had any experience with this? > Cheers, > John Hi John, I ported the patch to kernel 2.6.35, which I believe is what Mint 10 is based on. However, I found serious deadlock issues that arise when nodes are withdrawn. For details, and a link to the ported patch, see my post here: http://www.spinics.net/lists/linux-hams/msg03116.html 73, Matt VK2RQ

2 1

Gateway entry / pub routing
by Jason R Begley 12 Dec '12

12 Dec '12

There is a tunnel on the encap list that needs correction (recursive routing): route addprivate 44.131.192/29 encap 44.131.192.1 I have also noticed that routing from the public internet doesn't go any further than the 132.239.255.131 host at UCSD, but I've only spot test a few hosts other than myself. If anyone is interested in using a Cisco router for GW connectivity, I have a 7206 (non VXR) chassis(empty) up for grabs/trade. 73 Jason

2 3

Re: [44net] AMPRNet Gateways update
by Kutche, Jerry (Mitchell) USA 29 Nov '12

29 Nov '12

?? ----- Original Message ----- From: 44net-bounces+jkutche=lehighcement.com(a)hamradio.ucsd.edu <44net-bounces+jkutche=lehighcement.com(a)hamradio.ucsd.edu> To: 'AMPRNet working group' <44net(a)hamradio.ucsd.edu> Sent: Thu Nov 29 01:33:46 2012 Subject: Re: [44net] AMPRNet Gateways update (Please trim inclusions from previous messages) _______________________________________________ Hi Chris, I have an existing entry I need transferred so that I can manage it as I need to change my tcpip address. Username on new system is eddie. Entery to transfer is route addprivate 44.147/16 encap 121.98.130.16 73 and thanks Eddie Olson ZL2AQY -----Original Message----- From: 44net-bounces+eddie=olson.net.nz(a)hamradio.ucsd.edu [mailto:44net-bounces+eddie=olson.net.nz@hamradio.ucsd.edu] On Behalf Of Chris Smith Sent: 09 October 2012 21:45 To: AMPRNet working group Subject: Re: [44net] AMPRNet Gateways update (Please trim inclusions from previous messages) _______________________________________________ Another point I should mention concerning the new portal and Gateways robot: All of the current Gateway data has been imported into the new system. This means that if you already have a gateway registered on the current system, it will be present on the new system, so there is no need to add it. The downside to this, is that if you register on the portal to manage your gateway, it will not simply "appear" on your account. This is because it is already present on a default account. The solution is to contact me with your gateway details (Username as registered on the portal, Gateway IP and Subnets serviced) and I will transfer it across to your account. Thanks, Chris G1FEF _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 1

Re: [44net] AMPRNet Gateways update
by Eddie Olson 29 Nov '12

29 Nov '12

Sorry ignore the previous message it went to the wrong address. my apologies. Eddie ZL2AQY

1 0

AMPRNet Gateways update
by brian＠UCSD.Edu 29 Nov '12

29 Nov '12

With the kind assistance of Jim Fuller, Maiko Langelaar and Chris Smith have been working on an update of the AMPR gateways processing system. That project is now ready for service. Beginning October 15th 2012, updates to the gateways will be processed on a new host, portal.ampr.org, and the encap file will be distributed from there. Both email distribution and ftp retrieval are supported, as they were with the previous ampr-gateways host. The new gateways robot mailing address is gateways(a)ampr.org Your logins and passwords from the previous gateways system should continue to work on the new portal. The syntax and content of the various commands and parameters for the robot are quite similar to the previous version; you can get the details from the manual page for the new robot. https://portal.ampr.org/gateways_manpage.php I would like to personally thank Jim Fuller for his many years of service to the AMPRNet gateways community and wish him well. We couldn't have done it without you! Thank you, Jim! - Brian PS: My apologies if you receive more than one copy of this note.

7 7

R: DRAFT directly routed subnets supplemental information form
by renzorossi＠libero.it 22 Nov '12

22 Nov '12

Could be useful to distinguish, as an Internet domain registration, the Organization (Registrant), from Legal representative (admin contact), from Tech representative (tech Contact), and NSP references (as a Registrar contact) ? In this way should be: Organization name: Organization postal address: Organization email: [Modified] Admin Representative name: [Modified] Admin Representative callsign: [Modified] Admin Representative email: [Modified] Admin Representative telephone: [New] Tech Representative name: [New] Tech Representative callsign: [New] Tech Representative email: [New] Tech Representative telephone: Width of network requested (CIDR Notation): Estimated number of subnets this will be divided into: Estimated number of hosts on all subnets combined: Network Service Provider name: NSP postal address: NSP telephone: NSP email contact: NSP ASN: Ciao from Italy! IW0SAB Renzo >----Messaggio originale---- >Da: Brian(a)UCSD.Edu >Data: 20/11/2012 19.21 >A: <44net(a)hamradio.ucsd.edu> >Ogg: [44net] DRAFT directly routed subnets supplemental information form > >(Please trim inclusions from previous messages) >_______________________________________________ >Here's a draft copy of the form that we're going to be asking people >applying for directly routed subnets (BGP folks) to complete so that >we can get the show on the road. I hope to start allocating those in >early December. > >Anyone have suggestions or objections? > - Brian > >=========================================================================== >Amateur Radio Digital Communications Inc > >Application for Directly Routed (CIDR delegated) Subnet > >Please provide the requested information regarding the organization/person >to whom the addresses will be licensed. > >By submitting this form you affirm that you have read and agree to the >Acceptable Use and Terms of Service attached herein. >---------------------------------------------------------------------------- > >Organization name: > >Organization postal address: > >Organization email: > >Representative name: > >Representative callsign: > >Representative email: > >Representative telephone: > >Width of network requested (CIDR Notation): > >Estimated number of subnets this will be divided into: > >Estimated number of hosts on all subnets combined: > >Network Service Provider name: > >NSP postal address: > >NSP telephone: > >NSP email contact: > >NSP ASN: > >---------------------------------------------------------------------------- > >(TOS would be attached here.) >_________________________________________ >44Net mailing list >44Net(a)hamradio.ucsd.edu >http://hamradio.ucsd.edu/mailman/listinfo/44net >

1 0

gateways wiki
by kb9mwr＠gmail.com 22 Nov '12

22 Nov '12

http://wiki.ampr-gateways.org/ isn't responding :-( http://wiki.ampr.org/index.php/Main_Page Empty. Were there plans to move Jim's wiki to the main ampr site, or ?

5 6

Terms of Service revised
by Brian Kantor 20 Nov '12

20 Nov '12

In response to advice from some of you, we've added two new clauses to the terms of service. These are > ARDC's license of address(es) to You grants You a limited, non-exclusive, > non-transferrable, non-assignable, and terminable right to use the > address(es) in accordance with this Agreement and Terms solely for the > purposes stated herein. The duration of this license is five (5) years, > renewable upon Your request and consent to these Terms and Agreement > and subject to the discretion of ARDC. and > You may cancel this license at any time and for any reason by contacting > ARDC in writing and receiving acknowledgement of such request. Usage of > the address(es) must cease effective with the license cancellation. The full Terms of Service Agreement may be found on the AMPR web site http://www.ampr.org/ And may I gently remind folks that there is a DONATE button on that web site; we're still over $1,000 in debt at this point, all of it out of my pocket. Any amounts would be greatly appreciated. - Brian

1 0

DRAFT directly routed subnets supplemental information form
by Brian Kantor 20 Nov '12

20 Nov '12

Here's a draft copy of the form that we're going to be asking people applying for directly routed subnets (BGP folks) to complete so that we can get the show on the road. I hope to start allocating those in early December. Anyone have suggestions or objections? - Brian =========================================================================== Amateur Radio Digital Communications Inc Application for Directly Routed (CIDR delegated) Subnet Please provide the requested information regarding the organization/person to whom the addresses will be licensed. By submitting this form you affirm that you have read and agree to the Acceptable Use and Terms of Service attached herein. ---------------------------------------------------------------------------- Organization name: Organization postal address: Organization email: Representative name: Representative callsign: Representative email: Representative telephone: Width of network requested (CIDR Notation): Estimated number of subnets this will be divided into: Estimated number of hosts on all subnets combined: Network Service Provider name: NSP postal address: NSP telephone: NSP email contact: NSP ASN: ---------------------------------------------------------------------------- (TOS would be attached here.)

4 5

Re: [44net] Gateway entry / pub routing
by Kutche, Jerry (Mitchell) USA 13 Nov '12

13 Nov '12

I am interested.. If no one else is... ----- Original Message ----- From: 44net-bounces+jkutche=lehighcement.com(a)hamradio.ucsd.edu <44net-bounces+jkutche=lehighcement.com(a)hamradio.ucsd.edu> To: 44net(a)hamradio.ucsd.edu <44net(a)hamradio.ucsd.edu> Sent: Tue Nov 13 16:26:45 2012 Subject: [44net] Gateway entry / pub routing (Please trim inclusions from previous messages) _______________________________________________ There is a tunnel on the encap list that needs correction (recursive routing): route addprivate 44.131.192/29 encap 44.131.192.1 I have also noticed that routing from the public internet doesn't go any further than the 132.239.255.131 host at UCSD, but I've only spot test a few hosts other than myself. If anyone is interested in using a Cisco router for GW connectivity, I have a 7206 (non VXR) chassis(empty) up for grabs/trade. 73 Jason _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] Encap tunnels
by Nick G4IRX (44.131) 05 Nov '12

05 Nov '12

> Actually, ampr encap uses proto 4 (IPIP), proto 94 being obsolete. > 73s de Marius, YO2LOJ Thanks for clarifying that for me Marius! KA9Q still gets a mention in IOS 12.4 though. 73 Nick.

1 0

Cisco 1721 SLIP
by Nick G4IRX (44.131) 05 Nov '12

05 Nov '12

Jason, This is my IOS config for a 1721 but should work on other routers with an AUX port. The aux port corresponds to line 5 (show line will identify it). Encapsulation is set to slip but you can also set it to ppp. Connection to a PC serial port is via a normal Cisco (blue) rollover cable. ! interface Async5 ip address 192.168.44.1 255.255.255.0 encapsulation slip async mode dedicated ! ! line aux 0 modem InOut transport input all flowcontrol hardware rxspeed 19200 txspeed 19200 ! ! I would be most interested to see your perl script Regards, Nick.

1 0

Encap tunnels
by Nick G4IRX (44.131) 05 Nov '12

05 Nov '12

Hello, New to the list although I do have some JNOS experiences from 12+ years ago. FIrstly, I seem to have volunteered myself as co-ordinator for amprnets in my part of the UK - 44.131.[56-62] so I'd like to thank my predecessor John G1HTL for his efforts over the past couple of decades. I'm trying to discover what the best practice is for routing 44net traffic based upon what I can see in the encap file. Presumably each one of these is a tunnel, what would be defined in Cisco-speak as "tunnel mode nos" (protocol 94)? I'm experimenting here with the G8PZT Xrouter software which runs under dos and provides ip connectivity to radio links. I have a spare Cisco 1721 that I've connected to Xrouter with a SLIP link to the aux port on the router and once I figure out how to get encap routing up and running I may be able to provide 44net access via a radio port (subject to UK licensing of course ) . I'm interested to know what other folks are using to route 44net over the internet? Regards, Nick.

4 3

RE Cairns Paket Radio
by VK4FQ/VK4TTT Sam 04 Nov '12

04 Nov '12

Guys Wish to notify our site is down - Due to an adsl fault - the cable was cut and awaiting it to be rejoined. The temp fix they did a few months back has failed Regards Sam Amateur Radio Callsign: VK4FQ / VK4TTT Owner: VK4RCN P25 Repeater Cairns Sysop: APRS Cairns Mobile: VK4FQ-9 (vhf) VK4FQ-15 (Hf)

1 0

Links and forwarding partners
by Kutche, Jerry (Mitchell) USA 01 Nov '12

01 Nov '12

Hello. Looking for links and forwarding partners via NET44 44.48.0.46 encap 69.27. 54.92 Node call n9lya-6 BBS call n9lya-5 If interested please add me and send me your info.. I can do AXUDP or IPIP I am running Jnos 2.0j under debian 6.05 73 N9LYA Jerry Kutche Electrical Supervisor Lehigh Cement Company LLC 180 N. Meridian Road Mitchell, IN 47446 Phone: (812) 849-2191 ext. 251 Fax: (812) 849-5007 Cell: (812) 583-0445 jkutche(a)lehighcement.com<mailto:jkutche@lehighcement.com> www.lehighcement.com<file:///C:\Documents%20and%20Settings\kmundy\Application%20Data\Microsoft\S…> This e-mail may contain confidential and/or legally privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

3 3

San Joaquin Valley Gateway IP Change
by Ray Quinn 25 Oct '12

25 Oct '12

A heads up or FYI: For anyone exchanging messages with the W6RAY BBS (SJVBBS), I have changed the IP address. As soon as you update your encap.txt or RIP, you should have a correct address for w6ray.ampr.org. I have moved other software to another computer due to both needing the same IP addresses. The other software has its IP address in far more nodelists than the encapsulated list. It is much simpler to change this one than the many others. On another note: I would like to publicly thank Bob Tenty for his assistance in getting the W6RAY gateway accessible from the web. Bill Lewis, KG6BAJ, has also helped me a great deal, including pointing me to Bob. Thanks to both of you. 73 de Ray Quinn W6RAY Visalia, CA USA DM06ih

1 1

Address Coordinators please register
by Brian Kantor 21 Oct '12

21 Oct '12

Although the AMPR web portal is still under development, it would be very helpful if all the AMPR IP Address Coordinators were to please connect to <https://portal.ampr.org/> and register their login and password. In this way we can get the coordinator contact information updated. Thank you. - Brian

14 20

Re: [44net] Fwd: nuisance proto 94 ipip OSPFv2
by Kutche, Jerry (Mitchell) USA 14 Oct '12

14 Oct '12

I just unplugged my jnos see if it stopped.. ----- Original Message ----- From: 44net-bounces+jkutche=lehighcement.com(a)hamradio.ucsd.edu <44net-bounces+jkutche=lehighcement.com(a)hamradio.ucsd.edu> To: 44net(a)hamradio.ucsd.edu <44net(a)hamradio.ucsd.edu> Sent: Sun Oct 14 07:08:45 2012 Subject: [44net] Fwd: nuisance proto 94 ipip OSPFv2 (Please trim inclusions from previous messages) _______________________________________________ Anyone else getting this from 99.119.146.20? It's not a huge amount of bandwidth here, but it's a multicast of some type, and it comes from that ip with a 44-net address encapped in it...resolved to a k9 something....been constantly hitting me at about 40-50 packets per minute.... I've set my router to silently drop them for now.... Cheers, John _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

3 2

Fwd: Re: AMPRNet Gateways update
by Marco Di Martino (IW2OHX) 14 Oct '12

14 Oct '12

Hi Chris, my name is Marco and I'm Ampr Coordinator for Italy: 44.134.0.0/16. Please, can you allocate this range to me ? And... please can you also add these Gateways to my account ? Account name: iw2ohx Gateways: Title 83.211.73.103 Gateway IP 83.211.73.103 Subnet 44.134.160.0 / 24 Subnet 44.134.166.0 / 24 Subnet 44.134.167.128 / 25 Subnet 44.134.168.0 / 24 - Title 91.121.90.186 Gateway IP 91.121.90.186 Subnet 44.134.0.0 / 20 Subnet 44.134.128.0 / 20 Subnet 44.134.144.0 / 22 Subnet 44.134.173.0 / 24 Subnet 44.134.174.0 / 23 Many thanks, Marco iw2ohx On 10/09/2012 10:45 AM, Chris Smith wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > Another point I should mention concerning the new portal and Gateways robot: > > All of the current Gateway data has been imported into the new system. This means that if you already have a gateway registered on the current system, it will be present on the new system, so there is no need to add it. > > The downside to this, is that if you register on the portal to manage your gateway, it will not simply "appear" on your account. This is because it is already present on a default account. > > The solution is to contact me with your gateway details (Username as registered on the portal, Gateway IP and Subnets serviced) and I will transfer it across to your account. > > Thanks, > Chris > G1FEF > > > > > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net > -- --- Marco Di Martino Via Attimo, 18 - Bollate (MI) Mobile: +393285373364 e-mail:iw2ohx@iw2ohx.net - Amateur Radio: I W 2 O H X Homepage Inet:www.iw2ohx.net Homepage Ampr: iw2ohx.ampr.org LinuxNode:telnet://iw2ohx.ampr.org/ (X)net:telnet://iw2ohx-2.ampr.org/ Packet Mail : IW2OHX @ IW2OHX.ILOM.ITA.EU Ampr Mail:iw2ohx@iw2ohx.ampr.org ---

4 3

New Portal and DNS
by Chris Smith 11 Oct '12

11 Oct '12

Please note that the DNS functionality on the new portal is not live yet, any DNS update requests will be silently discarded by the system. It is planned that this functionality will be available quite soon, at which time an announcement will be made on this mailing list. Thanks, Chris G1FEF

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net