Freeradius-Users Digest, Vol 160, Issue 33

[Imdad Hasan]

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 at lists.freeradius.org> wrote:

> Send Freeradius-Users mailing list submissions to
>         freeradius-users at 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 at lists.freeradius.org
>
> You can reach the person managing the list at
>         freeradius-users-owner at 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 at gmail.com>
> To: freeradius-users at lists.freeradius.org
> Subject: Renew the session at midnight 12 o clock
> Message-ID:
>         <
> CAPidyMV-OmZWUxBwrH8RvxfP5COBVpTcUZu2gAfmCUvCZoq-rA at 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 at daork.net>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: Re: Renew the session at midnight 12 o clock
> Message-ID: <33845DBE-D464-4713-B980-0479726912C9 at daork.net>
> Content-Type: text/plain;       charset=utf-8
>
>
> > On 19/08/2018, at 9:34 AM, Imdad Hasan <imdadalikadiwala0 at 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 at daork.net>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: Re: IPv6 accounting RADIUS SQL schema?
> Message-ID: <786ED99C-8491-4A52-AEB3-B9D9FCC3E540 at daork.net>
> Content-Type: text/plain;       charset=utf-8
>
> Hi,
>
> > On 19/08/2018, at 9:11 AM, Michael Ducharme <mducharme at 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 at gmail.com>
> To: freeradius-users at lists.freeradius.org
> Subject: Re: IPv6 accounting RADIUS SQL schema?
> Message-ID: <5f9b3c0e-23ee-f7c0-46aa-5618b2274cd3 at 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 at daork.net>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: Re: IPv6 accounting RADIUS SQL schema?
> Message-ID: <1BF16ACE-882B-4F49-A696-A2E1685F9A62 at daork.net>
> Content-Type: text/plain;       charset=utf-8
>
> Hi,
>
> > On 19/08/2018, at 5:21 PM, Michael Ducharme <mducharme at 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
> *************************************************
>