44net

44net@mailman.ampr.org

3196 discussions

Using IPv6 hosts for AMPRNET
by Steve Fraser 01 Oct '17

01 Oct '17

Hi All, AMPRNET consists of IPv4 addresses 44.x.x.x. Tunnels used to support AMPRNET use IPv4 hosts as destinations for the tunnels, creating a "mesh-like" network. Bent OZ6BL and I have been experimenting with using an IPv6 host to carry AMPRNET traffic. The reason you might want to do this is that IPv6 addresses, particularly static addresses, can be much more readily available than with IPv4. Also, it's an interesting thing to try! We have working tunneled 44.x.x.x connectivity between three different IPv6 hosts. However, there are some issues that arise, mainly due to the way in which AMPRNET functions. Tunneling IPv4 inside IPv6 (ip4in6) is easily done and is well documented. In Linux, commands like these are all that's needed: /sbin/ip -6 tunnel add ip6tnl1 mode ip4ip6 \ remote 2001:0DB8:112:35c::5630:6324 \ local 2001:0DB8:1245:5200::ca0c:5902 /sbin/ip link set dev ip6tnl1 up /sbin/ip route replace 44.145.40.32/32 dev ip6tnl1 src 44.136.170.20 It's very similar to how conventional AMPRNET is set up. However, the first issue is that with ip4in6 you cant (unlike ip4in4) leave the "remote" address empty, and then use routing commands to set the destination for different AMPRNET hosts (you'd be trying to add an IPv4 route to an IPv6 gateway destination). So there's a scalability problem - you'd need to set up a different tunnel device for each subnet you communicate with! The second issue is interoperability - if Alf, Bob and Charlie each only have IPv6 hosted AMPRNET, and Doug, Ed and Fred have only IPv4, then A, B, and C can communicate with themselves, as can D,E,F, but the two groups cannot interconnect from tunneled addresses. Of course, A,B and C could host IP4 tunnels as well, but that would somewhat defeat the purpose! Alternatively, one or more gateways (G) could host both IP4 and IP6 based tunnels, and route between the different type of network, a bit like this: A,B,C <----> G <----> D,E,F Could/should amprgw be configured to do this? Or maybe some hosts elsewhere do that function? But it adds complexity to the overall routing setup (and starts to become a more centralised network). The final issue is dissemination of the information - can the portal be modified to support IPv6 hosts, or do we need another mechanism? Can encap.txt be used still? Would facilities such as ampr-ripd and ripd44 need modifications? So there's plenty to think about.... Steve, VK5ASF

2 1

amusing oddity
by Brian Kantor 01 Oct '17

01 Oct '17

For some bizarre amusement, from your Linux system try traceroute -m 64 bad.horse Don't use the -n option. - Brian

3 2

Proper Advertisement of AMPRnet addresses.
by Mike Vespoli 30 Sep '17

30 Sep '17

I am in need some guidance. I have a number of ways I can use this and I dont want to set it up wrong from the beginning. I was assigned a subnet in Denver, Colorado where I am working with local groups to get on some tower sites, but I have a Data Center in New Jersey that has a large VM infrastructure. I live in Colorado but since the data center is in New Jersey should I get another allocation? I still plan to use the Denver/Colorado Springs subnet, but that upstream ISP is being difficult at the moment since I am a subtenant, and my MOU is only for tower space and a two routers in the cabinet there. I was going to just route the Colorado IPs to my New Jersey Data Center then tunnel back to the Colorado Gateway, but am not sure what the policies on that are. My plans are to offer some free VMs and VPN tunnels to HAMS on my back end systems as well as VPN gateway points, etc. Those would be in NJ, but once I finish my migration into a dedicated cabinet here in Denver I would offer additional VMs / Gateways here as well. Future plans include California and Croatia. Please let me know if anyone has any ideas about what direction I should go. My provider in NJ is ready to add the routes next week (as soon as the go ahead authorization from AMPR). Thanks, Mike Vespoli Denver Colorado KE0HFH

3 3

Re: [44net] ampr.org and 44.in-addr.arpa nameservice
by Rob Janssen 27 Sep '17

27 Sep '17

> Yes, I'm now aware that there are nameservice problems > and I'm working on it. It won't be fixed quickly because > it requires manual intervention by several people in many > different places around the globe, including the registries. > Thanks all for bringing this to my attention. > - Brian Well, it appears that the originally envisioned problem (not all servers uptodate) has been fixed. The 2nd problem (incorrect servers in org zone) is still open, but that should affect only the lookup time. It probably explains why ampr.org lookups are often so slow. However, when I checked before there were only some servers that were at most 24h behind. Maybe they synchronize only once per day. Was that the "slave nameservers are not updating" issue that you were after? Or was there another slave that had not been updating for a much longer time? Generally, 24h out of date should not be that much of an issue. Of course, when it stopped syncing completely that would be bad. Rob

3 4

[44-announce] mailman.ampr.org has a new host
by Brian Kantor via 44-announce 24 Sep '17

24 Sep '17

Through the kind courtesy of John, KI5D, mailman.ampr.org has a new home, on a virtual host in Fremont Calif. It is now at IP address 199.249.223.193, and has a revised SPF record. This should significantly reduce the spam filtering problems we've been having. The hostname and web URLs have not changed. Because of long times-to-live in the ampr.org DNS tables (1 day), your mailer may still attempt to connect to the old address of 44.0.0.1 if you send mail to the 44net(a)mailman.ampr.org or 44-announce(a)mailman.ampr.org mailing lists. It's been about 12 hours since the address change, so about half of the cache entries people may have should have expired by now, but some will not have yet. I've reduced the TTL on ampr.org DNS records to 1 hour from the previous 1 day to help prevent this sort of long cache delay from occuring in the future. If you send mail to the 44net or 44-announce mailing lists and the connection is refused, you have the old address still and your mail should be delivered on some subsequent retry when that entry has expired. Or you might be able to flush the DNS cache on your mail host and retry for faster delivery. Similarly, if your web browser has the old address in its cache, you will get a 404 error attempting to access the mailman web interface. Flush the cache or wait. Thanks John! - Brian -- 44-announce mailing list 44-announce(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44-announce

2 1

spam filtering
by Brian Kantor 23 Sep '17

23 Sep '17

Ever since I moved the 44net mailing list from 'hamradio' to 'mailman' it's been running into spam filters. This is caused in part by the fact that 'mailman' is actually an alternate (duplicate A record) name for 44.0.0.1. The machine serving as 'mailman' is itself dual-homed to both 169.228.34.84 and 44.0.0.1 but uses 169.228.34.84 as its outgoing email IP address, and I can't change that. And UCSD blocks inbound SMTP to 169.228.34.84 as part of THEIR spam filtering. Another part of it was that the mailer on amprgw was identifying itself as 'gw.ampr.org' instead of 'amprgw.ucsd.edu' which is its name when looked up by the outgoing mail IP address of 169.228.34.84. This was tripping spam filters which believed that the mail was coming from a forged address. Among other people, Marius wasn't getting 44net mail because of his site's spam filtering objecting to the misidentification of amprgw's mailer. I've corrected the mailer name issue; it now identifies itself on incoming and outgoing mail as 'amprgw.ucsd.edu' which is its primary name in the DNS. Mail to it as 'amprgw.ucsd.edu', 'amprgw.ampr.org', 'gw.ampr.org', or 'mailman.ampr.org' will all be accepted. (Although mail to amprgw.ucsd.edu will be processed by UCSD's spam filters. Arrgh.) Mail from it will come from a connection from 'amprgw.ucsd.edu'. This may result in the need to adjust a few spam filters but will make other spam filters happy. The mailing list sender address will still be 'mailman.ampr.org'. I have updated the SPF record for that hostname to include all the MXs for it, and both addresses of it (169.228.34.84 and 44.0.0.1): "v=spf1 +mx +a ip4:169.228.34.84/32 ip4:44.0.0.0/24 ?all" With any sort of luck, this will appease the other spam filters. The reason for all this complication is that I've had to condense two machines, hamradio and amprgw, into one because hamradio is going away. The reason for using 'mailman' as the hostname in the mailing list headers is that we may someday move the mailing lists to their own machine with that name (and it's own IP address!) and I don't want to go through the pain of renaming the mailing list once again and having everybody have to change their filters and address books again. So if you encounter difficulties with the mailing list I apologize for the confusion. If this is the first message you've received since the list moved, then I've fixed your problem. If you find this message in your spam mailbox, then I've broken it for you. The basic problem is that there is no good solution for getting rid of spam. SPF is incomplete and DKIM is just broken itself because it breaks years-old tradition of mailing list formats. (It checks the Author address ['From:'] instead of the sender ['Sender:'] or error-return address ['MAIL FROM:' or 'From '] address.) So people, including myself, resort to kludges of various kinds, all of which are not fully satisfactory, and some mail just doesn't get delivered. It's a mess. Sorry. - Brian

3 3

Re: [44net] BeagleBone Black unstable connection.
by Rob Janssen 23 Sep '17

23 Sep '17

> I'm not sure it wasn't premature to go production on, but since this is > also an experimental network, they could just be giving it a try. I agree it is all about experimentation and learning. Learning that adding an IPv6 address may unexpectedly break some things is part of that, and it is better to experience it here that at work on some client visible site :-) Rob

2 1

Re: [44net] BeagleBone Black unstable connection.
by Rob Janssen 23 Sep '17

23 Sep '17

> >/I get 404 too, and I am IPV6. /> Same here, looks like an issue with incorrect IPv6 DNS information? Same here on my dual-stack network. It is probably a result of the recent changes that allow registration of AAAA records in ampr.org, and people experimenting by adding an AAAA record for their hostname to see if that is working. Not a good idea to do that when it either does not point to the same system, or the services on that system (like http/https) are not configured to actually handle the IPv6 case. I have seen this problem before when I added IPv6 capability to my own network and the proxy at work: even some of the "big guys" got this wrong especially in the early days. AAAA record in DNS but IPv6 not actually working, or only for some protocols and not for others. And often no monitoring for IPv6, so nobody noticing. Usually, when this became obvious a slightly different domain name was used for IPv6 testing (e.g. adding a 6 or .ipv6. somewhere), and that is probably what people testing IPv6 on .ampr.org should do as well. Rob

2 1

Re: [44net] spam filtering
by Rob Janssen 23 Sep '17

23 Sep '17

> The reason for all this complication is that I've had to condense two > machines, hamradio and amprgw, into one because hamradio is going away. > The reason for using 'mailman' as the hostname in the mailing list headers > is that we may someday move the mailing lists to their own machine with > that name (and it's own IP address!) It should not be that difficult to run a mailservice on the same machine but with a different address and name. I.e. add 44.0.0.2 to the machine, move mailman.ampr.org there, and run all SMTP services on that address and corresponding name. Then the move to the new machine is transparent. But otherwise, it is a good idea to use virtualization as much as possible. This can be classical hardware virtualization like we use (VMware ESXi) but there are also leaner methods. That way, you can keep the different tasks on separate virtual machines, on separate addresses with their corresponding hostname, and there is also a lot less impact when one time you want to update the OS or switch to another OS. (e.g. you could run the mailman on Linux and the gw on BSD, and maybe experiment with a new gw running on Linux, all on the same hardware) Rob

2 1

BeagleBone Black unstable connection.
by W.B.Hill 23 Sep '17

23 Sep '17

Hi, I'm moving my 44net connection from an OpenWRT device to a BeagleBone Black, because I've got a TNCblack to connect directly to a radio. However, in testing I'm finding the 44net connection doesn't stay up, max about 36hours before a reboot is required. Any ideas why this is, or how I could diagnose further. The device is always accessible via the local WiFi connection. Currently I've just got this tacked onto the end of my rc.local #Start 44net /usr/sbin/amprd -d -v 2> /var/log/amprd/amprd_err.log > /var/log/amprd/amprd_std.log & sleep 30 ip route add default via 169.228.34.84 dev ampr0 onlink table default ip rule add from 44.131.170.1 table default ip rule add from 44.131.170.1 to 44.131.170.0/30 table main sleep 10 ping -Iampr0 -c10 gw.ampr.org > /dev/null Device is on m1bkf.ampr.org - sometimes! Thanks. Bill (M1BKF) -- Red to red, black to black, switch it on, but stand well back.

6 7

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net