Re: [Bloat] mDNS

2024-02-28 Thread Juliusz Chroboczek via Bloat
>> I'm not sure how that could happen at boot time, it would need to
>> happen whenever a DHCPv4 lease changes.  This implies that the router
>> might need to renumber if the ISP changes its allocation, and there are
>> no renumbering procedures for IPv4 (I'm not sure if anyone implements
>> RFC 3203).

> it's unusual for the network block to change on a renewal,

At any rate, boot time is too early, since you don't know your
ISP-assigned address at that point.  You really need to delay until DHCPv4
gets a lease.

> and in that rare case you could reboot the router.

You don't need to reboot the router, it can renumber just fine.  You need
to reboot all the client devices (unless they implement DHCPv4 force renew
with nonce authentication, aka RFC 3203).

I'm not saying it's a bad idea, just pointing out some of the edge-cases
that you will need to consider in order to get a robust implementation.

-- Juliusz
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat


[Bloat] latency on hackernews

2024-02-28 Thread Dave Taht via Bloat
This was delicious:

"If latency doesn’t matter, can I create a service that cross-ships
1TB HDDs overnight and call it broadband?" -

https://news.ycombinator.com/item?id=39533800#39534166

Could someone weigh in over there with the current starlink measuremetns.

On Tue, Feb 27, 2024 at 11:08 PM Dave Taht  wrote:
>
> a little seo might help:
>
> https://news.ycombinator.com/item?id=39533800
>
> --
> https://blog.cerowrt.org/post/2024_predictions/
> Dave Täht CSO, LibreQos



-- 
https://blog.cerowrt.org/post/2024_predictions/
Dave Täht CSO, LibreQos
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat


Re: [Bloat] mDNS

2024-02-28 Thread Rich Brown via Bloat
I'm not advocating that we change the default OpenWrt address from 192.168.1.1 
That's welded too deeply into our synapses (and documentation). But this 
proposal will benefit newcomers for the reasons described below.

> On Feb 28, 2024, at 7:17 AM, David Lang  wrote:
> 
> remember, you don't need to randomly pick something, you just need to have a 
> couple networks, figure out if one is in use by the WAN and if so pick the 
> other.

Remember, too, that this proposal is designed to solve problems for first-time 
users. This lets them avoid reading an entire page of documentation that 
explains how to find their ISP's assigned subnet, and then set their new 
OpenWrt device LAN to use a different subnet.

This won't affect experienced OpenWrt users. On an initial flash/configuration, 
they'll know they can use 192.168.1.0/24 because they know their upstream 
device configuration. Or they can log in using the mDNS name and configure it 
themselves.

> I will say that 192.168.0 and 192.168.1 are very commonly used, so anything 
> other than those a better default
> 
> personally, I like 192.168.255 as people tend to forget that's a valid 
> network.

So... Is there any reason not to incorporate this into the OpenWrt default 
build? Thanks again.

-- Rich___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat


Re: [Bloat] mDNS

2024-02-28 Thread David Lang via Bloat

On Wed, 28 Feb 2024, Juliusz Chroboczek via Bloat wrote:


But my point is that the OpenWrt router has no way to predict what
address/subnet will be assigned to its WAN port.


In principle, the ISP should assign either a global address, or an address in
the range 100.64.0.0/10 (RFC 6598).  This range was deliberately chosen to
not collide with RFC 1918 space, so that the NAT box can choose any RFC 1918
prefix on its downstream interfaces.

In practice, however, ISPs don't necessarily obey the RFCs, and people do
chain NAT boxes, so none of the above is guaranteed.


chaining NAT boxes is very common, too many ISPs don't give you anything other 
than a NAT address from their router



Consequently, at boot-time, OpenWrt should simply choose some different
subnet for its LAN subnet(s), and then advertise an mDNS name.


I'm not sure how that could happen at boot time, it would need to happen
whenever a DHCPv4 lease changes.  This implies that the router might need
to renumber if the ISP changes its allocation, and there are no
renumbering procedures for IPv4 (I'm not sure if anyone implements RFC 3203).


it's unusual for the network block to change on a renewal, and in that rare case 
you could reboot the router.



It would also make addressing non-deterministic, which would make
debugging slightly more difficult.  But then, we already have
non-deterministic addressing in IPv6, so I guess that's something we can
live with.


remember, you don't need to randomly pick something, you just need to have a 
couple networks, figure out if one is in use by the WAN and if so pick the 
other.


I will say that 192.168.0 and 192.168.1 are very commonly used, so anything 
other than those a better default


personally, I like 192.168.255 as people tend to forget that's a valid network.

David Lang


-- Juliusz
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat


Re: [Bloat] mDNS

2024-02-28 Thread Juliusz Chroboczek via Bloat
> But my point is that the OpenWrt router has no way to predict what
> address/subnet will be assigned to its WAN port.

In principle, the ISP should assign either a global address, or an address in
the range 100.64.0.0/10 (RFC 6598).  This range was deliberately chosen to
not collide with RFC 1918 space, so that the NAT box can choose any RFC 1918
prefix on its downstream interfaces.

In practice, however, ISPs don't necessarily obey the RFCs, and people do
chain NAT boxes, so none of the above is guaranteed.

> Consequently, at boot-time, OpenWrt should simply choose some different
> subnet for its LAN subnet(s), and then advertise an mDNS name.

I'm not sure how that could happen at boot time, it would need to happen
whenever a DHCPv4 lease changes.  This implies that the router might need
to renumber if the ISP changes its allocation, and there are no
renumbering procedures for IPv4 (I'm not sure if anyone implements RFC 3203).

It would also make addressing non-deterministic, which would make
debugging slightly more difficult.  But then, we already have
non-deterministic addressing in IPv6, so I guess that's something we can
live with.

-- Juliusz
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat