Thank you Nathan Ward, Actually i want to make daily usage report, but if that session is older than one or two days than i dont get proper daily data usage report. For now, i was make script that disconnect all users with pod at midnight 12. Any other way to achieve this idea without disconnecting users. Warm Regard's Imdadali Kadiwala On Sun 19 Aug, 2018, 11:19 AM , < freeradius-users-request@lists.freeradius.org> wrote:
Send Freeradius-Users mailing list submissions to freeradius-users@lists.freeradius.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.freeradius.org/mailman/listinfo/freeradius-users or, via email, send a message with subject or body 'help' to freeradius-users-request@lists.freeradius.org
You can reach the person managing the list at freeradius-users-owner@lists.freeradius.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Freeradius-Users digest..."
Today's Topics:
1. Renew the session at midnight 12 o clock (Imdad Hasan) 2. Re: Renew the session at midnight 12 o clock (Nathan Ward) 3. Re: IPv6 accounting RADIUS SQL schema? (Nathan Ward) 4. Re: IPv6 accounting RADIUS SQL schema? (Michael Ducharme) 5. Re: IPv6 accounting RADIUS SQL schema? (Nathan Ward)
----------------------------------------------------------------------
Message: 1 Date: Sun, 19 Aug 2018 03:04:18 +0530 From: Imdad Hasan <imdadalikadiwala0@gmail.com> To: freeradius-users@lists.freeradius.org Subject: Renew the session at midnight 12 o clock Message-ID: < CAPidyMV-OmZWUxBwrH8RvxfP5COBVpTcUZu2gAfmCUvCZoq-rA@mail.gmail.com> Content-Type: text/plain; charset="UTF-8"
Respected All,
How can i kill old accounting sessions and generate new sessions without disconnect the users at every midnight 12 o clock.
Warm Regard's Imdadali Kadiwala
------------------------------
Message: 2 Date: Sun, 19 Aug 2018 15:21:48 +1200 From: Nathan Ward <lists+freeradius@daork.net> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Renew the session at midnight 12 o clock Message-ID: <33845DBE-D464-4713-B980-0479726912C9@daork.net> Content-Type: text/plain; charset=utf-8
On 19/08/2018, at 9:34 AM, Imdad Hasan <imdadalikadiwala0@gmail.com> wrote:
Respected All,
How can i kill old accounting sessions and generate new sessions without disconnect the users at every midnight 12 o clock.
Accounting sessions are managed by the NAS and distinguished by Acct-Session-Id etc., so, you can’t really unless your NAS can do this - but I’ve never seen such a “feature”.
Often we return a “Class” in an Access-Accept message, which is included in Accounting requests and is what FreeRADIUS uses to distinguish unique sessions. **Maybe** you can update Class in a CoA, but, that would almost certainly be NAS specific. Additionally, this would not cause the NAS to reset the counters to zero, nor send an accounting start type message.
This is quite a specific question - short answer is “you can’t” - but perhaps we can help if we know what you are doing. What are you looking to achieve? Why do you want new accounting sessions?
-- Nathan Ward
------------------------------
Message: 3 Date: Sun, 19 Aug 2018 15:37:23 +1200 From: Nathan Ward <lists+freeradius@daork.net> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: IPv6 accounting RADIUS SQL schema? Message-ID: <786ED99C-8491-4A52-AEB3-B9D9FCC3E540@daork.net> Content-Type: text/plain; charset=utf-8
Hi,
On 19/08/2018, at 9:11 AM, Michael Ducharme <mducharme@gmail.com> wrote:
I would say it is even more complicated:
If assigning framed prefixes is enabled on the NAS, each customer is given a /64 prefix and router advertisements are sent out so that the CPE can get a global address via SLAAC (reported as Framed-IPv6-Prefix and Framed-Interface-Id).
If DHCPv6-PD is enabled on the NAS, each customer who requests a prefix will be assigned one, typically a /56 (reported as Delegated-IPv6-Prefix). If DHCPv6 address assignment is enabled, then the CPE can get a global IP through DHCPv6 (reported as Framed-IPv6-Address).
Yep that’s right - in my prev. message, the /128 is a CIDR, so can be any length. If one uses SLAAC for CPE WAN interfaces, the prefix for that needs to be unique per subscriber so you can identify them, as SLAAC doesn’t give the BNG any indication of the address(es) which are selected.
So if the customer has a router that supports everything and has everything enabled, it could get two addresses on its WAN port, one via SLAAC and one via DHCPv6, and then a prefix via DHCPv6-PD for use on the internal network (LAN ports, guest wifi, etc.). If only routers are connecting via PPP and not customer computers directly, you can look at the Delegated-IPv6-Prefix to see what prefix the customer's computers are using. If customer computers connected directly to the NAS (ex. through an L2TP VPN), then the computer will use either a global address via SLAAC (found in the Framed-IPv6-Prefix and Framed-Interface-Id accounting) or a global address via DHCPv6 (found in Framed-IPv6-Address), or both.
While I agree that this is technically possible, it is unusual to have both SLAAC and DHCPv6 IA-NA at the same time on one device. DHCPv6 is triggered by flags in the RA. If you’ve got a broadband type environment where both happen, I would suggest changing that to support only SLAAC, or only DHCPv6 IA-NA.
Regardless, this is possible, so is something that should probably be permitted.
Because, depending on the exact situation, the end user device may be on an address in the Delegated-IPv6-Prefix (this is the case if they go through a router) or an address in the Framed-IPv6-Prefix (if they are on SLAAC) or an address in Framed-IPv6-Address (if they receive an address through DHCPv6 address assignment), all three fields must be stored. As an ISP, we are required to forward copyright infringement notices to customers, and in order to look up the address on the notice, we need to search all three fields (unlike in IPv4 where we only search one field).
Additionally, it is common that WAN side addresses are not assigned at all - and only DHCPv6 IA-PD is assigned - and there may even be multiple IA-PD assigned.
I think the short story is that a RADIUS “session” can have 0+ IPv6 addresses/prefixes. This is I suppose similar to IPv4, if you use Framed-Route to give customers additional addresses - these can exist in Accounting-Request messages.
I don’t know if this is something that FreeRADIUS should attempt to solve in a generic way, or if there should perhaps be some examples and have it left up to the operator. If it is solved in a generic way, how would that be done? - Additional tables for prefix assignments? - ARRAY support in SQL? (Not in MySQL, but is in other SQL DBs) - JSON or some other serialisation of an array in to text? - ARRAY for most DBs, JSON blob for others?
-- Nathan Ward
------------------------------
Message: 4 Date: Sat, 18 Aug 2018 22:21:19 -0700 From: Michael Ducharme <mducharme@gmail.com> To: freeradius-users@lists.freeradius.org Subject: Re: IPv6 accounting RADIUS SQL schema? Message-ID: <5f9b3c0e-23ee-f7c0-46aa-5618b2274cd3@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
On 8/18/2018 8:37 PM, Nathan Ward wrote:
Additionally, it is common that WAN side addresses are not assigned at all - and only DHCPv6 IA-PD is assigned - and there may even be multiple IA-PD assigned. Yes, I am aware - we do not assign WAN side addresses. An unfortunate side effect of this is that *many* consumer routers will then not function - quite a few consumer routers ask for address and prefix, and if offered a prefix with no address, will refuse it instead of correctly accepting the prefix. Once our NAS vendor adds proper RADIUS accounting support for IPv6, we might assign WAN-side addresses for that reason only.
We are only starting to provide managed residential gateways to our customers - our network has been historically BYOR (bring-your-own-router), and we even have some customers who have no computer and no router, only an xbox plugged into their modem configured with the PPPoE credentials. At the moment, the way our network is configured, those xbox customers are out of luck for IPv6, since the xbox is unlikely to request a prefix via DHCPv6-PD. Given our environment, as long as we have decent RADIUS accounting, we are likely to enable both SLAAC framed-prefix and DHCPv6 address provisioning, if only to provide working IPv6 connectivity to as many customers as possible, given the plethora of different ways they can connect.
I think the short story is that a RADIUS “session” can have 0+ IPv6 addresses/prefixes. This is I suppose similar to IPv4, if you use Framed-Route to give customers additional addresses - these can exist in Accounting-Request messages. The big difference with Framed-Route in IPv4 is there is not generally a mechanism for customers to be automatically assigned their own prefix with IPv4 -- at least I have never heard of a means to do so. The only way that the customer is going to get an IPv4 prefix is if the attribute is provided via RADIUS in the Access-Accept packet, and in that event, you don't necessarily need the accounting to know that the customer has that prefix (since somewhere else in the same RADIUS database there is the attribute that provided it in the first place). This is different with IPv6, where the customer can get a Delegated-IPv6-Prefix and/or Framed-IPv6-Prefix by automatic means without that prefix having been originally assigned via RADIUS, and having the accounting record is therefore more crucial.
I don’t know if this is something that FreeRADIUS should attempt to solve in a generic way, or if there should perhaps be some examples and have it left up to the operator. If it is solved in a generic way, how would that be done? - Additional tables for prefix assignments? - ARRAY support in SQL? (Not in MySQL, but is in other SQL DBs) - JSON or some other serialisation of an array in to text? - ARRAY for most DBs, JSON blob for others?
I considered the idea of another table, because it is tempting to have the idea of a structure that represents IPv6 addresses that the customer has in a single place, but that increases complexity in its own way. If you did have a second table, however, it would be even more tempting to have it store all other attributes that aren't recorded elsewhere, with fields for radacctid (to associate it with the correct accounting record), attribute name, and attribute value. It's always a weakness of the DB-field-per-attribute SQL approach that you aren't recording all accounting fields in the database, and the separate table would provide that - the database could record every value that the NAS provides. Alternatively as you suggest, you could have a JSON blob that records the remaining attributes. I don't personally like the idea of using a type like ARRAY that MySQL doesn't support, especially since it is probably the case that most FreeRADIUS SQL implementations out there are using MySQL.
However, I don't think it is necessarily a technical problem to have three different fields to store the IPv6 address and searching across three fields. The biggest risk is going to be lack of understanding of what the fields are for, where developers who create billing systems or web interfaces that offer some kind of address search function may only program it to search one of the three fields, not understanding the purpose of the different fields. I expect that a developer extending their billing system or web interface to IPv6, not having an understanding of some of the technicalities, would think that search of a "framedipv6address" field was sufficient and not bother to search the "framedipv6prefix" and "delegatedipv6prefix" fields, and that would end up creating issues for end users.
Michael
------------------------------
Message: 5 Date: Sun, 19 Aug 2018 17:49:21 +1200 From: Nathan Ward <lists+freeradius@daork.net> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: IPv6 accounting RADIUS SQL schema? Message-ID: <1BF16ACE-882B-4F49-A696-A2E1685F9A62@daork.net> Content-Type: text/plain; charset=utf-8
Hi,
On 19/08/2018, at 5:21 PM, Michael Ducharme <mducharme@gmail.com> wrote:
However, I don't think it is necessarily a technical problem to have three different fields to store the IPv6 address and searching across three fields. The biggest risk is going to be lack of understanding of what the fields are for, where developers who create billing systems or web interfaces that offer some kind of address search function may only program it to search one of the three fields, not understanding the purpose of the different fields. I expect that a developer extending their billing system or web interface to IPv6, not having an understanding of some of the technicalities, would think that search of a "framedipv6address" field was sufficient and not bother to search the "framedipv6prefix" and "delegatedipv6prefix" fields, and that would end up creating issues for end users.
If this would be the approach then I think it’s best left as examples of what could be done, rather than change the standard schema - a standard schema needs to support 0+ of each of the fields you suggest here, not simply 0-1.
-- Nathan Ward
------------------------------
Subject: Digest Footer
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------
End of Freeradius-Users Digest, Vol 160, Issue 33 *************************************************