19 Jan
2024
19 Jan
'24
3:20 p.m.
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
19 Jan
19 Jan
7:03 p.m.
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(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
20 Jan
20 Jan
12:52 a.m.
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
8:51 p.m.
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:
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
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
21 Jan
21 Jan
12:03 a.m.
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
1:25 a.m.
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(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
9:15 p.m.
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..
109
days inactive
111
days old
6 comments
2 participants
participants (2)
-
kc8qba＠wildtky.com -
Marius Petrescu