+1Hi all!
We try to use Mikrotik as router and DHCP server.
Switches send DHCP packets to Mtik, Mtik make req to Radius server and receive
dhcp pool name, speed limits...
All work good, but small problem.. No accounting
And i don't know IP address of user (from pool), traffic.
And don't know when user stops use address
Maybe it's possible:
1. Send Accounting-Start packet with IP address, when lease and queue created and up?
2. Send Accounting-Stop packet with traffic from queue (if created), when lease dropped?
Many people try to use Opt82 instead PPPxx, it's may be a good solution.
it's supported for many years alreadyand Option 82 support.
but this topic IS about RADIUS I think he should open a new topic (or better a support ticket?) about option82-based (not MAC-based, like now) leasesHe talks about native support for DHCP OPT82 without radius.
it's how it works: if you don't set lease timeout in RADIUS Access-Accept, then the value from DHCP server settings is used, and no RADIUS Request is made for lease renewals; if you return timeout from RADIUS, then any renews of that lease will require RADIUS authorization - that's what you're looking forAlso, I thought I would see an auth request every time the lease was renewed, but I haven't seen any auth requests after the initial request unless I delete the dynamic lease on the mikrotik before the lease is renewed.
Thank you, that is very helpful to know.it's how it works: if you don't set lease timeout in RADIUS Access-Accept, then the value from DHCP server settings is used, and no RADIUS Request is made for lease renewals; if you return timeout from RADIUS, then any renews of that lease will require RADIUS authorization - that's what you're looking forAlso, I thought I would see an auth request every time the lease was renewed, but I haven't seen any auth requests after the initial request unless I delete the dynamic lease on the mikrotik before the lease is renewed.
dear Chupaka, can you give me some example of how to configure RB DHCP Server to resend option82 data of DHCP request (received from some port L2 commutator) to freeRadius server connected directly to RB????it's how it works: if you don't set lease timeout in RADIUS Access-Accept, then the value from DHCP server settings is used, and no RADIUS Request is made for lease renewals; if you return timeout from RADIUS, then any renews of that lease will require RADIUS authorization - that's what you're looking for
as far as I can see, you just cannot disable it. if Option82 info exists in DHCP request, it will be sent to RADIUScan you give me some example of how to configure RB DHCP Server to resend option82 data of DHCP request (received from some port L2 commutator) to freeRadius server connected directly to RB????
Thanks, but what about freeRadius configuration? Do you have/know any examples?? or may be you know who can help me?as far as I can see, you just cannot disable it. if Option82 info exists in DHCP request, it will be sent to RADIUS
so just set 'use-radius=yes' on your dhcp server and then create radius for service=dhcp
Yes, why Mikrotik can't do it still???But the best way is DHCP-Radius packets for start, renew and expire lease.
It;s easy for development and i don't know, why Mikrotik can't do it.
+1Yes, I believe there are many people interested in this topic. Any response would be pleased. "We plan to implement" or "We don't plan to implement" would be sufficient .
+1through interim updates
+1It would be best if Mikrotik can send these accounting data to the RADIUS every time the device disconnected or through interim updates.
+1Yes, I believe there are many people interested in this topic. Any response would be pleased. "We plan to implement" or "We don't plan to implement" would be sufficient .
+1Yes, I believe there are many people interested in this topic. Any response would be pleased. "We plan to implement" or "We don't plan to implement" would be sufficient .
+1Yes, I believe there are many people interested in this topic. Any response would be pleased. "We plan to implement" or "We don't plan to implement" would be sufficient .
Have you successfully tested this one?Yes, I'm aware of it. Are you referring to this queue?rdelacruz - Please note that accounting will work only for those users which has a queue. Data for accounting is taken from queue statistics
If yes, can you please confirm that this added feature will work if we use RADIUS for accounting and lease? Thanks
Has anyone tested this feature?Have you successfully tested this one?Yes, I'm aware of it. Are you referring to this queue?rdelacruz - Please note that accounting will work only for those users which has a queue. Data for accounting is taken from queue statistics
If yes, can you please confirm that this added feature will work if we use RADIUS for accounting and lease? Thanks
I'm trying it on 6.45.3 in combination with radius server from BGBilling. Packets counting working properly, but traffic statistics looks very strange:Has anyone tested this feature?
08-08/15:35:14 INFO [rdsLstnr-p-7-t-16] InetRadiusProcessor - REQUEST_AFTER_PREPROCESS:
Packet type: Accounting-Request
Identifier: 25
Authenticator: {83 CF 00 41 9C 08 EC 4D E9 BF D9 C3 BE DE FA 1A}
Attributes:
NAS-Identifier=Core router
User-Name=00:AD:24:F9:BF:52
NAS-IP-Address=192.168.16.1
NAS-Port=-2095054647
Framed-IP-Address=172.16.58.9
Acct-Status-Type=3
Acct-Delay-Time=0
Acct-Input-Octets=938520311
Acct-Output-Octets=938520311
Acct-Session-Id=c9002083
Acct-Authentic=2
Acct-Session-Time=259
Acct-Input-Packets=670430
Acct-Output-Packets=108219
Acct-Input-Gigawords=0
Acct-Output-Gigawords=0
Event-Timestamp=1565267714
NAS-Port-Type=15
Called-Station-Id=client-58
Calling-Station-Id=1:0:ad:24:f9:bf:52