41 points by abdrzj 9 months ago | 54 comments
zamadatix 9 months ago
WatchDog 9 months ago
sebazzz 9 months ago
richrichardsson 9 months ago
> Note: Companies interested in purchasing a license to use the source code commercially can contact this number
and then
> This project is licensed under the MIT License.
I guess they didn't understand the MIT license and what rights it confers.
abdrzj 8 months ago
Best regards
thwarted 9 months ago
This project is licensed under the MIT License.
I hope everyone benefits from this open-source project for the development of IPv6.
jacobaul 9 months ago
From the readme:
>Note: Companies interested in purchasing a license to use the source code commercially can contact this number on WhatsApp
abdrzj 8 months ago
Best regards
richrichardsson 8 months ago
Pretty sure though any commercial entity that downloaded the code whilst it was MIT licensed (or if they just clone from the commit before you changed the license) that they can use the code with that license. Again, not a lawyer, I may be full of shit!
abdrzj 8 months ago
abdrzj 8 months ago
abdrzj 8 months ago
I have now removed the mit license and modified the license to accommodate commercial use of the source code.
Best regards
arjvik 9 months ago
zamadatix 9 months ago
Something like a DHCP option or NDP option ends up being a lot more natural: "Hey, here's your IP along with the information needed to access the network" is already a function of that layer. Some devices (e.g. macOS/iOS/iPadOS, Windows, Android) take a similar approach in the reverse by probing for a specific test url. That's also a bit hacky and unreliable (e.g. it can falsely trigger) but some minor standardization of it to e.g. a well known DNS name could be another good option.
0xbadcafebee 9 months ago
My assumption is this wasn't adopted because operators want the option of placing the captive portal upstream of the local network DHCP server. DNS spoofing works great over multiple network hops, but DHCP doesn't. (I'm not sure if that's a valid argument, but I'm sure somebody insisted on it)
gavinsyancey 9 months ago
gavinsyancey 9 months ago
https://www.rfc-editor.org/rfc/rfc8910.html https://www.rfc-editor.org/rfc/rfc8908.html
https://developer.android.com/about/versions/11/features/cap... https://developer.apple.com/news/?id=q78sq5rv
0xbadcafebee 9 months ago
Since those vendors largely use open source tools, if you patched open source DHCP servers with that option, it would get adopted quicker by them.
- KEA DHCPD supports it as option 114: https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/li...
- ISC DHCPD is officially ended (whoa!), but it looks like it supports option 114: https://gitlab.isc.org/isc-projects/dhcp/-/blob/master/commo...
- Dnsmasq author says they added the option (https://www.mail-archive.com/dnsmasq-discuss@lists.thekelley...) but I don't see it in their latest release
- Udhcpd doesn't seem to support it, so somebody could send them a patch, looks trivial to add
willidiots 9 months ago
It's really a business problem. IMO you shouldn't have to solve this just because you've gone indoors – you already pay a carrier for connectivity – but many carriers don't want to own that responsibility.
gruez 9 months ago
snvzz 9 months ago
Or do not offer internet access at all. People carry their own already-connected devices anyway.
somerandomqaguy 9 months ago
So not everyone. Actually a decent number of people that don't.
sulandor 9 months ago
leptons 9 months ago
Gud 9 months ago
gruez 9 months ago
>Or do not offer internet access at all. People carry their own already-connected devices anyway.
Travelers don't typically have gigabytes of bandwidth to spare. I for one like having unmetered internet access even when there's theoretically internet access available through roaming (absurdly expensive) or esims (expensive)
snvzz 9 months ago
The reality is that nobody wants to bother with any of that.
Either just connect me to the internet without extra steps, or don't at all. Don't waste my time.
gruez 9 months ago
I don't either, but for IT departments in large organizations, ignoring the legal department isn't an option.
immibis 9 months ago
notpushkin 9 months ago
stephenr 9 months ago
Configure your access points to use RADIUS or SAML for auth?
gruez 9 months ago
stephenr 9 months ago
As for importing a private CA. Use a certificate trusted by a public CA and you won't have this problem?
gruez 9 months ago
From an access control perspective, it probably doesn't matter much for a coffee shop, but matters more for something for a hotel where you want to limit to certain guests only (eg. ones with room or loyalty program members)
From a legal perspective, having an interstitial might provide cover for when a baddie uses the connection to order drugs or whatever. IANAL and I'm not sure whether it's actually needed or not, but most companies rather not risk it. Moreover it's unlikely that no jurisdictions require it, so you'd still support for it.
>As for importing a private CA. Use a certificate trusted by a public CA and you won't have this problem?
No idea. Last time I had to use WPA enterprise, the organization providing the connection isn't exactly small and couldn't afford a certificate, but still required me to import a CA. That makes me think it might be an inherent issue with WPA enterprise.
stephenr 9 months ago
.... Is this meant to be a joke?
> still required me to import a CA
It's reasonably likely that they wanted it to only work on known devices with their private CA cert installed; but either way, and regardless of the technology in question, I wouldn't suggest it's particularly meaningful to use one organisation's setup as the basis for how things inherently work.
gruez 9 months ago
Are you a lawyer? I wasn't making a definitive statement, but if you have stronger evidence to the contrary please present them rather than making shallow dismissals.
>It's reasonably likely that they wanted it to only work on known devices with their private CA cert installed
It's an organization where BYOD is very common.
chikere232 9 months ago
The right flavour of incompetence might get you there without bad intentions but really if you give someone the capability of eavesdropping you have to behave as if they're intending to use it
gruez 9 months ago
[1] https://askubuntu.com/questions/1317320/how-can-i-automatica...
[2] https://documentation.meraki.com/MR/Encryption_and_Authentic...
stephenr 9 months ago
coretx 9 months ago
apearson 9 months ago
I don’t see how CGNAT does anything but allow easier access to attacks (using private ip space outside of the local network)
coretx 9 months ago
zamadatix 9 months ago
It's nearly 8 years later, we haven't moved to IPv6, and they stopped making noise so I'm left to assume they either got more source port logging or found some other method?
sulandor 9 months ago
coretx 8 months ago
apearson 9 months ago
Uptrenda 9 months ago
Damn, you've done significant work on this. Will have to check this out more in depth.
abdrzj 8 months ago
Best regards
immibis 9 months ago
abdrzj 8 months ago
Best regards
ninkendo 9 months ago
I’ve never run a captive portal but I always assumed that the router just redirects all port 80 packets to the portal (and rejects everything else), and then upon authenticating, the gateway puts your IP in the “allow” bucket and you get access.
But if you’re generating random addresses every few minutes, you’d need to continually reauthenticate, unless the system has some way of associating the temporary addresses with the original connection. Maybe it listens to ndp and uses MAC addresses to associate? That would be more advanced than most captive portals I’ve seen which seem to only care about ip addresses. Maybe just none of them use IPv6, or simply break with temporary addresses?
mannyv 9 months ago
Once the agreement is accepted the MAC is added to the allow list.
Not sure how MAC address randomization works in these schemes, but it does. There must be some standard algorithm that everyone follows.
zamadatix 9 months ago
ninkendo 9 months ago
The randomization I refer to is of the outgoing IPv6 address, not the MAC address… nothing that I’m aware of randomly cycles MAC addresses (Apple’s OSes can be configured to randomly generate a MAC every time you connect to a network, but it won’t regenerate them continuously in a session. IPv6 addresses however are continuously generated, as per the RFC4941 spec.) If the system is using MAC addresses to identify users, then temporary/cycled IPv6 addresses should be no problem.
9 months ago