OpenNDS: How to limit time per day?

Installing and Using OpenWrt
1

I have an RV and travel to festivals, the desert, BLM etc where there is never any internet. Whenever I set up my Starlink people inevitably come up to me and ask to use it “just to check an important message” or let their friends know where they are or something. I always hesitate but almost always give in. But then they have password with no restrictions for as long as I’m around. I would like to be able to offer something like 15 minutes of internet, but once that 15 minutes expires they have to wait 4 hours or something like that so it’s not being abused.

I have a gl.inet router running openwrt. I’ve installed openNDS and got it running on my Guest Wireless with no password. It goes through the “simple continue” and gives them 15 minutes and then times out. Everything works how I want except I want it to not let them start another session for some amount of time.

Does this functionality already exist?
Is something I would have to program myself?

Thanks for your help!

1 Like
2

For many years, already. This is a standard functionality for a WiFi hotspot, and its controlling software. Part of this (besides the Captive Portal itself) is/was RADIUS, to manage/limit bandwidth, speed, max. session duration, max. connection time per day, max. download/upload limit etc. Having done several of these commercial, custom WiFi systems, I can not say, whether such sophisticated functions also available in openNDS.

3

Yes, support for this is available but you would have to write a script to make it work.

But there are much better ways with just a simple config change.

But first, the reason this is not included as standard is that there is very little requirement for it, so little that it was never used. We know it was never used because the "built in" script was deprecated and later removed entirely. You are the first person to mention it for years :wink:

The most effective way to manage your guest network is to set "fair usage policy".
See:
https://opennds.readthedocs.io/en/stable/config.html#set-volume-quotas
and
https://opennds.readthedocs.io/en/stable/config.html#set-fair-usage-policy-throttle-rate

Now you could set the session limit back to say 720 mins (12 hours) or so.
Set the download quota to a sensible value, say 500MB - up to you - but allowing people to do what you think is reasonable. Whilst they are using this quota, you can either leave the download rate unrestricted, or also set that to a relatively fast rate and the throttled rate to something low, for example so they can still pick up messages but would find streaming not so useable once the quota was exceeded.

You can also set upload quotas/rates/throttle_rates in the same way as required.

With this you can have a much more friendly restriction applied to users of your guest network yet still mitigate against usage abuse. Guests at public venues often have bursts of activity, picking up emails, browsing social media, uploading a photo or two etc. interspersed with spells of inactivity while "watching the band play" or whatever. So rather than cutting them off entirely after 15 minutes, they will have a much improved experience - subject to whatever you think is fair usage.

As @reinerotto says, this sort of thing has more or less been available in commercial systems since wireless networks have been a thing.
Most of the older commercial systems were based on one particular captive portal package, and yes radius was an important component. However this package has been unmaintained for a number of years now, with the commercial implementations struggling, with much hacking, to keep going.
Radius itself is also somewhat of a legacy system, originally developed pre-Internet for dial up systems. Many large corporations have a great deal invested in radius and the sunk cost fallacy leads them to be reluctant to change. So these days it is mostly only those corporations that keep radius alive, that and some academic exercises.

2 Likes
4

Thanks for the response! So that would limit them to (in your example) 500MB in 12 hours, then completely cut them off until their next session?

5

Yes, then they can start a new session, just like you have now, so nothing different as far as session length is concerned.

But it is much more than that. If they used up the 500MB (or whatever you decide to set it to) before the 12 hours, the data rate they can get is throttled (as hard as you decide).
You can also choose to limit the initial rate they can achieve, say 2Mb/s, plenty for posting on social media, uploading a selfie or two etc, but not so good for live streaming.
Once they have reached the 500MB quota, the rate they can achieve is throttled back, say to 500Kb/s. Then they can still get/send messages or even post selfies slowly, but will not be able to abuse the access you have granted them.

In summary you can set, in the openNDS config:

  • download volume quota before throttling occurs
  • download rate before throttling occurs
  • download rate whilst throttling is active
  • same as above but for upload
6

That seems workable. But in testing it looks like once they start getting throttled they can use the client.status to page to logout and reconnect to get a new session with a new 500MB and no throttle. Anyway to make that persist?

7

Yes, that is true. But most people (phones tablets etc) won't see status.client. Usually you see it only on a laptop for example.

But it is only a script that generates the logout button. It should be easy to edit it so logout is blocked...
I'll have a quick look if you like.

8

Ah I see. It looks like the package on the router is 9.8.2 and Fair Use is in 10.2 so that may not be available to me. So it hard stops and then invites them to login again immediately. I’m not sure if I can get 10.2+ on this gl.inet router (beryl ax).

Where are the files for status.client? I’m sure I can comment out the Logout button. Ultimately I wouldn’t mind them being able to see it to see how much data they’ve used.

9

What version of OpenWrt are you running. Is it the Gl-iNet fork version?
9.8.2 is ancient :flushed: AND has some critical security issues that were fixed ages ago :scream:

You need to upgrade one way or another......

10

Yes it’s gl.inet fork of openwrt. It’s a GL-MT3000.

When I do opkg install opennds it tells me 9.8.0-2 is up to date :confused:

11

Yes, up to date in the GL-iNet repository....

Show the output of:
ubus call system board

If it is 23.05.something, you are in luck, otherwise you would have to reflash with official OpenWrt.

1 Like
12 
{
	"kernel": "5.4.211",
	"hostname": "GL-MT3000",
	"system": "ARMv8 Processor rev 4",
	"model": "GL.iNet GL-MT3000",
	"board_name": "glinet,mt3000-snand",
	"release": {
		"distribution": "OpenWrt",
		"version": "21.02-SNAPSHOT",
		"revision": "r15812+899-46b6ee7ffc",
		"target": "mediatek/mt7981",
		"description": "OpenWrt 21.02-SNAPSHOT r15812+899-46b6ee7ffc"
	}
}

:frowning:

13

Yikes....

Are you doing anything special on the mt3000 over and above normal routing?
Reflashing to official is really something you need to do. Probably a simple task as well.

14

Looks like it may be possible:

https://firmware-selector.openwrt.org/?version=23.05.3&target=mediatek%2Ffilogic&id=glinet_gl-mt3000

I’ll have to take a look in the next couple of days. Ideally I’d prefer to keep the gl.inet interface. This is more for a convenience to others than it is for my own need.

15

Well, yes, that is why I suggested it. I have a couple of them here, both on 23.05.3

Yes I realised that, but working right, you could put out a donations box for beer money :smiley:

16

Are there newer standards that network tools like this can use?

17

It is not so much about "newer standards", it is more about complexity.
A captive portal requires:

  1. A database of clients
  2. Fields in that database containing client credentials and other information
  3. Fields in the database containing client usage information

Yes, Radius can do this, no problem. But then you need a Radius server running somewhere, you need to link the captive portal to the radius server, you need to manage the radius server in addition to managing the captive portal.

But all of the Radius stuff is complexity that is not required when using an already centralised forwarding authentication service (FAS) that is running on just about any standard web hosting solution.

In the simplest case, all that is needed is a lookup table, and in the most complex case, the standard relational database support found in any web hosting is more than adequate for any scenario.

Why add another, very complex additional component, when it is not actually needed for any functional or performance reason?

1 Like
18

You demonstrated, why RADIUS still has its dominance (?) in large scale/commercial Hotspot systems: In case of complex or varying Hotspot configs. I.e. to consider clients payments, login via usernam/pwd OR MAC, after first complete login. Limiting speed/traffic volume, even time based (more volume at night). Or usage time, i.e. connection time cheaper during night hours. And, obviously, nothing new (better ?) to replace RADIUS. Old, yes, but well proven, very solid. There is an old proverb: Never change a running (software-) system. RADIUS has one mayor disadvantage, though: To configure properly, some knowledge of "black magic" required :slight_smile: Not for the faint hearted.

19

Whereas a standard web hosting solution can do the job just as well, with no black magic and no extra server and everything that goes with that.

Up to a point of course, that is true. But why choose an old, cumbersome, black-magic-requiring add-on for a new system? Because "that's how we have always done it"?

For some small captive portal companies, it is the case of "we have this 10/15/20 year old product that does not work properly any more and we no longer have the in house expertise or funding to rewrite it from scratch so we will have to secretly pay some clever hackers to keep it going for us in the hope no-one will notice. Hopefully we can keep keep making sales for a little bit longer"