Replying very late in the game to general Starlink stuff. 1. Don’t trust that your IPv6 prefix will stay the same. I’ve had them change on a service, and last time I looked they don’t really mention IPv6 at all, so all bets are off. 2. Put the Starlink “router” in bridge mode. They are extraordinarily limited in the number of devices they allow behind them. It will all look good for you until too many people connect to the inbuilt wifi and suddenly your router drops (it seems to be a limit of the MAC addresses it allows at once). I’ve seen this where someone put a switch and started adding WAPs. All good until they got to about the third or fourth one and the first people connected started complaining that they had no internet anymore. 3. Starlink does (did?) their IPv4 DHCP renewal as layer 3 from a different source to the original layer 2 broadcast. This means that you may need to allow UDP port 68 in your firewall since your router may now get DHCP responses from a different source. The symptoms of this is that it connects and works, getting an IP via layer 2 DHCP broadcasts. At some point the DHCP renewal will fail because it’s coming from a source different address than the original broadcast. Everything stops until the router throws everything away and starts again sending a new broadcast and getting a new address. As a side note, I’d love to know a better way than to just wildly open UDP port 68! I think that’s pretty much it from a config point of view. The other things to consider: Starlink does slow down and can drop in rain. APNIC found they have increased latency just from cloud cover but I doubt many people would be significantly affected. Dropouts seem to need heavy rain but for farmers this sucks since that is exactly when they are inside trying to catch up on business online. Their latency figures appear often are complete nonsense. Check what the real latency is for you between your sites and decide whether it’s going to make some things unusable or at least unpleasant. Their advertising for pricing is bulls**t and I’m sure violates Australian law. Saying limited time offer reduced from $924, and then as soon at the offer is over the real price is actually only $599 should be investigated by the ACCC and have big consequences. They really do need installing properly as you’ve already noticed. Good cabling installers also tend to hate them, or at least charge more due to the extra work involved. Again their advertising of no installation necessary, or self installable, is bulls**t. Their roof mount kit is junk. In our part of the world (FNQ) where we get cyclones every unit installed this way will almost certainly need to be replaced when it has ripped straight of the roof in even a mild cyclone. Good installers generally use slightly modified (angle grinder cuts) standard satellite dish mounts. Much cheaper and appropriately rated for your area. Everything in our area needs to be cyclone rated so I wonder if this also breaks laws? Experiences in the US indicate that download speeds will drop off as user levels increase. Whether that happens here is hard to know as our population and existing infrastructure is different. Also newer generations of satellites may alleviate this. Personally I don’t want Ellon Musk in control of that much essential global infrastructure. I’m a *very* happy Tesla owner but I personally don’t trust him or his promises. Lastly, as negative as I sound about them, they are amazing technology. They completely change the world for remote areas. The fact that they can do what they do is astounding, and probably only someone like Elon Musk could’ve made it happen. I really hope the mad scramble by Europe and some private companies to produce a competitor works. Once we have more than one option the world will genuinely change. Cheers, Andrew
On 16 Oct 2023, at 9:37 am, Roger Plant <rplant@melbpc.org.au> wrote:
Not sure,
Perhaps it isn't choosing the wireguard interface's ip address for pinging for some reason. If very keen, you could do a packet sniff on the wireguard interface.
Regards Roger
From: Karl Auer <kauer@nullarbor.com.au> To: MikroTik Public <public@talk.mikrotik.com.au> Date sent: Mon, 16 Oct 2023 09:39:29 +1100 Organization: Nullarbor Consulting pty Ltd Subject: Re: [MT-AU Public] Mikrotik and Starlink Send reply to: kauer@nullarbor.com.au, MikroTik Australia Public List <public@talk.mikrotik.com.au>
[ Double-click this line for list subscription options ]
On Sun, 2023-10-15 at 14:55 +0000, Andrew Oakeley wrote:
I'd be inclined to set your allowed-address for the peers to 0.0.0.0/0
On Mon, 2023-10-16 at 09:10 +1100, Roger Plant wrote:
On the Server, You need to add 192.168.16.3 to the allowed addresses in the Client peer entry.
On the Client, You need to add 192.168.16.1 (or maybe .16.0/24 if there will be other peers attached to server in future) to the allowed addresses in the Server peer entry.
I had already tried what Roger suggested, and had added ",192.168.16.0/24" to the allowed-address on each end. It changed the error, but only on the client end, from the error 126 to a timeout.
So I just now tried what Andrew suggested, and FMS it then worked; I could ping each Wireguard interface address from its "opposing" address on the link. But WHY?!? Why was it not enough to add just the Wireguard link subnet to each end's allowed-address list?
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au---------------------------- Roger Plant
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au