Re: [Server-devel] [XSCE] Re: Captive portal updates

[Tim Moody]

Go for it. Is it possible to use coova for dhcpd even if captive is off?



Sent from my Samsung Galaxy smartphone.


 Original message 
From: Anish Mangal 
Date: 9/25/16 8:42 AM (GMT-08:00)
To: xsce-devel 
Cc: George Hunt , A Holt , 
server-devel 
Subject: Re: [XSCE] Re: Captive portal updates



On Sun, Sep 25, 2016 at 8:52 PM, Tim Moody 
mailto:t...@timmoody.com>> wrote:

In the radius+ solution am I required to create users?  Seems like overkill if 
all I want is a redirect to the home page when I first connect.  If I want 
named accounts then it is a good approach.


You are not necessarily required to create accounts *per* user, but an account 
is needed. It is easy enough to create a default account (during initial 
installation/setup itself). The default login/captive portal page can have the 
details prefilled. For example, take a look at the video:

http://people.sugarlabs.org/anish/captive.webm

In this case, I just require the user to press the "accept and login" button 
and get redirected to school.lan from there (the last bit is not in the video).


You _can_ have named accounts if you want. You can have bandwidth control per 
account as well if needed (this would obsolete wondershaper). This can be 
useful if some users have fast access and others have limited bandwidth access 
to your server (can happen in a mesh setup).

So, in sum, it is easy to have the default redirect without requiring the user 
to enter credentials, but it is possible to have credentials as well.

I think the answer to br0 is yes.


Wonderful :-)


I worry that switching dhcp providers could get tricky.


Why? In my testing so far, I havent faced any issues.



From: Anish Mangal mailto:anis...@umich.edu>>
Sent: Sunday, September 25, 2016 4:07 AM
To: Tim Moody; George Hunt; A Holt; xsce-devel; server-devel
Subject: Re: Captive portal updates

Hi,

I wanted to ask whether a captive portal + radius server + radius server gui 
would be a useful feature and wanted to discuss possible implementation routes 
as this affects other services on the XSCE.

A radius server allows to have controlled access to server resources, internet 
connectivity, and allows one to create users, groups, and set aside network 
bandwidth. i.e. it is quite useful in a medium to large setup. A captive portal 
alongside it allows for good UX with notifications in phones, tablets and not 
having users to type http://school.lan.

The existing captive portal PR (#771) is a very good step in that direction, 
but I believe we will eventually need to use some kind of standard 
implementations - radius + captive portal setups.

Now that 6.1 is out of the door, I would like to propose a captive portal 
feature for 6.2.

In the current setup I am testing, I am using freeradius[1] as the radius 
server, and CoovaChilli [2] as the captive portal. Coova does it's own dhcp so 
it will have to replace dhcpd if it is used. Also, starting/stopping the coova 
services affects iptables, so initially, having it run in conjunction with 
dansguardian and squid might be a little tricky (though it is certainly 
possible, just needs more time to test/develop). Also, while freeradius is 
available as a rpm package, coova, and a dependency needs to be complied from 
source. I can create the packages for it though - it did not seem complicated.

So, the current approach I am proposing is:
1. If captive + radius is enabled, dhcpd is disabled, squid and dansguardian 
are disabled. Later, we can just have dhcpd disabled and the other two enabled 
if need be
2. If captive + radius is enabled, either we include a few knobs and levers to 
manage radius in our admin console (more difficult), or include a radius admin 
console (easier)

At the same time I have a question, since my understanding of xsce networking 
is limited. When setup in LANcontroller mode with both the internal wifi + LAN 
being controlled by XSCE, does all the LAN side traffic flow through br0? Is it 
always the case?  (in gateway mode too). If that is so, then I will configure 
coova to work on br0.

[1] http://freeradius.org/
FreeRADIUS: The world's most popular RADIUS Server
freeradius.org
The FreeRADIUS Project. FreeRADIUS includes a RADIUS server, a BSD licensed 
client library, a PAM library, and an Apache module. In most cases, the word 
FreeRADIUS ...



[2] http://coova.github.io/CoovaChilli/
CoovaChilli, an open source captive portal access 
controller
coova.github.io
CoovaChilli. CoovaChilli is an open-source software access controller, based on 
the popular, but now defunct, ChilliSpot project, and is actively maintained by 
an ...




Best,
Anish


On Tue, Sep 20, 2016 at 7:36 AM, Anish Mangal 
mailto:anis...@umich.edu>> wrote:
I believe I am able to get the captive portal working as intended

http://people.sugarlabs.org/anish/captive.webm

Now w

Re: [Server-devel] [XSCE] Re: Captive portal updates

[Anish Mangal]

On Sun, Sep 25, 2016 at 8:52 PM, Tim Moody  wrote:

> In the radius+ solution am I required to create users?  Seems like
> overkill if all I want is a redirect to the home page when I first
> connect.  If I want named accounts then it is a good approach.
>
>
>
You are not necessarily required to create accounts *per* user, but an
account is needed. It is easy enough to create a default account (during
initial installation/setup itself). The default login/captive portal page
can have the details prefilled. For example, take a look at the video:

http://people.sugarlabs.org/anish/captive.webm

In this case, I just require the user to press the "accept and login"
button and get redirected to school.lan from there (the last bit is not in
the video).


You _can_ have named accounts if you want. You can have bandwidth control
per account as well if needed (this would obsolete wondershaper). This can
be useful if some users have fast access and others have limited bandwidth
access to your server (can happen in a mesh setup).

So, in sum, it is easy to have the default redirect without requiring the
user to enter credentials, but it is possible to have credentials as well.

> I think the answer to br0 is yes.
>
>
> Wonderful :-)


> I worry that switching dhcp providers could get tricky.
>
>
Why? In my testing so far, I havent faced any issues.


>
> --
> *From:* Anish Mangal 
> *Sent:* Sunday, September 25, 2016 4:07 AM
> *To:* Tim Moody; George Hunt; A Holt; xsce-devel; server-devel
> *Subject:* Re: Captive portal updates
>
> Hi,
>
> I wanted to ask whether a captive portal + radius server + radius server
> gui would be a useful feature and wanted to discuss possible implementation
> routes as this affects other services on the XSCE.
>
> A radius server allows to have controlled access to server resources,
> internet connectivity, and allows one to create users, groups, and set
> aside network bandwidth. i.e. it is quite useful in a medium to large
> setup. A captive portal alongside it allows for good UX with notifications
> in phones, tablets and not having users to type http://school.lan.
>
> The existing captive portal PR (#771) is a very good step in that
> direction, but I believe we will eventually need to use some kind of
> standard implementations - radius + captive portal setups.
>
> Now that 6.1 is out of the door, I would like to propose a captive portal
> feature for 6.2.
>
> In the current setup I am testing, I am using freeradius[1] as the radius
> server, and CoovaChilli [2] as the captive portal. Coova does it's own dhcp
> so it will have to replace dhcpd if it is used. Also, starting/stopping the
> coova services affects iptables, so initially, having it run in conjunction
> with dansguardian and squid might be a little tricky (though it is
> certainly possible, just needs more time to test/develop). Also, while
> freeradius is available as a rpm package, coova, and a dependency needs to
> be complied from source. I can create the packages for it though - it did
> not seem complicated.
>
> So, the current approach I am proposing is:
> 1. If captive + radius is enabled, dhcpd is disabled, squid and
> dansguardian are disabled. Later, we can just have dhcpd disabled and the
> other two enabled if need be
> 2. If captive + radius is enabled, either we include a few knobs and
> levers to manage radius in our admin console (more difficult), or include a
> radius admin console (easier)
>
> At the same time I have a question, since my understanding of xsce
> networking is limited. When setup in LANcontroller mode with both the
> internal wifi + LAN being controlled by XSCE, does all the LAN side traffic
> flow through br0? Is it always the case?  (in gateway mode too). If that is
> so, then I will configure coova to work on br0.
>
> [1] http://freeradius.org/
> FreeRADIUS: The world's most popular RADIUS Server
> 
> freeradius.org
> The FreeRADIUS Project. FreeRADIUS includes a RADIUS server, a BSD
> licensed client library, a PAM library, and an Apache module. In most
> cases, the word FreeRADIUS ...
>
>
> [2] http://coova.github.io/CoovaChilli/
> CoovaChilli, an open source captive portal access controller
> 
> coova.github.io
> CoovaChilli. CoovaChilli is an open-source software access controller,
> based on the popular, but now defunct, ChilliSpot project, and is actively
> maintained by an ...
>
>
>
> Best,
> Anish
>
>
> On Tue, Sep 20, 2016 at 7:36 AM, Anish Mangal  wrote:
>
>> I believe I am able to get the captive portal working as intended
>>
>> http://people.sugarlabs.org/anish/captive.webm
>>
>> Now will need to work in a branch on a playbook.
>>
>> Another idea would be to have a web ui for radius to show all kids of
>> user stats, control per user/group bandwidth, and accounting.
>>
>> On Mon, Sep 19, 2016 at 8:54 PM, Anish Mangal  wrote:
>>
>>>
>>>
>>> On Mon, Sep 19, 2016 at 8:54 PM, Anish Mangal  w