- brought back option -r, to allow using multicast sockets by default
and raw sockets as a backup for systems with multicast issues. This will hopefully sort out the firewall filtering inability on previous releases since 1.13.
I had to put back the -r option that I had cleaned up from my start script as it still does not work with the multicast socked on Debian Linux with kernel 3.16. I remember it failed after some kernel update and it apparenty is still broken. However, I do not mind using the -r option, only want to remind people that they may need to put it back.
Rob
Yes, the -r switch has to go back for those situations.
Strangely, I use Debian 8.7 with kernel 3.16 and it works without the '-r' switch.
Actually it seems to be a cach to the Debian 8 IPIP driver: It does not receive traffic before some "internal" activation.
So in my setup, in the network/interfaces file I use the following:
interface ampr0
...
up ping -c 1 -I ampr0 169.228.66.251 > /dev/null 2>&1
...
Marius, YO2LOJ
On 21.05.2017 10:04, Rob Janssen wrote:
(Please trim inclusions from previous messages) _______________________________________________
- brought back option -r, to allow using multicast sockets by default
and raw sockets as a backup for systems with multicast issues. This will hopefully sort out the firewall filtering inability on previous releases since 1.13.
I had to put back the -r option that I had cleaned up from my start script as it still does not work with the multicast socked on Debian Linux with kernel 3.16. I remember it failed after some kernel update and it apparenty is still broken. However, I do not mind using the -r option, only want to remind people that they may need to put it back.
Rob
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Marius,
Has this new version also the mod so that it adds also a direct route for the next hop gateway address if it is a 44 address in the ipip route and not commercial?
Bob VE3TOK
On 2017-05-21 04:16 AM, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Yes, the -r switch has to go back for those situations.
Strangely, I use Debian 8.7 with kernel 3.16 and it works without the '-r' switch.
Actually it seems to be a cach to the Debian 8 IPIP driver: It does not receive traffic before some "internal" activation.
So in my setup, in the network/interfaces file I use the following:
interface ampr0
...
up ping -c 1 -I ampr0 169.228.66.251 > /dev/null 2>&1
...
Marius, YO2LOJ
Yes, all previous functions/features are there - at least I hope so :-)
On 21.05.2017 22:02, Boudewijn (Bob) Tenty wrote:
(Please trim inclusions from previous messages) _______________________________________________ Marius,
Has this new version also the mod so that it adds also a direct route for the next hop gateway address if it is a 44 address in the ipip route and not commercial?
Bob VE3TOK
On 2017-05-21 04:16 AM, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Yes, the -r switch has to go back for those situations.
Strangely, I use Debian 8.7 with kernel 3.16 and it works without the '-r' switch.
Actually it seems to be a cach to the Debian 8 IPIP driver: It does not receive traffic before some "internal" activation.
So in my setup, in the network/interfaces file I use the following:
interface ampr0
...
up ping -c 1 -I ampr0 169.228.66.251 > /dev/null 2>&1
...
Marius, YO2LOJ
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
I'm afraid it doesn't work here with version 2.0 Marius and I assume it does this by default as I see no option for it. I checked all those with 44 address endpoints/gateways and no direct routes are added for these. Take for instance "44.130.124.2". I have to add a direct route manually to reach it
Bob VE3TOK
On 2017-05-21 03:30 PM, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Yes, all previous functions/features are there - at least I hope so :-)
On 21.05.2017 22:02, Boudewijn (Bob) Tenty wrote:
(Please trim inclusions from previous messages) _______________________________________________ Marius,
Has this new version also the mod so that it adds also a direct route for the next hop gateway address if it is a 44 address in the ipip route and not commercial?
Bob VE3TOK
On 2017-05-21 04:16 AM, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Yes, the -r switch has to go back for those situations.
Strangely, I use Debian 8.7 with kernel 3.16 and it works without the '-r' switch.
Actually it seems to be a cach to the Debian 8 IPIP driver: It does not receive traffic before some "internal" activation.
So in my setup, in the network/interfaces file I use the following:
interface ampr0
...
up ping -c 1 -I ampr0 169.228.66.251 > /dev/null 2>&1
...
Marius, YO2LOJ
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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:
(Please trim inclusions from previous messages) _______________________________________________ I'm afraid it doesn't work here with version 2.0 Marius and I assume it does this by default as I see no option for it. I checked all those with 44 address endpoints/gateways and no direct routes are added for these. Take for instance "44.130.124.2". I have to add a direct route manually to reach it
Bob VE3TOK
On 2017-05-21 03:30 PM, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Yes, all previous functions/features are there - at least I hope so :-)
On 21.05.2017 22:02, Boudewijn (Bob) Tenty wrote:
(Please trim inclusions from previous messages) _______________________________________________ Marius,
Has this new version also the mod so that it adds also a direct route for the next hop gateway address if it is a 44 address in the ipip route and not commercial?
Bob VE3TOK
On 2017-05-21 04:16 AM, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Yes, the -r switch has to go back for those situations.
Strangely, I use Debian 8.7 with kernel 3.16 and it works without the '-r' switch.
Actually it seems to be a cach to the Debian 8 IPIP driver: It does not receive traffic before some "internal" activation.
So in my setup, in the network/interfaces file I use the following:
interface ampr0
...
up ping -c 1 -I ampr0 169.228.66.251 > /dev/null 2>&1
...
Marius, YO2LOJ
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Marius et all,
root@router:~# ip route get 44.130.124.2 from 44.60.44.1 44.130.124.2 from 44.60.44.1 via 71.163.244.1 dev eth0.2 table 44 cache
I have a route. I use ampr-ripd 2.0
73,
- Lynwood KB3VWG
I'm afraid it doesn't work here with version 2.0 Marius and I assume it does this by default as I see no option for it. I checked all those with 44 address endpoints/gateways and no direct routes are added for these. Take for instance "44.130.124.2". I have to add a direct route manually to reach it
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:
(Please trim inclusions from previous messages) _______________________________________________ Marius et all,
root@router:~# ip route get 44.130.124.2 from 44.60.44.1 44.130.124.2 from 44.60.44.1 via 71.163.244.1 dev eth0.2 table 44 cache
I have a route. I use ampr-ripd 2.0
73,
- Lynwood
KB3VWG
I'm afraid it doesn't work here with version 2.0 Marius and I assume it does this by default as I see no option for it. I checked all those with 44 address endpoints/gateways and no direct routes are added for these. Take for instance "44.130.124.2". I have to add a direct route manually to reach it
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Marius,
Yes, It works as expected:
44
3.99 KB ACCEPT 4 * * 0.0.0.0/0 0.0.0.0/0 match-set ipipfilter src /* !fw3: Allow-AMPR_IPENCAP */
5355
2.69 MB ACCEPT udp * * 44.0.0.1 224.0.0.9 udp spt:520 dpt:520 /* !fw3: Allow-AMPR_RIP */
- KB3VWG
Marius,
I also wanted to note the same anomalies on LEDE:
- have to add the line
#define IPPORT_ROUTESERVER 520
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):
mips-openwrt-linux-musl-g++ ampr-ripd.c -v -fpermissive -Wwrite-strings
But, a simple hello_world.c file works on the LEDE packaged C compiler.
- KB3VWG
Marius,
I have a query regarding the -g argument and its auto-detect feature.
-g <gateway> Gateway for direct 44net connections. If not set, it will be auto-detected
- Does ampr-ripd auto-detect while it's running, or only at the beginning of execution? - If it only runs at execution, is it possible an <interface> could be specified instead of <gateway_IP>?
My concern:
On my device (on the date I lost Internet for 2 hours), I lost Layer 3 connectivity to my carrier. When my gateway came back online, it had a new IP, in a new SUBNET (and therefore, a new Gateway). My routes (and the running ampr-ripd process) may have specified an invalid next hop not for sending traffic to the WAN; and direct 44 connections (I assumed) failed until reboot.
- Lynwood 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:
(Please trim inclusions from previous messages) _______________________________________________ Marius,
I have a query regarding the -g argument and its auto-detect feature.
-g <gateway> Gateway for direct 44net connections. If not set, it will be auto-detected
- Does ampr-ripd auto-detect while it's running, or only at the
beginning of execution?
- If it only runs at execution, is it possible an <interface> could be
specified instead of <gateway_IP>?
My concern:
On my device (on the date I lost Internet for 2 hours), I lost Layer 3 connectivity to my carrier. When my gateway came back online, it had a new IP, in a new SUBNET (and therefore, a new Gateway). My routes (and the running ampr-ripd process) may have specified an invalid next hop not for sending traffic to the WAN; and direct 44 connections (I assumed) failed until reboot.
- Lynwood
KB3VWG
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Marius,
Whoa!
(FYI: by finding the nexthop for 8.8.8.8 which is usual de default gateway)
I missed this reading the code...I looked this morning to make sure the Old_AMPRGW IP wasn't hard coded. I need to see more how this next hop is found. I surmise if I were to disable all output from my WAN by default, autodetect would fail...unless I allowed output to 8.8.8.8?
(my concern are not firewalls...or Alphabet, Inc...it's a shied-away-from practice of hard-coding IPs...you don't have permission from the RFC Editor to hard-code)
In your next version, might I suggest a traceroute to 169.228.34.84 instead?
- Lynwood KB3VWG
- KB3VWG
PS: I think of you, my friend, when I allow output on WAN by default, lol. (I don't do that.)
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:
(Please trim inclusions from previous messages) _______________________________________________ Marius,
Whoa!
(FYI: by finding the nexthop for 8.8.8.8 which is usual de default gateway)
I missed this reading the code...I looked this morning to make sure the Old_AMPRGW IP wasn't hard coded. I need to see more how this next hop is found. I surmise if I were to disable all output from my WAN by default, autodetect would fail...unless I allowed output to 8.8.8.8?
(my concern are not firewalls...or Alphabet, Inc...it's a shied-away-from practice of hard-coding IPs...you don't have permission from the RFC Editor to hard-code)
In your next version, might I suggest a traceroute to 169.228.34.84 instead?
- Lynwood
KB3VWG
- KB3VWG
PS: I think of you, my friend, when I allow output on WAN by default, lol. (I don't do that.)
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Switching to 169.228.34.84 from 8.8.8.8???
Thats not feasible?
::lost in translation::
- KB3VWG
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:
(Please trim inclusions from previous messages) _______________________________________________ Switching to 169.228.34.84 from 8.8.8.8???
Thats not feasible?
::lost in translation::
- KB3VWG
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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:
(Please trim inclusions from previous messages) _______________________________________________ Marius,
Everyone is free to use the -g option if needed
Yes, but is eth0.2 a valid entry?
- KB3VWG
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Marius,
If my VLAN has an IP...will it work?
root@router:~# ifconfig eth0.2 eth0.2 Link encap:Ethernet HWaddr 00:90:A9:AE:1E:06 inet addr:71.163.244.98 Bcast:71.163.244.255 Mask:255.255.255.0
- KB3VWG
the kernel needs an IP to create a route.
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,
That's OK. It's not a big issue for me - especially if a great deal of re-coding would be necessary.
If I ever notice my WAN IP change, I usually reboot anyway.
As I noted, my subnet and gateway changed; this only occurs about once every 6 months or so. Thanks for considering. I'll just reboot as always.
- Lynwood KB3VWG
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
Rob,
Do you have a firewall that drops by default?
On my machine, I have to allow 520/udp from 44.0.0.1 to 520/udp at 244.0.0.9. I also have to allow IPENCAP. I now use a dynamic rule so only IPs in the Portal can send IPENCAP packets.
I recall my requiring to added these iptables rules around that time. It had to so with kmod-ipip and netfilter/iptables. They were not FILTERED as they are now.
- Lynwood KB3VWG
I had to put back the -r option that I had cleaned up from my start script as it still does not work with the multicast socked on Debian Linux with kernel 3.16. I remember it failed after some kernel update and it apparenty is still broken.
-
Boudewijn (Bob) Tenty -
lleachii＠aol.com -
Marius Petrescu -
Rob Janssen