Freeradius-Users Digest, Vol 160, Issue 34
Imdad Hasan
imdadalikadiwala0 at gmail.com
Sun Aug 19 12:01:59 CEST 2018
Thanks Nathan Ward,
Sure,
Say for example:
if any user "XYZ" have a one accounting session with the acct-start-time =
"2018-08-16 05:00:00" and acct-stop-time = " 2018-08-19 11:16:46". Ok.
Means only one accounting session 3 days. So, in this example how can i
calculate OR get the "2018-08-17" OR "2018-08-18" s' data usage of that
"XYZ" user?
Warm Regard's
Imdadali Kadiwala
On Sun, Aug 19, 2018 at 3:18 PM, <
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. Re: IPv6 accounting RADIUS SQL schema? (Michael Ducharme)
> 2. Re: Freeradius-Users Digest, Vol 160, Issue 33 (Imdad Hasan)
> 3. Re: daily usage report (Nathan Ward)
> 4. Re: IPv6 accounting RADIUS SQL schema? (Nathan Ward)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 18 Aug 2018 23:57: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: <2ac45a24-7dbf-7c03-c31e-b70cf41f5b60 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 8/18/2018 10:49 PM, Nathan Ward wrote:
> > 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.
> There *needs* to be a standard schema for IPv6 soon, the billing system
> we use does not support IPv6 RADIUS accounting yet mainly because there
> are no standard FreeRADIUS/MySQL field names to read the data from
> (hence the reason for my question and my pull request). How can I get
> our billing system vendor to support IPv6 RADIUS accounting in
> FreeRADIUS/MySQL when there are not even standard fields for storing
> this data?
>
> And, regarding 0+ instead of 0-1, even though the attributes may
> technically be usable multiple times, how often does this happen in
> practice? I would expect extremely rarely, based on what I have seen,
> especially in an automated sense. If there are multiple
> Delegated-IPv6-Prefix attributes, chances are that it is not due to an
> automated system but instead due to RADIUS assignment of
> Delegated-IPv6-Prefix, and that case is like the IPv4 Framed-Route
> attribute. If Delegated-IPv6-Prefix is assigned via RADIUS from the
> beginning, then at least there is a record that that prefix was assigned
> to that customer besides the accounting record.
>
> I just don't want this to turn into a "lets do nothing" situation, due
> to a few potential corner case situations, because then nothing is going
> to happen.
>
> Michael
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 19 Aug 2018 15:08:21 +0530
> From: Imdad Hasan <imdadalikadiwala0 at gmail.com>
> To: freeradius-users at lists.freeradius.org
> Subject: Re: Freeradius-Users Digest, Vol 160, Issue 33
> Message-ID:
> <CAPidyMX7ZM-8f4gujFTiQK84ZuhLmZAFPihoEvA=E
> Jr1d+OdKA at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
> > *************************************************
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 19 Aug 2018 21:43:29 +1200
> From: Nathan Ward <lists+freeradius at daork.net>
> To: FreeRadius users mailing list
> <freeradius-users at lists.freeradius.org>
> Subject: Re: daily usage report
> Message-ID: <D01DBD1C-9EC8-4FF5-8344-BA924FB40D65 at daork.net>
> Content-Type: text/plain; charset=utf-8
>
> You might want to subscribe to the list non-digest :-)
>
> > On 19/08/2018, at 9:38 PM, Imdad Hasan <imdadalikadiwala0 at gmail.com>
> wrote:
> >
> > 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.
>
> Sure there are plenty of ways. What is the problem re. the sessions being
> older than one or two days? Please be explicit about your problem and what
> you’re trying to achieve, and include as much detail as possible. I can
> guess, but, I am not exactly sure so I won’t. “Proper” is not an objective
> term - can you expand on that?
>
> --
> Nathan Ward
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 19 Aug 2018 21:47:54 +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: <CB334B87-4076-4673-9FA3-E0FBF0CA1E61 at daork.net>
> Content-Type: text/plain; charset=utf-8
>
>
> > On 19/08/2018, at 6:57 PM, Michael Ducharme <mducharme at gmail.com> wrote:
> >
> > On 8/18/2018 10:49 PM, Nathan Ward wrote:
> >> 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.
> > There *needs* to be a standard schema for IPv6 soon, the billing system
> we use does not support IPv6 RADIUS accounting yet mainly because there are
> no standard FreeRADIUS/MySQL field names to read the data from (hence the
> reason for my question and my pull request). How can I get our billing
> system vendor to support IPv6 RADIUS accounting in FreeRADIUS/MySQL when
> there are not even standard fields for storing this data?
>
> I would query why that data is in your billing system, but, I’m sure you
> have your reasons.
> Generally I prefer to expose data to “external” systems through APIs,
> rather than give them direct database access and tightly couple two
> applications together though a DB schema which may need to change for one
> side or the other.
>
> > And, regarding 0+ instead of 0-1, even though the attributes may
> technically be usable multiple times, how often does this happen in
> practice? I would expect extremely rarely, based on what I have seen,
> especially in an automated sense. If there are multiple
> Delegated-IPv6-Prefix attributes, chances are that it is not due to an
> automated system but instead due to RADIUS assignment of
> Delegated-IPv6-Prefix, and that case is like the IPv4 Framed-Route
> attribute. If Delegated-IPv6-Prefix is assigned via RADIUS from the
> beginning, then at least there is a record that that prefix was assigned to
> that customer besides the accounting record.
>
> > I just don't want this to turn into a "lets do nothing" situation, due
> to a few potential corner case situations, because then nothing is going to
> happen.
>
> I don’t think this is a hard problem to solve in a more flexible manner.
> Given that, I think we should do so.
>
> --
> 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 34
> *************************************************
>
More information about the Freeradius-Users
mailing list