- 44net - mailman.ardc.net

rip sender bug
by Brian Kantor 26 Apr '17

26 Apr '17

I just found and fixed another off-by-one error in the rip sender; this one had the effect of omitting the last route in each sent packet. Packets should hold up to 25 routes; they were being sent one route short at 24. Effectively, 25 subnets were missing from the rip transmissions. Oops. Sorry folks. - Brian

1 0

Revised amprgw firewall rules
by Brian Kantor 25 Apr '17

25 Apr '17

These are the rules that route AMPRNet traffic to and from the ipip daemon (FreeBSD ipfw syntax): # # AMPR routing # # table(1) contains all registered/routable 44net addrs. # table(2) contains all registered gateways. # outbound encapsulated packets # should go only to registered gateways 00100 allow ipencap from me to 'table(2)' # inbound encapsulated packets # should only come from registered gateways 00200 allow ipencap from 'table(2)' to me # filter the 44net input side of things # valid destination addresses go to the router socket: ipipd 00300 divert 4444 ip from any to 'table(1)' in not dst-port 111,135-139,445,1025-1028,1900,2323,5353,7547 # filter the 44net output side of things 00400 allow ip from 'table(1)' to any Explanation: Preliminary filtering of incoming packets is done by the BSD ipfw firewall because it's easy to set up and very fast. Quite a bit more filtering is done by the ipip router daemon. Ipfw table 1 contains a list of the 44-net host addresses from the AMPR.ORG DNS zone file that are routable according to the encap file. Table 2 contains a list of the gateways from the encap file. Once an hour, the AMPR.ORG DNS zone file is fetched, normally at 10 minutes past the hour. Also hourly, the encap file is fetched from the portal, normally at 20 minutes past the hour. Whenever these files differ from their previous version, the ipfw tables are flushed and reloaded. When the encap file changes, the ipipd routing and the rip sender tables are also reloaded. Rule 100 allows the encapped packets out to registered gateways. Rule 200 allows encapped packets in only from registered gateway source addresses. Rule 300 diverts incoming IP to the ipipd encapsulating router if the destination address is for a registered/routed address and not for certain destination ports. Rule 400 allows outgoing IP with source addresses from registered/routed hosts. That's about all the filtering that can be done without looking inside the encapped packets, which the BSD firewall can't do. The ipipd daemon handles that, and is much stricter. - Brian

3 6

Mikrotik router corrections
by Marius Petrescu 25 Apr '17

25 Apr '17

Hello, Since the appearance of the 44.0.0.1 route in RIP, some of you using the Mikrotik script may have noticed the disappearance of the RIP broadcasts and missing updates. This happens because of the creation of a alternative tunnel from your router to ampr-gw (ampr-169.228.66.251), which highjacks the normal ampr-gw tunnel. To correct this, follow the following steps: 1. under routing->prefix list create the following rules in the given order: chain ampr, prefix 44.0.0.1, prefix length 32 discard chain ampr, prefix 44.0.0.0/8, prefix length 8-32 accept chain ampr, prefix 0.0.0.0/0, prefix length 0-32 discard 2. under routing->rip->interfaces on your ucsd-gw set the 'ampr' prefix list as 'In Prefix List' 3. under interfaces find and delete interface ampr-169.228.66.251 4. under ip->routes find and delete the route to 44.0.0.1 via unknown 5. Optional: if you like to have 44.0.0.1 routed via tunnel, add a static route for 44.0.0.1 via interface ampr-gw. Marius, YO2LOJ

3 5

Re: [44net] more gateway router follies
by Rob Janssen 25 Apr '17

25 Apr '17

> Belows IP's belong to SR3BBS gateway > which _IS OFF LINE_ for a long time! Then why is it in the table? Maybe it should again be considered to add a mandatory field to a gateway registration with a net-44 IP that should be pingable via the tunnel (e.g. the IP of the gateway itself) and run some very infrequent ping to that address from a monitoring system that is also on the tunnel network (not amprgw as some people apparently choose not to tunnel to that system). When e.g. one ping per hour is made and nothing is heard for 7 days or even more, the gateway can be marked down and removed from the encap.txt and RIP broadcast. The operator can then re-enable it via the portal. Rob

3 2

Clarifications on the working of ampr-ripd and amprd for BGP announced gateways
by Marius Petrescu 25 Apr '17

25 Apr '17

Hi everybody, Just to clarify the issues related to "strange routes" appearing during the use of the rip daemons. Together with Jann, DG8NGN, we devised a solution for interoperating BGP announced 44 subnets with the current full mesh tunnel system. Initially I implemented the system for testing and proof of concept in the Mikrotik script v.3.0, and later in the ampr-ripd starting with version 1.16 and amprd version 1.5. Current versions are 1.16.3 for ampr-ripd (bug fixes and small enhancements) and 1.6 (bug fixes), please use these. Now to the idea behind it... Directly BGP announced gateways need to be reached, well, directly, as any other gateway. If we have a default route by which we could reach the BGP announced hosts (via your public IP, please don't use default routes via amprgw!), on installing a subnet route via the RIP daemon, e.g. 44.130.121.0/24 (it is a working test host) then the endpint 44.130.121.2 will also be routed via the tunnel, creating a loop, which is of course wrong. So ampr-ripd will detect your default gateway on the system, and set host routes for those direct gateways via the default gateway, if the RIP announced gateway has a 44 address. The detection of the default gateway is done by getting the route to 8.8.8.8 from your kernel tables. So you will end up with 2 routes for that entry, like: 44.130.121.0/24 via 44.130.121.2 dev tunl0 proto 44 onlink 44.130.121.2 via 192.168.1.1 dev eth0 proto 44 onlink. In this case, traffic for those subnets (in this case to 44.130.121.0/24) will be encapsulated and sent directly to 44.130.121.2, which is reachable via internet. It is expected that your system will nat those destinations to your public IP (which probably happens). If the detection of your default gateway is not correct, there is a parameter '-g' by which you can set your gateway IP by hand. Your internal addresses are not published, nor are the known to the gateway. It is a local lookup performed by the daemons. At the moment there are 4 functional gateways using this setup: 44.130.121.2, 44.130.122.2, 44.130.124.2 (as test systems) and 44.131.14.255 as a live setup. Reachable tests hosts are: 44.130.121.3, 44.130.121.130, 44.130.122.3, 44.130.122.130, 44.130.124.3, 44.130.124.130, and of course the end points. (44.130.121.2 runs amprd, 44.130.122.2 runs ampr-ripd and 44.130.124.2 runs the Mikrotik script). I hope this clarifies some of the questions that may arise. Have fun with the hobby, Marius, YO2LOJ

2 1

more gateway router follies
by Brian Kantor 25 Apr '17

25 Apr '17

amprgw has recently logged several discarded packets like the following: Apr 24 18:44:03 <local0.info> amprgw ipipd[1518]: IBCAST: len 149, os 208.110.114.235, od 169.228.66.251, is 44.135.193.18, id 255.255.255.255, ttl 64, proto 17 encapped packets aren't supposed to send to the broadcast address (255.255.255.255). Apr 24 18:44:05 <local0.info> amprgw ipipd[1518]: ISRC0: len 122, os 77.138.34.39, od 169.228.66.251, is 0.0.0.0, id 255.255.255.255, ttl 64, proto 17 encapped packets aren't supposed to come from address 0.0.0.0 and encapped packets aren't supposed to send to the broadcast address (255.255.255.255). Apr 24 18:44:06 <local0.info> amprgw ipipd[1518]: TIMXCEED: len 52, os 85.234.252.133, od 169.228.66.251, is 44.165.53.254, id 224.0.0.9, ttl 1, proto 17 Looks like a routing loop on RIP packets. Ah well, variety is the spice of life... - Brian

2 2

Re: [44net] rip sender change
by Rob Janssen 25 Apr '17

25 Apr '17

> Yes, it was intentionally dropped by the daemons. If it will be > reachable, I will update the code accordingly. I see it in the code now, just a couple of lines that can be deleted around line 1346: /* drop 44.0.0.1 */ if (rip->address == inet_addr("44.0.0.1")) { #ifdef HAVE_DEBUG if (debug && verbose) fprintf(stderr, " - rejected\n"); #endif return; } A temporary workaround until everyone has again updated ampr-ripd could be to announce 44.0.0.0/30 instead of 44.0.0.1/32 in the RIP sender. Rob

1 0

Re: [44net] rip sender change
by Rob Janssen 25 Apr '17

25 Apr '17

> ampr-ripd does not set a route for 44.0.0.1, because that IP is not > reachable via the tunnel, only via the internet. Ah, it is treated as a special case? Brian has been working on that problem and now this route is announced again. (it had been deleted from the RIP broadcast before) I think it is added in the RIP sender, maybe it would be better to just register a portal entry so it is in encap.txt as well. Rob

2 1

Re: [44net] more gateway router follies
by Rob Janssen 25 Apr '17

25 Apr '17

What you logged there are probably DHCP packets and private use of RIP, not the AMPR-RIP. Well, I do see a lot of those things here either... Recently I again worked on the filters and found e.g.: - router-sourced traffic with inner source address equal to the external IP (bad source address selection) - router sending some of the traffic outside of the tunnel (net-44 to net-44 traffic unencapsulated) the funny thing is that e.g. when pinging them it returns via the tunnel but when doing BGP the SYN ACKs from port 179 come outside the tunnel. when the sender had proper source address filtering at their ISP I would not see those packets at all. - of course still a lot of traffic with inner source address in RFC1918 range The first two above are blamed on "MikroTik VRF". I never use it, I always use a manual implementation using multiple routing tables, ip routing rules and maybe some mangle rules just as I am used to do on bare Linux, and I don't have those problems. Another group swears by VRF and they always have issues. As I believe MikroTik VRF is just an an automatic configuration of the mentioned features and it apparently does not work completely OK (and may need some help e.g. some extra mangle rule). I tried to get information on what really happens when you define a VRF, but I was unable to get answers. Rob

1 0

Re: [44net] rip sender change
by Rob Janssen 25 Apr '17

25 Apr '17

> Yes, there was an off-by-one error in the count of entries in > the last packet. This error was not present when we were sending > in gateway major order, but was there in packet-major-order which > change I made early today. It has been corrected. Please check > the next RIP update and see if that fixes things. Ok, now I get the correct RIP packet :-) But the entry still does not appear in the route table... :-( IP Address: 44.2.2.0, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.2.2.0 (44.2.2.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 24.52.189.1 (24.52.189.1) Metric: 1 IP Address: 44.0.0.1, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.0.0.1 (44.0.0.1) Netmask: 255.255.255.255 (255.255.255.255) Next Hop: 169.228.66.251 (169.228.66.251) Metric: 1 44.0.0.0/8 via 213.222.29.193 dev eth0 src 44.137.0.1 44.2.2.0/24 via 24.52.189.1 dev tunl0 proto ampr-ripd metric 4 onlink So now I can continue local debugging to see what is going wrong... It fails both on the gateway (running latest ampr-ripd) and the Raspberry Pi (running earlier version). It does not appear in /var/lib/ampr-ripd/encap.txt either. Never assume there is only one bug... Rob

2 1

Re: [44net] rip sender change
by Rob Janssen 24 Apr '17

24 Apr '17

> Yes, that's very much a mystery, because my tcpdump shows the route > being sent right after the one for 44.2.2.0/24. > [...] > AFI IPv4, 44.2.2.0/24, tag 0x0004, metric: 1, next-hop: 24.52.189.1 > AFI IPv4, 44.0.0.1/32, tag 0x0004, metric: 1, next-hop: 169.228.66.251 Could there be some length or count field that is off by one? I am tracing with wireshark (tshark). But ampr-ripd does not pick it up either. Rob

3 4

Re: [44net] rip sender change
by Rob Janssen 24 Apr '17

24 Apr '17

> Because of concern that the rip sender might be sending > the pseudo-RIP packets to gateways faster than they can > receive them, I have changed the sending order. > ... > This has the effect of inserting a few milliseconds delay > between consecutive packets being sent to any one gateway, > which should give the receiving process more time to handle > the transmission. My main concern was not the receiving process, but the routers in front of the gateway system that (in my case) appeared to drop the tail end of the transmission, probably because of rate limiting or a queue overflow. Now, I get the 26 packets in about 150ms, which should solve that problem for anything but the slowest connections. Thanks! Unfortunately there is still no 44.0.0.1 route. I did a trace and confirm that the last packet received has the lowest addresses, but it ends with: IP Address: 44.2.7.0, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.2.7.0 (44.2.7.0) Netmask: 255.255.255.252 (255.255.255.252) Next Hop: 73.185.12.233 (73.185.12.233) Metric: 1 IP Address: 44.2.2.0, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.2.2.0 (44.2.2.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 24.52.189.1 (24.52.189.1) Metric: 1 Still some mystery somewhere :-) Rob

2 1

rip sender change
by Brian Kantor 24 Apr '17

24 Apr '17

Because of concern that the rip sender might be sending the pseudo-RIP packets to gateways faster than they can receive them, I have changed the sending order. There are currently 26 packets per gateway per transmission. Instead of sending all packets to a gateway, then sending them to the next gateway, and so on, now each packet is sent to each individual gateway before the next packet is generated and sent. This has the effect of inserting a few milliseconds delay between consecutive packets being sent to any one gateway, which should give the receiving process more time to handle the transmission. The same total data is sent, so nobody should miss out on any routes. Thanks to Rob, PE1CHL for suggesting this technique. - Brian

1 0

Re: [44net] Enabling traffic from inet to 44-net and vice versa
by Rob Janssen 23 Apr '17

23 Apr '17

> My understanding is that it's working correctly, because the icmp reply > is sent back to 2.238.198.249 inside the tunnel and towards the > amprnet router (169.228.66.251). > Unfortunately there's something wrong in the middle because no packets > are actually reaching 2.238.198.249 It must be something in your 2.238.198.249 system or the path to it, because I can ping 44.134.160.1 without problem from other internet hosts. Rob

5 8

Open Source IP Address Management tool
by Bill Vodall 23 Apr '17

23 Apr '17

I don't remember seeing PHPIPAM mentioned here before. (And I searched...) https://phpipam.net/ Perhaps it would be useful - if not for the overall process for local or regional LANS. 73 Bill, WA7NWP

1 0

UDP PORT 5060 ?
by R P 23 Apr '17

23 Apr '17

I think I have asked it before but i see on the log a lot of incoming UDP port 5060 to all the hosts (even that are not active currently but defined in the AMPR dns and therefore have routing to my gateway ) from all over the world What is it ? who have interest to look for SIP on my system ? Is there a way to cut and paste part of the log of Mikrotik router ? i can not do it when i enter it from the web interface so could not copy the relevant log part Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

4 3

misconfigured encap routers?
by Brian Kantor 22 Apr '17

22 Apr '17

I've been analyzing some of the encap traffic and finding unexpected things. Several sources of ipencap'd packets being received by amprgw have non-44 inner source addresses. Would you all agree that a protocol-4 (ipencap) packet reaching the UCSD gateway should always have an inner (encap'd) source address on the 44-net? And that those that don't should be considered bogus and be discarded? - Brian

15 34

Re: [44net] Enabling traffic from inet to 44-net and vice versa
by Rob Janssen 21 Apr '17

21 Apr '17

> anybody knows how to filter this traffic with IPTables ? > It would be very helpful. Where is that traffic originated? Is that the address of your own system? If so, it can help to set a preferred source address on your routes towards amprgw. (add src 44.134.x.y to the route command) Rob

1 0

Enabling traffic from inet to 44-net and vice versa
by Marco Di Martino 21 Apr '17

21 Apr '17

Hi all, I'm checking my configuration at the gateway ampr-italy-gw.ampr.org due to an issue on routing. This gateway is the main one in the Country and manages several subnets interconnected via VPN (OpenVPN). The ampr-italy-gw.ampr.org is the point of contact with the AmprNet and it's handling the IPIP tunnel. I would like to permit traffic from inet to 44-net and vice versa and, of course, only for specific 44-net hosts that have the corresponding entry in the Ampr.org DNS. Well, it doesn't work :) Here is how the ampr-italy-gw.ampr.org router manages the traffic between inet and 44-net: ip rule add from 44.0.0.0/8 table 44 prio 200 GW_ADDR="169.228.66.251" # /sbin/ip route add 128.0.0.0/1 via $GW_ADDR dev tunl0 onlink table 44 #128-255 /sbin/ip route add 64.0.0.0/2 via $GW_ADDR dev tunl0 onlink table 44 #64-127 /sbin/ip route add 0.0.0.0/3 via $GW_ADDR dev tunl0 onlink table 44 #0-31 /sbin/ip route add 48.0.0.0/4 via $GW_ADDR dev tunl0 onlink table 44 #48-63 /sbin/ip route add 32.0.0.0/5 via $GW_ADDR dev tunl0 onlink table 44 #32-39 /sbin/ip route add 40.0.0.0/6 via $GW_ADDR dev tunl0 onlink table 44 #40-43 /sbin/ip route add 46.0.0.0/7 via $GW_ADDR dev tunl0 onlink table 44 #46-47 /sbin/ip route add 45.0.0.0/8 via $GW_ADDR dev tunl0 onlink table 44 #45 -- [root@ks28006 ~]# ip rule list 0: from all lookup 255 200: from 44.0.0.0/8 lookup 44 32766: from all lookup main 32767: from all lookup default The table 44 has a higher priority than the main table where the routes for each gateway are contained (basically what comes from the encap.txt). It should mean that when a 44-net hosts wants to reach an inet host, it happens through the amprnet router at UCSD.edu and not directly via the eth0 interface. Now, if I send ICMP packets from 2.238.198.249 to 44.134.160.1, the following is what I see with tcpdump at the ampr-italy-gw.ampr.org: eth0 (tcpdump -n -i eth0 proto 4) 21:36:36.915644 IP 169.228.66.251 > 91.121.90.186: IP 2.238.198.249 > 44.134.160.1: ICMP echo request, id 1, seq 51, length 40 (ipip-proto-4) 21:36:36.937888 IP 91.121.90.186 > 169.228.66.251: IP 44.134.160.1 > 2.238.198.249: ICMP echo reply, id 1, seq 51, length 40 (ipip-proto-4) tunl0 (tcpdump -i tunl0 host 44.134.160.1) 21:36:36.915664 IP 2-238-198-249.ip245.fastwebnet.it > iw2ohx.ampr.org: ICMP echo request, id 1, seq 51, length 40 21:36:36.937872 IP iw2ohx.ampr.org > 2-238-198-249.ip245.fastwebnet.it: ICMP echo reply, id 1, seq 51, length 40 My understanding is that it's working correctly, because the icmp reply is sent back to 2.238.198.249 inside the tunnel and towards the amprnet router (169.228.66.251). Unfortunately there's something wrong in the middle because no packets are actually reaching 2.238.198.249 C:\Users\marco>ping iw2ohx.ampr.org Pinging iw2ohx.ampr.org [44.134.160.1] with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 44.134.160.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Any ideas ? Thanks for the help Marco iw2ohx

1 0

Re: [44net] misconfigured encap routers?
by Rob Janssen 21 Apr '17

21 Apr '17

> For me, most all of the bad stuff is coming in via the spoofed ampr gateway address of 169.228.66.251 When you see internet traffic as bad stuff, you will receive a lot of it from that address, but most of it will not be spoofed. It is traffic from internet to your AMPRnet address(es) that is being relayed, the intended purpose of amprgw. Maybe there should be a separate filter for incoming traffic via the gateway. We have that on our gateway: a local AMPRnet user can indicate if they want to receive incoming connects from internet and they are placed in a bitmap ipset similar to the bitmap created from the DNS hosts. By default they are not in that map, and only replies to outgoing traffic are allowed. Of course this is only possible because we run connection tracking on our gateway, which is probably not done on amprgw. It keeps out a lot of junk. A simple version without connection tracking could block incoming TCP SYN and maybe some UDP traffic to ports like 53 and 161 and others. That would still mean there has to be some registration capability to turn this on/off per address. DNS is already used to control the strict allow/deny per address, so it cannot be used for this. Rob

1 0

Re: [44net] OpenWRT 15.05 upgrade to LEDE 17.01.1
by Rob Janssen 21 Apr '17

21 Apr '17

> - HTTP: 44.60.44.10 Now I can access your service for the first time. Rob

1 0

Re: [44net] misconfigured encap routers?
by Rob Janssen 21 Apr '17

21 Apr '17

> - make an IP tables rule AFTER (-A [APPEND]) your ALLOW IPENCAP from > AMPRGWS - to DROP IPENCAP > - let us know if you get any firewall hits by checking your running > ipencap list I have done that for a while and I do not see a lot of traffic, but there is some. Part of it is from gateways with dynamic address. When their address changes it takes a while for the update to bubble through DNS, the portal and AMPR-RIP, and during that time the traffic from their new address is dropped. But that does not matter, as return traffic would not arrive there either. A gateway with a daily changing external address is really not workable. Lately there has been a lot more bad GRE traffic. We run GRE tunnels as well, with a similar protection, and the default drop rule has logged quite some traffic the past months. Research indicates that it is related to a hacked video recording system, although it is unclear to me what the purpose or cause of the GRE traffic is. When browsing to the source address of these packets, one gets a logon screen of some Chinese video recording (for surveillance) system. Rob

1 0

Re: [44net] OpenWRT 15.05 upgrade to LEDE 17.01.1
by Rob Janssen 21 Apr '17

21 Apr '17

> Tom and Ruben, > traceroute to 44.165.2.4 (44.165.2.4), 30 hops max, 60 byte packets > 1 kb3vwg-001.ampr.org (44.60.44.1) 1.385 ms 1.392 ms 1.593 ms > 2 mail.sp2l.ampr.org (44.165.2.2) 154.783 ms 171.077 ms 171.653 ms > 3 home.sp2l.ampr.org (44.165.2.4) 171.674 ms 171.668 ms 171.650 ms I cannot ping, connect or traceroute you either. When it works from your side and not from ours, are you sure you have a *working* incoming IPIP protocol forward or DMZ host? It is all too common for stations behind ISP NAT modem/routers to have IPIP tunnels that work only outbound (and replies), not for unsolicited inbound traffic, because they only admit IPIP traffic as replies to their own outging traffic, even when they have set a DMZ host in their router. (which often only works for protocols like ICMP, TCP and UDP) Rob

4 15

Re: [44net] encapsulated ipencap packets
by Rob Janssen 20 Apr '17

20 Apr '17

> Regarding the other thread about which firewall rules to use, the > gateway is a little more complicated but for my home router I > (normally, not last night in case you saw differently) have the > equivalent to: > iptables -t filter -A FORWARD -i tunl0 ! -d 44.131.14.128/26 -j REJECT > iptables -t filter -A FORWARD -o tunl0 ! -s 44.131.14.128/26 -j REJECT > I think this pretty much covers the requirements for a basic end network? For the outgoing side, yes. It would be very helpful when everyone had a filter like that. For the incoming side it is a bit too simple. It covers the case where hackers send packets that you would then forward, but that can also be covered with a iptables -A FORWARD -i tunl0 -o tunl0 -j DROP However, it would still be advisable to: - only accept tunnel traffic from registered gateways (I have shown on the list how to do that a couple of times) - attempt to screen the source address of the tunneled traffic a little (e.g. accept non-44 traffic only from the gateway, as shown earlier today, and even better: to reverse path checking for tunnel traffic, i.e. only accept traffic from each tunnel whose source address matches the subnets registered for that tunnel) > If the main gateway receives an invalid encapsulated packet from a > known gateway or a 44net address, would it be helpful to return an > error instead of dropping it? An ICMP Administratively Denied packet > is more likely to generate an obvious error message than packets going > missing. The gateway would probably need to rate-limit the number of > errors it will send out to prevent abuse, though. This does not bring much, it would only help when someone is actually watching the traffic, and it appears not many people do. When a decapsulating gateway sends an ICMP unreachable packet to the encapsulating gateway, that gateway will not normally attempt to translate it into an ICMP packet related to the inner packet and send that back to the originating system. So the user behind the keyboard will never know. Rob

1 0

encapsulated ipencap packets
by Brian Kantor 20 Apr '17

20 Apr '17

In our tunnels, all traffic from a gateway should be encapsulated and should NOT contain an encapsulated ipencap packet. The ipip router at UCSD logs and discards these; I'm seeing such packets from gateways 77.138.34.39 85.234.252.133 86.161.255.194 185.58.225.84 which suggests that they have a routing misconfiguration. The operators of those gateways should examine their routing and encapsulation rules to see why this is happening. - Brian

2 1

DNS for Belgium (44.144.0.0/16)
by Ruben ON3RVH 20 Apr '17

20 Apr '17

Hey Guys, Does anyone have any contact info for ON4SAX? He should be the maintainer for the Belgium subnets. But I'm not able to mail him through the contact info on qrz.com (on4sax(a)on4sax.be<mailto:on4sax@on4sax.be>) to make DNS changes for my hosts. The domain seems parked and has no MX record as far as I can see. I also saw that the range for Belgium is routed through Wireless Belgium and as such not through ucsd so I am also wondering how I can get incoming traffic from the world (non 44net) to my 44net hosts and outbound from my 44net hosts towards the world. Thanks in advance. 73, Ruben - ON3RVH

2 3

Re: [44net] misconfigured encap routers?
by Rob Janssen 20 Apr '17

20 Apr '17

> iptables -I FORWARD ! -s 44.0.0.0/8 -i tunl0 -j DROP > iptables -I INPUT ! -s 44.0.0.0/8 -i tunl0 -j DROP > "If the source address of packets entering tunl0 doesn't equal AMPRNet, > DROP them." The problem with that is that it will also drop the legitimate internet traffic that is coming in via the gateway. So, when you want connectivity to/from internet, it has to be more complicated than that. You will need to put a rule in the mangle table for protocol 4 traffic arriving from the gateway, and add some packet mark to the packet, then in the above rule you exclude the packets with that mark. Like this: iptables -t mangle -A PREROUTING -p 4 -s 169.228.66.251 -j MARK --set-mark 1 and in the above rules add before the -j: -m mark ! --mark 1 When you are inside a BGP routed subnet that also is on the tunnel mesh (like 44.137.0.0/16) you will have to change the 169.228.66.251 to the address of your local gateway. And of course, now you make yourself vulnerable again for dedicated attacks that spoof the address of the gateway to send tunneled packets. So it remains mandatory to treat the traffic received via the tunnels as hostile from-internet traffic! Rob

1 0

Re: [44net] misconfigured encap routers?
by Rob Janssen 20 Apr '17

20 Apr '17

> What's peculiar about a lot of these non-44 is that they have > the encapsulated (inner) source and destination apparently interchanged: > Apr 19 21:28:27 <local0.debug> amprgw ipipd[66472]: NON44: len 40, > os 91.121.90.186, od 169.228.66.251, is 91.223.133.13, id 44.134.209.15, > ttl 237, proto 6 > Either that or they're encapping in the wrong direction. > I can't offhand think of what would cause THAT. When I see odd addresses on encap links they often are ICMP packets (e.g. TTL exceeded, a result of traceroute) that are sent by encap systems themselves and have the wrong source address. Also, there appears to be some traffic in the noise of Internet that is completely ridiculous. Things like this: Apr 20 10:43:30 Packet DROP: IN=eth0 OUT=gre14 SRC=44.137.49.139 DST=44.137.49.139 LEN=56 TOS=0x00 PREC=0x00 TTL=245 ID=35377 DF PROTO=ICMP TYPE=11 CODE=0 [SRC=44.137.49.139 DST=80.92.136.89 LEN=69 TOS=0x00 PREC=0x00 TTL=1 ID=35377 DF PROTO=UDP SPT=34973 DPT=53 LEN=49 ] Note that 44.137.49.139 is not a registered AMPRnet address so it can never have sent this query, but there is a ICMP TTL exceeded with source and destination being that address about a query it has allegedly sent to 80.92.136.89, an address at some broadband provider that often re-occurs in this (amongst others). It is completely unclear to me whether this is part of some attack on 80.92.136.89, on us, or is due to some bug in a router (that sends ICMP with the wrong source address). W.r.t. tunnel traffic, it sure is a good idea to drop anything not-AMPRnet. I also see a lot of RFC1918 addresses in those packets, and even when I mail the gateway operator about them I usually get a mail back that they are going to do something about it, but that rarely happens (i.e. it just continues). E.g. this repeat offender: Apr 20 07:52:05 Packet DROP: IN=tunl0 OUT=gre3 TUNL=90.63.239.151 SRC=192.168.1.3 DST=44.137.41.178 LEN=52 TOS=0x18 PREC=0xA0 TTL=59 ID=16343 DF PROTO=UDP SPT=50001 DPT=50000 LEN=32 It is unfortunate that setups of a gateway system can vary so widely that it is impossible to give a good firewall example that will work for everyone. My feeling is that many of the gateway operators lack the network knowledge to get the firewall setup correctly, and it would be nice if we could educate them. However, I am not going to be the sysop for even more systems. Some generic help would be a good thing, but it is hard to do. Rob

1 0

Re: [44net] Make Error
by lleachii＠aol.com 20 Apr '17

20 Apr '17

OK, it's my understanding the source and destination ports are undefined. I'll just leave the mesh DOWN at this time, as the cross compiler is configured exactly as before, and I am able to compile other software. Thanks, -Lynwood KB3VWG

6 19

UCSD ipip gateway firewall updated
by Brian Kantor 19 Apr '17

19 Apr '17

I've made a few small changes to the ipip encap firewall in the UCSD encapsulating router. If something has stopped working today because of that, please let me know. - Brian

3 7

Internet founder dies
by Brian Kantor 18 Apr '17

18 Apr '17

http://www.bbc.com/news/technology-39621198

1 0

Router advice
by Marc Williams 18 Apr '17

18 Apr '17

Hi all, As part of my gateway setup I am looking to get rid of my BT Home hub (which I am having to use with DMZ turned on) and put in an inexpensive but more capable router. So I was looking for peoples thoughts on either Microtik or Ubiquiti Edge routers. Is either particularly better suited? Kind Regards Marc (2W0PNT)

5 5

Re: [44net] Make Error
by Rob Janssen 17 Apr '17

17 Apr '17

> An update - I had success using compiling using 'cpp' instead of 'gcc' cpp is not a compiler. it will only resolve your #include #define etc but the output is still C. > I now receive less error output, but there's still an error: Your crosscompiler setup is seriously broken! It apparently misses critical include file contents, the first error about IPPORT_ROUTESERVER was also caused by that. Maybe you missed some step in setting it up, I remember from the past where I tried this for my Dreambox that it is quite an involved procedure. Rob

1 0

Make Error
by lleachii＠aol.com 17 Apr '17

17 Apr '17

All, I've been able to successfully compile ampr-ripd for the native OS (Ubuntu Linux x64); but I receive errors when trying to compile for MIPS: -------------------------------------------------------------------------- user@ubuntu-comp:~/ampr-ripd-1.16.2$ make CC=mips-openwrt-linux-musl-gcc LD=mips-openwrt-linux-musl-ld mips-openwrt-linux-musl-gcc -Wall -O2 -o ampr-ripd ampr-ripd.c ampr-ripd.c: In function 'create_fwsd': ampr-ripd.c:1536:23: error: 'IPPORT_ROUTESERVER' undeclared (first use in this function) sin.sin_port = htons(IPPORT_ROUTESERVER); ^ ampr-ripd.c:1536:23: note: each undeclared identifier is reported only once for each function it appears in ampr-ripd.c: In function 'on_alarm': ampr-ripd.c:1629:27: error: 'IPPORT_ROUTESERVER' undeclared (first use in this function) sin.sin_port = htons(IPPORT_ROUTESERVER); ^ ampr-ripd.c: In function 'main': ampr-ripd.c:1864:13: error: 'struct udphdr' has no member named 'dest' (udh->dest == htons(IPPORT_ROUTESERVER)) && ^ ampr-ripd.c:1864:29: error: 'IPPORT_ROUTESERVER' undeclared (first use in this function) (udh->dest == htons(IPPORT_ROUTESERVER)) && ^ ampr-ripd.c:1865:13: error: 'struct udphdr' has no member named 'source' (udh->source == htons(IPPORT_ROUTESERVER))) ^ Makefile:30: recipe for target 'ampr-ripd' failed make: *** [ampr-ripd] Error 1 -------------------------------------------------------------------------- Any assistance is appreciated 73, KB3VWG

2 4

Re: [44net] Make Error
by Rob Janssen 17 Apr '17

17 Apr '17

> I've been able to successfully compile ampr-ripd for the native OS (Ubuntu Linux x64); but I receive errors when trying to compile for MIPS: IPPORT_ROUTESERVER should be defined in <netinet/in.h> When it isn't, you can work around that by inserting this line near the top of the ampr-ripd.c file near the other #define lines: #define IPPORT_ROUTESERVER 520 Rob

1 0

fbi.gov at i0ojj.ampr.org
by Gustavo Ponza 16 Apr '17

16 Apr '17

Hi all, Just to inform all of you about the special visit at i0ojj.ampr.org/ir0rm-7.ampr.org by using the following references: fbi.gov. 0 IN TXT Dgoogle-site-verification=L8cauHJF4MANoTCkMbrLkAVfHBta28ctva9n1IDekToQ fbi.gov. 0 IN TXT Dgoogle-site-verification=6UEk-jfg1xPNjz_rQGcRFJOBGxMy1aARDZUTXgSNAqw fbi.gov. 0 IN TXT XublrZj1CzpSEiwtiRFKDAyiek8hRqkqaTTApxvhwai14i8JqVBOauW4cA06i39H5Lhl3HnALCM/xfTxIPEXEpA== fbi.gov. 0 IN TXT 625558384-8740534 -- 73 and ciao, gus i0ojj A proud member of linux team Non multa, sed multum

1 0

OpenWRT Upgrade - Linux Bug
by lleachii＠aol.com 16 Apr '17

16 Apr '17

All, I did an upgrade of my OpenWRT device to LEDE 17.01.0. At this time, everything is operation as before; except that I cannot execute the ampr-ripd from the CLI or the scripts that worked in the previous versions. I'm suspecting it may be missing dependencies; but while I troubleshoot, I am only accessible from the Global Internet. If anyone else is interested in upgrading and troubleshooting, I would ask that you make a copy of a list of all your installed packages prior to upgrading. In addition, please make an archive of your config before and after your upgrade. 73 and good weekend, - Lynwood KB3VWG

3 3

Re: [44net] portal down
by Rob Janssen 15 Apr '17

15 Apr '17

> Just to keep everyone in the loop: there have been four DDOS attacks on the portal recently, two against just port 443 and late last night (UK time) two simultaneous attacks against 443 and 25. > I have no idea why anyone is targeting the portal, nor who is behind it - as per your standard DDOS the attacks they mainly came from compromised PCs on the end of home DSL lines. We had a DDoS attack that affected our gateway, but it targeted the "Brandmeister" servers for interlinking digital voice repeaters, that were hosted on our network. (some on the same ESXi server as the gateway and some on another location linked by a radio link) This took down our connectivity as we got >200 Gbit/s of traffic and the gateway only as a 1 Gbit/s connection. The traffic in this case was "DNS reflection", i.e. DNS requests were sent by compromised PCs using a spoofed source address on AMPRnet, and the DNS servers were sending their replies to our gateway. Due to the high packet loss and the large replies these were mainly UDP fragments that would not re-assemble to complete datagrams. Of course it is bad that there still are so many ISPs that do not implement BCP38. But what can we do? However, more interesting is the cause of this attack: the maintainers of the Brandmeister system have a disagreement with the operators of the French gateway in that system and decided to disconnect it. The DDoS was done as a retaliation against that, probably by one or more French amateurs, not necessarily the gateway operators. (the disconnection of that gateway of course affected the repeater users in France, not only the operators) Like in your case, there were several waves of attacks. In the end, the affected addresses were nullrouted and the servers moved elsewhere. It might be that these same people are still looking for things to attack, and maybe they researched a bit how .ampr.org works and decided to attack the portal? (not effective against Brandmeister as our network is BGP routed) It is sad that people act this way, and the network operators do so little to prevent it. Rob

1 0

Re: [44net] portal down
by Rob Janssen 15 Apr '17

15 Apr '17

> Instead of this debate -- why not spec what the software does and start an > open source project to replicate its functionality. Because this is a one-instance project. It does not bring much to opensource it and have 5 different people working on it in 5 directions, because ultimately we need one instance that governs the AMPRnet. Even when we want to replicate it for redundancy, those copies need to run the same code or at least would have to have exactly the same functionality. Having said that, it appears to be a pretty mundane LAMP project and it has taken way more time to discuss about the developments it needs than it would have taken to actually do those developments. Maybe writing the specs and starting from scratch is not such a bad idea, especially when done by someone who can actually spend some time on it. I would have favoured integrating it with another AMPRnet application, HamnetDB, but unfortunately it appears its developer has just as little spare time, so that probably would be a tough project as well. Rob

1 0

Mikrotik ROS script update
by Marius Petrescu 15 Apr '17

15 Apr '17

Hello, I made some updates to the MT ROS script: - The script now maintains an interface list named 'ampr-interfaces' with all ampr tunnel interfaces. The list is persistent, and will be created on first script run. Afterwards it will be maintained by each interface add or remove. Useful for firewall rules. - Corrected an error when tunnel endpoint host routes where not deleted on interface removal. - Added step by step instructions using winbox GUI (inside the zip file). http://www.yo2loj.ro/hamprojects/ampr-gw-3.1.rsc http://www.yo2loj.ro/hamprojects/ampr-gw-3.1.zip 73s de Marius, YO2LOJ

1 0

Re: [44net] portal down
by Brian Kantor 15 Apr '17

15 Apr '17

Appears I was wrong about having to wait until tomorrow; the portal is back up. - Brian

1 0

UCSD gateway outage
by Brian Kantor 14 Apr '17

14 Apr '17

During the night, amprgw fetched a copy of the encap file from the portal which was truncated (it had 259 entries instead of over 600) and one of the entries that was in the copy fetched had no gateway address. Viz: route addprivate 44.131.168.128/29 encap This caused the ipip daemon to segfault and so there was no routing between Internet and tunnel subnets for an hour. The rip sender was similarly affected. Later fetches of the encap file obtained ones that appear to be intact and all routing is again operational. I've modified the code in the daemons to be more robust in the face of a bad encap fetch, and taken steps to ensure that future fetches are checked better. - Brian

8 9

Linux/Android kernel security bug
by Brian Kantor 14 Apr '17

14 Apr '17

The Register reports a Linux/Android kernel flaw that could expose you to remote privileged execution of arbitrary code: http://www.theregister.co.uk/2017/04/14/new_critical_linux_kernel_flaw/ As a lot of the machines and routers on the Amprnet are based on Linux, this may be incentive for you to update to the latest kernel. - Brian

1 0

Re: [44net] UCSD gateway outage
by Rob Janssen 14 Apr '17

14 Apr '17

> During the night, amprgw fetched a copy of the encap file from the portal > which was truncated (it had 259 entries instead of over 600) and one of > the entries that was in the copy fetched had no gateway address. Viz: > route addprivate 44.131.168.128/29 encap > This caused the ipip daemon to segfault and so there was no routing > between Internet and tunnel subnets for an hour. For this particular issue it would help when the encap file had a trailer that the script that fetches it could check for before loading it. Something like: # EOF Rob

2 1

DNS
by Marc Williams 13 Apr '17

13 Apr '17

So that time has come to get some DNS entries added.G1FEF seems to be my coordinator. Should I approach him about entries I cannot spot a contact address anywhere. Regards Marc (2W0PNT)

3 3

Portal down
by Marc Williams 11 Apr '17

11 Apr '17

The ampr portal is down for me here in the UK. Anyone else seeing an issue? Regards Marc (2W0PNT)

4 6

Small corrections and a bug fix: ampr-ripd 1.6.2 and amprd 1.6
by Marius Petrescu 07 Apr '17

07 Apr '17

Hello, I made some small fixes without major functional impact to ampr-ripd: - Routes where not cleaned up in debug mode, after hitting CTRL-C - If RIP forwarding was used and the forward interface became inactive/disappeared, the daemon would not be able to send any RIP updates. This use case can occur e.g. if ampr-ripd is providing RIP broadcasts for a jnos via a tunnel. On jnos crash the tunnel would fail and would not receive route updates after restart (tnx. Gus, I0OJJ for report and testing the fix). If these issues have not bothered you until now, there is no urge to upgrade. There was also a bug in amprd, which would not set the needed host routes if rip_set_routes was set to 'no'. Also, the password is hard coded in amprd, too (like in ampr-ripd). Sooo: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.16.2.tgz http://www.yo2loj.ro/hamprojects/amprd-1.6.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.16.2.tgz http://yo2tm.ampr.org/hamprojects/amprd-1.6.tgz Have fun! Marius, YO2LOJ

1 0

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 06 Apr '17

06 Apr '17

> I've sorted the source address and am now originating with a source > address of 44.131.14.255. Now I can ping those two other mentioned addresses > I guess this also highlights another issue, does anyone have a pointer > to the correct way to set up filters for this? I have added some quick > rules to prevent my gateway being a public IP relay, but it looks like > many others have not. I am not sure the correct way to configure these > filters for the general use case. I should now be discarding all > packets that don't have a source or destination within my network, but > I do not check for spoofing beyond that. This should be "good enough"? > Clearly, others have gone further. Well, what I have done up to now is a filter to allow IPIP traffic only from registered IPIP tunnel hosts, but no further. There is no strict "reverse path" checking yet, so anyone with a registered tunnel could in fact spoof traffic for any source IP. Maybe I'll fix that later, but for now I decide to allow traffic that may be routed somewhere else and then forwarded in a tunnel. The main purpose of the filter is to keep out the opportunists on Internet that could try to get around a firewall using tricky tunneled packets, not to regulate what the AMPRnet users can do. (I have seen examples of unwanted IPIP traffic, and lately GRE is a popular target as well, so similar filters are in place to allow GRE only from locally registered GRE endpoints) The filter is done as a -x script called by ampr-ripd when it updates the route table. The script is like this: #!/bin/sh # script called when ampr-ripd updates route table # load encap.txt into ipipfilter list AMPRGW="169.228.66.251" gwfile="/dev/shm/gw" cd /var/lib/ampr-ripd || exit 1 grep addprivate encap.txt | sed -e 's/.*encap //' | sort -u >$gwfile if iptables -N ipipfilter 2>/dev/null then iptables -F ipipfilter iptables -A ipipfilter -s $AMPRGW -j ACCEPT while read ip do iptables -A ipipfilter -s $ip -j ACCEPT done <$gwfile iptables -A ipipfilter -j LOGREJECT else iptables -L ipipfilter -n | grep ACCEPT | fgrep -v $AMPRGW | \ sed -e 's/.*-- //' -e 's/ .*//' | sort | diff - $gwfile | \ while read d ip do case "$d" in ">") iptables -I ipipfilter -s $ip -j ACCEPT ;; "<") iptables -D ipipfilter -s $ip -j ACCEPT ;; *) ;; esac done fi rm -f $gwfile This updates the "ipipfilter" chain that is used in the input firewall like this: iptables -A firewall -p 4 -j ipipfilter I use this method to have some statistics of traffic per endpoint as well, when you don't need that it would be better to use ipset to maintain an address set to be matched by a single iptables line. Rob

1 0

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 06 Apr '17

06 Apr '17

> If you want to test it, 44.131.14.254 is a second loopback on the > gateway that is used for status monitoring. 44.131.14.192 is a unicast > node "inside" my network to check end to end connectivity. Your network is OK in our routing table. I can ping 44.131.14.255 but not those other addresses. Rob

4 4

New ampr-ripd 1.16 and amprd 1.5 released
by Marius Petrescu 06 Apr '17

06 Apr '17

Hello! Today I released an update to ampr-ripd (1.16) and amprd (1.5) to support ipip encapsulation on subnets which have their endpoints BGP announced in the 44net space. Just compile and replace your current daemon executable file (stop the old one first). No changes in configuration should be necessary. Get them as usual from my ham project page: Internet: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.16.tgz http://www.yo2loj.ro/hamprojects/amprd-1.5.tgz 44net: http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.16.tgz http://yo2tm.ampr.org/hamprojects/amprd-1.5.tgz 73 de Marius, YO2LOJ

4 9

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 06 Apr '17

06 Apr '17

> Can you ping .254? .255 should go direct and .254 should be > encapsulated to the same machine. No > Do you have an address I can test to? I have been doing a few tests > and it would appear that there are some issues here. 44.137.0.1 should be fine, and 44.137.41.97 as well > Previously I was able to access services that were public the same as > an external host, but now many of those are not working. As an example > 44.137.0.1 works fine from an external IP address, but not a > 44.131.14/24 one. I have found at least 1 host responding to my > encapsulated packets with ICMP Administratively Denied, which makes me > suspect that the problem is actually my anycast setup with my source > address not matching the gateway address. It is. Now I see what is wrong, the firewall log is full of: Apr 6 19:47:01 Packet REJECT: IN=eth0 OUT= SRC=45.63.97.98 DST=213.222.29.194 LEN=104 TOS=0x00 PREC=0x00 TTL=52 ID=19182 DF PROTO=4 That source address apparently belongs to you but it is not the tunnel endpoint. We reject all protocol 4 traffic from hosts not in the RIP broadcast for tunnels. Rob

1 0

Re: [44net] Gatway up
by Rob Janssen 06 Apr '17

06 Apr '17

> We do this for a large percentage of our customers without issue. We route public subnets to customer specific firewalls which then translate those addresses to internal hosts: You are doing NAT. I know this is customary in commercial internet practice but in HAMNET/AMPRnet we don't like NAT. (too much time is wasted by debugging the issues caused by inserting NAT into networks that also have direct routing) Rob

1 0

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 06 Apr '17

06 Apr '17

> Now another question about directly connected 44net addresses - is there > a way for them to reach tunneled addresses? I would prefer to have my > services accessible from all 44net addresses when I start offering > something serious later this year. ATM, it appears my /24 would be > unreachable from these addresses, because even if there is a host route > to an endpoint, the 44net address is not exposed to directly connected > endpoints (they see the public IP of my router). And those direct > connected addresses not running tunnels wouldn't reach me for obvious > reasons. When you get BGP routing on internet for a certain subnet, you should install and register an IPIP tunnel gateway for the same subnet as well. Until now this required a public (outside net 44) IP address on the gateway system, but with the mod discussed in this thread you may be able to put the tunnel endpoint inside your BGP routed subnet. Of course it will take some time for all people to pickup the necessary software and configuration changes for this to actually work. So you will still be reachable for only part of the users for some time. Rob

1 0

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 06 Apr '17

06 Apr '17

> Now, ampr-ripd does identify this host as directly connected, which > appears to be the expected behaviour with the new version. All well and > good from the Pi, but there is one significant implication - the source > IP is no longer my 44 net IP, but it's the public IP of my router, and > the internal IP is the 10.x IP of the Pi (my regular IP range. I think > that's where things are breaking. Ah yes, it would be better when ampr-ripd added a "src" option with the IP of the tunnel interface to the /32 routes it adds to the table... Rob

2 1

Re: [44net] Gatway up
by Rob Janssen 05 Apr '17

05 Apr '17

> Good morning all, > I seem to have my gatway up (44.131.192.128) > It responds to some of the ampr ping tools in the service list but not others. Could I ask a few of you to ping it and see if you can see it. It works! Note it is a bit controversial to use the first (and last) address of your subnet. You may run into problems sometime. You have a /29 so you should use 6 addresses. Also, please register DNS names for your addresses. Rob

3 2

Returning an assignment
by James Sharp 05 Apr '17

05 Apr '17

I have a small subnet I was assigned by the Florida administration. I have since moved to Nevada. Should I return the assigned block and get a new one from the Nevada coordinator, just to keep things square and straight?

2 1

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Brian Kantor 05 Apr '17

05 Apr '17

Mike, the problem is that the n8lrf gateway has an address on the subnet instead of a commercial IP address and is therefore not reachable. - Brian On Wed, Apr 05, 2017 at 07:43:15AM -0400, Michael Wolthuis wrote: > Rob, > I have managed that subnet since early 90's. What is your concern? You are welcome to be assigned ips on it in Kent County. I have several other subnets for our HamWan project and even an IPv6 assignment from ARIN. > > How can I help meet your goals? > > Feel free to call me at 616-422-5412 or on the 145.27 Lowell repeater > > Mike > KB8ZGL > > Sent from my iPhone > > > On Apr 5, 2017, at 6:13 AM, Brian Kantor <Brian(a)UCSD.Edu> wrote: > > > > I think it's a mistake. It's confusing. The gateway belongs to > > n8lrf(a)comcast.net but the subnet belongs to kb8zgl(a)kb8zgl.net. > > I'm guessing that n8lrf entered a gateway hostname that belongs to the > > ampr side of the gateway rather than the commercial IP. > > - Brian > > > >> On Wed, Apr 05, 2017 at 11:53:40AM +0200, Rob Janssen wrote: > >> But there also is a network 44.102.128.0/24 and it does not work. Is that one okay or is > >> it another config mistake? I suppose so, as its gateway 44.102.128.1 is routed to amprgw. > >> > >> I'm afraid we need better directions and/or safeguards in the portal. > >> > >> Rob > >> _________________________________________ > >> 44Net mailing list > >> 44Net(a)hamradio.ucsd.edu > >> http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 05 Apr '17

05 Apr '17

I have installed the 1.16 on our gateway (without the safeguard for now) and it appears to be doing its thing. I can ping hosts on those test networks. But there also is a network 44.102.128.0/24 and it does not work. Is that one okay or is it another config mistake? I suppose so, as its gateway 44.102.128.1 is routed to amprgw. I'm afraid we need better directions and/or safeguards in the portal. Rob

2 1

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 04 Apr '17

04 Apr '17

> Wouldn't you achieve the same result by adding that network's IP/subnet > to the -a list? Yes, but then I would have to know the offender's IP beforehand :-) However, it would be possible to just delete the route in the -x script that we already have. I think ampr-ripd will not detect that and the route will not be added every 5 minutes, right? Rob

2 1

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 04 Apr '17

04 Apr '17

> If the daemon encounters a 44 gateway in the RIP data, it creates a host > route to that specific host via the default gateway of the system. I was thinking about one specific issue: when we run this code on our gateway, which is BGP-routed for our 44.137.0.0/16 network and is on the IPIP network as well and runs ampr-ripd, and some portal user who does not understand the system well, they could add a gateway with an endpoint address inside the 44.137.0.0/16 network and we would add a circular route for that address to our table. Of course users should not do that. But they have done so, in the past. Maybe we would need an option to specify a (list of) subnet(s) where this new mode of operation would not be performed. Then a gateway can set that to the BGP routed network(s) it serves. (similar to the -a option) Rob

2 1

Gatway up
by Marc Williams 04 Apr '17

04 Apr '17

Good morning all, I seem to have my gatway up (44.131.192.128) It responds to some of the ampr ping tools in the service list but not others. Could I ask a few of you to ping it and see if you can see it. Many thanks Marc ("2W0PNT)

4 5

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 04 Apr '17

04 Apr '17

> No, but it is quite simple. > If the daemon encounters a 44 gateway in the RIP data, it creates a host > route to that specific host via the default gateway of the system. Aha ok that is a nice solution. It should fix the problem for those that have two routing tables. In our gateway we are using a single routing table (with some different metrics) so we don't have the problem for isolated gateways, but your solution would still fix the case where the endpoint has an address inside the subnet being routed (Sweden??). I'll try to install it soon. Rob

1 0

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 03 Apr '17

03 Apr '17

> Today I released an update to ampr-ripd (1.16) and amprd (1.5) to > support ipip encapsulation on subnets which have their endpoints BGP > announced in the 44net space. Is it described somewhere how that works? Rob

2 1

pfsense
by Tom C 02 Apr '17

02 Apr '17

Is anyone using pfsense as your gateway/router? If so how do you handle rip44? Is anyone interested in testing a package if I compile ampr-ripd? Tom/N2XU/BSCS/CASP, Security+ ce -- 73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified

2 1

Introduction
by Marc Williams 30 Mar '17

30 Mar '17

Hi folks on the list, The obligatory introduction email. I am Marc (2w0pnt) based in the Vale of Glamorgan in Wales.Currently messing around with ax25 on 2m and wifi meshing using Ubiquiti equipment. All this is currently around serving an Synchonet bbs system.I have been collecting packet tnc gear for a few years now buying it cheap whenever it appears on gumtree/ebay/etc and now finally have moved to a location with the space for me to properly play with it all. Cheers Marc

1 0

rackmount server(?)
by Brian Kantor 28 Mar '17

28 Mar '17

The perfect accessory for your server rack: http://www.canford.co.uk/Products/11-231_CANFORD-RACKWINE-Winerack-rack-mou… - Brian

3 2

Re: [44net] rackmount server(?)
by Rob Janssen 28 Mar '17

28 Mar '17

> The perfect accessory for your server rack: > http://www.canford.co.uk/Products/11-231_CANFORD-RACKWINE-Winerack-rack-mou… <http://www.canford.co.uk/Products/11-231_CANFORD-RACKWINE-Winerack-rack-mou…> > - Brian A bit expensive for the amateur... Seriously, we a looking for a rackmount coffee machine for our repeater site. We are often working there all saturday and we need to leave the place tidy. Lugging a coffee machine there and taking it home again becomes a bit bothersome. But if we could find a coffee machine in maybe 8-10 U of rackspace... https://www.hobbyscoop.nl/wp-content/uploads/2016/12/20161203_112425-e14809… https://www.hobbyscoop.nl/wp-content/uploads/2016/12/20161203_154317-e14809… Rob

1 0

node linux
by Eduardo Castillo 27 Mar '17

27 Mar '17

Hello ! I'm trying a node on linux I leave the data to see if you can connect Your nodes to mine route lu9dce-2 lu9dce.ampr.org udp 93 b Can also be used udp 10093 and tcp ============= 73

1 0

OpenVZ Ham Radio image
by Shawn Bush 27 Mar '17

27 Mar '17

I currently use Proxmox, a virtualizing operating system. It uses OpenVZ and I was wondering if there is a image for ham radio users. If not I was thinking of using my web server and maybe hosting a image that I could maintain. I currently have net44 [some what] running in a VM alone with linBPQ32. It has a web based login to the shell and webmin for maintaining the VM. I would probably like to setup something like that for the VM. I'm by far an expert with net44, but would be interested in providing this if there would be a need for it. The road to net44 comes with alot of upward climbing without much help. 73's Shawn Bush KD8NCV

3 2

Re: [44net] Trouble creating a Gateway into 44net
by Rob Janssen 24 Mar '17

24 Mar '17

> I am sorry about my multitude of questions but sometimes I can read > things a million times and still not understand. > Would I have to use either ampr-ripd > <http://wiki.ampr.org/wiki/Ampr-ripd>, or rip44d > <http://wiki.ampr.org/wiki/Rip44d> on the server to forward the traffic > to my AMPRnet box? Would I have to use either ampr-ripd > <http://wiki.ampr.org/wiki/Ampr-ripd>, or rip44d > <http://wiki.ampr.org/wiki/Rip44d> to tell the server where to send the > AMPRnet traffic cumming from the box. Rip44 is not for forwarding. It is used to populate the routing table for the IPIP tunnel system. The forwarding is done by the kernel and is configured the usual way. I.e. forwarding is to be enabled in the kernel and the proper interfaces and subnets are added. You would be setting up the AMPR IPIP tunneling on your brother's computer (first ask if he agrees with that) and you get a subnet from your coordinator, e.g. a /28 network, where your brother's computer gets an AMPRnet address and your own computer gets another address in the same subnet, you set your brother's computer as the default gateway, and all AMPRnet traffic is forwarded via your brother's computer that will tunnel it over the IPIP network. The ampr-ripd running on your brother's computer will receive the AMPRnet RIP packets and maintain a routing table with about 400 routes, plus it has the locally attached AMPRnet subnet that was assigned to you. All AMPRnet traffic is forwarded between the IPIP tunnels and your local subnet. > Or can I use a "simple" tool such as BIRD Internet Routing Daemon > http://bird.network.cz/ <http://bird.network.cz/> (the first thing that came up when I searched > for ipip routing deamons). No. That software only handles standard protocols, and RIP44 isn't one. (well, it almost is, it is just RIPv2, but the handling of the information by the routing daemon is different) An alternative when you do not want to do as much on your brother's computer and do have a Linux system yourself, is to just forward all IPIP traffic received by your brother's computer to your computer over the local network, and run ampr-ripd etc on your own computer. Rob

5 5

Re: [44net] Trouble creating a Gateway into 44net
by Rob Janssen 24 Mar '17

24 Mar '17

> Subject: > Re: [44net] Trouble creating a Gateway into 44net > From: > "Augustine Tabeling, W8AWT" <w8awt(a)qsl.net> > Date: > 03/24/2017 12:36 PM > > To: > 44net(a)hamradio.ucsd.edu > > > > "An alternative when you do not want to do as much on your brother's computer >> and do have a Linux system yourself, is to just forward all IPIP traffic received >> by your brother's computer to your computer over the local network, and run >> ampr-ripd etc on your own computer. " >> --- >> This is exactly what I want to do but I have no Idea how to do it. By "all IPIP traffic" do you mean _only_ the IP Protocol 4 Traffic or do you mean effectivly all IP traffic (I dont think that would be ok.)? I ask this because my brothers >> computer has several websites and a few other web services (IRC, SSH, FTP, Minecraft) running on it and everything that I do cannot interfere with them. On a Linux system, this is easy. IPIP stands for "IP in IP" which is the protocol that is used for AMPRnet tunnels. The outer IP packet has protocol 4, the inner IP packet is the actual packet to be transferred. Use the following command to send all incoming IPIP traffic (IP protocol 4) to another system using a destination NAT rule: *|iptables -t nat -A PREROUTING -p 4 -j DNAT --to-destination 1.2.3.4|* Instead of the 1.2.3.4 you put the IP address of your own computer. The replies to those packets can be sent directly to the router so it is not required to configure a reverse for this. (assuming the router does NAT itself) This command has to be repeated every time the computer is booted. To do that, you can add it to the file /etc/rc.local Rob

1 0

Re: [44net] Trouble creating a Gateway into 44net
by Augustine Tabeling, W8AWT 24 Mar '17

24 Mar '17

Hi All, > > I am new to 44net and I am trying to create a gateway into it. but I > am running into problems. > My brother runs a Ubuntu server on our LAN and has the router DMZ'd to > it. I would like to create a gateway to 44net on the LAN but not on > his server. Would it be possible to set up 44net access on the LAN and > working with but not on his server. if possible I would like to start > by using a Ubuntu Server Virtual Machine and later move to a Linksys > wifi router If I get it working well. > I am new to networking and learning slowly. My brother is willing to > work with me if I tell him what I need him to do but wont put a lot of > energy into figuring out how to make it work. > > 73!, > Augustine, W8AWT >

3 7

Re: [44net] FW: JNOS2.0K and Netrom problem
by Rob Janssen 18 Mar '17

18 Mar '17

> While ago, just for fun, SUCCESSFULLY compiled JNOS-2.0k > on Debian-8.7/64 bit with CFLAGS -m64 > This binary is running right now on desktop PC instance of JNOS: > 2LPJNS:SP2L - simply flawlessly... Hi! Ok, that is good! I once tried this with NETCHL and it failed, and I did not want to spend the effort of going through all code to make it 64-bit secure, and this is a waste for such a program anyway (it does not require large integers or pointers that can access more than 2GB). So for NETCHL the -m32 flag is mandatory. Of course, with Debian8.7 there still are several compiler options (4.6 - 4.9 and maybe more) so there may be some issue with a different version of the compiler, I have seen that happen in the past. Otherwise I have no clue what could be happening, we would need at least the stack backtrace and maybe more. Rob

5 6

Re: [44net] FW: JNOS2.0K and Netrom problem
by Rob Janssen 15 Mar '17

15 Mar '17

> A couple of weeks ago I downloaded and compiled jnos2.0K and found that > while the compile appeared to be successful, jnos would crash when a nodes > list was sent or I entered "netrom bc xxx" > So I have learn a lot about linux since then but not yet found the problem. > I compiled using Fedora 24 with the most latest updates on two different > PC's and today downloaded the gz file again. As you mention JNOS I presume you are not using the NET/ROM code built into the Linux kernel, but run JNOS as a user program on some tun/tap device. This means, this problem has very little to do with Linux. It is just a bug in the code, maybe combined with a property of the compiler. It sometimes happens that when you compile C code with a newer (or another) compiler than the original developer used, bugs surface that have always been present under the carpet. What happens when it crashes? Segmentation violation? That would indicate a corrupted pointer or -memory. When you type "ulimit -c unlimited" before you start the program you will get a core file (memory dump), and you can find out what is happening using gdb. Of course you need some insight in programming, but it could already help when you just print the stack backtrace (bt) and post it here. I have no personal experience with JNOS under Linux but it kind of surprises me that nowhere in the makefile or compile document there is mention of "64 bits". I would compile a program this age in 32-bit mode (my NETCHL also requires this), and that would be done by adding -m32 to the CFLAGS and installing the 32-bit development libraries first. But I leave it to others to comment if this is required. Unclean code could fail in the way you describe when compiled in 64-bit mode and work perfectly in 32-bit mode. Rob

2 2

FW: JNOS2.0K and Netrom problem
by vk1kw 15 Mar '17

15 Mar '17

Hi All, A couple of weeks ago I downloaded and compiled jnos2.0K and found that while the compile appeared to be successful, jnos would crash when a nodes list was sent or I entered "netrom bc xxx" So I have learn a lot about linux since then but not yet found the problem. I compiled using Fedora 24 with the most latest updates on two different PC's and today downloaded the gz file again. A kind user has helped enormously and sent me a file he compiled last December 11 (I think) and it runs well. Jnos2.0i compiled here today also runs well with no problems using my same config.h file. So it seems that something has changed with the "netrom broadcast" source file since around December. I have discounted Fedora mostly as jnos2.0i still compiles good so a side by side source file compare is the next do. The question is then, has anyone else had netrom crashes after a recent Fedora jnos2.0k compile please? Regards Rob vk1kw -----Original Message----- From: 44Net [mailto:44net-bounces+vk1kw=netspace.net.au@hamradio.ucsd.edu] On Behalf Of vk1kw Sent: Thursday, March 09, 2017 10:28 PM To: 44net(a)hamradio.ucsd.edu Subject: [44net] JNOS2.0K and Netrom problem (Please trim inclusions from previous messages) _______________________________________________ . _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] TimeFrame
by Rob Janssen 11 Mar '17

11 Mar '17

> What's the timeframe to get a block of IP's, I'd like to start testing > and messing around with AMPRnet. I've got BGP routing available, and I > can't wait to get connected. > I am my Wireless ISP, so that won't be an issue. I have a few different > routes, so I'm hoping for a /23, and put one on each end of my network. Well, it should be mentioned that going directly for BGP routing and mentioning that you are an ISP is probably not going to speed things up! It would be advisable to start experiments with IPIP tunnels or other connectivity and add BGP routing later, as a service to local hams only. There are lots of requests for large blocks to be BGP routed for AMPRnet that really are attempts from ISPs to get IPv4 space that they can no longer obtain from the normal registries, so this kind of requests and formulation will make the coordinator very wary... Rob

3 2

TimeFrame
by Michael W Rhone II 11 Mar '17

11 Mar '17

What's the timeframe to get a block of IP's, I'd like to start testing and messing around with AMPRnet. I've got BGP routing available, and I can't wait to get connected. KB3PEV Michael W Rhone II

4 5

Re: [44net] TimeFrame
by Michael Fox - N6MEF 11 Mar '17

11 Mar '17

> We do service a handful repeaters, and I'm hoping to do a some sort of > RF based TCP/IP solution, haven't found one I like yet. Any > recommendations? I could go Wifi based, 900/2.4,5ghz, but I'm hoping > to find something other then packet to use at 440 or 1.2. Check out NW Digital Radio's UDRX-440 (56kbps IPv6 on 440 MHz) MichaelN6MEF

1 0

Axip and mail
by Shawn Bush 09 Mar '17

09 Mar '17

Hello, I have linbpq32 setup and would like to get more axip connections and chat links. I also would like to get some messages flowing my direction. Could anyone help? I can give you my MAP line... 73's Shawn Bush KD8NCV

2 1

JNOS2.0K and Netrom problem
by vk1kw 09 Mar '17

09 Mar '17

Hi All, Since compiling JNOS2.0 some years ago, I have always had problems with Netrom transmits killing it back to the directory prompt. I have been using JNOS1 version ? in its place for a long time because of the same problem. But today I downloaded and compiled the latest JNOS2.0k and have the very same problem. It all compiles ok on my Fedora (latest updates) it starts and runs perfectly until it does a node transmit and dies immediately. I can poke it with all the netrom commands until I do "netrom bcnodes port" and it crashes. It receives nodes ok and populates the list ok. It also does normal "Connect XX VK1KW-5" ok. So to try another idea, I removed all my netrom options from autoexec.nos and used the defaults. (except interface /call/node name). Same problem and crashed. I notice also in this version, you need to type the whole word eg "connect" vice "con" or "ifconfig" vice "ifc". Maybe something in Fedora is not compiled in or is missing or I haven't read enough yet. There may be a conflict in my config.h but it's pretty much the same as original. So I am open to ideas. Thanks in advance Regards Rob Vk1kw

3 5

[xfbb-bis] - (new/test) mailing list
by SP2L 08 Mar '17

08 Mar '17

Last night launched fully functional mailing list named xfbb-bis and currently widely available at: http://www.sp2l.ampr.org/mailman/listinfo/xfbb-bis I warmly invite everyone wishing/willing to test performance and usability of this site. Best regards. -- Tom - SP2L ------------------------------------ It is nice to be important. But it is more important to be nice!

3 3

bogus entry in encap file
by Brian Kantor 07 Mar '17

07 Mar '17

The encap file currently contains a bogus entry: route addprivate 44.8.1.16/28 encap 0.0.0.0 I've asked Chris to make it impossible to enter this into the portal as it's clearly wrong. The ripsender and amprgw encapsulating daemon discard this already. - Brian

2 1

Re: [44net] Hello
by Tom C 05 Mar '17

05 Mar '17

W4EWH de N2XU. The 172.x.x.x space I use sits within the reserved RFC-1918 172.16.0.0/12 space reserved for private networks. I use it for my home LAN just as I could use 10/8 or anywhere in 192.168/16 space. I use it because some folks are unaware of the allocation and are more likely to see it as you have which is intended to make them shy away from messing with it OR ask questions which I welcome because it's an opportunity to help folks learn something they might not know. Any time we learn more about networks and networking to advance what we know is a good thing. 74 de N2XU Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+ ce -- 73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified

1 0

Re: [44net] AXUDP spec
by Rob Janssen 03 Mar '17

03 Mar '17

> >/The list of UDP ports at Wikipedia(1) doesn't show port 93 or 10093, /> >/so I suggest we correct Wikipedia's list, since port 93 is shown as /> >/assigned to "Device Control Protocol" by the IANA(3). / > Yes, our usage of port 93/UDP for AXUDP is completely unrecognized by > IANA. There is no official document describing AXUDP so there is no > way for us to claim a port - although there's no prohibition on > using any port number we want, since port numbers are not absolutes. > Still, it's not wise to double-up on port numbers. In the "old days" it was quite easy to register port numbers, and in fact I have registered a few myself that I still use for similar but not the same purposes (459, 1535, 1536). However, it appears to be not as simple anymore and looking at protocols that are in much more widespread use than AXUDP it appears to be not common anymore to register ports used only by some proprietary protocol at IANA (there are way, way more protocols in use than those with IANA-registered port numbers). Note that at the time I registered the above 3, IANA would not take suggestions for the numbers to register. I claimed different numbers that were unregistered, but they gave me those instead. Asking for port 93 to be registered is unlikely to succeed, 10093 may be possible. Registered port numbers are useful mainly for open protocols that are widely implemented and that accept unsolicited incoming connections. So everyone knows what port you have your wellknown services listening on. There is not much that can go wrong when using a port number without registering it, especially when the receiving application accepts data only from a pre-configured peer. The port numbers used essentially don't matter in that case, the only thing you need to make sure is that you don't have another session with that same peer that would want to use the same port number. (e.g. it would not be wise to use port 5198/5199 as these are used by Echolink, another port usage that is not registered at IANA and is in much more widespread use than AXUDP) Rob

2 1

Re: [44net] Hello
by Rob Janssen 03 Mar '17

03 Mar '17

> I'm a bit confused by your post: since 172.29.x.x addresses are > reserved for "Detached" networks, please clarify the source of the > 172.29.60.0 IP range you mentioned. Is it provided by your ISP, or are > you going through a corporate network to get to the Internet? TIA. This range is from RFC1918 where the 192.168 addresses also come from. He probably has those addresses on his LAN and uses NAT to connect to internet. Of course it is possible to use NAT between such a range and the AMPRnet, but I don't recommend it. It is better to assign net-44 addresses to AMPRnet devices, maybe have 2 addresses on one device. Understanding a mixed-network NAT configuration (NAT to internet and NAT to AMPRnet in the same network router) is hard for most people, and often mistakes are made, resulting it lots of RFC1918 traffic ingress in the AMPRnet. I get lots of log entries like this in our gateway: Mar 3 09:56:13 Packet DROP: IN=gre8 OUT=tun0 SRC=192.168.1.101 DST=44.137.25.148 LEN=590 TOS=0x00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=5060 DPT=5060 LEN=570 (you see, the timestamp is "current") Apparently someone experimenting with SIP. My own SIP phone is at 44.137.41.104 so I don't have such issues, I can connect to that 44.137.25.148 SIP server without NAT. Rob

1 0

AXUDP spec
by Michael Fox - N6MEF 03 Mar '17

03 Mar '17

I'm looking for the specific definition of AXUDP. Is there an official protocol specification for AXUDP somewhere? Thanks, Michael N6MEF

6 12

Hello
by Tom C 02 Mar '17

02 Mar '17

I've bitten the bullet and started to make some progress getting on 44net. I'm certain my current issues are firewall and I'll get it sorted out. My non-ham network is in the 172.29.60.0/22 range. I don't think I'm leaking internal stuff to my partially built tunnel but If anyone sees packets from that block please let me know. Status: Attempted to ping 44.0.0.1 on a system on the ampr enclave on my network, With tcpdump listening on the gateway ampr0 interface I can see packets going out on the interface but that doesn't mean the packets are getting out of the box. I'm not seeing a response but like I said, I think it's a firewall issue. I just wanted to say Hi to to everyone and say I'm looking forward to exchanging packets with everyone 73 de n2xu Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+ ce -- 73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified

4 4

Re: [44net] AXUDP spec
by Rob Janssen 02 Mar '17

02 Mar '17

> Unfortunately, there are problems with AXIP and AXUDP ever since the > revisions of AX.25 were published - the AX.25 frames may get too big > to encapsulate in unfragmented IP and UDP frames. Any new document > would have to discuss the fragmentation issues, and I'll bet they're > not defined. (As far as I know, the same issue applies to ROSE, KISS, > and Net/Rom encapsulation too.) Is this an issue? The AXUDP protocol simply is "put AX.25 frames in UDP datagrams" and an UDP datagram can be nearly 64KB in size so I would not think there are any issues. UDP and IP handle the fragmentation and reassembly and the receiver gets the original datagram to insert it into the AX.25 stack. Of course, AXUDP senders should not set the DF flag, and if they do, they should not expect more than about 512 bytes maximum frame size. Which still is enough for classic AX.25 packet radio. > Do any of the various implementations of AX.25 encompass v2.0 et seq as > published by TAPR? Ie, is anyone actually implementing jumbo frames, > expanded frame sequence numbers, etc? Or should we just treat it as a > bad idea that should be buried and go on with the old protocol? The actual AX.25 version and extensions like jumbo frames and extended sequence numbers should not affect AXUDP at all. The UDP layer only replaces the HDLC layer normally used to transfer data over radio, and all things happening in AX.25 should be compatible between the endpoints, as always. Rob

1 0

amsat.org mail
by Rob Janssen 23 Feb '17

23 Feb '17

Earlier I wrote: > Well I did not get a mail from you, probably it has been lost somewhere due to spamfiltering. I now found how that happened... I use my @amsat.org address on this list, and I found that the forward address has been reset about 2 weeks ago, back to a value that it was a few months ago. I had changed it since. I still receive most of my mail because that other path still sort of works, but it tends to block a lot of mail that from the amsat.org forwarder as spam. So I now found a couple of mails in a spamfolder where I normally don't look anymore. I'm not sure what happened, there appears to be no announcement on the amsat.org page, but it could be that they had to restore a backup of the alias database. So when you use amsat.org and changed your forwarding address, it might be worthwhile to check if it is still OK. Rob

1 0

Re: [44net] Is AMPR still relatively active?
by Elias Basse 21 Feb '17

21 Feb '17

I have received repeated requests from a non licensed user. When I reject, he resubmits. It is obvious that this person may have an alterior motive as it is a hosting company. What to do in such cases? I have just let the request sit. None of the hams or it people in my area have ever heard of the hoster. Any way to ban a submission? Best, Elias Kd5jfe On Feb 20, 2017 3:00 AM, "Rob Janssen" <pe1chl(a)amsat.org> wrote: (Please trim inclusions from previous messages) _______________________________________________ > I was thinking what would be helpful is if there was specific information > required, it would be good to prompt for it ahead of time. In reading > through these threads, it appears there can be some variance in what may be > required by each coordinator. Perhaps instead of free form text block > there could be a means to prompt for some of the information that would be > considered qualifying fields. > That is a good point! There should be an optional text record for each network, to be entered by its coordinator, about the local requirements for allocation and that will be displayed on the request form above the input section. Rob _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

4 3

Re: [44net] Is AMPR still relatively active?
by Rob Janssen 20 Feb '17

20 Feb '17

> I was thinking what would be helpful is if there was specific information required, it would be good to prompt for it ahead of time. In reading through these threads, it appears there can be some variance in what may be required by each coordinator. Perhaps instead of free form text block there could be a means to prompt for some of the information that would be considered qualifying fields. That is a good point! There should be an optional text record for each network, to be entered by its coordinator, about the local requirements for allocation and that will be displayed on the request form above the input section. Rob

1 0

Re: [44net] Is AMPR still relatively active?
by Rob Janssen 20 Feb '17

20 Feb '17

> Thanks Tom. The portal already automatically sends reminder notices > to coordinators with outstanding allocation requests, twice a month. > If all the coordinators agree, we could change that to weekly. I don't think that will help. In the cases where I did not get a response from others it usually turned out they were moving, busy at work, etc. Overwhelming them with more notices is not going to solve that. > I find that the coordinations which take more than a few minutes to handle > are those where the requester is confused and asking for something that > is not sensible, so an email exchange is necessary to get the request > straightened out. That is correct. There should be an option for the coordinator to abandon the request and take the thing to e-mail. Now the only option is to reject the request, which often upsets the requester and also (because of language barriers) the requester often clicks all links in the message, causing it to be re-submitted. I would like to see a button on that screen that just deletes the request without further mail towards the requester, so I can then send mail and explain the situation. Rob

1 0

Re: [44net] How to reach VE2HOM?
by Rob Janssen 20 Feb '17

20 Feb '17

> Hello Rob, > I have receive your email this morning and reply to it before your send > on the group, I also close my amprnet for the moment. I'm new with the > mikrotik router and don't know all, I get information on the internet to > get it work. Sorry for the bad packet this is not intentionnal. > 73 de Pascal > ve2hom Hi Pascal, Well I did not get a mail from you, probably it has been lost somewhere due to spamfiltering. Good to hear you use a MikroTik router! It is possible to fix it on this kind of router. When you go to the IP->Firewall page and open the NAT tab, you will find an existing NAT rule that you use for your internet connection. It will probably show something like "masquerade", chain srcnat, out.interface ether1. You can just add another item like that, with the settings: chain srcnat src.address 192.168.0.0/16 out interface ! ether1 (click in the empty box for the ! to appear and select your internet interface) action src-nat to address 44.135.50.x (select an address you want to use for this) That should fix your problem, assuming you use this router only for internet and hamnet and have no other interfaces to other networks. This rule will make any traffic from the 192.168 range to be translated to a fixed address in hamnet (but only when it is not sent to the internet interface, that is where the other rule applies) Rob

1 0

Is AMPR still relatively active?
by F6CNB 20 Feb '17

20 Feb '17

Jim, For the european activity, you should read the Jann DG8NGN paper presented at the DCC 2014 in Austin, TX. http://tapr.org/pdf/DCC2014-TheEuropeanHAMNET-DG8NGN.pdf 73 Remi F6CNB/AG5IR

8 13

Re: [44net] Is AMPR still relatively active?
by William Lewis 20 Feb '17

20 Feb '17

> This also provides an opportunity for peer review in cases of misguided > allocation schemes >(such as breaking up a state block by county). > >Tom Tom. Can you validate why using a county scheme is misguided? ---------- Wm Lewis (KG6BAJ) AMPR Net IP Address Coordinator - Northern and Central California Regions (A 100% Volunteer Group) ______________________________________________ ---------- This message is for the designated recipient only and MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. If you have received it in error, please notify the sender immediately and delete the original. Any other use of this E-mail is prohibited.

3 2

How to reach VE2HOM?
by Rob Janssen 19 Feb '17

19 Feb '17

Does anyone know how to reach VE2HOM? He is keeping his contact information well-hidden, it appears. His gateway at 206.80.251.222 is sending a lot of traffic with RFC1918 source address: Feb 19 15:00:53 Packet DROP: IN=tunl0 OUT=eth1 TUNL=206.80.251.222 SRC=192.168.0.5 DST=44.137.42.18 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=13455 DF PROTO=TCP SPT=40510 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0 Feb 19 15:00:57 Packet DROP: IN=tunl0 OUT=eth1 TUNL=206.80.251.222 SRC=192.168.0.5 DST=44.137.42.18 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=38262 DF PROTO=TCP SPT=40512 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0 Feb 19 15:01:01 Packet DROP: IN=tunl0 OUT=eth1 TUNL=206.80.251.222 SRC=192.168.0.5 DST=44.137.42.18 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=14124 DF PROTO=TCP SPT=40480 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0 Everyone remember: when you are combining the routing of AMPRnet and other network traffic, make sure you have the proper routing and/or NAT rules in place, and preferably also a filter, to make sure you don't send traffic with a source address like 192.168.0.5 into an AMPRnet tunnel. Rob

4 3

Configuration for Ubiquity UniFi Gateway
by F. John Rowan 19 Feb '17

19 Feb '17

Has any one successfully configured the Ubiquity UniFi Gateway to work with Amprnet ? If so would you be willing to share your configuration. Thanks

1 0

Re: [44net] Is AMPR still relatively active?
by Rob Janssen 19 Feb '17

19 Feb '17

> I am trying to get a feel for how active AMPR is today. This varies a lot by region. The old network (1200/9600 bps packet radio) is completely dead in most regions and what is left over in those speeds is usually only APRS, so unrelated to IP used in AMPRnet. However, in some places new networks are being built using WiFi technology. Much faster and much more usable. Plus there is tunneling and direct routing of the net-44 space over internet to interconnect those islands. Rob

2 1

Is AMPR still relatively active?
by Jim Hankins 17 Feb '17

17 Feb '17

Greetings, I am trying to get a feel for how active AMPR is today. I am a software developer by trade these days and am relatively new to the hobby but not to IT / networking. Looking for a place to get involved and give back to the community. Regards, Jim KD8MTY Sent from my iPhone

1 0

Re: [44net] Amprnet vpn
by Rob Janssen 17 Feb '17

17 Feb '17

> Subject: > [44net] Amprnet vpn > From: > Shawn Bush <daemon75joker(a)gmail.com> > Date: > 02/17/2017 01:18 PM > > To: > 44net(a)hamradio.ucsd.edu > > > something > that I couldn't figure out how to get a ubuntu vm to run with. > > In the ubuntu host, the ipip works just fine and there is a module for it. > But the module isn't in the VM and I dont see why. You probably are not running a full VM (hardware virtualization with a standard OS running in it) but paravirtualization like Xen which runs a special kernel in the guest machine. This is popular for providing virtual webservers and other "cloud" servers. However, as those servers are normally not full-featured, the guest kernel is compiled with limited selections in the kernel config, and it may well be that exotic features like IPIP tunnels are not provided in that config. When it is your own system, you could opt to compile your own kernel and modify the config while doing that. It may be easier to run the IPIP tunnel gateway on a dedicated system, e.g. a Raspberry Pi (as I do myself) or router (e.g. a MikroTik using Marius YO2LOJ's method. Rob

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net