I had some problem in very large environments because the chilli DHCP refuse to dish out more than 512 leases, we can see in the logs this message:

reached max connections 512!

So I found that the dhcp of chilli by default manages until 512 IP addresses, but luckily this value can be customized via the variable maxclients.
I would like to have this variable implemented in the hotspot so that it can handle these cases easily.

For testing see: NethServer/dev#6634

To match Term of Services we have to create a new task to delete users and change some text inside the policy.

Steps:

• create daily clean-users task to remove users older than 24 months
• change text to new 24 months limit here
• change text to new 24 months limit here

When I provision icaro I get the following error

fatal: [icaro]: FAILED! => {"changed": false, "msg": "There was an issue creating /opt/icaro as requested: [Errno 13] Permission denied: '/opt/icaro'", "path": "/opt/icaro/sun-ui/", "state": "absent"}

Starting from version 94 Chrome block any requests to private networks from insecure public websites[1] and this new behavior interfere with the captive portal authentication flow.
An authenticated user at the end of the authentication process, request access to the internet by making a call to the local coova-chilli instance, and this communication is no longer possible.

Device authentication occurs via a daemon, which runs on the hotspot unit and authenticates the devices after making a request to the hotspot server. The devices, and therefore the users, who have a verified authentication on the server side, are also authenticated on the hotspot unit.

After an user has been authenticated with success via one of login methods (Instagram, Facebook, LinkedIn, Email, SMS, Voucher) the captive portal creates a valid record in the database on table daemon_auths for that user, the daemon reads that record and the authentication is done.

The daemon uses:

• /aaa/auth API to get the list of users to authenticate

The captive portal uses:

• /aaa/login: to create a login record on database (this is the record used to autheticate)
• /aaa/logout: to create a logout record on database (used to track the login worflow)
• /aaa/temp: to create a temp record on database (used to create a temporary session for Email login)

The records on the database are cleaned with a cron running every day. This is used when an user does not complete the authentication flow and the records on table remain dirty.

Proposed solutions are:

• Backend: #156
• Dedalo client: #157

[1]https://developer.chrome.com/blog/private-network-access-update

I just can't make it working. No logs, no debug options. No comprehensive manuals. Even no issues in this repo. It is strange. How to debug this?

Hotspot with proxy enabled (this enable a transparent proxy for http/https traffic) : proxy bypasses defined in the web proxy panel are not working for hotspot traffic.

Steps to reproduce

• Enable hotspot with the proxy flag
• Enable web proxy
• Define one or more bypasses in the web proxy page : by source, destination or domain (in this case hotspot clients should use hotspot interface ip address as dns)

Expected behavior

Defined exception are not intercepted by proxy

Actual behavior

Defined exception are still intercepted by proxy

Components

NethServer release 7.6.1810 (final)

nethserver-squid-1.7.4-1.ns7.noarch
squid-3.5.20-999.ns7.x86_64
nethserver-dedalo-1.0.7-1.ns7.noarch
dedalo-0.2.1-1.ns7.noarch

The Icaro project can be integrated with external services to add more functionalities:

• new table to list external integrations (Sun-API)

• Gain access to the users to the external integration with the same credentials (Sun-API)

• new API (Sun-API):

  • GET: to get integrations list
  • PUT: to update integrations with hotspot (provides external access credentials etc...)

• Insert a pre and post auth hook in Wings to redirect user in the external integration URL (Wings)

Add new type of access_token, role token that can be used from external applications (Sun-API):

• ACLs must be:
  • full (for all http verbs)
  • write (only for GET,PUT,POST)
  • read (only for GET)
• never expires
• can be added only by admin
• support only http verbs in this stage, maybe in future can filter also the API endpoints

Possibility to see if a unit is active or not in the unit summary page.

Proposed solution

Continuous check if a unit has active sessions in the previous 30 minutes:

• if so, the active status will appear with a green symbol
• if not, the inactive status will appear with a red symbol

Hotspot with proxy enabled.
Proxy bypasses defined in the web proxy panel are not working for hotspot traffic.

Steps to reproduce

• Enable hotspot with the proxy flag
• Enable web proxy
• Define one or more bypasses in the web proxy page : by source, destination or domain (in this case hotspot clients should use hotspot interface ip address as dns)

Expected behavior

Defined exception are not intercepted by proxy

Actual behavior

Defined exception are still intercepted by proxy

Components

NethServer release 7.6.1810 (final)

nethserver-squid-1.7.4-1.ns7.noarch
squid-3.5.20-999.ns7.x86_64
nethserver-dedalo-1.0.7-1.ns7.noarch
dedalo-0.2.1-1.ns7.noarch

Error retrieving hotspot list.
That's all error message that I got. using dedalo from cli I got this:
Error: unit not added!
There is no any description of error.

At the moment when a new unit is added using the dedalo helper, the reference to the hotspot is only the name, that could be not unique and the result is that the unit is not correctly added to the right hotspot.

Steps

1. Create a hotspot and name it test with some description
2. Create another hotspot and name it again test with some description
3. Try to register an unit using the hotspot named test.
4. The registration fails because the unit is added to a bad hotspot

We must change the registration method by modify the sun-api endpoint POST /units to accept hotspot_id filed in JSON request instead of hotspot (that contains the name)

Steps to reproduce

• Create a customer profile

• Login to web manager using the customer profile

• Try to edit the captive portal page

• Click on Update

Expected behavior

The page is saved and the captive portal is modified.

Actual behavior

The web paging is in never ending waiting state, if you try to reload the page nothing has changed