Yes, all previous functions/features are there - at least I hope so :-) On 21.05.2017 22:02, Boudewijn (Bob) Tenty wrote:

Here a route list on my test setup: root@server:~# ip ro li table default | grep "via 44." 44.0.0.0/8 via 44.182.21.254 dev eth1.44 44.24.131.0/24 via 44.24.241.98 dev ampr0 proto 44 metric 90 onlink window 840 44.24.241.98 via 44.182.21.254 dev eth1.44 proto 44 onlink 44.130.119.0/24 via 44.130.121.2 dev ampr0 proto 44 metric 90 onlink window 840 44.130.121.0/24 via 44.130.121.2 dev ampr0 proto 44 metric 90 onlink window 840 44.130.121.2 via 44.182.21.254 dev eth1.44 proto 44 onlink 44.130.122.0/23 via 44.130.122.2 dev ampr0 proto 44 metric 90 onlink window 840 44.130.122.2 via 44.182.21.254 dev eth1.44 proto 44 onlink 44.130.124.0/22 via 44.130.124.2 dev ampr0 proto 44 metric 90 onlink window 840 44.130.124.2 via 44.182.21.254 dev eth1.44 proto 44 onlink 44.131.14.252/31 via 44.131.14.253 dev ampr0 proto 44 metric 90 onlink window 840 44.131.14.253 via 44.182.21.254 dev eth1.44 proto 44 onlink 44.136.150.0/23 via 44.136.150.2 dev ampr0 proto 44 metric 90 onlink window 840 44.136.150.2 via 44.182.21.254 dev eth1.44 proto 44 onlink As you can see, there is a host route entry for every 44 gateway. Remember, those entries go into the same routing table as the ampr routes, not in the main table. Marius, YO2LOJ On 22.05.2017 06:12, Boudewijn (Bob) Tenty wrote:

Lynwood, Tnx. Does your iptables filtering work now on the ampr0 interface with the multicast socket instead of the raw socket access? On 22.05.2017 08:50, lleachii--- via 44Net wrote:

Marius, I also wanted to note the same anomalies on LEDE: - have to add the line in the first empty space between includes and change notes. - After doing so, I can only seem to create the ampr-ripd binary for LEDE Atheros MIPS 71xx - using the C++ compiler via the following command (per the OpenWRT/LEDE manuals) and seeing arguments that could bypass certain errors, previously noted): But, a simple hello_world.c file works on the LEDE packaged C compiler. - KB3VWG

Yes, these are issues to be addressed: - It does gateway auto-detection only at startup (FYI: by finding the nexthop for 8.8.8.8 which is usual de default gateway) - It does not accept interface names (possible only for PtP connections) - I will add this in the next release On 25.05.2017 17:07, lleachii--- via 44Net wrote:

Using such an approach is not feasible. The gateway is obtained by interrogating the kernel routing table via a netlink socket about the gateway for that IP and it takes milliseconds. Traceroute needs an implementation in the code, and takes forever. For those who wish it, they can use traceroute, parse the output, and place it as the gateway parameter in the ampr-ripd command line. On 26.05.2017 02:35, lleachii--- via 44Net wrote:

I was talking about traceroute not being feasible. And I would assume, a public DNS is more likely to be reachable via the default gateway, while 169.228.34.84 may be subject to some special routing. e.g. in my case, tunnel endpoints do not use the same ISP as my default gateway: ampr tunnels go via a slow 6Mbps/1Mbps ADSL fixed IP connection, while everything else goes via a fiber optics 1Gbps link with dynamic IP. Everyone is free to use the -g option if needed. On 26.05.2017 03:13, lleachii--- via 44Net wrote:

Is eth0.2 a valid IP? For the moment it accept IP addresses only. I'm working on adding interface names for PtP connections. But this would not work for ethernet connections (including vlans) since the kernel needs an IP to create a route. Marius, YO2LOJ On 26.05.2017 04:00, lleachii--- via 44Net wrote:

Lynwood, The daemon doesn't care if it deals with a vlan or not. But for interfaces which are not point to point, you will need a gateway IP, no matter what. For point to point links, the interface name could suffice, but this is not supported at the moment. There needs to be an IP address for the -g option. Regarding the possibility of re-detection, this is not as easy as it seems. Re-detection is easy, but another additional route management is needed to be able to delete/change established routes (a new list, additional checks, periodic re-detection). This is a quite big change to be done for possible 1 system on the whole ampr network. Can't you just detect the gateway IP change (like in a dynamic dns detection script) and just restart ampr-ripd with a new -g parameter? BTW, your ISP gateway (which you need to use as your gw) probably doesn't change, only your IP. In most dynamic IP use cases there is a router in front of the gateway. In that case, the -g will have the router's local IP as the gateway and would be permanently correct. Marius, YO2LOJ

Marius, I see what you mean, this config only worked on a Brouter. Thanks. - KB3VWG