- 44net - mailman.ardc.net

Re: [44net] Tunnel mesh is (mostly) down
by Rob Janssen 06 Jan '15

06 Jan '15

> Subject: > Re: [44net] Tunnel mesh is (mostly) down > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 01/05/2015 10:54 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Yes, the latest version drops subnets for which the gateway is set inside > their own subnet, sice this breaks routing. > > Marius > > -----Original Message----- > From:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu > [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Rob > Janssen > Sent: Monday, January 05, 2015 22:28 > To:44net@hamradio.ucsd.edu > Subject: Re: [44net] Tunnel mesh is (mostly) down > > ... > It could be that the latest version that I now downloaded hides that problem > with 44.140.0.1 > but I can easily see if other routes are appearing/disappearing regularly. > ... > > Rob There is still something wrong with that network. Now that the 44.140.0.1 gateway is rejected, a gateway 192.16.126.18 inconsistently appears in the route table (sometimes it is there, sometimes it isn't). But that gateway is not listed at all in the portal! In the portal there is a gateway at 44.140.0.1 that advertises to be the gateway for subnet 44.140.0.0/16, of course wrong. The 192.16.126.18 would be fine, but it does not appear in the gateway listing at portal.ampr.org. But it is broadcast (occasionally) in the RIP broadcast. Difficult to follow what is going on here, I would say there is insufficient error checking somewhere. Rob

1 0

Re: [44net] Tunnel mesh is (mostly) down
by Rob Janssen 06 Jan '15

06 Jan '15

> Subject: > Re: [44net] Tunnel mesh is (mostly) down > From: > "Michael E Fox - N6MEF" <n6mef(a)mefox.org> > Date: > 01/06/2015 12:32 AM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hmmm. Given a 1 hour timeout, then any error would need to be detected and > corrected within that hour, or else routes will still be lost. Correct? > > It would seem that a timeout of something more like 24 hours would be more > practical. The rationale behind the 1 hour timeout is not to cover errors and outages, although it could cover cases where e.g. the server has to be relocated within the same room, or network maintenance occurs. The reason is that one of the hypotheses is that there is packet loss that drops the RIP packets, and when two subsequent RIP bursts would each loss the last (or n'th) packet e.g. because of a queue overflow somewhere the route would be already lost. The chance of this happening to 12 subsequent broadcasts (1 hour) is smaller. Further increasing the timeout would mean that a route that is no longer present would take much longer to disappear, unless a mechanism as described by Marius is added. (where a deleted route is announced in a special way) With that modification, the timeout could be safely set to something like 1 week. Rob

1 0

Re: [44net] Tunnel mesh is (mostly) down
by Rob Janssen 05 Jan '15

05 Jan '15

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] Tunnel mesh is (mostly) down > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 01/05/2015 07:30 AM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hello, > > I don't think that increasing the route timeout the would have any bad side > effects (I think 7200 would be a good value). I have recompiled with 3600 before I read that. However, I'll keep a watch on it for some time to see if strange things still happen. It could be that the latest version that I now downloaded hides that problem with 44.140.0.1 but I can easily see if other routes are appearing/disappearing regularly. > > But maybe there is another mechanism that could be added to the ampr gateway > (And which is already implemented in ampr-ripd): > The daemon is capable of force exipring routes if they are received with > metric 15. > So adding the sending of deleted subnets with metric 15 fore a given time > AND increasing normal expire time to higher values (e.g. 10800 - 3 hours, or > even more) would make the system more stable. > > Marius, YO2LOJ > > That sounds like a good idea, in that case there could be a much longer timeout, but maybe it should then (as Brian suggested) log when it receives less packets than normal. E.g. count the received packets in a single burst and syslog a message when it is 2-3 less than in the previous burst. When we fix the problem that routes disappear too soon, but then nobody notices anything and 24 hours later we still have a problem because the routes are suddenly deleted, not much has improved. When there is some alert I can watch it in our nagios monitoring. Rob

2 1

PP5ES
by Brian Kantor 05 Jan '15

05 Jan '15

Is PP5ES on this mailing list? If so, please contact me off-list. Thank you. - Brian

1 0

Re: [44net] Tunnel mesh is (mostly) down
by Rob Janssen 05 Jan '15

05 Jan '15

> Subject: > Re: [44net] Tunnel mesh is (mostly) down > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 01/05/2015 07:26 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Mon, Jan 05, 2015 at 02:27:18PM +0200, Marius Petrescu wrote: >> >Let me get this right... You are talking about the encapsulated RIP >> >transmissions originating from 169.228.66.251 to each public gateway IP? >> > >> >-----Original Message----- >> >On Behalf Of Rob Janssen >> >Sent: Monday, January 05, 2015 11:11 >> >To: Brian Kantor >> >Cc:44net@hamradio.ucsd.edu >> >Subject: Re: [44net] Tunnel mesh is (mostly) down >> > >> >Maybe something else you can do is drop the extra transmission of RIP >> >packets from the public IP >> >address. I think nobody is really using those (if not because of the funny >> >destination port number), and >> >they only add to this problem by putting even more data in the queue. > Up until a few minutes ago, the amprgw system was sending the RIP data > twice - once UNencapsulated to the public gateway IP, once encapsulated. > > Since to the best of my knowledge, no one was using the UNencapsulated RIP > for anything, I've discontinued sending it. > > If I'm wrong and someone is using it for something, I'll turn it back on. > - Brian > > > Note that those transmissions were sent to a seemingly random destination port number, which made them kind of hard to use. The source port number was always 520. I don't know if that was a bug or a feature, but it puzzled me when I was trying to receive them and could not get the encapsulated transmission working in ampr-ripd. (an issue that I later located and Marius made a change that fixed that) Rob

1 0

AMPR Portal Error for Coordinator
by William Lewis 05 Jan '15

05 Jan '15

Chris / Brian. I had a new request for an AMPR addresses allocation from the portal, but there seems to be a couple of issues. First, I never received the new request via email as I usually do. Not sure why I didn't get this request. Second, the user that submitted the request accidentally select my network of 44.002/16 when he should have selected Daniel Curry's network of 44.004/16. In the coordinators section of the portal, when I tried to DENY the request, the page refreshes and I get an error in red stating : "There are children but selected owner is not a coordinator." and I can not deny the request. I have contacted the user who submitted the request and informed him to make another request on the correct network. But, it appears there is a bug on the portal that is not sending me email notifications and not letting me deny requests. Thanks for looking into this. ---------- Wm Lewis (KG6BAJ) AMPR Net IP Address Coordinator - Northern and Central California Regions (A 100% Volunteer Group) (530) 263-1595 (Home/Office) ______________________________________________ ---------- This message is for the designated recipient only and MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. If you have received it in error, please notify the sender immediately and delete the original. Any other use of this E-mail is prohibited.

1 0

Linux policy routing explained briefly
by Brian 04 Jan '15

04 Jan '15

There seems to be a bit of confusion as to how linux routes via policy routing. The tool which appears to be the most flexible is "ip" found in the iproute2 package. The two key switches are "route" and "rule", and they do exactly what they sound like; one manages routes and route-tables, while the other manages the ruleset in which these routes/tables are called upon. Linux begins with a main route table and a default ruleset in which that table is used. Typically you don't even notice this as it's created with the configuration of the standard network devices upon boot. Two rules will be applied for this main route table: 1) main 2) default The rules are such that the priority to these tables is so low almost any other rule will take priority over it. That's what makes amprnet routing for linux quite simple. The rule you want to make for amprnet is such that any inbound OR outbound routing sourced as 44-net uses it's own route table, with a priority higher than the main table rule. As long as the routes are in this matched table, the kernel will act as an amprnet router just fine even to entities such as xNOS, Xnet, etc. So if you want proper packet flow make sure all paths and rules match for the source you wish to route - in our case it's 44/8: A sample standard path would look like: commercial to commercial/nat inet/0 <----> linux-nat or com IP table main commercial to your ampr inet/0 <----> ucsd/bgp host ucsd/bgp host <---> linux 44-tunl0 via rule 1/table 1 <---> node/bbs/dxc ampr to ampr (tunnel only shown) 44/8-tunl0 <---> linux tunl0/rule 1/table 1 <---> node/bbs/dxc ampr to ampr to xNOS/Xnet (tunnel only shown) 44/8-tunl0 <---> linux tunl0/rule 1/table 1 <---> tun0/tap0-xNOS/Xnet This shows that the Xnet or xNOS tun/tap interfaces need to be included within the ruleset that matches table 1 or else it will become unroutable. Also you need to insure ip_forwarding is enabled, and your firewalling permits ip protocol 4 (ipencap), and ip protocol 93 (AX.25) A simple script which can do this for you is found at http://n1uro.ampr.org/linuxconf/dotun.html # --- dotun.sh --- #! /bin/bash # dotun.sh script written by N1URO # June, 2013 # enter in your information below, these are used for creating a # gateway and linking to the amprnet: AMPRIP='x.x.x.x' IPMASK='x.x.x.x' COMMIP='x.x.x.x' NOSIP='x.x.x.x' case "$1" in start) # Load your ipencap module in the kernel: modprobe ipip # Allow ip forwarding from amprnet to your ethernet interface echo "1" > /proc/sys/net/ipv4/ip_forward # load RIPv2 routing using the ampr-ripd daemon /usr/local/sbin/ampr-ripd -t 1 -a $COMMIP -p <password> -i tunl0 -v -s -r # Configure your ipencap tunnel interface - required for the amprnet ifconfig tunl0 $AMPRIP netmask $IPMASK up # Allow traceroutes to work on the amprnet: ip tunnel change tunl0 mode ipip ttl 64 tunl0 pmtudisc # If you run xNOS, configure a tun/tap interface: ifconfig tun0 $AMPRIP pointopoint $NOSIP up # configure your rointing accordingly: ip route add $NOSIP dev tun0 onlink table 1 src $AMPRIP ip route add default via 169.228.66.251 dev tunl0 src $AMPRIP onlink table 1 # configure policy routing so that frames from/to your 44-net IP # know how to route accordingly: ip rule add from 44/8 pref 1 table 1 ip rule add to 44/8 pref 1 table 1 # script is done, exit as a clean flush. exit 0 ;; stop) # Unload what we loaded above: ip rule del to 44/8 pref 1 table 1 ip rule del from 44/8 pref 1 table 1 ifconfig tunl0 down ifconfig tun0 down killall -TERM ampr-ripd modprobe -r ipip exit 0 ;; restart) dotun stop sleep 3 dotun start exit 0 ;; *) echo "Usage: dotun {start|stop|restart}" exit 0 ;; esac exit 0 --- EOF --- -- If Microsoft intended Windows to be for ham usage, they would have incorporated our protocols into their kernel. 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

5 6

Tunnel mesh is (mostly) down
by Rob Janssen 04 Jan '15

04 Jan '15

The tunnel mesh went down today at about 08:20 UTC. Most of our routes have disappeared, are no longer being advertised on RIP. The portal.ampr.org site is not responding anymore. It looks like the portal is no longer distributing correct information to the RIP server and so the RIP server sends incomplete broadcasts and the ampr-ripd deletes the routes. Is there some fallback scenario, e.g. loading a last correct list of routes by the RIP server to make the network come back up in the state it was just before the mishap? Rob

12 15

Re: [44net] Tunnel mesh is (mostly) down
by Rob Janssen 03 Jan '15

03 Jan '15

> Subject: > Re: [44net] Tunnel mesh is (mostly) down > From: > Eric Fort <eric.fort(a)gmail.com> > Date: > 01/03/2015 05:35 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > how about eliminating this issue perminantly from ever happening and > moving to voluntary peering between gateways. Know thy neighbor and > be responsible foryourpeers androutesseems to work really well for > everyone else yet amprnet still relies upon route distribution from a > single source. > > Eric > AF6EP It is still not clear to me what exactly happened, and how it was resolved, but what I saw here is that the number of tunnel routes decreased dramatically and this disconnected the stations on IPIP including myself. We already are BGP announced. That is not the problem. But as a properly setup gateway, we are both on BGP and the IPIP tunnel mesh, and the latter we configured using RIP (ampr-ripd). What apparently happened is that we received RIP broadcasts with only a very small subset of the active routes, and over time most routes got deleted. So we still had full connectivity to internet for net 44.137.0.0/16 and our statically connected subnets, but the tunnel routes inside the country and to the rest of the world mostly vanished. We don't really need those tunnels to everywhere over the world, but we run them to remain compatible with the rest of the system. It would be sufficient for us to have only tunnels to our local users, and have the remainder of the traffic routed over plain internet. However: - there is no way in the portal to specify that you want to use tunnel routes only for your own subnets - there are access lists in use at other stations that would block traffic going outside the tunnel system, because they want to limit traffic to only net-44, so we would get obscure routing problems So for now we will keep running a tunnel mesh system, and I hope that everyone else who prefers functionality over other reasons will do the same. (I fail to see how a single-point-of-failure solution can be a worse choice than a configuration that does not work *at all* even when everything is up and running) In the meantime, I hope some people can find some time to debug what was going on here. I have seen a similar problem in the RIP broadcasts before, a set of routes that appears and disappears at random. They appear in some RIP broadcast sets, then do not appear in some, then re-appear, etc. There must be a problem somewhere, but it is unclear if it is in the RIP server or in the code that delivers info to it. Maybe the problem of this morning is caused by the same bug, as it appears to have affected only a subset of all routes. Rob

1 0

Re: [44net] Tunnel mesh is (mostly) down
by Bryan Fields 03 Jan '15

03 Jan '15

On 1/3/15, 11:45 AM, Brian wrote: > On Sat, 2015-01-03 at 08:35 -0800, Eric Fort wrote: > >> > how about eliminating this issue perminantly from ever happening and >> > moving to voluntary peering between gateways. Know thy neighbor and >> > be responsible foryourpeers androutesseems to work really well for >> > everyone else yet amprnet still relies upon route distribution from a >> > single source. > Are you suggesting something such as a possible BGPv2 that all gateways > or designated regional gateways could perhaps tunnel broadcast between > themselves? This would be interesting and may help with other route > issues between those using RIPv2 <-> BGP amprnet sites. Why tunnel at the gateway level?, let the other gateways run BGP. Problem solved. How you get to the gateway could be IPIP, GRE, IPSEC, or you can run BGP yourself. Or even if you have a friendly peering location that lets you put a dish on the roof. Treating this like is some kinda special VPN really holds amprnet back. 73's W9CR -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

4 3

Re: [44net] Should I worry about this crud coming in via the tunnel?
by Rob Janssen 02 Jan '15

02 Jan '15

> Subject: > [44net] Should I worry about this crud coming in via the tunnel? > From: > Arno Verhoeven <pe1icq(a)vrhvn.nl> > Date: > 01/02/2015 04:11 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hi, > > I have been monitoring traffic coming in via the tunnel and am a bit shocked how much bogus (?) traffic comes in from non-44 addresses. Yes, this is quite normal. Imagine how much comes in to the country gateway and gets dropped... The internet is full of people who only want to destroy it and there is not much that can be done about it. People use spoofed sender addresses (their provider should block that but many providers don't care), and others like to scan for all kinds of situations they can abuse, e.g. for DDOS. You need a good firewall. But maybe not what Tom suggests, because that ends your connectivity with the non-44 part of internet. Rob

1 0

Should I worry about this crud coming in via the tunnel?
by Arno Verhoeven 02 Jan '15

02 Jan '15

Hi, I have been monitoring traffic coming in via the tunnel and am a bit shocked how much bogus (?) traffic comes in from non-44 addresses. I have these rules in my firewall script: /usr/sbin/iptables -P INPUT DROP # Drop all traffic coming from Internet addresses via the tunnel to PE1ICQnet, except port 8000:8001 to raspberry pi (Dire Wolf). /usr/sbin/iptables -A INPUT -i ampr0 -s 44.0.0.0/8 -d 44.137.27.123 -p tdp -m multiport --dport 8000:8001 -j ACCEPT /usr/sbin/iptables -A INPUT -i ampr0 ! -s 44.0.0.0/8 -d 44.137.27.112/28 -j DROP When I monitor traffic on the tunnel interface with tcpdump -i ampr0 -vvn then I see a lot of traffic like this: 15:47:54.172385 IP (tos 0x0, ttl 51, id 60643, offset 0, flags [none], proto ICMP (1), length 98) 119.206.12.19 > 44.137.27.125: ICMP 119.206.12.19 udp port 53 unreachable, length 78 IP (tos 0x28, ttl 234, id 31771, offset 0, flags [DF], proto UDP (17), length 70) 44.137.27.125.29327 > 119.206.12.19.53: [udp sum ok] 31771+ A? ocektarhe.www.2015yf.com. (42) Remarkable, because at the moment I do not even have ip address 44.137.27.125 in use on the LAN. How do I need to interpret the above traffic dump? Is it because 44.137.27.125 is spoofed? Is it an attack using bogus domain resolving? (I see a lot of variants in the 2015yf.com domain) Basically, my question is, should I worry? ;-) 73 PE1ICQ // Arno

2 1

Attn. Brian ref IP address.
by trcarswell 27 Dec '14

27 Dec '14

I sent an email over a year ago...(it seems) to remove me from being an IP coord. I guess you missed it. I just got a email for a request...that was over a year old....the guy is pissed... as I would be....lol Pls remove me ...I hope someone can take my place... My wife got sick right after I became the the NC coord. Sorry. Trip - KT4WO

1 0

How to make traffic coming in on the tunnel interface get answered from that interface?
by Arno Verhoeven 27 Dec '14

27 Dec '14

Hi, I am looking for help setting up a conditional routing table. I have my tunnel up and running. I can reach other 44-net host. amrp-ripd is used to fill the routing table. So far so good, but I would like one of the web-sites (apache httpd vhost) to be reachable from both 44-net and non-44-net. If i check with tcpdump I see traffic coming in when I try to access the web-site (pi8zaa.ampr.org) via the Internet (I used my phone connected to t-mobile network). But it doesn't work because my server routes the replies to my ISP's Gw where they get source filtered. Basically I want/need traffic that comes in via the tunnel to get answered from the tunnel interface. I Googled for a solution. Found lots of variant of this http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html but if I understand what is described there correctly, then that is not exactly what I need. Maybe I don't understand iproute2 and its routing table concept correctly. They way I understand it, those examples assume destination routing based on provider subnet, while in my case the destination is on the Internet, and in normal cases should be routed via my ISP except if it came in via the tunnel. Thanks for any help you can offer. 73 PE1ICQ // Arno

8 36

Merry Christmas
by Brian Kantor 25 Dec '14

25 Dec '14

+ XXX XXXXX XXXXXXX XXXXXXXXX "BUON ANNO" "JOYEUX NOEL" "VESELE VANOCE" "MELE KALIKIMAKA" "NODLAG SONA DHUIT" "BLWYDDYN NEWYDD DDA" "GOD JUL" "FELIZ NATAL" "BOAS FESTAS" "FELIZ NAVIDAD" "MERRY CHRISTMAS" "KALA CHRISTOUGENA" "VROLIJK KERSTFEEST" "FROHLICHE WEIHNACHTEN" "BUON NATALE-GODT NYTAR" "HUAN YING SHENG TAN CHIEH" "WESOLYCH SWIAT-SRETAN BOZIC" "MOADIM LESIMHA-LINKSMU KALEDU" "HAUSKAA JOULUA-AID SAID MOUBARK" "'N PRETTIG KERSTMIS" "ONNZLLISTA UUTTA VUOTTA" "Z ROZHDESTYOM KHRYSTOVYM" "NADOLIG LLAWEN-GOTT NYTTSAR" "FELIC NADAL-GOJAN KRISTNASKON" "S NOVYM GODOM-FELIZ ANO NUEVO" "GLEDILEG JOL-NOELINIZ KUTLU OLSUM" "EEN GELUKKIG NIEUWJAAR-SRETAN BOSIC" "KRIHSTLINDJA GEZUAR-KALA CHRISTOUGENA" "SELAMAT HARI NATAL - LAHNINGU NAJU METU" "SARBATORI FERICITE-BUON ANNO" "ZORIONEKO GABON-HRISTOS SE RODI" "BOLDOG KARACSONNY-VESELE VIANOCE " "MERRY CHRISTMAS - - HAPPY NEW YEAR" "ROOMSAID JOULU PUHI -KUNG HO SHENG TEN" "FELICES PASUAS-EIN GLUCKICHES NEWJAHR" "PRIECIGUS ZIEMAN SVETKUS SARBATORI VESLLE" "BONNE ANNEBLWYDDYN NEWYDD DDADRFELIZ NATAL" XXXXX XXXXX XXXXX XXXXXXXXXXXXX Submitted by: Gordon Joly <G.Joly(a)cs.ucl.ac.uk> Nov. 30, 1994

1 0

Seasons Greetings
by Brian 24 Dec '14

24 Dec '14

To those on the list; Happy and memorable holiday wishes to you and your families. The amprnet has gone through many changes and developments bringing it great success. Here's to even more success in 2015 *raises glass of spiked egg nog* cheers! -- If Microsoft intended Windows to be for ham usage, they would have incorporated our protocols into their kernel. 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

3 2

Problem with new subnet security policy
by F6CNB 22 Dec '14

22 Dec '14

Hi, I have been running a gateway since 1991 either in Texas or in France. I have a serious problem with the new security policy which does not allow to add a subnet if it is not allocated to you in the portal database. First it is preventing a single gateway to serve multiple hamradios and their subnets. This is completely against the spirit of hamradio. It is also preventing to serve IP addresses which are not registered in the portal.ampr.org. (i.e. HAMNET Europe (44.168.x.x for France) are defined in hamnetdb.net portal. Some 44.76.x.x addresses are not in the portal too but only in the host file) In the Paris area we are developing a HAMNET network using the French allocation 44.168.x.y. This network is using wifi equipments in 2.3 and 5.6GHz hamradio band. There is a single gateway (mine) and a lot of sites/subnet/host and backbones which are not mine of course. I have currently several subnets to add to my gateway but unfortunately I cannot. This is holding the deployment of several sites and applications like DMR repeaters connections thru HAMNET and other. I hope that a solution will be find very quickly. 73 de Remi F6CNB (or W5/F6CNB)

4 3

Re: [44net] ampr-ripd 1.12 released
by Rob Janssen 14 Dec '14

14 Dec '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] ampr-ripd 1.12 released > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 11/16/2014 01:36 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hello OMs, > > Following the idea from Rob, PE1CHL, I added the possibility to execute a > system command from ampr-ripd if routes are set or changed. > This will happen on startup, after an existing encap is found in > /var/lib/ampr-ripd, or after 30 seconds after a RIP update, if there is a > change in the encap data (AFTER saving the new encap file if requested). Thanks Marius! I have installed it on my own gateway and the 44.137 gateway and first tests shows it works fine. For the others: I requested this feature to modify a firewall when gateways change address. Before I accepted IPIP packets from everyone, but this is a weakness in the system that maybe could be exploited. I observed rogue IPIP packets from the far east. So instead of: iptables -A firewall -p 4 -j ACCEPT on the incoming interface, I now have: iptables -A firewall -p 4 -j ipipfilter and I have the following script that inserts/updates the ipipfilter list: #!/bin/sh # load encap.txt into ipipfilter list PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" AMPRGW="169.228.66.251" gwfile="/tmp/gw" cd /var/lib/ampr-ripd || exit 1 grep addprivate encap.txt | sed -e 's/.*encap //' | sort -u >$gwfile if iptables -N ipipfilter 2>/dev/null then iptables -F ipipfilter iptables -A ipipfilter -s $AMPRGW -j ACCEPT while read ip do iptables -A ipipfilter -s $ip -j ACCEPT done <$gwfile iptables -A ipipfilter -j DROP else iptables -L ipipfilter -n | grep ACCEPT | fgrep -v $AMPRGW | \ sed -e 's/.*-- //' -e 's/ .*//' | sort | diff - $gwfile | \ while read d ip do case "$d" in ">") iptables -I ipipfilter -s $ip -j ACCEPT ;; "<") iptables -D ipipfilter -s $ip -j ACCEPT ;; *) ;; esac done fi rm -f $gwfile The full pathname of this script /usr/local/sbin/load_ipipfilter is passed with the new -x option to ampr-ripd. It will load the entire filter the first time, and later it will only update the filters that have changed. It is required that the -s option is passed as well, so the encap.txt file is created by ampr-ripd. Now I only accept IPIP packets from addresses in the gateway list, which makes me feel a bit safer. (of course sanity checks were already done on the incoming IPIP packets) Rob

3 2

Oops what went wrong
by Erwin 07 Dec '14

07 Dec '14

Hi, Some dutch hams did a great job to bring the Gateway to Holland. Roundtrip time drops to about 17ms now. I wanted to do some tests and logged in into the portal to add a gateway and subnets. Using the portal it didn't succeed to add it and I tried the email robot instead. When I take a look to my gateway address it's in use by Chris, G1FEF. I don't see anything from me in the gateway list now. How solve this problem? 73, Erwin

1 0

Add network to gateway
by Marc, LX1DUC 28 Nov '14

28 Nov '14

Good afternoon, in the original layout it was possible to add any network to a gateway. Now you can only add networks assigned to the account holding the gateway, at the same time it seems impossible to add a gateway more than once or to share a gateway between several network holders. While I agree that users should be unable to add foreign networks to their gateway, it also creates an issue where several OMs decided to share 1 single gateway for various reasons. Can someone please advise how to share a gateway between several resource holders under the current portal design and logic? vy 73 -- Marc, LX1DUC -- www.laru.lu - Luxembourg Amateur Radio Union www.emcomm.services - Emergency Communication www.ham-dmr.lu - DMR Infos for HAMs

8 11

Re: [44net] Add network to gateway
by Rob Janssen 28 Nov '14

28 Nov '14

> Subject: > Re: [44net] Add network to gateway > From: > Chris <chris(a)g1fef.co.uk> > Date: > 11/28/2014 08:13 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Guys, > > The intention was not to cut anyone off, but there were a lot of folk adding 44 networks to gateways that had not been allocated to them, or indeed allocated at all. Of course that is because your view on "allocated" is different from others' I think any address that has an entry in the .ampr.org DNS is "allocated". That it does not have an entry in your list of allocated subnets is a different matter. > The whole point of the Portal is to document who has been allocated (and is using) what IPs. So the gateway code has been updated to only allow allocated networks to be added to gateways. I would have considered it better when the work on managing allocations (addresses and DNS entries) had been finished first. But of course it is a hobby project so you can set your own priorities. Rob

1 0

Portal API
by Chris 26 Nov '14

26 Nov '14

I have implemented an API for accessing the Portal data programatically, if you login and select “API” from the menu there is some info there about it. So far I have only implemented one function: the ability to retrieve the encap routes. I would appreciated comments / feedback / suggestions as well as any bug reports. Thanks, Chris

6 20

Re: [44net] Bogus route entries
by Rob Janssen 25 Nov '14

25 Nov '14

> Re: [44net] Bogus route entries > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 11/25/2014 07:26 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hello, > > With the last apr-ripd version (1.13), this entry (or any other having the > gateway inside its own subnet) gets ignored and can be direct routed (since > it is BGP-ed). > Unlike the entry 44.140.0.0/24 via some public IP which does not work. > I would prefer to see it as it is via 44.140.0.1... > > Marius, YO2LOJ Ok I must tell I have not yet installed the latest version, I am using 1.12 with the -x option and I noted this one (as it appears near the top of the list) is coming and going all the time. I captured a trace and this entry was not among the RIP entries sent at that time. So the problem is somewhere upstream, not in ampr-ripd. Next tuesday we will move our gateway to the datacenter of our ISP and we will start doing BGP routing of 44.137 (permission from ARDC is already obtained), so then I will update ampr-ripd and see what I can do to have entries like this working OK. But this time my main question is why is this route changing all the time even when it is not updated in the portal? (unlike the French one and now a Spanish one where users apparently are experimenting and do not understand the system so they insert and delete their entry all the time until it works) Rob

1 0

Bogus route entries
by Rob Janssen 25 Nov '14

25 Nov '14

Can somebody explain why the entry "44.140.0.0/16 via 44.140.0.1" keeps appearing and disappearing? Of course it was already discussed before that this entry has limited usefulness, but ok when someone wants to have it, let them (I won't be able to use it). However, it appearing and not appearing in the routing table in a blinkenlight fashion, while the portal says: Last modified 2014-04-12 17:46:33 Something is going wrong somewhere, but where? Rob

2 1

Re: [44net] Attn LX gateway
by Rob Janssen 25 Nov '14

25 Nov '14

> Subject: > Re: [44net] Attn LX gateway > From: > "Marc, LX1DUC" <lx1duc(a)laru.lu> > Date: > 11/14/2014 12:25 AM > > To: > 44net(a)hamradio.ucsd.edu > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12/11/2014 21:46, Rob Janssen wrote: > > As Rob seems to have had issues finding the correct contact email > address for the IP address mentioned, I thought this might be helpful > to share with the group: > > For IP addresses allocated by RIPE there is the Abuse (Contact) Finder: > https://apps.db.ripe.net/search/abuse-finder.html > > Not each and every network has updated to the latest RIPE policies, > but it's always worth a shot:-) > > 73 de Marc It is also helpful when some contact or identifying information is present in the gateway listing on portal.ampr.org. In this case it only points to a clubstation with an info address, but via that I was able to get the message forwarded to you. It would have been helpful when your callsign and/or e-mail had been present in the portal listing. 73, Rob

13 24

Which radio is good for connect with a PC ?
by Ernest.Tse＠Pacswitch 19 Nov '14

19 Nov '14

An embedded and charset-unspecified text was scrubbed... Name: not available URL: <http://hamradio.ucsd.edu/mailman/private/44net/attachments/20141120/41bcfb6…>

1 0

Which radio is good for connect with a PC ?
by Ernest.Tse＠Pacswitch 19 Nov '14

19 Nov '14

An embedded and charset-unspecified text was scrubbed... Name: not available URL: <http://hamradio.ucsd.edu/mailman/private/44net/attachments/20141119/c3f67e2…>

4 3

Re: [44net] amprgw ok?
by Rob Janssen 18 Nov '14

18 Nov '14

> Subject: > Re: [44net] amprgw ok? > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 11/18/2014 06:05 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Brian, Chris, thank you for your efforts. > > I took a look at the latest sent encap info and I want to bring in > discussion the way how some gateways are announced. > >> >route addprivate 44.24.240/20 encap 44.24.221.1 > Now this one is ok. The gateway (44.24.221.1) is BGP announced, but not in > the encap file. Everything ok and working. Ok, with the exception that my systems cannot route to there, because the gateway is within network-44. Discussed before. Hopefully will change after we are on BGP ourselves, on a connection that does not do source address filtering. But we won't be using a gateway within network-44 unless absolutely required, I still think it is something to be avoided because quite a lot of gateways will not be able to route there, and the reason of "reliability" that was given for this setup in fact results in permanent failure. > > Now to the other two IMHO are wrong: > >> >route addprivate 44.151.94.28/32 encap 44.151.94.28 > So this host expects to get encapsulated traffic to a gateway which is the > host itself. This leeds to a routing loop and is not possible with a regular > setup. > This encap entry is in fact plain and simple useless: It states 'you can > reach me via me' which gives not much information. This one appears and disappears. Sometimes it is in my list, sometimes not. It could be that he does not understand how to setup his system, and is not able to read English very well. Maybe a French or otherwise Francophone person can try to contact him and ask what is going on. > >> >route addprivate 44.140/16 encap 44.140.0.1 > The same applies to the above, just that the whole subnet is routed to a > gateway which is part of that subnet itself. > This one also appears and disappears. When I looked in the portal gateway list, the last two gateways were not appearing there. Could it be that they are old gateways that have already been deleted by their owners but are irregularly being re-announced due to the damaged database? Rob

2 1

portal issue?
by Brian 18 Nov '14

18 Nov '14

It appears some subnets have been purged from the portal. Can we restore from a backup? -- If Microsoft intended Windows to be for ham usage, they would have incorporated our protocols into their kernel. 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

1 0

Which HAM Radio is good for connect with PC
by Ernest.Tse＠Pacswitch 17 Nov '14

17 Nov '14

An embedded and charset-unspecified text was scrubbed... Name: not available URL: <http://hamradio.ucsd.edu/mailman/private/44net/attachments/20141118/0763fce…>

1 0

Re: [44net] ampr-ripd 1.12 released
by Rob Janssen 17 Nov '14

17 Nov '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] ampr-ripd 1.12 released > From: > "SP2L-wp" <sp2l(a)wp.pl> > Date: > 11/17/2014 08:02 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Rob, Marius et al. > > WOW!!! > What a nifty script! > > Isn't small mistype here: > > while read d ip <--- "d" is it correct? > do Hi Tom, Yes, it is correct. It reads the output of the diff command which has lines like: < 1.2.3.4 > 5.6.7.9 It puts the < or > into $d and the IP address into $ip. Then it either deletes or inserts the IP address in the list using the case/esac on $d. You can copy/paste the script and run it and check using: iptables -L ipipfilter -vn to see if it works OK. You can run it again and nothing should change. When all is OK you can change the ampr-ripd startup to add the -x option and modify the firewall to use ipipfilter instead of ACCEPT for -p 4. Make sure in the startup sequence of the system you run the script once before the firewall is loaded, so that the ipipfilter target does exist before the rule for -p 4 is loaded. I have my own script that sets up the entire firewall, so I call the script from there. Rob

1 0

External address changed
by Rob Janssen 16 Nov '14

16 Nov '14

For those who have not yet implemented RIP or automatic import of encap.txt: The external address of the gateway for 44.137 has changed from 194.109.64.198 to 213.222.29.194 in preparation of the setup of direct BGP routing of 44.137.0.0/16 Rob

1 0

Beware of Mikrotik RouterOS v6.21 and v6.22
by Marc, LX1DUC 13 Nov '14

13 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear YLs and OMs, beware of the latest Mikrotik RouterOS version 6.21 and 6.22. It generates strange IPIP packets adressed to the remote endpoint of an IPIP tunnel. The IPIP packets itself contains an IP packet that is addressed from the remote endpoint to the mikrotik router. Pseudo packet capture Frame: 1 Time: 0 Internet Protocol Version 4, Src: Mi.Kr.Ot.Ik (Mi.Kr.Ot.Ik), Dst: Re.Mo.Te.IP (Re.Mo.Te.IP) Internet Protocol Version 4, Src: Re.Mo.Te.IP (Re.Mo.Te.IP), Dst: Mi.Kr.Ot.Ik (Mi.Kr.Ot.Ik) Frame: 2 Time: 10 Internet Protocol Version 4, Src: Mi.Kr.Ot.Ik (Mi.Kr.Ot.Ik), Dst: Re.Mo.Te.IP (Re.Mo.Te.IP) Internet Protocol Version 4, Src: Re.Mo.Te.IP (Re.Mo.Te.IP), Dst: Mi.Kr.Ot.Ik (Mi.Kr.Ot.Ik) and so on, almost every 10 seconds. Once I downgraded to version 6.20 the strange packets seem to have stopped appearing. If someone discovers the origin of this issue and knows of a way to avoid the issue other than downgrading, please let me know. Thanks to PE1CH for notifying me after seeing the strange IPIP packets on his system. 73 de Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJUZTQXAAoJEHFIN1T8ZA8vGwAP/2qJuWXQLG4x3S2zPkQFll15 PA9H/ytSxxfdDsKe7tCf7Ky0qmxUV6WNVbq19/Ag1q6Ld+cBhKbWHa7BOVK9hjV0 8NO2ZV5D7KtYkhSLpNE9othhdtU/hRouevEQy/qoO6EvJxE4fEpbOrMiNX6aTAeQ bnqBWeGsuds7/qHFjOrID0jrfYXdddMW4e9cXwRJRfiFafBIwwLaNHhlKXORaXQy 23mPs+woFskGPk4VXDxWXMuOe3TeWzpxpwldYHaPRhzfUmGBj0ogQ1tSJPiMYMy8 Rc8iE4NtmZMyP0b6IdnoIjveloCpILDIwCHD8ZRba4KSs3aRVcyLih3v67zuu3Jf i+K7BCKXNFIQtGoY7IQQawRF8AP7vxL30r9J9pgKk7IjURDTBWRDbyZb201gdfbp PKV+XBlm+Hq9kxs04BIYeYBES+iVLMOJYtLPQtF906EEc1RuzjjvoKu+BVqIB+vk IRLSBqLsU4V7CM/aj2gvik4TyC2huBjhqpvxNUXeAP5CyMSfqJ8OZZmOYEGyWmZc vif4F5HhwCjPCaQr0OCqUIKuH/hd+/4qXrFtSnTOYPT+mRCMNg1PW/IvkysS86+5 orQ1J+OeqUnfwHrXvR26l9Yo+SqKie3k+1v9iYyv6ZS7eKFKqseL+lPgQmdnnJl4 gY65U+kkGw27RtlLYw5+ =+9vG -----END PGP SIGNATURE-----

3 4

Attn LX gateway
by Rob Janssen 13 Nov '14

13 Nov '14

I am getting a constant stream of nested encapsulated packets from 46.29.182.226 Something is going wrong there. Rob

2 1

Re: [44net] Gateways with external address in net-44
by Rob Janssen 12 Nov '14

12 Nov '14

> Subject: > Re: [44net] Gateways with external address in net-44 > From: > Brian <n1uro(a)n1uro.ampr.org> > Date: > 11/12/2014 02:07 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Wed, 2014-11-12 at 10:16 +0100, Rob Janssen wrote: > >> >Ok, but then I think those gateway entries should not be distributed via RIP. >> >When they are directly routable, should we use a tunnel to reach them? > That's only half the equasion. The other half is when one is SAFed > (Source Address FilterED) and they policy route 44/8 via their tunnel > interface, and anything else via UCSD... Yes that is the problem. I need to policy route on source address because of SAF and I use a separate routing table for the tunnels with a default to UCSD. This fails with that 44.24.240/20 with gateway 44.24.221.1 network. We are building a gateway for 44.137.0.0/16 which in fact has already been running since the summer but the process of getting the provider to agree to route BGP has taken much longer than anticipated. Anyway, this gateway (which of course is not affected by SAF itself) has a separate public IP (194.109.64.198) for use by the IPIP tunnels to other gateways. I think that is a better method, it avoids lots of confusion and complicated policy routing rules. Maybe the routing will work again once we have our country gateway up and running with BGP and direct outbound routing of net-44 traffic (without having to tunnel to UCSD). I plan to work out a routing configuration without separate net-44 routing table at that time. Rob

1 0

Re: [44net] Gateways with external address in net-44
by Rob Janssen 12 Nov '14

12 Nov '14

Brian Kantor wrote: > Those are valid gateway entries; those particular 44-net addresses > are directly routed via BGP advertisement. > - Brian > Ok, but then I think those gateway entries should not be distributed via RIP. When they are directly routable, should we use a tunnel to reach them? There is a problem because when the destination of the tunnel is within the net-44, the routing gets in an encapsulation loop. Rob

6 10

Re: [44net] Gateways with external address in net-44
by Bryan Fields 12 Nov '14

12 Nov '14

+1 On November 12, 2014 12:15:25 PM EST, Tom Hayward <esarfl(a)gmail.com> wrote: > >I think we're getting a bit ahead of ourselves here proposing new >special announcements. > >Here's another idea: don't assume anything spans the whole 44/8. >Instead of policy-routing 44/8, policy route for each of the routes >found in the encap. 44.24.221.0/24 isn't in the encap, so you should >source packets to it from your commercial ISP source IP. UCSD is not >involved. > >Tom KD7LXL -- Bryan Fields 727-409-1194 http://bryanfields.net

1 0

Gateways with external address in net-44
by Rob Janssen 12 Nov '14

12 Nov '14

When I was working on my gateway I noticed that stations use a 44-address as their external address. For some time there has been the gateway to 44.24.240/20 with gateway 44.24.221.1 This morning I noticed gateways with address 44.151.94.28 and 44.140.0.1 but they have been removed in the meantime. I want to notice that my gateway cannot route traffic to gateways like that, due to the policy routing used to separate internet traffic and tunnel traffic. And I think that many other gateways have a similar setup and have the same problem. Is there any official policy on the external gateway address? Is it allowed to be in net-44, and if not, wouldn't it be better to check this in the portal and reject submissions like this with a suitable error message? I suspect part of those entries are just the result of misunderstanding by a newcomer, and we help them getting things working by hinting at this incorrect configuration. Rob

1 0

Rip44d
by Peter Mallett 01 Nov '14

01 Nov '14

Hi All Agn, I wonder if there are any new thoughts on rip44d and Linux Lite ? Regards ..... Peter ZL2BAU

7 11

OpenVPN to reach whole 44-network...
by sp2lob 27 Oct '14

27 Oct '14

Hello Rob/PE1CHL et al. Rob, thank you very much for "pushing me" into right direction! Today I made interesting and promissing tests with OpenVPN. My question and goal was: "Whether and how one can allocate any-in-size subnet to particular VPN client?" Of course, from the address space being at disposal. Hardware setup: - AMPRNet gateway server, Debian-7.5 (LAN + WAN) utilizing 44.165.2.0/28 address space - OpenVPN server running on above mentioned gateway utilizing 44.165.15.0/24 address space - Desktop PC - Debian-7.5 (on LAN, behind router) - VirtualBox machines: Debian-7.5 Fedora-20 OpenBSD-5.5 (running on Desktop PC) - Sony Xperia Z1 running OpenVPN client OpenVPN addresses allocation: - OpenVPN server - 44.165.15.0/24 - Desktop PC - 44.165.15.16/28 - VirtualBox Debian-7.5 - 44.165.15.32/29 - VirtualBox Fedora-20 - 44.165.15.40 - VirtualBox OpenBSD-5.5 - 44.165.15.253 - Sony Xperia Z1 - 44.165.15.2 Commands giving such nice possibility (example for Desktop PC): - in the OpenVPN server config file topology subnet route 44.165.15.16 255.255.255.240 44.165.15.30 - in the OpenVPN client config file (on server!!!) ifconfig-push 44.165.15.17 255.255.255.0 iroute 44.165.15.16 255.255.255.240 Already allocated subnets may appear and will be reachable EXCLUSIVELY on previously assigned machines. All other addresses may emerge anywhere. Finally very brief answer is: YES, it is possible to assign subnet to a particular VPN client! For more detailed descriptions please refer to OpenVPN manual. Best regards. Tom - sp2lob

3 2

RIP44d
by Andy Brittain 25 Oct '14

25 Oct '14

Hi folks Anyone running rip44d with ubuntu server 14.04 ? I have been for a while but after a recent update its now causing the server to hang on reboots :-( Running kernel 3.13.0-37 I can get in to the server using recovery mode and disable the loading and all is OK so I know its a compatibility issue. Andy G0HXT

10 16

Test only...
by SP2L 23 Oct '14

23 Oct '14

Test only. Disregard please. Tom – SP2L (ex sp2lob)

1 0

CSF and debian 7.7
by Jerry Kutche 23 Oct '14

23 Oct '14

Hello, Anyone here using CSF (ConfigServerFirewall) with net44... I seem to have an issue .. Seems Chinese hackers are obliterating my URONODE/JNOS Box... and I cannot even run it long enough to do a tcpdump without losing all network activity... I have my config and allow and ignore files if anyone has an idea Id send them off list for review.. What I see when I start it CSF does great job of stopping the hackers.. and shortly thereafter it also stops net44.. I have in both allow and ignore files... 192.0.0.0/8 44.0.0.0/8 127.0.0.1 And I have ignore allow set to 1 in the config.. I see what I run csf -l A line where its is deny tun0 !44.0.0.0/8 Even though just up from there is a listing of Source and destinations where its allowed.. I think the lfd function of csf is the reason.. But from what I read in the docs if I allow and ignore an ip or /8 it should allow via csf and lfd should ignore it. Not sure what I am doing wrong.. But this has my system offline till figured out. If I turn on the CSF FW it shuts me out of the 44net altogether.. If I turn it off same results due to hackers. Plus I am off the internet as well. Many thanks 73 jerry N9LYA ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5557 / Virus Database: 4181/8439 - Release Date: 10/23/14

1 1

Debian 7.6
by Peter Mallett 23 Oct '14

23 Oct '14

Hi, Does anyone know the answer to no pty legacy ports in 7.6 ? I tried to enable it in the grub,cfg file - pty.legacy_count=32 but it no longer works ? Regards ..... Peter ZL2BAU

3 4

An introduction to high-speed ham networks
by Bryan Fields 23 Oct '14

23 Oct '14

I'm doing a presentation to the local ham radio club here in St Pete, FL and have put this together. http://keekles.org/~bryan/Ham%20radio%20networking.pptx It may be of interest to the group, feel free to use it or take from it for you own needs. any feedback would be great too. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

3 2

Re: [44net] 44Net Digest, Vol 3, Issue 171
by Ernest.Tse＠Pacswitch (HK) 22 Oct '14

22 Oct '14

An embedded and charset-unspecified text was scrubbed... Name: not available URL: <http://hamradio.ucsd.edu/mailman/private/44net/attachments/20141023/0c23601…>

1 0

VE3MCH
by Brian 21 Oct '14

21 Oct '14

Bob; Can you email me off-list please using a 44-net mailbox? -- If Microsoft intended Windows to be for ham usage, they would have incorporated our protocols into their kernel. 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

1 0

Re: [44net] An introduction to high-speed ham networks
by Bryan Fields 21 Oct '14

21 Oct '14

On 10/20/14, 10:11 PM, Bill Vodall wrote: > The ultimate application is ... Facebook. Really! idk, as a 30 yr old single male, I have some great things to say about pof and tinder. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

3 2

seeking vps host for use as 44net hub
by Eric Fort 20 Oct '14

20 Oct '14

I'm presently looking for a virtual private server host to setup as a hub for my 44net address block. it has been mentioned when I tried this in the past that some virtualization technologies work better than others when it comes to setting up a linux virtual machine with the tunnel mesh (then subneting the netblock and routing it over various vpn links). i.e. xen hvm vs xen pvm vs kvm vs vmware.... Also does anyone know a vps provider that might bgp announce a /24 block and properly feed it to a vps on their network? Thanks, Eric AF6EP

3 3

Raspberry pi VPN
by amprnet＠wizards.sytes.net 20 Oct '14

20 Oct '14

Hi All, After a long wait I finally have my 44 address space and my security certificate. Following the steps on the wiki I have set up the raspberry pi as a vpn client and during boot I see the VPN client start. However just a couple of questions. Do I need to open and redirect a port on my router pointing to the raspberry pi running the vpn and if so which port? Once I have done that, what is the recommended method (software) that should be installed to protect the network both to and from me? Before I add any other software is there a way to test the functionality of what I have done so far? at the moment all it appears to be doing is sitting there and blinking the wireless access LED Equipment is a raspberry B+ running off a UPS with wireless access to my network. Thanks in anticipation, Regards Tony VK3API

2 1

Shellshock
by sp2lob 16 Oct '14

16 Oct '14

Greetings to everybody. Remember Heartbleed? Now there's something new: http://www.wired.com/2014/09/hackers-already-using-shellshock-bug-create-bo… Noticed several times in log files of my server! Best regards. Tom - sp2lob

6 8

Pirate Packet Radio Node CB0AFU
by Jann Traschewski 14 Oct '14

14 Oct '14

Hi, for those of you running a Packet Radio Link to CB0AFU: It seems it is *not* located in Chile but running a gateway to CB-Radio (through two links to Nodes in CB-Nodes in Austria). Can you please check in advance before running those links? DG8NGN de CB0AFU (H=Help - 09:15) ->ro Routes of AFUGAT:CB0AFU (12/32) Node------SSID--Typ-Po--Dst/Rou---L3SRTT[ms] KS0NOD 0 I 0 91/67 2/2 VE3UIL-7 7 N- 0 0/0 Qual:192 AE5E-14 14 N- 0 0/0 Qual:192 CT1ENI-8 8 N- 0 1/1 Qual:192 G4MKI-8 8 N- 0 1/1 Qual:192 K9DRH-7 7 N- 0 1/1 Qual:192 IR2UFV-1 1 N- 0 1/1 Qual:192 N9PMO-2 2 N- 0 0/0 Qual:192 N9LYA-7 7 N- 0 0/0 Qual:192 AT2SN 0 I 0 57/31 2/5 GB7COW-3 3 N- 0 0/0 Qual:192 IV3ONZ-2 2 N- 0 1/1 Qual:192 Thank you! 73, Jann -- Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn

5 6

Re: [44net] Pirate Packet Radio Node CB0AFU
by Rob Janssen 13 Oct '14

13 Oct '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] Pirate Packet Radio Node CB0AFU > From: > Jann Traschewski <jann(a)gmx.de> > Date: > 10/10/2014 09:22 AM > > To: > 44net(a)hamradio.ucsd.edu > > > Hi, > > for those of you running a Packet Radio Link to CB0AFU: It seems it is > *not* located in Chile but running a gateway to CB-Radio (through two > links to Nodes in CB-Nodes in Austria). Also watch out when stations use an NL prefix, the CB stations in the Netherlands commonly use(d) that, so be careful to check if they are really from Alaska. Rob

8 13

Re: [44net] Odd DNS Issue
by lleachii.aol.com 12 Oct '14

12 Oct '14

The issue is only on my DNS server. I have a zone transfer from 44.in-addr.arpa and ampr.org, so a copy of the zones are located on my BIND server at 44.60.44.3 I've been using nslookup to look at the records from multiple machines. It only occurs on certain IPs where the fourth octet is less than 10. I'll try dig as well. - KB3VWG

2 1

Re: [44net] Odd DNS Issue
by Rob Janssen 11 Oct '14

11 Oct '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] Odd DNS Issue > From: > lleachii(a)aol.com > Date: > 10/10/2014 11:28 PM > > To: > 44net(a)hamradio.ucsd.edu > > > All, > > I'm wondering if anyone else has seen this issue. I'm running BIND version 9.9.5 at 44.60.44.3. I just recently upgraded from 9.8 because I thought it would solve a very weird issue that I'm experiencing. > > I allow all to to lookup 44.in-addr.arpa and ampr.org; and it works. BUT, some reverse records always time out. I have seen this many times and never have been able to solve it. Some ampr.org DNS servers time out on some PTR records. It comes and goes, can be OK for months and then come back. When you focus on it to debug the issue it often disappears under your hands. No idea what it is. Rob

1 0

Re: [44net] Pirate Packet Radio
by Bryan Fields 11 Oct '14

11 Oct '14

On 10/11/14, 10:31 AM, Brian wrote: > Andy et al; On Sat, 2014-10-11 at 13:18 +0100, Andy Brittain wrote: >>> I think opening up 44 net is potentially a good idea but then we run in >>> to trouble where RF is involved. Would we not be passing traffic that >>> technically doesn’t fit under our license t’s&c’s? > Absolutely. That would easier open us up to pirating (why bother get a > license if it's freely available?) and put us in jeopardy for possible > violation of 3rd party communications regulations depending what the 3rd > party does. 1. There is no guarantee that 44/8 traffic is sourced from licensed radio amateurs. 2. There is no guarantee that 44/8 traffic is suitable for use over licensed amateur radio frequencies in $REGULATORY_DOMAIN. The only thing there is guaranteed about 44/8 is that is must be used for bona fide amateur radio purposes. What these purposes are, is loosely defined and open to interpretation. Guys, it's just IP space. The sooner we separate networking from IP space, the better IMO. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Odd DNS Issue
by lleachii＠aol.com 11 Oct '14

11 Oct '14

All, I'm wondering if anyone else has seen this issue. I'm running BIND version 9.9.5 at 44.60.44.3. I just recently upgraded from 9.8 because I thought it would solve a very weird issue that I'm experiencing. I allow all to to lookup 44.in-addr.arpa and ampr.org; and it works. BUT, some reverse records always time out. So far, I have tested the following IP addresses which have PTR records, but do not produce results: 44.102.1.1 44.102.1.2 44.108.1.1 44.108.1.2 44.108.1.3 44.60.44.1 44.60.44.2 44.60.44.3 44.60.44.6 44.60.44.7 The only pattern that I've discovered when a lookup times out, is that the fourth octet is always less than 10. I've checked the system log, and there is no denial for the DSN query. I was wondering if anyone had ideas/suggestions. Thanks and 73, Lynwood KB3VWG

3 2

Re: [44net] Call for : Extended Frequency Support
by Steve L 09 Oct '14

09 Oct '14

Well I know this obviously, but we did get a 180 degree sector up on a broadcast tower, so I have a bunch of newbies to microwave and networking in general to deal with. The consensus is to probably use the BBHN firmware as that is what the Emcomm and not so tech guys will have a liking to. So overall I don't think adding that kind of support to a ham rolled firmware is a bad idea if someone out there had the urge to try and figure it out. A few years back Ubiquiti AirOS supported those frequencies natively. So one wonders if one day even Mikrotik might have those features removed. Speaking of BBHN is there any kind of video showing the more nuts and bolts of it working for those of us who (or want to) understand things a bit deeper? A video that perhaps shows broadband hamnet speed test (FTP transfer to a localhost, etc) traceroutes to show hops when a node disappears or comes online broadband hamnet route command output when a node disappears Steve ---- Quote ----- If you want to get out of the part 15 jungle just use Mikrotik gear... It won't run HSMM mesh but that's not a bad thing if you don't want to pay the performance penalty of a mesh... Bill

1 0

Call for : Extended Frequency Support
by Steve L 09 Oct '14

09 Oct '14

Atheros Chipset Radios are capable of operation between 2312-2732, 4920-6100 MHz. The purpose of this message is to hopefully draw a few talented hams out of the wood work that can make a programming contribution to an the existing Broadband Ham Network firmware project. You can look at how the ham radio frequency allocations overlap the Part 15 bands here: http://www.qsl.net/kb9mwr/projects/wireless/allocations.html The Part 15 overlap where all consumer devices operate is heavily crowded, and thusly the noise floor is high hampering long range links that we as hams would like to establish. There are a couple third party solutions to enable the extended frequency support to be able to shift operations into the ham only portions of the bands. Neither of them presently have native OLSR support in addition to the extended frequency support. It would be highly desirable to see our own ham firmware support the extended frequency support. HSMM-Mesh / Broadband Hamnet Firmware In the Fall of 2008, a group of amateurs from the Texas area announced development of their own custom firmware for the WRT-54G to enable HSMM-Mesh networking. This is the first ham specific firmware build. It is also one of the first firmware builds to support OLSR, an ad-hoc wireless mesh routing daemon. Initially this ham firmware build was limited to the Linksys WRT54 series of wireless routers. In February 2014 the development team announced support for Ubiquiti 2.4 GHz devices. In July 2014 support was extended to Ubiquiti 5 GHz devices. I should clarify that this firmware does not yet support non-part 15 channels, aka, extended channels / custom frequencies. Nor does it yet support half-rate (10 MHz wide), or quarter-rate (5 MHz wide) bandwidth channels to accompany use on ham only spectrum. If you are knowledgeable with the Linux Kernel programming please consider reaching out to the development team. http://www.broadband-hamnet.org/download/firmware/ A discussion on the Broadband Hamnet / HSMM-Mesh ham firmware about using channels outside of the Part 15 space: http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-1113/t… If we can develop the firmware that enables ham channels, Heikki Hannikainen OH7LZB presented at the 2013 DCC a way to authenticate the person who might like to download it is a ham. http://www.youtube.com/watch?v=7anDmQQfyu8 Video presentation from the DCC http://authtest.aprs.fi - authentication demo site https://github.com/hessu/ham-cert-web-demo - Apache configuration and PHP scripts

2 1

DNS Strays
by Brian 07 Oct '14

07 Oct '14

Greetings; I have created a file at http://n1uro.ampr.org/amprdns.brk This file contains a ton of stray MX and CNAME records. If a coordinator wishes to sort through it and clean up invalid entries, it's there. -- 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

3 4

tmUnblock.cgi
by sp2lob 05 Oct '14

05 Oct '14

Greetings to everybody. Following Shellshock... There is another hole, called tmUnblock.cgi targetted on some Cisco Linksys routers: http://www.scip.ch/en/?vuldb.12362 More info on Internet, for instance: http://security.stackexchange.com/questions/68405/what-is-tmunblock-cgi-and… Even targeted at specific hardware, it is poking everywhere... Short extract from my apache2.log 50.193.84.18 - - [05/Oct/2014:14:03:33 +0200] "GET /tmUnblock.cgi HTTP/1.1" 400 518 "-" "-" Best regards. Tom - sp2lob

2 1

Re: [44net] Apache2 log - suspicious entries...
by sp2lob＠tlen 29 Sep '14

29 Sep '14

Hello Brian(N1URO) et al. My list of "abusing" subnets and single IP's contains 56 lines and still grows almost every day. All of them blocked continuously by iptables. For securing all amprnet interfaces I have one PERFECT cure: -A INPUT ! -s 44.0.0.0/8 -i tunl0 -j DROP -A INPUT ! -s 44.0.0.0/8 -i tun0 -j DROP -A INPUT ! -s 44.0.0.0/8 -i tun1 -j DROP -A INPUT ! -s 44.0.0.0/8 -i tun2 -j DROP -A INPUT ! -s 44.0.0.0/8 -i sl0 -j DROP -A INPUT ! -s 44.0.0.0/8 -i sl1 -j DROP -A INPUT ! -s 44.0.0.0/8 -i sl2 -j DROP Really deadly weapon, Hi! Nothing, literally nothing, what isn't originated from 44 network is explicitly DROPped. JNOS-2.0j4, TNOS-2.40, OpenVPN(44net), TNOS-3.01a1 and two (X)net's are as safe as never before. Sending email to the "abuse" mailbox is nice and pollite way but do not change situation right away. Just my personal point of view... One day somebody said: if I run taxi business, say in Texas, I do not want customer from LaLaLand poking around! Best regards. Tom - sp2lob Send from Sony Xperia Z1 http://www.aqua-mail.com

3 4

Re: [44net] Apache2 log - suspicious entries...
by William Lewis 29 Sep '14

29 Sep '14

Tom, I am also using Fail2BAN. I created my own jail for JNOS and it works great. That is also why I needed to change the JNOS log file name to something static. That way I could avoid having to reload/restart Fail2Ban every morning at midnight to look for a new log. If you need the Jail regex I created for JNOS (assuming you're using JNOS), contact me off-list (kg6baj(a)n1oes.org) and I can email it to you. Bill KG6BAJ At 09:13 AM 09/29/14, you wrote: >I do this with a program called fail2ban. You configure it to watch >log files for authentication failures or other suspicious activity. It >then blocks the suspicious source IP in iptables for the configured >period of time. When the time expires, the IP is unbanned, so false >positives or new users of an IP address aren't adversely affected. > >I get many bans per day and don't put much energy into monitoring or >reporting them. > >Tom KD7LXL >_________________________________________

1 0

Apache2 log - suspicious entries...
by sp2lob 29 Sep '14

29 Sep '14

Greetings to everybody. ****I want direct your attention to two networks that lately I'm seeing in my Apache2 log files: 5.141.0.0/16 213.33.130.0/24 Log entries are at least suspicious. I keep sharp lookout. Best regards. Tom - sp2lob

5 5

Re: [44net] Global Callbook Server
by K7VE - John 24 Sep '14

24 Sep '14

HamQTH's API is pretty easy to use and provides a decent international callbook. http://hamqth.com/developers.php I use it for validation and profile at http://hf.dstar-relay.net and http://qso.freedv.org If someone wanted to write a simple callsign lookup, it wouldn't be a big deal. ------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays>

1 0

Global Callbook Server
by Brian 24 Sep '14

24 Sep '14

Greetings; Is anyone running a global buckmaster or similar server on 44/8 that I can query from xNOS? It would be greatly appreciated. Thanks much. -- 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

4 7

Ripd transmissions from amprgw...
by sp2lob＠tlen 21 Sep '14

21 Sep '14

To whom it may concern. Quote: Niall Parker 2013/12/14 at 06:28 I suspect the intent (of Heikki et al) was to keep that password from being published… I suspect it would have helped me though if I hadn’t been paranoid to read all the docs anyway. Unqote Just wonder, whether this security measure is still in force and should be obeyed without any exempts? Best regards. Tom - sp2lob Sent from Sony Xperia Z1 http://www.aqua-mail.com

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 140
by f5pbg＠free.fr 21 Sep '14

21 Sep '14

Hello, I am back... The final settings for me are here : http://radioamateur.forumsactifs.com/t1725-gateway-hamnet-echolink-installa… (use google translate if necessary) Best regards, Ludovic Vuillermet - F5PBG http://inforadio.free.fr

2 1

Duplicate encap entry
by Tom Hayward 21 Sep '14

21 Sep '14

I noticed that around 2014-09-20 06:00 UTC, the line: route addprivate 44.136/21 encap 124.171.137.31 started appearing twice in the encap file. Before this, all entries in the encap file were unique. Did something change about how the encap file is generated? Is this line intentionally included twice? If so, what value does the second entry serve? Tom KD7LXL

2 1

Dormant account warning
by Michael E Fox - N6MEF 20 Sep '14

20 Sep '14

I just got the following. One month is way, WAY too short. If my records needed updating every month, it would be a mess and I'd rather just shut down. Perhaps once a year is a good requirement, just to verify that we're all still alive. But if things are stable, forcing a login every month is just too much. Michael N6MEF Hello Michael, THIS IS A SYSTEM GENERATED EMAIL FROM THE AMPRNET PORTAL. Your account on the AMPRNet portal has been dormant for over one month. It is important that you login regularly to ensure that your personal details are up to date, as well as ensuring that any AMPRNet resources allocated to you are correct, e.g. IP allocations, DNS entries, etc. Please login to the AMPRNet portal soon: https://portal.ampr.org If you have any questions relating to this email, you may reply to it and a human being will read it and respond. Kind Regards, Marvin, The AMPRNet Robot

11 11

Re: [44net] Thread changes
by Bryan Fields 20 Sep '14

20 Sep '14

On 9/18/14, 5:42 PM, Marc, LX1DUC wrote: > Changing the Subject line of a digest email isn't enough for "modern" > email clients (probably post 2005 email clients) which use the > "References" header to organize messages into threads. > > I consider digest mode a nice mode for those that want to stay > informed but it is a bad choice for those who want to participate. Digest replies really need to go away, as no one can truly reply to a single message in it. It breaks threading. Changing the subject does not fix this as threading is done on the references header, it has nothing to do with the subject. I consider the 44net list to be people that "get" how email and networking works, and even here see so many replies that break threading due to using broken MUA's and generally not taking 30 seconds to ensure the email is correctly formatted. I'm on a number of other ham lists, and most are good, there is a certain subset who are willfully ignorant of proper grammar, spelling, formatting, top-posting, proper replies, etc. The ones on yahoo groups tend to be the worst for this (ex. Repeater-Builder). Some of the best how-to on posting to a list is from #10 on the qmail list guide. http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html#step10 Some of this is of course not applicable to a general list, but most is. I've considered writing up a Ham list specific how-to, but I doubt it would change anything. I think it's why I'm checked in here engaging in some good passionate discussion from time to time, and then take a couple weeks off not replying at all. :) 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] Dormant account warning
by Bryan Fields 19 Sep '14

19 Sep '14

On 9/19/14, 4:59 PM, K7VE - John wrote: > Once a year or 6 months (if we are clearing out inactive accounts) How about if it's in the global routing table I shouldn't need to verify it? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

4 3

ATTN KD2CXZ
by Mark Phillips 19 Sep '14

19 Sep '14

Gavin, I just today saw your application for IP space in the portal. Whilst I am the regional co-ordinater for NJ your request did not reach me. Would you please contact me off-list. We can work out a subnet for you. Mean time, please read this document http://mrprosser.g7ltt.com/docs/New%20Jersey%20ampr.org%20addressing%20sche… Thanks Mark

1 0

Re: [44net] Thread changes
by Rob Janssen 19 Sep '14

19 Sep '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] Thread changes > From: > "Marc, LX1DUC" <lx1duc(a)laru.lu> > Date: > 09/18/2014 11:42 PM > > To: > 44net(a)hamradio.ucsd.edu > > I consider digest mode a nice mode for those that want to stay > informed but it is a bad choice for those who want to participate. > > 73 de Marc > I switched to digest mode when there was the umpteenth discussion about how everything we do is bad and everything needs to be overhauled, with >30 messages per day. I really cannot have these come in my mailbox one by one. It would be better when we used a newsgroup (possibly on a closed server) where you can, with a suitable reader, just kill an entire thread and future replies to it. For now, digest mode it is. Rob

2 1

Re: [44net] Thread changes
by Rob Janssen 18 Sep '14

18 Sep '14

> Subject: > Re: [44net] Thread changes > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 09/12/2014 04:37 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > It's when people reply to the digest and don't remember to edit > the subject line. > - Brian I try to remember to copy the subject back to the subject field but sometimes I forget. Actually it is a bug in the mail program, as everything is available in the digest to reply to individual messages. Rob

2 1

Re: [44net] DD-wrt om wrt54gl and 44net
by lleachii＠aol.com 18 Sep '14

18 Sep '14

Luc VE3JGL, You can configure DD-WRT to pass 44net traffic through the device. I'm not certain that the WRT54GL has enough capacity to install the gateway routing daemon and VPN server: **Command for Static Public IP (tested on DD-WRT and OpenWRT): iptables -t nat -I PREROUTING -p ipencap -d <GW Public IP> -j DNAT --to-destination <GW LAN IP> iptables -t filter -I FORWARD -p ipencap -d <GW LAN IP> -j ACCEPT **Command for Dynamic Public IP - (WAN is vlan1 in DD-WRT in OpenWRT it is usually eth0.1): iptables -t nat -I PREROUTING -p ipencap -i vlan1 -j DNAT --to-destination <GW LAN IP> iptables -t filter -I FORWARD -p ipencap -d <GW LAN IP> -j ACCEPT 73, KB3VWG Hi, is there a web page for setting up a WRT54GL with DD-WRT as a 44net gateway and VPN server

1 0

DD-wrt om wrt54gl and 44net
by Luc Pernot 17 Sep '14

17 Sep '14

Hi, is there a web page for setting up a WRT54GL with DD-WRT as a 44net gateway and VPN server Luc VE3JGL

1 0

New Tapr
by Brian 14 Sep '14

14 Sep '14

For those who are curious or run URONode, TAPR was kind enough to make an email list on their mailman server. You can find it at: http://www.tapr.org/mailman/listinfo/uronode Thanks to WA1LOU and the TAPR BOD. -- 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

1 0

Portal PHP coders wanted
by Chris 13 Sep '14

13 Sep '14

Would anyone with HTML / PHP / MySQL experience like to collaborate with continuing the development of the portal code? Anyone interested, please email me and I will arrange access to the repository. You will need to be familiar with Subversion and how to checkout a local copy of the project, do updates and commits. Thanks, Chris

5 4

SJVBBS
by Ray Quinn 13 Sep '14

13 Sep '14

The SJVBBS (W6RAY) will be reinstalled at Park Ridge today, Saturday 13 September, 2014. It will have a new public IP address, which has been updated on the portal. For those of you who exchanges traffic to the system will need to use the new ip address once installed. The AMPRnet address will remain the same. OLD: 71.130.72.52 NEW: 104.49.13.173 This new Internet feed is strictly for amateur radio and the Tulare County Amateur Club (WA6BAI). 73 de Ray W6RAY Visalia, CA DM06ih

1 0

Thread changes
by Brian 12 Sep '14

12 Sep '14

Can anyone answer why threads keep getting relabled? I don't recall a thread starting with: 44Net Digest, Vol 3, Issue 146 It makes it very difficult to follow a thread, and in a sense kills the flow of the topic. Thanks. -- 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

4 4

Re: [44net] 44Net Digest, Vol 3, Issue 146
by Rob Janssen 12 Sep '14

12 Sep '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] 44Net Digest, Vol 3, Issue 145 > From: > sp2lob <sp2lob(a)tlen.pl> > Date: > 09/10/2014 10:02 PM > > To: > 44net(a)hamradio.ucsd.edu > > > Rob at al. > > I am reaching this site: > ftp://n1uro.ampr.org/packet/xfbb/fbbquit.patch > without any problems, via browser or ftp client. > > Best regards. > Tom - sp2lob It still does not work from here. Strange... I can ping the public address that claims to be the gateway for network 44.88.0.0/24 but no reply from 44.88.0.9 (tried from 44.137.40.2) Brian, do you see occasional incoming SMTP connects? There is a mail queued to your address but it does not get delivered. Can you ping 44.137.40.2 or 89.18.172.156? Rob

2 1

Portal translators wanted !
by Chris 12 Sep '14

12 Sep '14

Tom, SP2LOB has very kindly been working with me to translate the portal into Polish, so we now have English and Polish to choose from. It would be nice to have a few more languages, e.g. French? German? Does anyone who has English plus at least one other language have the time to help with translations please? It will be an ongoing job, initially there will be quite a lot of work to translate every page, afterwards it will just be a case of keeping it up to date as the English version is update occasionally. So there is a commitment involved, not just a one off translation. You will need a basic understanding of HTML but nothing too technical, no PHP coding experience is required as the portal uses a simple template system, so there are HTML template pages to translate, a text file with error messages and a handful of text files for emails sent by the system. The portal is now under a Subversion repository, so you will also need to be familiar with how to checkout a project, make your modifications then commit the changes back to the repository. If anyone is interested, please email me: chris(a)g1fef.co.uk Thanks, Chris

1 0

Re: [44net] 33rd DCC 2014 Proceedings Papers online
by kb9mwr＠gmail.com 11 Sep '14

11 Sep '14

Thanks for the paper and your work Jann also. At last years DCC I believe, OH7LZB shared a concept for authenticating: http://sigspace.wordpress.com/2013/09/21/tapr-dcc-authenticating-amateur-ra… http://www.youtube.com/watch?v=7anDmQQfyu8 http://authtest.aprs.fi https://github.com/hessu/ham-cert-web-demo KB9MWR WAPR TCP/IP Page: http://www.qsl.net/kb9mwr/wapr/tcpip/ Jeroen Massar wrote: >Thanks for the preso and more importantly the work done on Hamnet! > >Are there more details about the "Authentication platform"? I might have >some input on that based on a variety of projects... ;) > >Greets, > Jeroen

1 0

33rd DCC 2014 Proceedings Papers online
by Jann Traschewski 11 Sep '14

11 Sep '14

Hi, you can find the proceedings papers from the 33rd DCC 2014 in Austin, TX, now here: http://www.tapr.org/pub_dcc33.html I've been giving a talk about the HAMNET: http://www.tapr.org/pdf/DCC2014-TheEuropeanHAMNET-DG8NGN.pdf 73, Jann DG8NGN -- Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn

2 2

Re: [44net] 44Net Digest, Vol 3, Issue 145
by Rob Janssen 10 Sep '14

10 Sep '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] LinFBB patch > From: > Brian <n1uro(a)n1uro.ampr.org> > Date: > 09/10/2014 02:05 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > For those who run LinFBB 7.05f on the amprnet, I have a patch for it > that I released last night. All it does is adds a (Q)uit command which > parallels the existing (B)ye command. Considering with FlexNet and Xnet, > and other softwares leaning more towards Quit than Bye for an "exit > application" command, this patch will make FBB more user friendly. In the old days, everyone had an FBB BBS (or maybe RLI or 4RE) and used B for Bye, except the Germans who had "DIEBOX" where B meant "Bell (alert the sysop)"! Always fun. > > You may find it at: > ftp://n1uro.ampr.org/packet/xfbb/fbbquit.patch > > if interested. The system is not reachable from here (44.137) Rob

2 1

N1URO
by Luc Pernot 10 Sep '14

10 Sep '14

The system is not reachable from here (44.135.96.65) Luc VE3JGL

1 0

Gateway : How create one ??
by f5pbg＠free.fr 10 Sep '14

10 Sep '14

Hello, i am coord offrench network 44.151. I want to make gateways : For example, i want ping 44.151.29.1 and i would like to have an answer from my localIP 78.241.81.29. What is the command to the server. I knows these command f5pbg add a 78.241.xxx.xxx etc... but i don't know the command to make gateways... Thank's a lot for the answer. All the best Ludovic - F5PBG.

3 6

LinFBB patch
by Brian 09 Sep '14

09 Sep '14

For those who run LinFBB 7.05f on the amprnet, I have a patch for it that I released last night. All it does is adds a (Q)uit command which parallels the existing (B)ye command. Considering with FlexNet and Xnet, and other softwares leaning more towards Quit than Bye for an "exit application" command, this patch will make FBB more user friendly. You may find it at: ftp://n1uro.ampr.org/packet/xfbb/fbbquit.patch if interested. -- 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

1 0

Mesh support?
by Kris Kirby 07 Sep '14

07 Sep '14

Are we anywhere close to being able to support an RF-based mesh network? Or is it just simplest to have backhaul to a single tunnel device? I'm thinking the RF network side would be using OSLR or some other routing protocol, providing it with the information it needs, but for the tunnel announcing a single IP makes the most sense. Otherwise, the large network would show up with multiple diverse routes, but may in reality be partitioned. -- Kris Kirby, KE4AHR Disinformation Architect

3 3

Re: [44net] 44Net Digest, Vol 3, Issue 142
by Ernest.Tse＠Pacswitch (HK) 06 Sep '14

06 Sep '14

An embedded and charset-unspecified text was scrubbed... Name: not available URL: <http://hamradio.ucsd.edu/mailman/private/44net/attachments/20140907/02aeece…>

1 0

Portal bug - Please select your country
by Chris 06 Sep '14

06 Sep '14

To anyone that reported the “Please select your country” bug when editing an IP request allocation. This has now been fixed. Please let me know if anyone finds anymore bugs. Thanks, Chris

1 0

Re: [44net] ve2pkt, n1uro
by kb9mwr＠gmail.com 03 Sep '14

03 Sep '14

Both work for me from my 44.92.21.X subnet. Last login: Wed Sep 3 12:46:55 2014 root@ampr-gw:~# ping 44.135.49.2 PING 44.135.49.2 (44.135.49.2) 56(84) bytes of data. 64 bytes from 44.135.49.2: icmp_req=1 ttl=63 time=100 ms 64 bytes from 44.135.49.2: icmp_req=2 ttl=63 time=100 ms ^C --- 44.135.49.2 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 100.335/100.639/100.944/0.439 ms root@ampr-gw:~# ping 44.135.52.33 PING 44.135.52.33 (44.135.52.33) 56(84) bytes of data. 64 bytes from 44.135.52.33: icmp_req=1 ttl=30 time=51.1 ms 64 bytes from 44.135.52.33: icmp_req=2 ttl=30 time=54.3 ms ^C --- 44.135.52.33 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 51.161/52.745/54.329/1.584 ms root@ampr-gw:~#

1 0

ve2pkt, n1uro
by Michel Beaudry 03 Sep '14

03 Sep '14

Jean ve2pkt asked me to setup a axip link between our gateways. ve2pkt 44.135.49.2 and ve2uqh 44.135.52.33 When trying to ping ve2pkt I get no response, a few hours later it works fine. The next day again no response. Same results from n1uro. Route to ve2pkt is via n1uro. I can ping other gateways fine. Could this be a firewall problem ? I run jnos2.0j on Debian wheezy with rip44d. thanks, Michel ve2bcw sysop ve2uqh.ampr.org Gatineau/Ottawa

2 1

Portal..
by gm4upx＠gb7jd.co.uk 02 Sep '14

02 Sep '14

Why does clicking on the [ Co-ordinator s ] tab still return me to the [ home ] page ?? Cheers, Ian..

2 1

SP2LOB
by Brian 01 Sep '14

01 Sep '14

Please contact me offlist :) -- 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

2 2

Gateway
by f5pbg＠free.fr 01 Sep '14

01 Sep '14

Hello, i am coord offrench network 44.151. I want to make gateways : For example, i want ping 44.151.29.1 and i would like to have an answer from my localIP 78.241.81.29. What is the command to the server. I knows these command f5pbg add a 78.241.xxx.xxx etc... but i don't know the command to make gateways... Thank's a lot for the answer. All the best Ludovic - F5PBG.

3 2

Re: [44net] 44Net Digest, Vol 3, Issue 137
by Rob Janssen 28 Aug '14

28 Aug '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] 44Net Digest, Vol 3, Issue 136 > From: > Libor Berka <ok2pen(a)seznam.cz> > Date: > 08/27/2014 10:24 PM > > To: > 44net(a)hamradio.ucsd.edu > > > Re wrong server IP, Brian sorry but that was my writing msg error, the IP in my > ampr-run start script is correct 169.228.66.251 > There must be some other problem. > Libor Libor, You should not need the address of the ampr gateway in your script, so that is probably where the error is. The RIP packets are sent by 44.0.0.1, that is what you should allow to pass your firewall. Don't be misled by RIP packets sent by 169.228.66.251, they have source and destination port numbers reversed and will not be processed by the ampr-ripd. I think they would better be removed because they add confusion. Rob

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 136
by Libor Berka 27 Aug '14

27 Aug '14

Re wrong server IP, Brian sorry but that was my writing msg error, the IP in my ampr-run start script is correct 169.228.66.251 There must be some other problem. Libor On 08/27/2014 04:00 PM, 44net-request(a)hamradio.ucsd.edu wrote: > Send 44Net mailing list submissions to > 44net(a)hamradio.ucsd.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://hamradio.ucsd.edu/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)hamradio.ucsd.edu > > You can reach the person managing the list at > 44net-owner(a)hamradio.ucsd.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > > > Today's Topics: > > 1. Getting no response from 251.66.228.169 (Libor Berka) > 2. Re: Getting no response from 251.66.228.169 (Brian Kantor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 27 Aug 2014 11:52:23 -0300 > From: Libor Berka <ok2pen(a)seznam.cz> > To: 44net(a)hamradio.ucsd.edu > Subject: [44net] Getting no response from 251.66.228.169 > Message-ID: <53FDF0A7.50501(a)seznam.cz> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello i am sysop of OK2KOJ-5 gateway in Brno, Czech Rep. The gateway has known amprIP 44.177.10.253 and > public IP 176.74.143.164 hostname ok2koj.ddns.net. > I registered this gateway here for the encap table. I have run on OK2KOJ the ampr-rip program with proper tunl0 interface > but there is no response packets from amprnet server 251.66.228.169 (port 520 is open). I use appropriate text > password which I put in text into registration of that gateway. The problem is that I don't know how to get > coded string of that text password. So I think that is the problem why I do not get response from amprnet server. > How can I get that text password in coded form? > Thank you for help > Dalibor > P.S. I am laso sysop of OK2PEN-5 gateway (44.77.10.10) where I get successfull response from amprnet gateway. > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 27 Aug 2014 08:14:05 -0700 > From: Brian Kantor <Brian(a)UCSD.Edu> > To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > Subject: Re: [44net] Getting no response from 251.66.228.169 > Message-ID: <20140827151405.GA2825(a)UCSD.Edu> > Content-Type: text/plain; charset=us-ascii > > This may be caused by an incorrect address; you mention 251.66.228.169 > but the correct address is 169.228.66.251. > - Brian > > > On Wed, Aug 27, 2014 at 11:52:23AM -0300, Libor Berka wrote: >> (Please trim inclusions from previous messages) >> _______________________________________________ >> Hello i am sysop of OK2KOJ-5 gateway in Brno, Czech Rep. The gateway has known amprIP 44.177.10.253 and >> public IP 176.74.143.164 hostname ok2koj.ddns.net. >> I registered this gateway here for the encap table. I have run on OK2KOJ the ampr-rip program with proper tunl0 interface >> but there is no response packets from amprnet server 251.66.228.169 (port 520 is open). I use appropriate text >> password which I put in text into registration of that gateway. The problem is that I don't know how to get >> coded string of that text password. So I think that is the problem why I do not get response from amprnet server. >> How can I get that text password in coded form? >> Thank you for help >> Dalibor >> P.S. I am laso sysop of OK2PEN-5 gateway (44.77.10.10) where I get successfull response from amprnet gateway. >> >> >> >> _________________________________________ >> 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 > > > End of 44Net Digest, Vol 3, Issue 136 > ************************************* >

1 0

Getting no response from 251.66.228.169
by Libor Berka 27 Aug '14

27 Aug '14

Hello i am sysop of OK2KOJ-5 gateway in Brno, Czech Rep. The gateway has known amprIP 44.177.10.253 and public IP 176.74.143.164 hostname ok2koj.ddns.net. I registered this gateway here for the encap table. I have run on OK2KOJ the ampr-rip program with proper tunl0 interface but there is no response packets from amprnet server 251.66.228.169 (port 520 is open). I use appropriate text password which I put in text into registration of that gateway. The problem is that I don't know how to get coded string of that text password. So I think that is the problem why I do not get response from amprnet server. How can I get that text password in coded form? Thank you for help Dalibor P.S. I am laso sysop of OK2PEN-5 gateway (44.77.10.10) where I get successfull response from amprnet gateway.

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net