Hello! I've been working on getting my IPIP mesh gateway set up on Debian & feel like I'm almost there. One thing I’ve noticed is every time I reboot the router, it takes around 45-60 minutes before I can start passing traffic to the public internet again via the ucsd gateway. For example, after rebooting the router, once rip44d has retrieved the routes I can:
(a) Ping and curl across tunl0 to n2nov.ampr.org (b) Use yo2tm’s nettools to successfully ping my ampr ip and see that traffic locally via tcpdump
But cannot: (c) Ping 8.8.8.8 across tunl0 (via 169.228.34.84) or (d) Curl to ifconfig.me across tunl0 (via 169.228.34.84)
However, if I just leave everything running and come back 45-60 minutes later, (c) and (d) work fine with no additional configuration changes and (d) returns the assigned 44net ip address.
Just curious if the above is an expected behavior or a sign that I’ve got something misconfigured.
-Steve kc8qba
Hi Steve,
I assume you registered your gateway with a dynamic IP address. In that case afaik the behavior is like expected.
- The mesh connections are updated on the first RIP sending via DNS resolution on the gateway side. - The forwarding rules of the ucsd gateway are scheduled for update once per hour or so, giving that delay you are noticing.
If you have a fixed IP address this should not happen, since no change in the IP configuration at ucsd is necessary.
Marius, YO2LOJ
On 19/01/2024 17:20, kc8qba--- via 44net wrote:
Hello! I've been working on getting my IPIP mesh gateway set up on Debian & feel like I'm almost there. One thing I’ve noticed is every time I reboot the router, it takes around 45-60 minutes before I can start passing traffic to the public internet again via the ucsd gateway. For example, after rebooting the router, once rip44d has retrieved the routes I can:
(a) Ping and curl across tunl0 to n2nov.ampr.org (b) Use yo2tm’s nettools to successfully ping my ampr ip and see that traffic locally via tcpdump
But cannot: (c) Ping 8.8.8.8 across tunl0 (via 169.228.34.84) or (d) Curl to ifconfig.me across tunl0 (via 169.228.34.84)
However, if I just leave everything running and come back 45-60 minutes later, (c) and (d) work fine with no additional configuration changes and (d) returns the assigned 44net ip address.
Just curious if the above is an expected behavior or a sign that I’ve got something misconfigured.
-Steve kc8qba _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Thanks Marius, The gateway is configured on the AMPRnet portal with a static IP - the other interesting thing I've noticed is that when trying to curl out to ifconfig.me:
1. Initially curl won't be able to connect (0-30 min after gateway reboot) 2. Then curl will be able to connect but ifconfig.me will reply with an error instead of my IP address (30-40 min after reboot) 3. Then ifconfig.me will return the correct IP address (40+ after reboot)
Given that there doesn't appear to be an issue with traffic between other ipip peers it makes me wonder if it's something to do with how the ucsd gateway is announcing my AMPRnet ip to the public.
Best, -Steve kc8qba
What is your default gateway settings for outgoing connections from ampr addresses? AMPR doesn't announce your IPs individually on the internet. It announces only 44.0.0.0/9 and 44.128.0.0/10.
On 20/01/2024 02:52, kc8qba--- via 44net wrote:
Thanks Marius, The gateway is configured on the AMPRnet portal with a static IP - the other interesting thing I've noticed is that when trying to curl out to ifconfig.me:
- Initially curl won't be able to connect (0-30 min after gateway reboot)
- Then curl will be able to connect but ifconfig.me will reply with an error instead of my IP address (30-40 min after reboot)
- Then ifconfig.me will return the correct IP address (40+ after reboot)
Given that there doesn't appear to be an issue with traffic between other ipip peers it makes me wonder if it's something to do with how the ucsd gateway is announcing my AMPRnet ip to the public.
Best, -Steve kc8qba _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
I've got: ip route add default via 169.228.34.84 dev tunl0 onlink table 44 ip rule from 44.0.0.0/9 priority 1 table 44 ip rule to 44.0.0.0/0 priority 1 table 44 also, rip44d is -i tunl0 -a my_public_gateway_ip -t 44 -p password
Ok, so that's not 100% correct/complete, but it is not the cause of the observed behavior...
Since there are 2 parts to this network, the correct set should be:
ip route add default via 169.228.34.84 dev tunl0 onlink table 44 ip rule from 44.0.0.0/9 priority 1 table 44 ip rule from 44.128.0.0/10 priority 1 table 44
The last part has no effect (an IP other than 0.0.0.0 with netmask /0 makes no sense), but it is superseded by the default rule anyway. The correct form would be: ip rule to 44.0.0.0/9 priority 1 table 44 ip rule to 44.128.0.0/10 priority 1 table 44
At least this is not the reason why it happens...
On 21/01/2024 02:03, kc8qba--- via 44net wrote:
I've got: ip route add default via 169.228.34.84 dev tunl0 onlink table 44 ip rule from 44.0.0.0/9 priority 1 table 44 ip rule to 44.0.0.0/0 priority 1 table 44 also, rip44d is -i tunl0 -a my_public_gateway_ip -t 44 -p password _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Apologies for the typo, the to rule I had was also: ip rule to 44.0.0.0/9 priority 1 table 44
I've done some additional testing by bringing up a second debian device, performing the same configuration using a different 44net ip (w/dns entry) from my allocation, & putting the second device in the DMZ which results in connectivity across the UCSD gateway with no delay.
I sincerely appreciate the feedback - it's definitely been a learning experience & I may try to replicate from another location with a different ISP/CPE/etc..
-
kc8qba＠wildtky.com -
Marius Petrescu