Multiple endpoints. Have more than one router per region or the possibility to announce the subnet through another region and tunnel back to there. If region A goes down, region B takes over and tunnels to region A will have to be (auto would be my preference) rebuild to region B Ruben - ON3RVH

Rob, * FYI - Wireguard has a Windows client; but I get your point about being OS/NOS agnostic * I honestly understand there to exist 2 common paradigms: 1.) those who route IPs to others/clients/hosts; and 2.) those who only tunnel the AMPR IPs to a single device. Your statement primarilly covers the latter use case. * I know of no embedded "Windows routers" (well there are small x86_64 machines) * IP Protocol No. 4 (IPENCAP) is possible on Windows (specifics unclear)...but there was never much support to ensure ampr-ripd/rip44d/something was tested/working, at least when I was attempting in 2012 * I found out even if I got a Windows machine working, if I wanted to do DNS (which I noted to late Brian that I would for the MDC Section), I leaned the Windows dns.exe executable will crash attempting to load our Public Forward and Reverse Zones - so I still need a *nix server/router - KB3VWG --- I think we should avoid running into traps like "let us choose that new wireguard as thestandard protocol to be used by everything" as we would again exclude everything outside of Linux and OpenWRTand end up in the same situation as we now are with IPIP mesh: always requiring the user to install a Linux box.

Lynwood, On 29.12.20 at 13:28 wrote lleachii(a)aol.com: :-) I was, but not more The modules is available by default in stock debian. Ok, why do you think so? These are not my invention, I copied them from templates in the ampr wiki. AFAIK they refelct the fact of the sold upper quater of the addresses, no? No, I am using ampr-ripd. vy 73 Roland, oe1rsa -- __________________________________________ _ _ | Roland Schwarz |_)(_ | | \__) | mailto:roland.schwarz@blackspace.at ________| http://www.blackspace.at

Roland, * I tested on a Ubuntu system, so the 'sudo modprobe -r ipip' command worked as tested. I gleaned to use it '-r' from the Startampr wiki (I developed the script with PE1CHL and others on the mailing group here). Therefore, I cannot speak specifically to why Debian automatically pre-loads the Kernel module. Can you explain the issue this presents for you? Could a firewall rule fix it? You only have a single /32 IP - this shouldn't cause a major issue to your setup. * Can you show the Wiki URL you're referencing that tells you to make a route for 44.0.0.0/9 and 44.128.0.0/10 - so it may be corrected? I know the routes to be invalid; because they do not specify where those subnets in the /9 and /10 are exactly located (e.g. your IP 86.5x.x.42 to reach 44.130.240.3/32). That's what ampr-ripd or rip44d does. You should now be able to see valid routes by running the command 'ip route show table 44' * You noted you're running ampr-ripd...but answered no....that confused me, but nonetheless I see it's running successfully; perhaps it was semantics or a language barrier. - KB3VWG :-) I was, but not more The modules is available by default in stock debian. Ok, why do you think so? These are not my invention, I copied them from templates in the ampr wiki. AFAIK they refelct the fact of the sold upper quater of the addresses, no? No, I am using ampr-ripd.

Roland, My apologies, those being IP RULES and not ROUTEs....you are correct. Thanks for the clarity. Be mindful though, some routes will use your Ethernet and will therefore need to be masqueraded. I was going to provide an example of such an an IP - but as someone else said, those routes appears down or at least un-pingable. You can see these routes on your device by running the command 'ip route show table 44 | grep enp2s0' - KB3VWG

Let me explain those rules a little, since the wiki just puts them there without a "why" explanation... In that specific setup mode, we have some routing tables (table 44 an 45 could actually have any number as long as the configuration is modified accordingly): - the main table (32767), holding our regular routes, like default gateway, subnets and other static stuff. Usually it is something like:     192.168.0.0/24 via eth1     default via eth1 - table default (32767), usually empty, holds the default routes if the main table does not specify a default route - table 44 will hold all routes created by the ampr-ripd daemon. They are in a format like <subnet> via <gateway> dev <tunnel> onlink Note that there is usually no default gateway in this table - optional table 45, holding the return route for connections initiated from the internet to your 44net machine Usually this holds a single route default via 169.228.34.84 dev <tunnel> onlink Now let's come to the rules: They tell the system, that routes to those subnets (44.0.0.0/9 and 44.128.0.0/10) should be looked up in table 44 first. If found, those routes will be used (ipip encap to the proper gateway, as defined in that 'via'). If the route is not found, the system will fall back to the main table, do the lookup there and in the end will use the default gateway as defined. If there is a default gateway defined in table 44, it will use that one (this will burden the ampr gateway but you will have an outgoing 44 address - do not use it for ALL of your internet access). Table 45, just to complete the description, has the role of replying to internet connection requests from the via the tunnel. For this, you need to mark incoming requests with a connection mark, 45, and all those marked with connection mark 45 with a routing mark of 45. So a minimal gateway start script would look like this, assuming that the tunnel interface name is tun44 and it is configured properly before starting this script, e.g. in 'interfaces': #!/bin/sh MY_IP=`ip addr list dev tun44 | grep inet | awk '{print $2}'` # wait for tunnel interface while [ "$MY_IP" == "" ]; do     sleep 1     MY_IP=`ip addr list dev tun44 | grep inet | awk '{print $2}'` done # AMPR routes go to table 44 # ip rule add from $MY_IP table 44 ip rule add to 44.0.0.0/9 table 44 ip rule add to 44.128.0.0/10 table 44 # default AMPR reply route is in table 45 # ip route add default via 169.228.34.84 dev tun44 table 45 onlink # mark incoming and route replies via table 45 # ip rule add fwmark 45 table 45 iptables -t mangle -A PREROUTING -i tun44 ! -s 44.0.0.0/8 -j CONNMARK --set-mark 45 iptables -t mangle -A PREROUTING ! -i tun44 -m connmark --mark 45 -j CONNMARK --restore-mark iptables -t mangle -A OUTPUT -m connmark --mark 45 -j CONNMARK --restore-mark # start ampr-ripd (add your -a parameter if needed) ampr-ripd -s -t 44 -i tun44 -m 90 Of course, this can be migrated to 'interfaces' as 'up' steps (so please adapt as 44.128.x.y and 192.x.y.z are not valid, note the rmmod at the end to clear that tunnel0) iface ampr0 inet static         address 44.128.x.y         netmask 255.255.255.255         metric 100         pre-up ip tun add ampr0 mode ipip ttl 64 local 192.x.y.z dev eth0 # uncomment for bgp 44 routing via ampr-gw #       up ip route add 44.0.0.0/9 via 169.228.34.84 dev ampr0 onlink table 44 onlink #       up ip route add 44.128.0.0/10 via 169.228.34.84 dev ampr0 onlink table 44 onlink         up ip route add default via 169.228.34.84 dev ampr0 onlink table 45 onlink         up ip rule add from 44.128.x.y table 44         up ip rule add to 44.0.0.0/9 table 44         up ip rule add to 44.128.0.0/10 table 44         up ip rule add fwmark 45 table 45         up ampr-ripd -s -t 44 -i ampr0 -m 90 -L n0call@aa00aa         post-down killall ampr-ripd         post-down ip rule del fwmark 45 table 45         post-down ip rule del to 44.128.0.0/10 table 44         post-down ip rule del to 44.0.0.0/9 table 44         post-down ip rule del from 44.128.x.y table 44        post-down ip tunnel del ampr0        post-down rmmod ipip So there it is, and maybe it helps. Feel free to add some of it to the Wiki if it seems useful (I don't like modifying things written by others...). Marius, YO2LOJ On 29.12.2020 14:28, lleachii--- via 44Net wrote: