44net

44net@mailman.ampr.org

3196 discussions

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net