listen_addrs lags updating newly assigned IP of hotspot

[ghost]

listen_addrs takes 12-22 hrs to update to a new IP of an unrelayed hotspot.
Used to take <1hr but lag has increased exponentially and still is. Move to Validators has not changed that so far.

Since in EU countries some ISPs disconnect internet and assign new IPs every 24hrs, those hotspots are becoming effectively cut off from receiving challenges and transmitting beacons.

[LilaQ]

Not even a comment on this?

[dakky221]

I will just add my comment that I have exactly the same problem, and so far I've been pointed out to the libp2p which Helium uses for this. The hotspot just doesn't checks it's external IP as often as it should, which results in a lag. Workaround is to reboot/power cycle the hotspot occasionally, as that will force the check of the public IP and then update the blockchain and gossip through p2p.

[ghost]

I will just add my comment that I have exactly the same problem, and so far I've been pointed out to the libp2p which Helium uses for this. The hotspot just doesn't checks it's external IP as often as it should, which results in a lag. Workaround is to reboot/power cycle the hotspot occasionally, as that will force the check of the public IP and then update the blockchain and gossip through p2p.

That is not technically correct. The hs is only aware of its assigned local (static) IP. When the hs issues a challenge package, the router - not the hs - includes the public IP in the package as sender address, which is then propagated p2p through the network. That is why a PF rule is required for the router to correctly forward incoming packages sent to the public IP through to the hs' local IP.

The time to propagate an IP p2p increases the more the network grows. Since the network has grown exponentially, so has the time to propagate a public IP.
Powercycling might help reduce waiting-time to issuing the next challenge, but with a PoC-interval of currently 300 blocks compared to the current observed propagation time of 16-28 hrs, it does not make much difference, when public IPs are re-issued every 24hrs.

[dakky221]

Actually, I am technically correct, and unfortunately - you are incorrect. But I'm not going to argue here, it is not the place. If you checked libp2p you would have noticed the variable NAT_EXTERNAL_IP, but you didn't and you have no idea what are you talking about. ;)

[ghost]

I always prefer to be corrected when wrong. I think you are referring to Validators, not hs. But in one thing I agree with you, this is not the place.

[dakky221]

Messaged you on Discord, if you need an explanation why you are wrong.

Anyway, to stay on topic, current solution is either to broadcast a correct public IP through the validator/cloud miner OR to reboot the hotspot. Once per day will definitely shorten the SD card lifespan, but that's the only solution till they implement the external IP check to happen more often (ideally every 5 minutes or so).

[ghost]

Read it through and not seeing which part(s) of my comment I'm technically wrong.
Anyway my guess is, that propagating through a validator is a solution, but as long there's no way for a hs/router to target a validator to "broadcast" its public IP to, it's academical.
With powercycling propagating an IP would still have to take the "ordinary" slow road.

As workaround I removed PF running hs on relay, with improved results compared to with activated PF. Another possible alternative would be to setup a VPS and tunnel a static IP.

Thanks for the link, interesting read and somewhat enjoyable to see even CoreDevs don't know everything for certain.

[dakky221]

You are technically wrong on how ipv4 works and what role your router has in it and how hotspots reach the p2p network and how the peers on p2p network get back to the hotspot. It has a lot to do with ipv4 packet headers and tcp/ip model while it absolutely has nothing to do with your PF. PF is running on just one layer of all that and is irrelevant to what is happening here.

[ghost]

Then let's leave it at that you know more than I do and will dig deeper into the subject - I do appreciate the straight talk.

[shawaj]

FYI @danggoma helium/erlang-libp2p#373

[ghost]

FYI @danggoma helium/erlang-libp2p#373

Yep, thanks.
The reason I closed this issue.