Erik Kline <[email protected]> wrote:
>> I will not be surprised if there is nothing that satisfies my needs
>> and is still capable of dealing with portals.
> Can you clarify what "dealing with" means here for you?
> Automatically interacting with a portal? (e.g. clicking agreement
> checkboxes, filling in email addresses or facebook details, ...)
That would be be awesome, but until we are widely successful, it isn't going
to happen, so it's really, as you guessed:
> Detecting the presence of a portal and then "calling a human for
> help"? (vis. your Chrome X11 forwarding idea)
Calling human for help.
The connectivity is not for long durations of time.
The initial purpose of this box is to bring IPv6 uplink into a wired testing
environment, and act as the "ISP" link for other devices.
[Some of which will be captive portals under test... :-)]
But, you didn't comment on my real query:
> So it occurs to me that maybe a document that establishes a reasonable
> subset of capabilities would be a good thing to have. Then at least, both
> portal makers and captive portal browser providers could have something to
> work towards.
> Maybe this is really W3C work?
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature