- 44net - mailman.ardc.net

44 net connectivity problems ?
by R P 15 Jun '17

15 Jun '17

Has anyone else see connectivity problems of the 44 net ? My tunnel work but no connection to the internet Regards Ronen - 4Z4ZQ

10 24

Re: [44net] AMPR.Org DNS
by Rob Janssen 14 Jun '17

14 Jun '17

I get no reply on an update mail to the ampraddr robot, but the changes did get processed... Rob

2 1

Re: [44net] AMPR.Org DNS
by Rob Janssen 14 Jun '17

14 Jun '17

> I get no reply on an update mail to the ampraddr robot, but the changes did get processed... Ah, now I got the reply... too impatient, it got delayed by a greylister probably because the sender address changed. Rob

1 0

Re: [44net] AMPR.Org DNS
by Rob Janssen 14 Jun '17

14 Jun '17

> I don't plan to change the format of the new zone files; they are what is > being loaded into the nameserver. Please accept my apologies for the > difficulty. Ok no problem, I make the small changes required to ignore case and that TTL value when comparing the zone file to what comes out of my hosts->zone converter. Rob

1 0

Re: [44net] AMPR.Org DNS
by Rob Janssen 14 Jun '17

14 Jun '17

> I've switched the AMPR.Org and 44.in-addr master nameserver over to > using a new database and maintenance software. All seems to > be working correctly. > If you encounter any problems looking up a hostname or IP address > in the relevant ranges, please let me know. There is a change in the content of the downloadable zone file ampr.org.gz This causes problems in my scripts. I can modify the scripts, but first let's see if you can make them like before so similar issues for others could be avoided... Rob

2 1

missing encap.txt
by Michael Fox - N6MEF 14 Jun '17

14 Jun '17

The encap.txt file is missing from the portal. The last "encap.txt-<date>" is encap.txt-20170714073337 Starting after that, there are some "new_encap_<date>" files. But no "encap.txt". Michael N6MEF

3 2

Re: [44net] DNS Cleanup
by Rob Janssen 13 Jun '17

13 Jun '17

> Ok, they're gone too. What about > pe5hwg IN A 62.108.10.22 > which appears to be an anomoly, being outside net 44. Hmm that is a strange one! I don't think I added that, and pe5hwg is not a valid callsign. The IP address is in the Netherlands, though. Maybe you can still trace who submitted that? Rob

2 1

Re: [44net] DNS Cleanup
by Rob Janssen 13 Jun '17

13 Jun '17

> There were 23 44.137 addresses on the list of potential deletions. > They have been removed from the list. Thanks! There are 13 CNAME records as well: pd1aay IN CNAME pe1sac pe2ro IN CNAME pa7o links.pi1ehv IN CNAME pi1ehv pi8brd IN CNAME pi1brd www.pi8cdr IN CNAME pi8cdr smtp.pi8cdr IN CNAME lx.pi8cdr pop.pi8cdr IN CNAME lx.pi8cdr ns.pi8cdr IN CNAME lx.pi8cdr news.pi8cdr IN CNAME lx.pi8cdr ftp.pi8cdr IN CNAME pi8cdr pi8dec IN CNAME pi1dec pi8rmd IN CNAME pi1rmd sys2.pi8shb IN CNAME sys2.pi1shb Rob

2 1

Re: [44net] DNS Cleanup
by Rob Janssen 13 Jun '17

13 Jun '17

> Returning to the perennial subject of cleaning up the AMPR.Org DNS > database, Neil Johnson has done a thorough job of investigating the > entries in the current database. He has generated a file available from > the gw.ampr.org anonymous FTP server "Hosts-TBD.txt" which lists 2,045 > callsign-based entries in the DB where > 0. They're in the current AMPR.Org DNS. > 1. They're not found in active entries on QRZ.com. > 2. They're not found in the online Callbook database. > 3. They're not in the portal. > 4. They're not in HamNet.de. > 5. They were NOT entered into the AMPR.Org DNS after 2011. > 6. Or they are listed as expired in QRZ. All hosts in the 44.137.0.0/16 network are validated against the license authorities' callsign list on a weekly basis and expired licenses are deleted. Entries have been re-confirmed in 2014 and 2016 by sending a mailing and news bulletin and keeping only those entries for which a mail reply was received or that were otherwise confirmed as still active. About 1/3 of the hosts were deleted in 2016. Please don't delete further hosts from 44.137.0.0/16 (hostnames p[a-i][0-9][a-z]* ) Rob

2 1

Which FTP server to use for encap.txt?
by Michael Fox - N6MEF 13 Jun '17

13 Jun '17

I've been downloading the encaps.txt file from portal.ampr.org. Mostly, that's been OK except for the recent outage and some hick-ups in the data a year or so ago. Now the file is also on gw.ampr.org (if I understand correctly) in a slightly different format (<sigh>). The question is: which is the better source to use, considering likely uptime (network reliability, UPS, etc.) and reliability of data (fewest transforms from original data, etc.)? Thanks, Michael N6MEF

2 2

Re: [44net] DNS Cleanup
by William Lewis 13 Jun '17

13 Jun '17

Any way in which we will know what is getting deleted ? At 05:59 AM 6/13/2017, you wrote: >Returning to the perennial subject of cleaning up the AMPR.Org DNS >database, > >I propose to delete these entries from the AMPR.Org DNS around July 1st. > - Brian ---------- Wm Lewis (KG6BAJ) AMPR Net IP Address Coordinator - Northern and Central California Regions (A 100% Volunteer Group) ---------- William Lewis, 51-701 / KG6BAJ Deputy Chief Comm Reserve Officer (North) Deputy State RACES Officer (North) Communication Reserve Unit California Governor's Office of Emergency Services (530) 648-4920 Cell <mailto:wlewis@acscalifornia.org>wlewis<mailto:wlewis@acscalifornia.org>@acscalifornia.org **Confidentiality Notice: This e-mail, including any attachments, is for the sole use of the intended recipients and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient please notify the sender by reply e-mail and destroy all copies of the original message**

2 2

Re: [44net] 44Net Digest, Vol 6, Issue 112
by Gustavo Conrad 11 Jun '17

11 Jun '17

Hi Brian, thanks for your explanation. I was not aware of that requirement. I thought that every entry in the encap file, either host or network, it was fully routed. I will email Pedro LU7ABF to ask for the update. Also thanks to Brian N1URO and Tom SP2L for their feedback. 73! Gustavo LU7WA Date: Fri, 9 Jun 2017 20:44:38 -0300 > Date: Fri, 9 Jun 2017 17:56:14 -0700 > From: Brian Kantor <Brian(a)UCSD.Edu> > To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > Subject: Re: [44net] Routing problem? > Message-ID: <20170610005614.GB9749(a)UCSD.Edu> > Content-Type: text/plain; charset=iso-8859-1 > > Amprgw filters at the per-host (/32) level. Each host which is to receive > traffic from the Internet into AMPRNet must individually be listed in > the permissions file, which is built from the AMPR.ORG DNS 'A' records. > > The only host on your subnet which is listed (and therefore is the only > one authorized) is 44.153.164.5. If you want .6 or other hosts on your > subnet to be able to communicate with the Internet, you will need to > have your local coordinator add them to the DNS for you. Or I can do it. > - Brian

1 0

AMPR map update
by Marius Petrescu 11 Jun '17

11 Jun '17

I updated the map site (sorry for a lot of interruptions) to somehow work on all the browsers I had on hand. It uses websockets and eventstream as fallback. This is the current status: - Mozilla Firefox (latest): Full - Chrome Desktop (latest): Full - IE 11: No pulse animation due to the lack of full SVG support - Chrome Android (latest): No 'pew' sound. Sometimes horizontal clipping on HD displays occurs."Request desktop site" fixes this. - Android internet browser (latest): No pew sound - Iceweasel 3.5 (Debian 6): Not supported

1 0

IP connectivity for KB3VWG
by Brian Kantor 09 Jun '17

09 Jun '17

Lynwood, It appears that your dynamic address gateway 'www.kb3vwg.info' keeps cycling between address 173.66.138.32 and 71.178.210.39. When it resolves to the latter address, your 44net hosts are reachable. It did so this morning whilst I happened to be looking: Jun 9 03:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]: 44.60.44.0/24: from 173.66.138.32 to 71.178.210.39 and I was able to connect to your web server on 44.60.44.10. I don't know why this is happening. Is your commercial IP really changing as often as it appears from the logs or is this a problem at your dynamic address provider? - Brian Jun 8 07:13:43 <local0.info> amprgw ipipd[51724]: route changed [129]: 44.60.44.0/24: from 173.66.138.32 to 71.178.210.39 Jun 8 07:18:02 <local0.info> amprgw ipipd[51724]: route changed [138]: 44.60.44.0/24: from 71.178.210.39 to 173.66.138.32 Jun 8 08:04:37 <local0.info> amprgw ipipd[51724]: route changed [138]: 44.60.44.0/24: from 173.66.138.32 to 71.178.210.39 Jun 8 08:15:05 <local0.info> amprgw ipipd[51724]: route changed [138]: 44.60.44.0/24: from 71.178.210.39 to 173.66.138.32 Jun 8 09:15:05 <local0.info> amprgw ipipd[51724]: route changed [138]: 44.60.44.0/24: from 173.66.138.32 to 71.178.210.39 Jun 8 15:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]: 44.60.44.0/24: from 71.178.210.39 to 173.66.138.32 Jun 8 16:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]: 44.60.44.0/24: from 173.66.138.32 to 71.178.210.39 Jun 8 19:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]: 44.60.44.0/24: from 71.178.210.39 to 173.66.138.32 Jun 8 22:15:05 <local0.info> amprgw ipipd[51724]: route changed [137]: 44.60.44.0/24: from 173.66.138.32 to 71.178.210.39

4 7

Routing problem?
by Gustavo Conrad 09 Jun '17

09 Jun '17

Hi All, I'm new to the list and I find it very interesting. Let me introduce myself: ham since 1996, former call LU8WFY, primary interests CW, HF and later digital communications. Devoted to linux for more than ten years. Work in telecommunications since 2001. Now the problem: I got the assignment 44.153.164.4/30 <http://44.153.164.4/30> from the local coordinator (LU7ABF) and (after some NAT fighting with my Cisco 877 router) I was able to put it online from dynamic IP. From the gateway IP 44.153.164.5 there's no problem pinging to 44/8 and to the outside world. Ping from outside to .5 is also ok. But when I ping from outside to 44.153.164.6 there's no response. The strange thing is that, using tcpdump, I see no packets coming into the gateway from amprgw (of course they do show when the ping is to .5). Further testing from 44 net (using yo2tm.ampr.org network tools) showed that from 44 to my host everything works as expected. I guess that there's some routing problem between outside world and 44 net. I don't know in which way the routes from 44 are propagated to the rest of the internet. Maybe I´m missing something but I can't find the problem. Any help will be appreciated. Thanks! 73 Gustavo LU7WA

3 3

Encap
by lleachii＠aol.com 08 Jun '17

08 Jun '17

All, I once again notice intermittent connection to AMPRNet for about 24 hours. When this happens: - When I login into the /private page, I cannot see Encap.txt - Each time, this is how I attempt to confirm I'm in the most recant Encap - I'm not on Marius' map, and from my understanding of his OS (hi) he will not receive packets if he doesn't have a route for me I figure I'm not on Encap.txt. Can someone check? Linux commands: dynamic filter check: ipset test ipipfilter 71.178.210.39 check route: ip route get 44.60.44.0/24 from <your_AMPR_IP_on_router> My encap file reads June 8, 00:20 UTC. - Lynwood KB3VWG > -rw-r--r-- 1 root root 31119 Jun 7 20:20 /etc/config/encap.txt

7 20

Re: [44net] AMPRNet DNS robot
by Rob Janssen 08 Jun '17

08 Jun '17

> How many of you who use the robot are using software to handle > the responses? I don't parse the responses, but I do have automated software to generate the request mails. When that format changes, I like to know beforehand. Rob

2 1

Re: [44net] tunnel window settings
by Rob Janssen 08 Jun '17

08 Jun '17

> I was wondering if the usual TCP window setting of 840 makes any sense in > our current mesh. > This setting was imposed by the assumption that our IP traffic will pass > over ax.25 connections, with their MTU and ACK limitations, and does not > affect AXIP, AXUDP or other transfer modes. I am using -w 0 to override this handling. Note that it does not work in the scenario you depict: the setting only has influence on an end-system (where tcp connections terminate), not on a forwarding gateway. Only when a gateway is an end-system as well, this setting has any effect. And in that case it is not likely it is operating over ax.25. I think it is the responsibility of end-systems on a slow ax.25 network to configure a proper window size. The gateway does not have a role in that. Rob

1 0

Greetings All - Peculiar problem
by Tom Cardinal 08 Jun '17

08 Jun '17

This could be me or maybe not. I got online a few weeks ago with Lynwood's help without it I'd still be offline. Since then I've been attempting to take my script apart and put it back together in an attempt to understand what makes it work and what breaks it From a workstation on my segment I am able to ping, browse and pretty much do anything I'd expect to be able to do. The problem arises if I attempt to ping or traceroute on my gateway to anything in the AMPRnet. No matter what routes exist in my routing table (44) and what rules I create, any and all attempts to connect to an AMPR ip INSIST on going out through eth0 OR tries to use the external IP of my gateway box on the tunl0 interface. I'm using an ubuntu 16.04 lts box with the latest ampr_ripd (2.3). Configuration is: eth0 - isp provided address (DHCP) (IPTables Masqueraded interface for LAN) eth1 - home LAN on RFC 1918 IP space 192.168.1.254/24 eth2 - 44.98.63.6/29 My AMPR segment tunl0 - Tunnel to the rest of the AMPRNET. (no IP Address assigned) Asi Isaid earlier, from the gateway I can't initiate connections through the tunl0 interface even though everything works from an AMPR IP (listed in DNS) on my segment. I'm putting my start script up here. Firewall is in a separate script with nothing blocked at the moment (wide open), I normally run a pretty restrictive firewall and will re-lock it down when I get things sorted out. ---- startampr script ---- #!/bin/sh ### ENABLE IP FORWARDING ### sysctl -w net.ipv4.ip_forward=1 ### Allows traceroute to respond using 44net IP of tunl0 or br-amprlan echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr ### AMPRNet IPENCAP ### modprobe ipip ip tunnel add tunl0 mode ipip ### Bring the tunl0 interface up ### ip link set tunl0 mtu 1480 up ip tunnel change tunl0 ttl 64 pmtudisc ### ROUTING ### Set default route ip route add default dev tunl0 via 169.228.34.84 onlink proto 44 table 44 ### OPTIONAL LOCAL RULES ip rule add from 44.98.63.0/29 to 192.168.1.0/24 table main priority 22 ip rule add from 192.168.1.0/24 to 44.98.63.0/29 table main priority 23 ####REQUIRED RULES ### Handles routing between local AMPR segment and External AMPR network ip rule add to 44.98.63.0/29 table main priority 44 ip rule add dev tunl0 table 44 priority 45 ip rule add dev eth2 table 44 priority 46 ip rule add from 44.98.63.0/29 table 44 priority 47 ### RUN AMPR-RIPD /usr/sbin/ampr-ripd -i tunl0 -t 44 -a 44.98.63.0/29 -s -x '/etc/ampr/load_ipipfilter.sh' -p <password> #### End startampr script #### If I try to add a route to 44.0.0.0/8 with this command: ip rule add to 44.0.0.0/8 table 44 priority 48 and then I do "ip route get 44.0.0.1" I get the following output: root@blackjack:~# ip route get 44.0.0.1 44.0.0.1 via 169.228.34.84 dev tunl0 src 68.109.14.113 cache window 840 When the priority 48 rule in place, my workstation on my 44net segment loses connectivity through the tunnel... Perhaps my ip rule commands are incomplete. I know I'm close, but what am I missing? Are there any policy routing experts that can help explain what I'm missing and why what I have doesn't work if I try to ping/traceroute/mtr on the gateway? -- Tom Cardinal/N2XU/MSgt USAF (Ret)/BSCS/CASP, Security+ ce

5 14

Mikrotik
by Jacek Grzona 08 Jun '17

08 Jun '17

Hello. Is there any probel for a few days with yo2loj script? For a few days I receive such a return in the logs of the mikrotik "Jun / 06/2017 13:21:00 script, error AMPR: To few RIP entries available" Regards SP2GCH

8 24

tunnel window settings
by marius＠yo2loj.ro 08 Jun '17

08 Jun '17

I was wondering if the usual TCP window setting of 840 makes any sense in our current mesh. This setting was imposed by the assumption that our IP traffic will pass over ax.25 connections, with their MTU and ACK limitations, and does not affect AXIP, AXUDP or other transfer modes. The question is: Is there anyone forwarding TCP/IP over AX.25 at this moment? Because if not, we could drop that window setting in the routing daemons and get a more streamlined data flow. Marius, YO2LOJ

3 2

AMPRNet DNS robot
by Brian Kantor 07 Jun '17

07 Jun '17

I'm planning on making some changes to the AMPRNet DNS robot that will significantly alter the transaction response format. It will still be human readable, but if you are analyzing the responses using software of some kind, you'll have some work ahead of you. How many of you who use the robot are using software to handle the responses? - Brian

2 1

AmprNAT
by Brian 07 Jun '17

07 Jun '17

I have finished documenting and putting up on my website what I call AmprNAT. For those who attempting to get out via amprgate sourcing as their lan IPs, this not only will prevent this from occurring but also it will NAT you out as your gateway's IP... pending you're using a distro of linux. It requires a static route in your route pointing to your gateway, and then 3 lines of iptables rules. You may read about it at: https://n1uro.ampr.org/linuxconf/44nat.html I believe Lynwood is adding info on the wiki for this. -- I was reading a book about the history of glue... I couldn't put it down. ...think about it... -------- 73 de Brian - N1URO/AFT1BR email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, New Jersey, Pennsylvania, Rhode Island, and Vermont.

2 1

Reminder about Amprd for simple configurations
by Marius Petrescu 07 Jun '17

07 Jun '17

Hi, Since everyone seems to like to use the most unusual script with "original" settings without trying ever to understand what's happening, I would remind you that there is a more or less "plug-and-play" solution called amprd... Let's assume a system with: - 44net assignment: 44.128.1.0/24 - WAN on eth0 (let's assume 1.2.3.4) - LAN on eth0 (192.168.1.1/24) - AMPR on eth2 (44.128.1.0/24) - We choose our GW IP to be 44.128.1.1 and that the internet access from the system is already set up, with NAT and default gateway via WAN. Now: 1. compile (make) and install (make install) amprd 2. create the following /etc/amprd.cfg: ----------------------------------------------------------------- [ampr0] prefix = 44.128.1.1 rip_receive = yes rip_save = yes ----------------------------------------------------------------- 3. Set address 44.128.1.1/24 to your eth2 interface 4. Start amprd. And basically that's it: a fully functional mesh gateway. If you want access from the internet to your subnet, too, instead of just starting amprd, create the following ampr startup script: ----------------------------------------------------------------- amprd ip route add default via 169.228.34.84 dev ampr0 onlink table default ip rule add from 44.128.1.1 table default ip rule add from 44.128.1.1 to 44.128.1.0/24 table main ----------------------------------------------------------------- This should do the trick. Marius, YO2LOJ

1 1

Portal IP hasn't changed in a few hours
by lleachii＠aol.com 07 Jun '17

07 Jun '17

All, Once again, my WAN IP and Subnet changed (about 5 hours ago now). I did reboot my GW; but my IP has not yet changed in the portal and I cannot reach other 44subnets or the Internet. I have logged in the Portal, removed the IP from the GW webform and hit save (leaving only the DDNS hostname). - Lynwood KB3VWG

2 1

DDOS attack Monitor Sites
by R P 06 Jun '17

06 Jun '17

I think it might interest us as a users of a big network Maybe it has interest to you Brian as our network Manager http://www.digitalattackmap.com/#anim=1&color=3&country=ALL&list=0&time=173… http://map.norsecorp.com/#/

2 1

Ampr-ripd experimental 2.3 version
by Marius Petrescu 05 Jun '17

05 Jun '17

Hello everyone, Since experimenting goes one, here a new ampr-ripd version that forces the sending of call home data to use the tunnel's IP as its source IP address. Tnx. Lynwood for pointing out that necessity. Interactive map which is available at http://yo2tm.ampr.org/ampr-map/ For those that do not want to participate, there is no need to upgrade. And even if you do, not setting the -L parameter will not send any data, the result being the same behavior like 2.1.1. Download: http://www.yo2loj.ro/hamprojects/ampr-ripd-2.3.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.3.tgz Have fun, Marius, YO2LOJ

6 19

Odp: Re: Ampr-ripd experimental 2.3 version
by Tomasz Stankiewicz 05 Jun '17

05 Jun '17

Marius et al. Presently my server employs ampr-ripd-2.3 Did not observed any issues so far. encap.txt file at the very beginning contains two entries: # # encap.txt file - saved by ampr-ripd (UTC) Mon Jun 5 03:20:34 2017 # route addprivate 44.0.0.1/32 encap 169.228.34.84 route addprivate 44.0.0.2/32 encap 169.228.66.251 RIP broadcast are coming through as before. Best regards. Tom - SP2L

2 1

Odp: Re: Ampr-ripd experimental 2.3 version
by Tomasz Stankiewicz 05 Jun '17

05 Jun '17

An HTML attachment was scrubbed... URL: <http://hamradio.ucsd.edu/mailman/private/44net/attachments/20170605/f4bb34a…>

1 0

Amprd v2.1 update
by Marius Petrescu 04 Jun '17

04 Jun '17

Hello everyone, To be in line with the latest ampr-ripd & co, here a new amprd version that forces the sending of call home data to use the tunnel's IP as its source IP address. Also, it supports multiple call home info's, one for each tunnel configured. Interactive map which is available at http://yo2tm.ampr.org/ampr-map/ For those that do not want to participate, there is no need to upgrade. Download: http://www.yo2loj.ro/hamprojects/amprd-2.1.tgz http://yo2tm.ampr.org/hamprojects/amprd-2.1.tgz Have fun, Marius, YO2LOJ

1 0

Amprd 2.0 - map functionality and new GW IP
by Marius Petrescu 04 Jun '17

04 Jun '17

Hello, For those using amprd (like myself), here a small update: - added map notification every 5 min. There is a new config file parameter for it, check the example config - modified the default ampr gw address to the new IP. This has actually no effect until the RIP broadcasts for 44.0.0.1 will change to the new IP (44.0.0.1 still uses the old GW address). Older versions, like 1.5 and 1.6 will switch gateways automatically if presented with a new gw for 44.0.0.1 in the RIP data, so unless you want to be on the map with a blue dot, there is no urge to update (live map is at http://yo2tm.ampr.org/ampr-map/) As always: http://www.yo2loj.ro/hamprojects/ http://yo2tm.ampr.org/hamprojects/ Marius, YO2LOJ

6 30

tcpdump
by gm4upx＠gb7jd.co.uk 03 Jun '17

03 Jun '17

Hello, With the changes taking place I have been monitoring both the " old " and the " new " addresses. I'm receiving rip broadcasts from both and additionally similar broadcasts to the two lines below on the " old " address only. amprgw.sysnet.ucsd.edu > 172.16.1.4: IP (tos 0x0, ttl 111, id 14685, offset 0, flags [none], proto UDP (17), length 90) 218-228-138-51f1.osk3.eonet.ne.jp.25465 > mb7njd.ampr.org.3544: [udp sum ok] UDP, length 62 I have little knowledge of the meaning of this and would appreciate someone explaining it to me. Thanks in advance. ( Monitored from eth0 at 172.16.1.4 which is in DMZ ) Regards, Ian..

3 4

Re: [44net] hosts accessibility
by Rob Janssen 03 Jun '17

03 Jun '17

> Recently some important changes were > performed pertaining whole [44net] community. > Today I made few test in order to check > accessibility of [44net] hosts. Currently IPIP routing via the old amprgw is broken for our network. This is the result of several changes in the local config and at UCSD. I am not going to fix it, it should all be OK again after the change on monday. (it should not affect BGP routing of our network and traffic from other gateways) Rob

1 0

No networks found in my region
by Quan Zhou 03 Jun '17

03 Jun '17

Hi 44net, I just signed up AMPRNet but wasn't able to find my country [China] in the list. So I tried to register a new region, am I doing it correct? Thanks. -- Regards, Quan Zhou E271C0D1BD90012B8D8EECF6F822BC9F8E1C35C8 quanzhou822(a)gmail.com https://keybase.io/qzhou

2 2

Nevada coordinator
by James Sharp 02 Jun '17

02 Jun '17

I put in a request on 2017-05-18 for a netblock since I've moved to Nevada, but I haven't gotten the allocation. I can't seem to find a direct contact for the administrator.

2 2

Map game for mikrotik routers
by Marius Petrescu 02 Jun '17

02 Jun '17

For those who want to join the map test with mikrotik routers: - create a new script containing a single line (replace the call and locator, of course): /tool fetch mode=http url="http://44.182.21.1:59001/mikrotik?id=yo2loj@kn05os" keep-result=no - in the scheduler get it to run every 5 minutes. That's it. ampr-ripd clients appear as green dots, MT routers as reddish ones. http://44.182.21.1/ampr-map/ Marius, YO2LOJ

8 22

Gateways errors at amprgate
by R P 02 Jun '17

02 Jun '17

What is it ? 127.0.0.1 5.254.66.117 3 [19] dropped: non-44 inner source address 127.0.0.1 13.59.252.204 2 [19] dropped: non-44 inner source address 127.0.0.1 23.234.29.148 3 [19] dropped: non-44 inner source address 127.0.0.1 27.193.36.35 2 [19] dropped: non-44 inner source address

3 21

Packet/protocol generator web page ?
by R P 02 Jun '17

02 Jun '17

Does anyone know if there is on the web place that i can give address and a protocol / port and it will send data according to the protocol / port i want ? Or has anyone the capability to do so ? I want to tests some firewall rules that i made ... Thanks Forward Ronen - 4Z4ZQ

3 6

Re: [44net] mailing list security
by Rob Janssen 02 Jun '17

02 Jun '17

I think an adequate explanation for the URL-fetch mystery is that some people run a virus scanner or have their e-mail delivered to a mailservice that does scanning, and this scanner fetches all URLs in the message to check if they point to malware... No amount of validation of the subscribers will solve that problem. The only thing you can do is obfuscate the links, but that is incovenient for the reader. Similar problem: whenever you download a program, a second fetch is done by Microsoft/Google/Apple/whatever your favorite vendor to check what it is. I have seen this several times on a download server we run at work. Rob

2 1

Map notification for generic systems.
by Marius Petrescu 02 Jun '17

02 Jun '17

I also added a notification method for generic systems (they will appear as grey dots). Schedule a 5 min cron job (or whatever is needed to get it done) with the following instruction: wget -O /dev/null http://44.182.21.1:59001/generic?id=test@AA00AA Replace test@AA00AA with your gateway_call@qth_locator This also will only work from 44net sources only. Have fun, Marius, YO2LOJ

5 7

amprgw changeover schedule
by Brian Kantor 01 Jun '17

01 Jun '17

On Monday, around 0930 Pacific (1630 UTC), we'll be moving the inbound route for 44.0.0.0/8 from old amprgw to new. Shortly after, as soon as it's confirmed working, I'll turn off the RIP sender on old amprgw and you should stop seeing any more traffic from 169.228.66.251 (although the machine will stay up so we can archive it before turning it off). You'll continue to get RIP from 169.228.34.84, and that's where encap traffic will come from for the foreseeable future. This changeover will have the effect of moving the gw.ampr.org web site from old amprgw to new amprgw, so the graphs, charts, and tables will change to content as seen from new amprgw's view, thus we'll lose a few days history. Encap packets sent to old amprgw after the changeover will not be forwarded, as the machine will have no further routing to network 44. Gateways which have not updated their outgoing encap path will be unreachable. Everything else should just work. Wish us all good luck! - Brian

1 0

mailing list format
by Brian Kantor 01 Jun '17

01 Jun '17

I got tired of seeing the 'please trim inclusions' header line on each message, and I don't think it was doing any good being there, and there were some negative comments about it, so I deleted it. If I did it right, this message won't have it. - Brian

2 1

Re: [44net] mailing list security
by Steve L 01 Jun '17

01 Jun '17

Someone could create an email list only available on 44net, however I doubt there would be much activity on such a list. The biggest thing I wish this list had was a way to search the archives. I almost sometimes wish it was crawled by google etc. But at the same time that just welcomes more of the unwanted.

4 3

Re: [44net] ampr-ripd special experimental release 2.2
by Marius Petrescu 01 Jun '17

01 Jun '17

David, For the purpose of placing devices on a world map a 6-position gridsquare should be minimal and enough. People wanting to send a more exact position can do it, but a 4-position grid square is IMHO not sufficient. So for the moment, the receiving side truncates the locator to 6 positions and converts that one to a lon/lat value (the center of the subsquare). Let me get this map running first and we will see where we go from there. On 31.05.2017 03:58, David Ranch wrote: > Hey Marius, > > If you are going to use grid squares instead of Lat/Long or GPS > coordinates, could you maybe support addition resolution on the Grid > square? For example, my high resolution grid square is CM97ai02ak > <http://www.dxmaps.com/callbook/gmap.php> . Most people might only > like to give say CM97, most people will give CM97ai, maybe others > might give CM97ai02 . > > --David > > > On 05/30/2017 01:43 PM, Marius Petrescu wrote: >> (Please trim inclusions from previous messages) >> _______________________________________________ >> Hello everyone, >> >> For the proposed experiment on creating a interactive dynamic map of >> the ampr-ripd systems, I created a special version (2.2). >> >> The daemon accepts a new parameter -L <string>. If this string is >> defined, it will be sent every 5 minutes to my gateway 44.182.21.1 >> via UDP to port 59001. >> >> The format I will use is plain and simple gwcallsign@locator, case >> insensitive e.g. -L yo2loj@kn05or. >> >> If we will ned somehow more data, the string can be replaced wit >> anything, it is just sent as it is and will be parsed by the backend. >> >> For the moment there is only a simple listener monitoring that port, >> and I am working on the server and interactive map which will be >> available at >> >> http://yo2tm.ampr.org/ampr-map/ >> >> >> For those that do not want to participate, there is no need to upgrade. >> >> And even if you do, not setting the -L parameter will not send any >> data, the result being the same behavior like 2.1.1. >> >> >> Download: >> >> http://www.yo2loj.ro/hamprojects/ampr-ripd-2.2.tgz >> >> http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.2.tgz >> >> >> Have fun, >> >> Marius, YO2LOJ >> >> >>

5 11

Re: [44net] Gateways errors at amprgate
by lleachii＠aol.com 31 May '17

31 May '17

Brian, That seems to have fixed it! Thanks and 73, -KB3VWG ----- Reply message ----- From: "Brian Kantor" <Brian(a)UCSD.Edu> To: "lleachii--- via 44Net" <44net(a)hamradio.ucsd.edu> Cc: <lleachii(a)aol.com> Subject: [44net] Gateways errors at amprgate Date: Wed, May 31, 2017 17:31 Well, damn. I restarted the ipip daemon and they went away. Looks like it's time to debug the routing table maintenance routing. The log shows a new route being added but it appears to have been loaded on top of your route, thus misdirecting traffic. I'll work on it. Sorry for the bug. - Brian On Wed, May 31, 2017 at 05:14:13PM -0400, lleachii--- via 44Net wrote: > Odd...they're still being received (Eastern Daylight Time). Just a few > moments ago:

1 0

Re: [44net] Gateways errors at amprgate
by Brian Kantor 31 May '17

31 May '17

Amprgw ignores the TOS field. I don't see how that would affect anything here. - Brian On Wed, May 31, 2017 at 04:47:44PM -0400, lleachii(a)aol.com wrote: > Brian, > Since I noticed the connection issue, I switched back to ToS 0x00 (Default)...just to be sure. > > I can still reach other gateways directly... I'll check to make sure I'm receiving routes. > > - KB3VWG

1 0

Re: [44net] Gateways errors at amprgate
by lleachii＠aol.com 31 May '17

31 May '17

Brian, Since I noticed the connection issue, I switched back to ToS 0x00 (Default)...just to be sure. I can still reach other gateways directly... I'll check to make sure I'm receiving routes. - KB3VWG ----- Reply message ----- From: "Brian Kantor" <Brian(a)UCSD.Edu> To: "lleachii--- via 44Net" <44net(a)hamradio.ucsd.edu> Cc: <lleachii(a)aol.com> Subject: [44net] Gateways errors at amprgate Date: Wed, May 31, 2017 16:38 Everything is fine here as far as I can see. I don't know why you got traffic for 44.62.1.x when you're not the gateway for it. The route table has the proper route in it. Nor do I know why you're having intermittent connectivity. The cross-country link from Los Angeles to Washington doesn't seem to be dropping packets. And I've been at lunch so I wasn't fiddling with the router. - Brian On Wed, May 31, 2017 at 04:14:37PM -0400, lleachii--- via 44Net wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > Brian, > > Is everything OK at AMPRGW, I just received some VERY odd traffic (and I've > been having interment connectivity): > > > 2017-05-31 14:59:57.803 0.000 TCP 104.236.151.76:48212 -> > 44.62.1.10:143 1 40 1 > 2017-05-31 15:00:32.321 0.000 TCP 125.212.218.198:65415 -> > 44.62.1.14:22 1 48 1 > 2017-05-31 15:00:32.321 0.000 TCP 125.212.218.198:65415 -> > 44.62.1.12:22 1 48 1 > 2017-05-31 15:00:32.321 0.000 TCP 125.212.218.198:65415 -> > 44.62.1.10:22 1 48 1 > 2017-05-31 15:00:32.330 0.000 TCP 125.212.218.198:65415 -> > 44.62.1.9:22 1 48 1 > 2017-05-31 15:00:32.330 0.000 TCP 125.212.218.198:65415 -> > 44.62.1.11:22 1 48 1 > 2017-05-31 15:00:32.330 0.000 TCP 125.212.218.198:65415 -> > 44.62.1.13:22 1 48 1 > 2017-05-31 15:00:36.520 0.000 TCP 213.32.7.73:44191 -> > 44.62.1.10:22 1 40 1 > 2017-05-31 15:02:45.210 0.000 TCP 181.113.163.24:59150 -> > 44.62.1.10:22 1 40 1 > 2017-05-31 15:03:08.697 0.000 TCP 186.134.5.194:51377 -> > 44.62.1.12:22 1 40 1 > 2017-05-31 15:03:26.190 0.000 TCP 104.236.151.76:48281 -> > 44.62.1.12:143 1 40 1 > 2017-05-31 15:03:28.222 0.000 TCP 117.9.45.58:47360 -> > 44.62.1.11:22 1 40 1 > 2017-05-31 15:03:31.438 6.996 TCP 187.199.54.149:43075 -> > 44.62.1.9:81 4 240 1 > > > 73, > > > - Lynwood > KB3VWG > > >44.62.1.8 / 29 Southern Virginia Gateway AB4MW > > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

AMPR Gateway error
by R P 31 May '17

31 May '17

Brian May you explain this error line apear in the errors of the gateways ? 169.228.34.84 44.0.0.1 702 [18] dropped: multicast inner destination address

2 1

Those Running Linux - DSCP Test
by lleachii＠aol.com 30 May '17

30 May '17

All, If your device runs Linux using the common script, and if you have a desktop on AMPRNet, please test the following: - run a speedtest at http://44.60.44.10/tools/mini/ - add Expedited Forwarding of IPENCAP packets by entering the following on your router 'ip tunnel change tunl0 mode ipip ttl 64 tos B8 pmtudisc' - run a speedtest again *You MUST run this test on AMPRNet directly to my node.* - Lynwood KB3VWG

1 0

ampr-ripd special experimental release 2.2
by Marius Petrescu 30 May '17

30 May '17

Hello everyone, For the proposed experiment on creating a interactive dynamic map of the ampr-ripd systems, I created a special version (2.2). The daemon accepts a new parameter -L <string>. If this string is defined, it will be sent every 5 minutes to my gateway 44.182.21.1 via UDP to port 59001. The format I will use is plain and simple gwcallsign@locator, case insensitive e.g. -L yo2loj@kn05or. If we will ned somehow more data, the string can be replaced wit anything, it is just sent as it is and will be parsed by the backend. For the moment there is only a simple listener monitoring that port, and I am working on the server and interactive map which will be available at http://yo2tm.ampr.org/ampr-map/ For those that do not want to participate, there is no need to upgrade. And even if you do, not setting the -L parameter will not send any data, the result being the same behavior like 2.1.1. Download: http://www.yo2loj.ro/hamprojects/ampr-ripd-2.2.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.2.tgz Have fun, Marius, YO2LOJ

4 9

Re: [44net] ToS/DSCP
by Rob Janssen 30 May '17

30 May '17

I do not see what all this tracerouting has to do with ToS/DSCP but I can add that we have full support for ToS/DSCP in our local net and it works beautifully. We use the top 3 bits of the ToS/DSCP to split the traffic in 8 queues in a Queue Tree (MikroTik feature) on links with a defined bandwidth, and it is used in WiFi link equipment (Ubiquiti, MikroTik) to split the traffic in 4 queues typically (WMM). We mainly use EF (46) for voice, CS1 (8) for background traffic like backups, and have CS2 (16) for a priority slightly above that. Default 00 is above that priority. I see no latency effects of running a long backup over the same links used for the repeater audio for our co-channel multi site repeaters. Of course DSCP only works as long as it is not abused to get priority over fellow hams. It is like using more power to wipe everyone else from the repeater... works until the others do it too. Rob

3 2

ToS/DSCP
by lleachii＠aol.com 30 May '17

30 May '17

All, I've been doing some testing with the Type of Service and Differentiated Services Code Point for tunl0. I've been working to determine if connectivity to Ronen's camera's could be slightly improved from the tunnel's perspective. I'm focusing on the improvements seen using hex code 0xB8, known as High Priority Expedited Forwarding, or 'Virtual Leased Line.' I wanted you all to check your connections to me, and make sure that I'm still reachable. Feel free to ping, or simply use my tool at http://44.60.44.10/tools/trace/php-trace44.php/ to reach yourselves. 73, - Lynwood KB3VWG > ip tunnel change tunl0 mode ipip ttl 64 tos B8 pmtudisc

3 7

Re: [44net] Mapping experiment proposal
by Rob Janssen 30 May '17

30 May '17

> I can modify ampr-ripd (and amprd if needed) to periodically sent some > data "home", locator and gateway callsign to 44.182.21.1. > This would need an additional parameter, something like "-Lyo2loj at kn05or <http://hamradio.ucsd.edu/mailman/listinfo/44net>". > This would allow me to put together a simple tracking database and show > active nodes on a world map for everybody to gaze at :-) Yes, it could send some fields like the software version and maybe the number of routes it has put in the table, so it will be possible to debug things and be able to notify users when a serious problem is discovered or protocol change is made that requires update beyond some version number. That could be done using MNDP or similar protocol sending to 44.0.0.1? I would recommend having different fields for different information. (sysop, locator, etc) Way I the past I had something like this in my NET version. It used multicast to 224.0.1.31 which is a multicast address I registered for this purpose. host 224.0.1.31 31.1.0.224.in-addr.arpa domain name pointer ampr-info.mcast.net. You are welcome to use that address when required (probably not, just send over tunnel to some real destination or 255.255.255.255) Rob

1 0

Mapping experiment proposal
by Marius Petrescu 30 May '17

30 May '17

If anyone is interested, I would propose an experiment. I can modify ampr-ripd (and amprd if needed) to periodically sent some data "home", locator and gateway callsign to 44.182.21.1. This would need an additional parameter, something like "-L yo2loj@kn05or". This would allow me to put together a simple tracking database and show active nodes on a world map for everybody to gaze at :-) Anyone interested? Marius, YO2LOJ

6 7

Tunnel keep allive
by R P 30 May '17

30 May '17

So with Brians "pressure" on me (HI) i think i have found the problem ... it it the tunnel keep alive and now the questions 1)Does it necessary to turn it on ? 2) why this uses source address of amprGW and destination of my local address maybe its a a bug in the Mikrotik tunnel ? what protocol keep alive uses ? is there anyone else here with mikrotik that have a keep alive open and know if he get same errors from AMPGW ? I have changed the keep alive timing from every 10 to 610 seconds and the errors reduced to 2 every 15 minutes from about 100 Ronen - 4Z4ZQ

3 3

Re: [44net] MikroTik uptime
by Rob Janssen 30 May '17

30 May '17

> Reverse engineering the protocol was a bit of a challenge. I couldn't > find it documented in sufficient detail anywhere and wound up decoding the > protocol format from the hex dump and decoding that wireshark provided. Yes, that is kind of inconvenient. From the wireshark decoding I guessed that it would be a float. Apparently not. Wireshark shows that it is TLV data and what the types mean, and I knew that you would be able to map the TLV to the hexdump. Rob

1 0

Re: [44net] MikroTik uptime
by Rob Janssen 30 May '17

30 May '17

> Thanks Tom, yes, when I assume it's seconds, I get > uptime numbers like 22+02:22:54, which is 22 days, > 2 hours, and some minutes/seconds. Yes, it is in seconds. The latest software release was early may, so that is a uptime that can be expected. Rob

2 1

Re: [44net] Tunnel keep allive
by Rob Janssen 30 May '17

30 May '17

> So with Brians "pressure" on me (HI) i think i have found the problem ... it it the tunnel keep alive > and now the questions > 1)Does it necessary to turn it on ? > 2) why this uses source address of amprGW and destination of my local address maybe its a a bug in the Mikrotik tunnel ? what protocol keep alive uses ? is there anyone else here with mikrotik that have a keep alive open and know if he get same errors from AMPGW ? Yes, that is probably the reason. You should simply turn it off. The tunnel keep alive packets are tunneled packets with source and destination address swapped. There is no standard for this, but it is a method used by other manufacturers as well. Apparently the expectation is that the remote end of the tunnel will just route the packets and return them on the same tunnel, just like a ping. However, in your case one of the addresses is a 192.168 (RFC1918) address. Likely you are running your MikroTik behind another router that does NAT. That is not a good idea, you should try to get the real internet address on the MikroTik. With some ISPs it may be difficult because the use of the provided router is mandatory and it cannot be put in transparent mode. Setting "DMZ mode" in the router often causes additional problems. Rob

1 0

MikroTik uptime
by Brian Kantor 30 May '17

30 May '17

Rob or Marius, do you know what units the MikroTik reports its uptime in? Is it seconds? I get numbers like 1922575 or 1909374 for the two I have MNDP data for. - Brian

2 2

MNDP packets
by Rob Janssen 30 May '17

30 May '17

Maybe one of the interesting "things to do" would be to write a small daemon that captures those UDP packets to 255.255.255.255 port 5678 (MNDP) and stores the latest one received from each source. It would have to have access to the outer IPIP header to do that. Then, it could regularly dump the collected "latest packets" in a tabulated text file with the fields that there are in these packets each in a column. When you look in wireshark (which knows about this format) you see it is quite easy to do. This table would present an overview of the MikroTik routers in use, and could help identify possible problems with the tunneling they do. You could also stop handling them as an error condition. How would such a daemon have to be written so it can run at the gateway? Could it just do a pcap with the appropriate filter? Rob

7 19

Re: [44net] MNDP packets
by Rob Janssen 30 May '17

30 May '17

> Why my Mikrotik dont appear in this data ? When you are using Marius' automatic tunnel configuration script, you won't appear there. It disables the MNDP transmission on the tunnels. What you see in that list is only those routers where an IP tunnel to the new gateway was manually configured and MNDP was not turned off. Rob

2 1

Re: [44net] MNDP packets
by Rob Janssen 30 May '17

30 May '17

> Researching, I believe I noticed 44.137.1.80/28 appear, and that you're > the coordinator. > Otherwise, there's already a route existing in the portal. I know, I will try to contact him to see if he has problems. (I guess he has only made a tunnel to amprgw. I cannot ping him from a Dutch AMPRnet IP) Some people apply for a subnet on IPIP and then find that it is not as easy as they would have guessed to get it working correctly. Probably they expected it would be a matter of configuring an IP tunnel in their router. We know there is a little more to it. Rob

1 0

Re: [44net] MNDP packets
by Rob Janssen 30 May '17

30 May '17

> Well, what I wrote does this: > 68.100.10.100 44.62.5.1 5678 MikroTik 6.36.1 (stable) MikroTik 5RRB-VMWG RB750Gr3 UCSD > 84.106.126.184 44.137.1.92 5678 MikroTik 6.38.5 (stable) MikroTik V2P4-7CQK RB2011UiAS-2HnD ucsd-gw > As far as MikroTik router gateways go, that's pretty much all there is > to be learned from the MNDP broadcasts. Believe it or not, that already reveals 1 issue and one possible issue... That second entry has an unregistered address as the router address, and it is likely only having a single tunnel towards ucsd instead of a full mesh. Rob

2 1

Re: [44net] MNDP packets
by Rob Janssen 29 May '17

29 May '17

> I forgot: the firmware version, too. And the router IP address. That is interesting information as it allows us to check if the gateway is up and actually functioning. The receiving of these MNDP packets in fact is some indication of that. Of course the number of gateways using MikroTik routers is low, but maybe when similar packets were sent by ampr-ripd there would be info from a lot of gateways. I thought it might be useful to have some status overview and maybe version information. It can help answer basic questions like "how many of the registered gateways are actually operational". Of course it has to be decided if it is worth the extra traffic and the trouble of writing the software. About gathering service information: there is some demand for an overview of services available on AMPRnet. People have suggested installing a search engine, and it has been done in some places, but IMHO a search engine, while useful, is not really the answer. When you do not know what to search for, a search engine has to be very clever to give useful results for queries like "show me an interesting service to try today". What I am looking for is more like a website that shows a table of services, one line per service and with a clickable link that expands one item into more detail, describing interesting services (not limited to websites!) on AMPRnet. Things that draw your attention and that you may want to try. The detail would include things like "how to get an account" (when relevant) etc. It could be constructed in a similar way to the neighbor table maintained by MNDP, except it would not be UDP broadcasts but e.g. some HTTP POST. When you have a service that is available on AMPRnet, you would do an automated daily POST of a small file describing the service (would be easy to install as a cron job using curl or wget) to the server, and the webpage shows all services that have recently been (re-)posted. The result would be similar to the Wiki page http://wiki.ampr.org/wiki/Services , but with the advantage that services that have become unavailable will disappear from the list automatically (assuming that the posting of the info is done from the system providing the service and stops at the same time). The beauty of a network of course is that anyone can make this and put it online. It does not have to run on amprgw or other parts of the network infrastructure, it can just be an experiment running on a Raspberry Pi at someone's home. When we have something like that, it is easier to get people going after they have connected to the network, and keeping them interested in exploring new things on the network. Maybe suitable software already exists, otherwise it should be quite easy to do on a LAMP server or similar. Rob

1 0

need help in AMPRGW statistics PCAP decode (gateway errors)
by R P 29 May '17

29 May '17

I get the following error in the statistic file of amprgate 5.29.18.144 169.228.66.251 4122 [19] dropped: non-44 inner source address when i look on the PCAP file here is what I see #1 0.000000 169.228.66.251 -> 192.168.1.180 IPv4 20 #2 9.996091 169.228.66.251 -> 192.168.1.180 IPv4 20 #3 19.997040 169.228.66.251 -> 192.168.1.180 IPv4 20 #4 29.996386 169.228.66.251 -> 192.168.1.180 IPv4 20 #5 39.995885 169.228.66.251 -> 192.168.1.180 IPv4 20 #6 49.997226 169.228.66.251 -> 192.168.1.180 IPv4 20 #7 59.996845 169.228.66.251 -> 192.168.1.180 IPv4 20 #8 69.996284 169.228.66.251 -> 192.168.1.180 IPv4 20 #9 79.996422 169.228.66.251 -> 192.168.1.180 IPv4 20 #10 90.006277 169.228.66.251 -> 192.168.1.180 IPv4 20 #11 99.996794 169.228.66.251 -> 192.168.1.180 IPv4 20 #12 109.996173 169.228.66.251 -> 192.168.1.180 IPv4 20 #13 120.008209 169.228.66.251 -> 192.168.1.180 IPv4 20 #14 129.997756 169.228.66.251 -> 192.168.1.180 IPv4 20 #15 139.996572 169.228.66.251 -> 192.168.1.180 IPv4 20 inside the PCAP here is what I see Frame 1: 20 bytes on wire (160 bits), 20 bytes captured (160 bits) Encapsulation type: Raw IP (7) Arrival Time: May 29, 2017 08:59:04.652285000 CEST [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1496041144.652285000 seconds [Time delta from previous captured frame: 0.000000000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 0.000000000 seconds] Frame Number: 1 Frame Length: 20 bytes (160 bits) Capture Length: 20 bytes (160 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: raw:ip] Raw packet data Internet Protocol Version 4, Src: 169.228.66.251, Dst: 192.168.1.180 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 0000 00.. = Differentiated Services Codepoint: Default (0) .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 20 Identification: 0x0000 (0) Flags: 0x00 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 255 Protocol: IPIP (4) Header checksum: 0x0caa [validation disabled] [Good: False] [Bad: False] Source: 169.228.66.251 Destination: 192.168.1.180 [Source GeoIP: La Jolla, CA, United States, AS7377 University of California, San Diego, 32.880699, -117.235901] [Source GeoIP City: La Jolla, CA] [Source GeoIP Country: United States] [Source GeoIP AS Number: AS7377 University of California, San Diego] [Source GeoIP Latitude: 32.880699] [Source GeoIP Longitude: -117.235901] [Destination GeoIP: Unknown] Collapse Tree I dont understand what is the problem May anyone help ? Thank Forward Ronen - 4Z4ZQ

4 6

PCAP viewer ?
by R P 29 May '17

29 May '17

Hi Someone know if there is somewhere on the net something that (web page) can view PCAP file ? If not is there any Software that doesn't need to be installed (unlike WireShark) for PC ? Thanks for Any info Ronen - 4Z4ZQ

2 1

Re: [44net] MNDP packets
by Rob Janssen 29 May '17

29 May '17

> there have only been 8 hosts sending broadcast destination packets Maybe some have turned this off (easy to do) because they are considered errors now. > I don't know if it would be worth the effort to decode them into a text > file since they are already available for download. > What information is in them that might be of general interest? Well, as also suggested by Lynwood, these packets (and others) can be used to maintain a table of software in use, and can be helpful when there is some problem that appears to affect part of the gateways, but it is not immediately clear what they have in common. Rob

1 0

message to all gateway operators
by Brian Kantor 29 May '17

29 May '17

The following message is being queued for email delivery to everyone registered on the portal as operating a gateway. - Brian -------------------------------------------------------------------- From: Brian Kantor <Brian(a)UCSD.Edu> To: AMPRNet Gateway Operators:; Subject: AMPRNet - Important notice regarding your gateway system Hello. You are receiving this email because you are registered with portal.ampr.org as operating an IPIP encapsulating gateway, and there are changes coming that will affect the operation of your gateway. We are replacing the equipment at the UCSD Internet-AMPRNet gateway with a newer, more capable device. In the process, the new equipment will be assigned a NEW IP ADDRESS. You will have to make changes in YOUR gateway configuration for your gateway to continue functioning. The new equipment is already in service as amprgw.ucsd.edu and is on IP address 169.228.34.84. This replaces the old equipment, known as amprgw.sysnet.ucsd.edu, on IP address 169.228.66.251. What you have to do to maintain the operability of your gateway: 1. You must change the outgoing destination address of your gateway from 169.228.66.251 to 169.228.34.84. You may do this immediately; the new equipment at UCSD is already operational. 2. You must allow packets from the new address, 169.228.34.84, into your gateway router software configuration. If you are running with a firewall, you must open a new path through it to your equipment. Packets (RIP44 transmissions) are already being sent to you from this address. 3. You must continue to accept packets from the old address, 169.228.66.251, for a period of a few weeks as the changeover is being made. After a few weeks, packets will stop coming from that address and you may remove permission for them to enter your firewall, if you have one. These are simple changes, involving editing a few configuration parameters, but because there are so many different types of gateway in operation on AMPRNet, how to make these changes cannot be detailed here. You may find more information regarding your particular configuration on https://wiki.ampr.org/ or on the 44net(a)hamradio.ucsd.edu discussion mailing list, which you should join if you are not already a subscriber. Best wishes and 73, - Brian

3 3

ampr-ripd 2.1.1 bugfix released
by Marius Petrescu 29 May '17

29 May '17

Hello everyone, Due to an cut instead of copy /paste error, there was a wrong tunnel interface index detection (it always got the last interface in the system). So here the a correted version of ampr-ripd (2.1.1) with the fix. Changelog: - Fixed a tunnel interface detection error - No functional changes Download: http://www.yo2loj.ro/hamprojects/ampr-ripd-2.1.1.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.1.1.tgz Have fun, Marius, YO2LOJ

4 4

Re: [44net] AMPRNet - Important notice regarding your gateway system
by jerome schatten 29 May '17

29 May '17

As regards preparing a jnos system: http://kf8kk.com/packet/jnos-linux/linux-jnos-setup-1.htm gives a 404 What port will the new gateway ip nee? Still 520 udp? Thanks, jerome - ve7ass > On May 28, 2017, at 20:56, Brian Kantor <Brian(a)UCSD.Edu> wrote: > > Hello. You are receiving this email because you are registered with > portal.ampr.org as operating an IPIP encapsulating gateway, and there > are changes coming that will affect the operation of your gateway. > > We are replacing the equipment at the UCSD Internet-AMPRNet gateway > with a newer, more capable device. In the process, the new equipment > will be assigned a NEW IP ADDRESS. You will have to make changes in > YOUR gateway configuration for your gateway to continue functioning. > > The new equipment is already in service as amprgw.ucsd.edu and is on > IP address 169.228.34.84. This replaces the old equipment, known as > amprgw.sysnet.ucsd.edu, on IP address 169.228.66.251. > > What you have to do to maintain the operability of your gateway: > > 1. You must change the outgoing destination address of your gateway > from 169.228.66.251 to 169.228.34.84. You may do this immediately; > the new equipment at UCSD is already operational. > > 2. You must allow packets from the new address, 169.228.34.84, into > your gateway router software configuration. If you are running with > a firewall, you must open a new path through it to your equipment. > Packets (RIP44 transmissions) are already being sent to you from > this address. > > 3. You must continue to accept packets from the old address, > 169.228.66.251, for a period of a few weeks as the changeover is being > made. After a few weeks, packets will stop coming from that address > and you may remove permission for them to enter your firewall, if you > have one. > > These are simple changes, involving editing a few configuration > parameters, but because there are so many different types of gateway in > operation on AMPRNet, how to make these changes cannot be detailed here. > You may find more information regarding your particular configuration > on https://wiki.ampr.org/ or on the 44net(a)hamradio.ucsd.edu discussion > mailing list, which you should join if you are not already a subscriber. > > Best wishes and 73, > - Brian > .

4 3

ampr-ripd 2.1 released
by Marius Petrescu 29 May '17

29 May '17

Hello everyone, I released a new version of ampr-ripd (2.1) with fixes and additions. Changelog: - Fixed a segfault when using the -F option - Added the possibility to use interface names for the -g option - Interface used for raw RIP forwarding restarts on interface error Download: http://www.yo2loj.ro/hamprojects/ampr-ripd-2.1.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.1.tgz Have fun, Marius, YO2LOJ

4 7

Latency in various protocoles
by R P 28 May '17

28 May '17

Im experimenting two net cameras on the AMPRNET One is http streaming the other is RTSP streaming The http uses tcp port 80 the rtsp uses udp (dont remember the port now ) The http replace photo every 250 MS (i assume after it get ACK and then send the next image) ( i see about 4 frames per second) and make a traffic of about 1000 kbit/sec the RTSP send photos in about 10 frames per second and produce traffic of about 500-800 Kbit sec all this over the amprNet May someone explain this ? how come that the RTSP photo is like movie and the http is 4 frames per second (of course that if i view the http camera direct on the net i see the 10 frames per second i set the camera for) And why i tell you all of this ? Because i wonder how a DMR repeater connection will work on the amprNet ... If i can see in RTSP video without problems or frame loss should a VOIP (or more exact) data stream of the DMR work ? after all it is less data .... Is there anyone that can light my eyes on the subject ? Regards Ronen - 4Z4ZQ

2 3

unreachable gateways and hosts
by Brian Kantor 28 May '17

28 May '17

I'm experimenting with a new technique in the routing daemon on amprgw: if during a send to a gateway, the router gets certain ICMP UNREACHABLE packets from the gateway it's sending to, it drops the host or gateway from the routing table for a time. This has the effect that if a gateway tells us that they don't want packets from us by means of sending us a HOST or NET unreachable ICMP response, we'll stop sending to them for a while. Specifically, PORT UNREACHABLE is ignored. We don't route based on ports. Any of the various HOST UNREACHABLE packets will defer just the one destination host that was being sent to from the routing table; any of the NET UNREACHABLE or PROTOCOL UNREACHABLE packets will defer the subnet from the routing table. The deferral period is currently set to 15 minutes. Watching this happen, one can observe that every 15 minutes, there are a number of hosts and a subnet or two deferred out of the table as packets are sent to them and rejected by the gateways. The number added to the deferral list drops in rate as time goes on. When a gateway changes its address, it is immediately removed from the deferral list. As with the ICMP response suppressing sending RIP transmissions, the purpose of this is to not bombard gateways with packets they don't want and aren't going to deliver anywhere. This is especially important with the number of dynamic gateways we have, where a change in the gateway address may wind up sending IPIP packets to an innocent host that has inherited the gateway's old address. Packets to unreachable destinations are dropped; we don't send UNREACHABLES ourselves. (With all the backscatter and probes, we'd be sending a LOT of them.) We're trying to be good net neighbors. - Brian This is what the log entries look like: May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.104 deferred May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.236 deferred May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.4 deferred May 28 03:54:37 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 97.84.0.85: subnet 44.102.132.0/24 deferred May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.153 deferred May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.210 deferred May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.210 deferred May 28 03:54:42 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 40.143.112.188: subnet 44.88.8.32/28 deferred May 28 03:54:43 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 216.161.250.190: host 44.22.128.10 deferred May 28 03:54:44 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.102 deferred May 28 03:54:45 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 78.226.112.146: host 44.151.67.67 deferred

4 8

icmp redirects to the new router
by Brian Kantor 28 May '17

28 May '17

On Fri, May 26, 2017 at 04:04:24PM -0700, David Ranch wrote: > Hey Brian, > What about configuring an ICMP direct on the old IP to point to the new IP? > --David > KI6ZHD Well, after thinking about it a bit and reading the relevant RFCs, I thought I'd give it a try and wrote some code in the router daemon to do this. Unfortunately, the FreeBSD kernel prohibits a user-space process from sending ICMP Redirects - you get 'Permission denied' errors when you attempt to write one to the outgoing ICMP socket. Too bad, it would have been an interesting experiment. Maybe there's some way to fiddle the routing table so that the kernel itself sends them. I'll look into it, but a quick peek into the kernel source suggests it's not doable. - Brian

2 2

ampr-ripd test version 2.1
by Gustavo Ponza 28 May '17

28 May '17

After Marius continued efforts [TNX] see the results of the new feature *raw AMPR-RIPD forwarding* at: http://44.134.32.240/www/tun0.html ampr-ripd traffic slowed down from 5.3 kb/s to 1.6 kb/s maintaining/obtaining the same effect. The blue peaks (outgoing traffic) denote the various kinda attacks on the structure. -- 73 and ciao, gus i0ojj A proud member of linux team Non multa, sed multum

2 1

ampr-ripd-1.16.3 and saving routes?
by Steve L 28 May '17

28 May '17

Has anyone else had an issue where even though you use the -s option, you don't have a /var/lib/ampr-ripd/encap.txt file? I know this was working for me in prior versions.

3 2

How to modify the mikrotik scripts to work in current "dual gateway" setup
by Marius Petrescu 27 May '17

27 May '17

Hi guys, I tried to set up my router so match the current situation, so here are the steps to get it working: 1. add a filter to Routing->prefix lists to drop 44.128.0.0/16, prefix length 16-32, similar to the one for 44.0.0.1 (IMPORTANT - the dynamic created ampr-169.228.34.84 would interfere with our tunnel base interface , having the same IP endpoint and taking precedence over it being newer) For the RIP protocol, you should now have drops on 44.0.0.1 pref len 32, 44.128.0.0 pref. len 16-32 and your local subnets (if any are there), accept the rest. 2. Change your endpoint in the current ucsd-gw interface from 169.228.66.251 to 169.228.34.84 3. Delete the interface ampr-169.228.34.84 in Interfaces 4. Delete the now invalid route to 44.128.0.0 in IP->Routes Wait a while for the first RIP update. Mesh access should work fully now and you should see RIP updates in Routing->RIP->Routes If you need access from internet to your 44net hosts, these are the additional steps: 3. Add a new IPIP interface, lets say 'ucsd-gw-old' with endpoint 169.228.66.251 (like the old one) 4. Add an unused 44 local ip other than your gateway IP witm mask /32 to the 'ucsd-gw-old' interface in IP->Addresses 5. Add similar connection marks as the ones for ucsd-gw for uscd-gw-old under IP->filter->mangle 6. Check your firewall filters to allow incoming connections from ucsd-gw-old like tho ones from ucsd-gw (input and forward) These latter changes will be removed after full switch to the new gateway. Marius, YO2LOJ

2 3

Good News! and some changes coming
by Brian Kantor 27 May '17

27 May '17

Good News! Our friends in the CAIDA research group at UCSD have come up with a new machine for amprgw, quite a bit newer than the existing one, and with faster CPU, more cores, and more memory. It also has RAIDed disk and dual power supplies, although unlike the current amprgw, it won't be on a UPS. (There isn't a UPS in the new building where the new machine is located. Luckily our power is pretty reliable; besides buying utility power, UCSD also generates its own from solar and natural gas sources. And we don't have lightning storms very often here in the almost-desert.) There will be some minor differences between the machines, of course, although small enough that I hope to move all the services over from the old machine to the new one over the next several weeks. The primary difference is that the gateway will have a NEW ADDRESS and a slighly DIFFERENT NAME. Instead of being known as 'AMPRGW.SYSNET.UCSD.EDU' as the current one on address 169.228.66.251 is known, the new machine will be 'AMPRGW.UCSD.EDU' (no 'sysnet' in the name), and will be on address 169.228.34.84. You should probably adjust your firewalls soon, letting both machines in for a while, as they will both be operating at the same time as services are moved from old to new. Do not move your tunnel endpoints to the new machine quite yet; that won't work until the routing software is installed and reconfigured for the new address. I'll let you know what it's ready for that. - Brian

8 27

documentation of gateway move
by Michael Fox - N6MEF 27 May '17

27 May '17

I can find where the new amprgw info is documented. Shouldn't the old/new hostname, external IP address and cut-over date appear prominently somewhere? Michael N6MEF

3 4

Re: [44net] Good News! and some changes coming
by Rob Janssen 27 May '17

27 May '17

> Yes, it's on the same box, but because the two boxes are on physically > different networks, I can configure them both to be 44.0.0.1 without > conflict. One of them won't get any packets except those originating > on its own physical network, but they won't conflict. That's what I've > done; when the 44/8 route next hop is moved from old amprgw to new amprgw, > which machine serves 44.0.0.1 to the outside will automatically change. I think when you announce 44.0.0.1 with the new gw address on the gateways list (encap, RIP) and keep the 44.0.0.0/8 BGP pointed to the old box, users with a tunnel will connect to the new box and those connecting from internet will get the old box, without any conflict or need to re-route things inside the campus network. That makes it possible to test tunnels two-way. But it is not that important, it will probably work right away and obvious mistakes will be found and fixed within one or some days, which is good enough. I have been doing quite some rebuilding lately, short downtimes sometimes are unavoidable when working within hobby constraints. Rob

1 0

Re: [44net] documentation of gateway move
by Michael Fox 26 May '17

26 May '17

Yes, thanks.M Sent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: Brian Kantor <Brian(a)UCSD.Edu> Date: 5/26/17 18:31 (GMT-08:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] documentation of gateway move (Please trim inclusions from previous messages) _______________________________________________ I assume you meant "can't". Updates to the wiki are in progress. I think there ought to be an 'amprgw' page on the wiki, but there isn't one yet. I'll try to get to writing one soon. - Brian old address: 169.228.66.251 old hostname: amprgw.sysnet.ucsd.edu New address: 169.228.34.84 New hostname: AMPRGW.UCSD.EDU Cutover date: TBD On Fri, May 26, 2017 at 06:20:34PM -0700, Michael Fox - N6MEF wrote: > I can find where the new amprgw info is documented. > Shouldn't the old/new hostname, external IP address and cut-over date appear > prominently somewhere? > Michael > N6MEF _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] Good News! and some changes coming
by Rob Janssen 26 May '17

26 May '17

> I've already tested the 44.0.0.1 address using loopback and it > works ok, and I've tested inbound using 44.128.0.1, and it > works ok too. I think things will be ok. > I don't like to bother the campus networking people more than I have to. Ah, I thought that 44.0.0.1 was running on the same machine as amprgw and would be moved as well... so that ciould be done before. Apparently it is a different box. Rob

2 1

Re: [44net] Good News! and some changes coming
by Rob Janssen 26 May '17

26 May '17

> Don't most hosts and routers ignore ICMP Redirects > out of security concerns these days? Certainly for such external addresses. Locally on the LAN it usually works. (e.g. when you have two routers and one sends redirects to the address of the other, both in the local subnet) Rob

1 0

Re: [44net] ampr-ripd 2.0 released Marius Petrescu marius at yo2loj.ro
by Rob Janssen 26 May '17

26 May '17

> - brought back option -r, to allow using multicast sockets by default > and raw sockets as a backup for systems with multicast issues. This will > hopefully sort out the firewall filtering inability on previous releases > since 1.13. I had to put back the -r option that I had cleaned up from my start script as it still does not work with the multicast socked on Debian Linux with kernel 3.16. I remember it failed after some kernel update and it apparenty is still broken. However, I do not mind using the -r option, only want to remind people that they may need to put it back. Rob

4 22

Re: [44net] Good News! and some changes coming
by Rob Janssen 26 May '17

26 May '17

We do not send outgoing traffic via amprgw so no change is necessary, but I updated the address on our info page (that says "use our address instead of 169.228.66.251 as your default gw"). It would probably be a good idea to change the route for 44.0.0.1 before the incoming routes are switched over, so it can be tested from the inside. Rob

2 1

Warning - Bad Startampr/Linux Scripts on Internet
by lleachii＠aol.com 26 May '17

26 May '17

All, It's my understanding that there are multiple copies of the original Startampr script on the Internet. What I have not noticed until alerted by two operators that attempted to implement those copies in their devices, are the following: - Scripts NOT distributed from my site at http://44.60.44.10 ON AMPRNET include the misuse of the -a argument to run the RIP44 daemon(s). - The syntax used on the Internet scripts ('use -a argument to remove your allocation from the table' by a. specifying WAN IP IN rip44d; vs b. specifying 44 allocation CIDR IP as in ampr-ripd, are reversed. - This appears to be a documentation bug made by a copier who used my original scripts (made for rip44d) and converted them to work for ampr-ripd. - if you use my scripts placing lookups for your local 44 LAN in the main table, this issue wouldn't affect you 73, -Lynwood KB3VWG

1 1

Re: [44net] ampr-ripd 2.0 released Marius Petrescu marius at yo2loj.ro
by Rob Janssen 26 May '17

26 May '17

> >/Everyone is free to use the -g option if needed /> Yes, but is eth0.2 a valid entry? The parameter of -g is an IP address. It it not the IP address of an interface but of the gateway to the internet. So specifying an interface like eth0.2 does not make sense. You could use something like this: .... -g `ip route list | grep '^default' | sed -e 's/.*via //' -e 's/ .*//'` Rob

2 1

Re: [44net] non-operational gateways
by Rob Janssen 26 May '17

26 May '17

> Thinking about this, I recall that I run an IPv6 tunnel with Hurricane > Electric in the same manner. They require that I allow ICMP - Echo > Request to the border. The tunnel doesn't come online at their end, > until they receive an Echo Reply from the IP I specified (either > statically or with DDNS). > Just a rule used by one ISP. I think it is not required to allow pings to the outside address, and it may be difficult for some people to fulfill that requirement (as it may be part of the setup of their ISP router to disallow these). Instead, I would like to see that pings to at least one of the gatewayed addresses are allowed (a net-44 address inside one of the subnet(s) routed to that gateway). This is also much more indicative of a functioning gateway. In the IPv6 tunnel example that would mean allowing ping to one IPv6 address. Of course our problem is that we never asked the gateway operators for the address of their gateway on net-44. So that would have to be added in the form, the database and the encap file (or some other file). Rob

1 0

Wiki Content - How many tunnels?
by lleachii＠aol.com 25 May '17

25 May '17

All, It's my understanding that the operating systems we work with only need 1 tunnel, or one system declaration for it. Except those OSes listed under "Non-RIP44 Workarounds", does anyone else run an OS not on the list - that requires you to create more than one (1) tunnel, specify a remote IP other than "Any", or create a route for it before you receive traffic? All I have to do is tell tunl0 to be UP and I'll receive ANYTHING. OPs using other operating systems seem to have configuration differences (maybe that's why they don't understand security concerns). I'm not sure if there's a configuration difference in the Kernels, or what...? 73, - Lynwood KB3VWG

2 1

brave volunteer needed
by Brian Kantor 25 May '17

25 May '17

It looks to me like the new amprgw is working. I'd like to ask for a brave volunteer who is willing to try changing his outgoing route from old amprgw (169.228.66.251) to new amprgw (169.228.34.84) to see if he's able to make connection with the outside world. The return path will still be via old amprgw as we haven't changed the nexthop for 44.0.0.0/8 from oldamprgw to new. If someone would try this and let me know if it worked I'd very much appreciate it. - Brian

2 17

non-operational gateways
by Tom C 25 May '17

25 May '17

In just the past couple of days I got my gateway working. I have a CS degree, test software for a living and considered myself proficient on linux but found getting the gateway to work correctly difficult due to contradictions in documentation and examples. With KB3VWG's help I was able to get it working. I'll just say it was a little difficult to get it going, mostly due to understanding how it all works together. I'm using ubuntu linux as a gateway. On the subject of non-operational gateways I would consider attempting to send RIP broadcasts to them at a reduced rate instead of deleting them. In my case I'm on a dynamic address. It doesn't change often, longest I've had an address was about 5 months. It's most apt to change if I restart. I registered my gateway in January... it was down all of Jan and Feb. It's been intermittent but mostly down since until Monday evening of this week. Had my gateway been deleted or removed from the list I'd now be offline rather than online. Lynwood was a great help with understanding policy routing rules and I'd like to publically thank him here. He's patient and points things out that don't work. I plan to document my journey so others who wish to join the network can learn from my mistakes. I'm a firm believer in understanding how it works. --tom /n2xu -- 73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified

6 5

netflow
by Brian Kantor 25 May '17

25 May '17

I'm now gathering netflow-like statistics from the router daemon. It's a lot of data. I've been unable to find a clear definition of the standard (v1 or v5) netflow disk file format, so I don't have input suitable for any of the good analysis tools. Does anyone have such a description? And what are your favourite analysis tools? - Brian

6 20

Re: [44net] Traffic not routing to my gateway
by Rob Janssen 25 May '17

25 May '17

> IPIP is possible on the SRX but not in cluster (virtual chassis mode) Being able to setup a single or even multiple IPIP tunnels is not suffcient to be a member of the AMPRnet IPIP mesh. See what Brian wrote: > This is a mesh network, not a star, so there is no default route; you > need a separate tunnel route to each gateway you want to communicate with, Marius has written a very nice script to get it working on a MikroTik router, but most other commercial routers lack the scripting capabilities to pull this off on their own. Someone wrote a script to use a Cisco router but it requires a separate machine to run it. Rob

5 9

Re: [44net] non-operational gateways
by Rob Janssen 24 May '17

24 May '17

> I've added code to the rip sender that watches for ICMP unreachable > packets coming back to amprgw during the rip sending cycle, which repeats > every 5 minutes. Make sure you act only on ICMP unreachables that refer to the protocol 4, not to the port 520! When protocol 4 is unreachable, it sure means the gateway is not operational, as it rejects operational traffic. When it rejects port 520, it could be that it is not using RIP to update its tables (it could be downloading encap files!) or even that it *is* using RIP but via raw sockets (ampr-ripd -r) and has a firewall that rejects the packets. ampr-ripd would still see and process them! That condition could be flagged in yet another status report, but it should not be a base to declare the gateway inactive. Also, we recently have seen some postings that indicate that some people operate a gateway that has tunnels to all other gateways, but explicitly have excluded a tunnel to amprgw. Because that brings mostly internet traffic and they don't want to have that. Of course another (not exclusively deciding) check on gateway activity could be to check if you actually receive any tunneled packets from them. I do have that as a byproduct of having an access list that accepts protocol 4 traffic only from addresses of registered gateways. At the moment it shows traffic from 34 different gateways (including amprgw). Of course, when the external address of a gateway changes, its history is lost. Rob

6 14

Re: [44net] non-operational gateways
by Rob Janssen 24 May '17

24 May '17

> Sorry to ask but what has accepting RIP to do with the gateway IP? > RIP is encapsulated into IPIP, so no firewall will ever care about that. > And no sane firewall setup will accept RIP on its WAN. > From both the gateway's point of view it's just protocol 4, nothing else. What I mentioned in my earlier post is that a "protocol unreachable" (for protocol 4 packets) is a serious condition although it could still be valid when encountered by amprgw and not by the other gatways. A "port unreachable" for UDP port 520 indeed is not an error condition. The gateway may not be using RIP. Or, the firewall may have been configured to reject port 520 traffic while ampr-ripd -r is still processing it. (not likely because the RIP traffic is multicast so would not normally be replied to by the firewall) To do some better "gateway alive" testing I think some extra steps are required: 1. a mandatory field has to be added to a gateway registration entry, with an IP address inside the routed subnets that is pingable. (of course getting everyone to enter this data will be difficult) 2. a separate "monitoring station" has to be setup that acts as a gateway and pings that address regularly (but not overly often) and keeps stats on the returned pings. The monitoring station has to be separate from amprgw because some people choose not to tunnel to amprgw. Alternatively, a checkbox could be added to gateway registrations to specify if the gateway wants to receive internet traffic (to be handled by the amprgw firewall table) and it could be made mandatory to tunnel to amprgw. That would probably be preferable, as it would also make 44.0.0.1 reachable for those gateways that do not want to get internet traffic. Adding the fields to the gateway registration system should be straightforward, but of course getting everyone to enter them wouldn't be. Not responding to a request to enter information of course could be treated as an indication that the gateway is no longer active. Rob

3 2

Re: [44net] non-operational gateways
by Rob Janssen 24 May '17

24 May '17

> There is also the question of how this data is to be transferred > from the portal to amprgw. We currently download the same encap > file that any gateway would use. Some new file format would also > be needed. It should be trivial to add another file, gateways.txt, that contains the per-gateway information. Or it could be added as comment lines into the existing encap.txt file. Maybe it would also make some tunnel creation scripts simpler when there is a section with gateway info (one line for each gateway, with a unique ID, the external IP, and info like proposed today: an internal IP and the "accept internet traffic" flag) ahead of the traditional route lines. It would allow the preparation of all required tunnel interfaces in environments where that is required before parsing the subnet routes. Rob

1 0

Reported AX.25 repository 'bug' on OpenWRT/LEDE
by lleachii＠aol.com 24 May '17

24 May '17

All, FYI, I'm not sure if anyone may be interested in setting up a portion of their allocation with an AX.25 ports (I definitely am). I informed the LEDE developers that they provide the kmod-ax25 package and its dependency; but do not provide libax25, ax25-tools and ax25-apps. The bug report can be found here: https://bugs.lede-project.org/index.php?do=details&task_id=802 73, - Lynwood KB3VWG

1 0

non-operational gateways
by Brian Kantor 23 May '17

23 May '17

I got to thinking about Ronen's question as to how to find non-functional gateway, and I've come up with a scheme. I've added code to the rip sender that watches for ICMP unreachable packets coming back to amprgw during the rip sending cycle, which repeats every 5 minutes. If an ICMP unreachable packet is received, the matching gateway is removed from that cycle, so with luck (if the unreachables get here quickly enough) we'll only send one or two packets to a gateway that's not reachable. The time and gateway address are logged; some future process should be able to analyze this log and do something about the gateway if it's out of service long enough. (What it will do about it isn't exactly clear right now.) This doesn't seem to have slowed down the rip sender much if at all. - Brian

2 2

Re: [44net] RIP transmission question
by Rob Janssen 23 May '17

23 May '17

> That's actually a limitation on how multicast works. In usual > circumstances, a router does not listen to multicasts not originating > from the subnet its interface is connected to. Could that be the reason why ampr-ripd multicast mode does not work for me? I always put the local address /32 on the tunnel interface. Maybe it would work when that is changed to /8 ? Rob

5 5

Re: [44net] RIP transmission question
by Rob Janssen 23 May '17

23 May '17

> I'm curious, what Router OS are you using? Debian Wheezy with backport kernel 3.16 Also Raspbian Wheezy with kernel 4.1.19+ Well, it probably is some setting. It has worked before but lately I have not seen any RIP packet in the iptables counters, even though I see them with tshark. Now I just use -r and that works. Not worth to spend effort on. Rob

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net