Use of 4.3.2.1 - which is routable space in 0.8.5

[aenertia]

Hi there ;

Pet peeve; the 4.3.2.1 address now used in AP mode is part of the routable space it's allocated to google - and it shouldn't be used for local networks ; yes I know chances are minimal it will get advertised from a microcontroller in host AP mode - but many OS's will treat it differently than RFC space or Zeroconf address space.

There are RFC's about this - please use the allocated local non-routable ranges for internal addressing.

[Aircoookie]

Hi,

yes, I am fully aware that I am using public address space. The reason for this change is Captive Portal support on Samsung devices. Their implementation doesn't conform to industry standards and for some reason only works when the host is in non-private address space. See tzapu/WiFiManager#553

I've done tests under Windows, iOS, several Android versions and Ubuntu, none of them seem to misbehave with the non-standard address space, but I agree that this solution is less than ideal.
Perhaps I should add a checkbox that reverts the AP IP to 192.168.4.1 in case there are actually conflicting devices.

[daveloyall]

Sorry, I understand that you want your firmware to work with a bunch of smart phones already on the market, but you don't get to violate RFCs just because you have good intentions. Please remove the wontfix tag.

For what it is worth, I am giving these instructions to my buddy as I give him a device with your firmware as a gift:

You wifi system may prompt you to "sign in". This will take you to
the device's embedded web server, but on my device, it does that with
some crappy internal web browser, so I tell it to skip sign in and
"use as is", then I point my browser where it needs to go. (If you don't
finish the "sign in" process one way or another, your OS might block your
browser from using the connection.)

In short, I think that the problem you can only solve by using somebody else's IP is a problem you made for yourself! (Perhaps teaching your users how to type a non-routeable address into their browser's address bar will be a net gain for them.)

[raoulteeuwen]

Sorry, I understand that you want your firmware to work with a bunch of smart phones already on the market, but you don't get to violate RFCs just because you have good intentions. Please remove the wontfix tag.
...
In short, I think that the problem you can only solve by using somebody else's IP is a problem you made for yourself! (Perhaps teaching your users how to type a non-routeable address into their browser's address bar will be a net gain for them.)

Maybe i'm misreading your post, but this sounds rather unfriendly. We have a dev here, and collaborators, working their ass of, sharing their code. I assume they welcome suggestions, and would love to hear about a better way to do this. But afaik, in the end, they don't 'have to' do anything. Did you already send them some money for their effort btw?

[Aircoookie]

@daveloyall If you don't like it, don't use it, or rather change it yourself. WLED is open source and I am sure you can figure out the location where to change the IP to a private address space. I'd be happier as well if we could adhere to the spec, but since some phone manufacturers don't (including Samsung!) I just went with what works in practice. Better to have a technically incorrect solution than not having captive portal support at all on about 50% of devices. Lastly, I'm not using "somebody elses IP". This is not the internet, but rather a AP<==>Device only network with no way to interfere with the public internet. I could use any of the 2 billion available IPv4 address without harming anyone.

[pille]

while i used the same arguments as @Aircoookie in the past, i learned last week in a park, that at least my android can't connect to the ad-hoc-hotspot, while mobile data is activated. while it should not create a routing issue, it actually does.

[Aircoookie]

@pille that is indeed concerning. What phone model do you use?
I've heard that Google wants to create a new Captive Portal API for Android 11, my hope is that that will allow more devices to have a working captive portal in private address space.

[pille]

the device was a blackview A7 PRO, running android android 7.0

[daveloyall]

Maybe i'm misreading your post, but this sounds rather unfriendly.

Well, I did mean to be firm! Please let me add that I really love WLED. It's a great teaching tool because it is so engaging. Thank you very much for making it and releasing it under a Free license.

My advise is to pick an IP designated for private use and drop the whole "captive portal" feature.

Adherence to the RFCs is what makes the internet exist. We all must do our part!

[sansillusion]

I don't get why it bothers you so much. It's not an internet connected device if it's not connected to a router yet. This makes it easy for anyone to configure the device not just internet expert's. It doesn't interfere with internet standards since it's not connected to internet when using that IP.

[margau]

Hi,
digging this up as I tumbled across it today.
As a person, who does both networking and embedded IoT stuff, I definitively see the need to address this issue.
4.3.2.0/24 is assigned to google (see https://whois.arin.net/rest/net/NET-4-3-2-0-1.html), and we should avoid using it.

Scenario: Dual NIC computer, e.g. LAN to Public Internet and Wi-Fi to setup WLED. I regulary use such an setup. When we use non-RFC-1918 IP-Space in the private, non-routed segment, this will cause issues sooner or later as the computer would take the route from the WLED-Hotspot for public communication to 4.3.2.0/24.
In my opinion, the interference with public IP-space in this case is more serious than the samsung-problem.

Therefore, I'd suggest fixing this using another RFC1918-Prefix, and digging deeper into the samsung issue. I could prepare and test an PR, if we find consensus here.
Unfortunately, I really do not see "wontfix" as a proper solution to this issue, as it violates some RFCs.

Best regards,
margau

[samstreak]

A PC regardless of OS will choose the most-direct route to an IP. If there is an entry in the route table to 4.3.2.0/24 because there's a directly-connected interface to that subnet, it will choose that interface assuming the route metric isn't something crazy out of normal range. But even still, the PC isn't going to advertise it's route because PC's generally don't run routING protocols, just routED protocols. The WLED device isn't connecting anywhere on the internet and can't route anywhere while on that IP range because it has no routes - as soon as it is configured for a WiFi AP, it uses the AP-provided IP settings.

I do agree that RFC's should be followed if at all possible, but it's just basic TCP/IP at that point, not part of the internet.

[aenertia]

This same logic has been used in various example network vendor equipment System Loopback IP's for decades leading to several quite big public meltdowns in BGP route tables due to non-routable or overloaded system IP's being used. The number of times I have logged into production or Lab systems with 1.1.1.1 as there system address is shocking. Don't use allocated IP ranges because there is always some corner case which just because of your lack of imagination doesn't currently extend to, is potentially problematic. Just because the worst case scenario I expereience due to this is; whenever I connect to an unprovisioned WLED device via a VIF on my Wifi AP's I blackhole 4.3.2.1 for the period of time it is connected for the rest of my network doesn't mean there are not worse scenarios. There is no need to do it, so don't do it.

…

On Tue, Nov 24, 2020 at 11:01 AM samstreak ***@***.***> wrote: A PC regardless of OS will choose the most-direct route to an IP. If there is an entry in the route table to 4.3.2.0/24 because there's a directly-connected interface to that subnet, it will choose that interface assuming the route metric isn't something crazy out of normal range. But even still, the PC isn't going to advertise it's route because PC's generally don't run routING protocols, just routED protocols. The WLED device isn't connecting anywhere on the internet and can't route anywhere while on that IP range because it has no routes - as soon as it is configured for a WiFi AP, it uses the AP-provided IP settings. I do agree that RFC's should be followed if at all possible, but it's just basic TCP/IP at that point, not part of the internet. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#232 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACF5L5ZT67QLVLXMKX7SHLSRLLTBANCNFSM4I3B6FZA> .

[gotiniens]

Is there any progress on this issue?

[blazoncek]

it says wontfix

[cinderblock]

While this is labeled as "wontfix", might a fix be accepted if someone proposed one? It's unclear to me if you're against the change or just don't see a solution. I see the issue is still "open" and marked as "keep" and so maybe that's indicating what I'm asking, but I just wanted to be sure.

[Aircoookie]

We are against changing to a proper private address as this breaks captive portal functionality on Samsung devices (or at least did, we ought to re-check it). Actually changing the used address is trivial. If you think you have a solution that maintains Captive Portal support on all devices, by all means propose it!