Thats a clever way of doing it, that would solve the IPv6 issue as well. On Fri, Aug 26, 2016 at 2:47 PM, David Bird <db...@google.com> wrote:
> The DHCP option, once set, remains constant. The client learns the URL > from DHCP Offer/ACK. > > For an example: > > Client sends DHCP Discover/Request > NAS returns DHCP Offer/ACK containing: > Assigned IP: 10.0.0.100 > Gateway IP: 10.0.0.1 > CAPPORT URI: http://10.0.0.1:3990/prelogin > > [Chilli is the daemon responding to DHCP and is listening on 10.0.0.1:3990 > ] > > The client can issue a HTTP request to http://10.0.0.1:3990/prelogin and > the NAS returns with a HTTP 302 redirect to something like > https://my.domain/wifi?mac=... -- with session/station specific values. > > > On Fri, Aug 26, 2016 at 11:29 AM, Alexander Roscoe < > alexander.ros...@gmail.com> wrote: > >> Hi David, >> >> I am not too familiar with CoovaChili internals, does the hijacking >> routine add the string params(station/session) to the DHCP option or is it >> scripted to use the option82 data and add the parameters after the user >> goes to http://<nas-ip>:<port>/prelogin? >> >> On Fri, Aug 26, 2016 at 2:00 PM, David Bird <db...@google.com> wrote: >> >>> RFC 7710 says, ".. provides the URI to access an authentication page." >>> Obviously, this will need further clarification should it point to an API >>> end-point. As it is written, I think it is clear that the URI should be the >>> same (or will redirect you to the same) URL as a HTTP hijack takes you to >>> (minus any "original URL"). >>> >>> In CoovaChilli, at least, there is already an internal/local URL that is >>> suitable for RFC7710. In that the URL http://<nas-ip>:<port>/prelogin >>> in chilli hooks into the hijacking routine to redirect the user to the >>> captive portal URL specific to them (e.g. the hijacking routine adds the >>> query string params specific to station/session). >>> >>> https://github.com/coova/coova-chilli/pull/274/commits/1e95a >>> 2cf97e981f2f53826e38cd12372555a809c >>> >>> >>> On Fri, Aug 26, 2016 at 10:08 AM, Dave Dolson <ddol...@sandvine.com> >>> wrote: >>> >>>> Alexander, >>>> >>>> Suppose instead of providing a URL for the landing page, the RA >>>> provided the URI for a standardized REST interface; the client could post >>>> its details (MAC address, device type?) to this interface, which would >>>> return the URL for the browser landing page, and possibly any number of >>>> other details and mechanisms, e.g., in a JSON response. >>>> >>>> >>>> >>>> This adds a level of indirection that simplifies what needs to go in >>>> the RA. >>>> >>>> >>>> >>>> I think there is also flexibility in letting the client know details >>>> about the capport situation in the API. E.g., how often will the page need >>>> to be visited? >>>> >>>> >>>> >>>> RA-->client: “This is the URI for getting capport info: >>>> http://capport.example.com/api” >>>> >>>> Client-->capport/api: “My MAC address is 01:02:03:04:05:06 and my IP >>>> address is …” >>>> >>>> Capport/api-->client: “Your landing page is >>>> https://capport.example.com/landing/mac=01:02:03:04:05:06 ; refresh >>>> every 60min” >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -Dave >>>> >>>> >>>> >>>> >>>> >>>> *From:* Captive-portals [mailto:captive-portals-boun...@ietf.org] *On >>>> Behalf Of *Alexander Roscoe >>>> *Sent:* Friday, August 26, 2016 11:15 AM >>>> *To:* captive-portals@ietf.org >>>> *Subject:* [Captive-portals] IPv6 RA URI option >>>> >>>> >>>> >>>> I am looking over RFC 7710 <https://tools.ietf.org/html/rfc7710> >>>> concerning how the URI is communicated to the end user. I really like the >>>> IPv4 DHCP solution, I think this could easily be implemented in a DHCP >>>> server. I think it could be easily implemented in the RA for IPv6 as well >>>> however I do see a challenge when each connected client needs a unique URI >>>> such as it containing the parameter for the client mac. For example, a url >>>> like https://captiveportal/?client-mac=11:22:33:44:55:66. The RA is >>>> sent to everyone and cannot be tailored to each client while DHCP is very >>>> client specific and can be changed on-the-fly. Most captive portals rely >>>> on the client mac address during the authentication process. I am aware of >>>> networks using the IP address to associate the user at the AAA server but >>>> from my understanding this is a rare network setup. I think a potential >>>> solution for the IPv6 RA would be to define an HTTP POST parameter in which >>>> the client can use like ‘client-mac’ and let the client post it the URI >>>> https://captiveporta/. Thoughts? Ideas? >>>> >>>> >>>> -- >>>> Alexander Roscoe >>>> 484-716-9048 >>>> >>>> _______________________________________________ >>>> Captive-portals mailing list >>>> Captive-portals@ietf.org >>>> https://www.ietf.org/mailman/listinfo/captive-portals >>>> >>>> >>> >> >> >> -- >> Alexander Roscoe >> 484-716-9048 >> > > -- Alexander Roscoe 484-716-9048
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
