device registration for wifi on Princess ship

To register a device for wifi on Princess ship, connect to wifi MedallionNet, and point. a browser at login.com.

Background: 

tardtards decided that wifi connection couldn't be done via wifi protocols, it had to be via a web page.  So were born "captive portal"s.  When web was plain-text, network provider's stack could easily man-in-the-middle user's web requests (assumption: user goes straight to web), and redirect to their captive schmortal page, and make them fill forms.

Then the web went mostly-https, (SSL / TLS), meaning encrypted, so MITM shouldn't be possible, and the captive schmortal MITM attempts result in certificate errors.  User may choose "abandon ssl certificates", "do anyway" kind of things in browser.  But the client is now told, I think by a DHCP item, what URL to go to to do the captive schmortal.  This is somehow passed from the client's OS to the client's browser.  Sometimes a new browser window is launched, on the captive schmortal page.  That's at the nice end (this is relative).  Or the existing browser opens bar with button "network login page", which assumes existing browser session.

The problem with current implementations is that the current situation arises: The user connects to the wifi, and knows they have to go to the captive schmortal page, but their system doesn't take them there, and there isn't a convenient way to find out the URL.  This happens on iOS and it happens on Debian 13, and probably all.

The solution in the case of Princess ships is currently "go to login.com".

The improvement in client interface design and software stack, assuming acceptance of this captive schmortal situation, would be: Have a command to launch browser on URL of captive schmortal page as told by DHCP server.  Have this launchable from desktop menu and from keyboard shortcut, or equivalently convenient mobile counterparts.  Have browser function to go to same URL.  Have system command to print same URL as string.

Note: according to this AI, the DHCP protocol details are "DHCP Option 114, defined in RFC 8910. For IPv6 networks, the equivalent setting is DHCPv6 Option 103".  Apparently these DHCP items just have numbers, not names?

Comments

Post a Comment

Popular posts from this blog

the persistent idiocy of "privileged ports" on Unix

TCP and UDP have ports.  These are 16 bit; there are 65535 or so per IP address. These protocols don't care to differentiate between the ports.  Elsewhere, IANA presumes to operate a process to allocate "well-known" ports in the range 1-1023, "registered ports" in the range 1024-49151, and to reserve the remainder, 49152–65535, for "ephemeral" ports.  The caller end has to have a port, which is how replies get back within the virtual connection, and these are conventionally picked from the ephemeral range by the OS's networking stack. The whole idea of ports is ridiculous, because it allows ISPs to arse around presuming to decide which services they will "not allow".  Anything that allows IPSs to do anything other than shift opaque packets will allow ISPs to meddle and break things, and due to the Law of Meddling, if they can, they will.  I am currently working around an issue with Claro, a pretend ISP, blocking port 5060, allocated to SI...
Read more

difference between timezone and offset

This is something I tried and failed to explain to a Computer Science graduate some years ago.  The Computer Science graduate assumed I was trying to make a point about seconds difference between UTC and GMT.  No.  I hope this doesn't count as slop, but Gemini can put it pretty well: User Question 1 what is the conceptual difference betwen a timezone and an offset AI Response 1 While they both help us tell time across the globe, a time zone and an offset are fundamentally different concepts. An offset is a static mathematical calculation, while a time zone is a dynamic geographic region governed by local laws. What is an Offset? An offset is the exact amount of time added to or subtracted from Coordinated Universal Time (UTC) to get the local time. Format: It is always expressed as a plus or minus sign followed by hours and minutes (e.g., +01:00 or -05:00). Nature: It is purely digital and mathematical. Limitation: It does not account for daylight saving time (DST) o...
Read more

the state of clock synchronization and setting in debian

 In the PC "architecture", there are two main clocks in the sense of what's the time.  The hardware clock lives on the motherboard, and can be spotted by its button-shaped CR2032 battery, which maintains the time even when no power supply is connected.  The OS clock exists in volatile state, somehow between the memory and the CPU, meaning it is lost when the OS is shut down.  From the perspective of a POSIX user, the OS time is accessed thru functions like time(2), or the date(1) utility. On boot, the OS clock gets its time initialised from the hardware clock.  Shortly after, depending on the system's ntp configuration, and the right network access, this may get replaced straight away with an ntp server's notion of the time.  Therefore, the sysadmin may not notice if the hardware clock is wrong, if the system gets its time from ntp shortly after each boot.  This creates a situation where, if the system has to be brought up without network (or internet,...
Read more