Re: [RADIATOR] Tacacs Authentication to survive reloads ?
Hello,
Yes, I'm aware of that option.
But despite setting it and seeing it being in use, aka. I see that it gets
updated, the authentication doesn't survive the reload/restart.
Trace 4 Log info:
--
the authentication
-
Fri Apr 13 09:21:46 2012: DEBUG: New TacacsplusConnection created for
equipment-ip:50393
Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection request 192, 1, 1, 0,
536499257, 35
Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Authentication START 1,
1, 1 for username, telnet261, user-ip
Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Authentication REPLY 5,
1, Password:,
Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection request 192, 1, 3, 0,
536499257, 14
Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Authentication CONTINUE
0, **obscured**,
Fri Apr 13 09:21:46 2012: DEBUG: TACACSPLUS derived Radius request packet dump:
Code: Access-Request
Identifier: UNDEF
Authentic: 163311602451407134J^178173170157J@l
Attributes:
NAS-IP-Address = equipment-ip
NAS-Port-Id = telnet261
Calling-Station-Id = user-ip
Service-Type = Login-User
NAS-Identifier = TACACS
User-Name = username
User-Password = **obscured**
cisco-avpair = action=1
cisco-avpair = authen_type=1
cisco-avpair = priv-lvl=15
cisco-avpair = service=1
OSC-Version-Identifier = 192
Fri Apr 13 09:21:46 2012: DEBUG: Handling request with Handler 'Realm=',
Identifier 'HandlerMAINIdentUser'
Fri Apr 13 09:21:46 2012: DEBUG: SessionDBM Deleting session for username,
equipment-ip,
Fri Apr 13 09:21:46 2012: DEBUG: Handling with Radius::AuthGROUP:
AuthenticateMainUsers
Fri Apr 13 09:21:46 2012: DEBUG: Handling with Radius::AuthGROUP:
AuthenticateLuser1
Fri Apr 13 09:21:46 2012: DEBUG: Handling with Radius::AuthGROUP:
Fri Apr 13 09:21:46 2012: DEBUG: Handling with Radius::AuthFILE:
Fri Apr 13 09:21:46 2012: DEBUG: Reading users file /etc/radiator/mix/manager
Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthFILE looks for match with
username [username]
Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthFILE ACCEPT: : username
[username]
Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthGROUP: result: ACCEPT,
Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthGROUP:AuthenticateLuser1 result:
ACCEPT,
Fri Apr 13 09:21:46 2012: DEBUG: Handling with PAM service radiusd
Fri Apr 13 09:21:46 2012: DEBUG: PAM is asking for 1: 'Password'
Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthGROUP:AuthenticateLuser1 result:
ACCEPT,
Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthGROUP:AuthenticateMainUsers
AuthenticateLuser1 result: ACCEPT,
Fri Apr 13 09:21:46 2012: DEBUG: AuthBy GROUP result: ACCEPT,
Fri Apr 13 09:21:46 2012: DEBUG: Access accepted for username
Fri Apr 13 09:21:46 2012: DEBUG: Packet dump:
*** Reply to TACACSPLUS request:
Code: Access-Accept
Identifier: UNDEF
Authentic: 163311602451407134J^178173170157J@l
Attributes:
Service-Type = Administrative-User
Mikrotik-Group = full
AuthGroup = manager
Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection result Access-Accept
Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Authentication REPLY 1,
0, ,
Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection disconnected from
equipment-ip:50393
Fri Apr 13 09:21:46 2012: DEBUG: New TacacsplusConnection created for
equipment-ip:50787
Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection request 192, 2, 1, 0,
373655910, 54
Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Authorization REQUEST 6,
15, 1, 1, username, telnet261, user-ip, 2, service=shell cmd=
Fri Apr 13 09:21:46 2012: DEBUG: AuthorizeGroup rule match found: permit
service=shell cmd= { priv-lvl=15 }
Fri Apr 13 09:21:46 2012: INFO: Authorization permitted for username at
equipment-ip, group manager, args service=shell cmd=
Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Authorization RESPONSE 1,
, , priv-lvl=15
Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection disconnected from
equipment-ip:50787
Fri Apr 13 09:21:46 2012: DEBUG: New TacacsplusConnection created for
equipment-ip:36884
Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection request 192, 3, 1, 0,
2069353695, 72
Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Accounting REQUEST 2, 6,
15, 1, 1, username, telnet261, user-ip, 2, start_time=1334330908
service=shell
Fri Apr 13 09:21:46 2012: DEBUG: TACACSPLUS derived Radius request packet dump:
Code: Accounting-Request
Identifier: UNDEF
Authentic: 1193fw227139142209:167]195214131197
Attributes:
NAS-IP-Address = equipment-ip
NAS-Port-Id = telnet261
Calling-Station-Id = user-ip
NAS-Identifier = TACACS
User-Name = username
Acct-Status-Type = Start
Acct-Session-Id = 2069353695
cisco-avpair = start_time=1334330908
cisco-avpair = service=shell
OSC-Version-Identifier = 192
Fri Apr 13 09:21:46 2012: DEBUG: Handling request
Re: [RADIATOR] FW: RADIATOR: EAP-FAST-MSCHAPv2
On 04/12/2012 04:14 PM, Sudhir Harwalkar wrote: 1. Whenever I flash the new code to the device it's generating new PAC key at that time it's getting authenticate with the server, If PACs are gone after a restart, but our device generating the same and send to the server so it should authenticate, why that's not happening here. If the server has lost its PACs, the client PAC are useless. It is the server that decides if the PAC is valid. If the server refuses the PAC client sends, then a new PAC needs to be provisioned to the client. That is my take to how this should work. 2. For EAP-TLS I took CA Certificate from C:\Radiator\Radiator-Locked-4.9\certificates\demoCA \cacert.pem and for Client I used C:\Radiator\Radiator-Locked-4.9\certificates\ cert-clt.pem is these are the correct files that I am using. Yes. See goodies/eap_tls.cfg for an example of EAP-TLS configuration. Heikki Sudhir H -Original Message- From: Heikki Vatiainen [mailto:h...@open.com.au] Sent: Thursday, April 12, 2012 2:52 PM To: Sudhir Harwalkar Subject: Re: FW: [RADIATOR] FW: RADIATOR: EAP-FAST-MSCHAPv2 On 04/12/2012 09:25 AM, Sudhir Harwalkar wrote: Thanks for helping me Heikki, when I flash the new code, then start the radius server it's working fine after that I restarted the radius server and power on the device then it's not authenticated. Again I flash the code and verified working fine. Ok. Good to hear it works. Problem arises only if I restart the radius server. This should not happen right. By default Radiator keeps PACs in memory and they are gone after a restart. There is a possibility to keep them in SQL so that they survive across reboots. Heikki Larsen Toubro Limited www.larsentoubro.com This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] FW: RADIATOR: EAP-FAST-MSCHAPv2
Hi Heikki, Thanks for information, 1. Please guide me how to keep PACs in memory, what are all the changes need to make in config files. 2. I tried to authenticate with the EAP-TLS, as I was seen Access challenge message only and I haven't found any error in that case, please find the log, and config files for this. Regards Sudhir H -Original Message- From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On Behalf Of Heikki Vatiainen Sent: Friday, April 13, 2012 6:00 PM To: radiator@open.com.au Subject: Re: [RADIATOR] FW: RADIATOR: EAP-FAST-MSCHAPv2 On 04/12/2012 04:14 PM, Sudhir Harwalkar wrote: 1. Whenever I flash the new code to the device it's generating new PAC key at that time it's getting authenticate with the server, If PACs are gone after a restart, but our device generating the same and send to the server so it should authenticate, why that's not happening here. If the server has lost its PACs, the client PAC are useless. It is the server that decides if the PAC is valid. If the server refuses the PAC client sends, then a new PAC needs to be provisioned to the client. That is my take to how this should work. 2. For EAP-TLS I took CA Certificate from C:\Radiator\Radiator-Locked-4.9\certificates\demoCA \cacert.pem and for Client I used C:\Radiator\Radiator-Locked-4.9\certificates\ cert-clt.pem is these are the correct files that I am using. Yes. See goodies/eap_tls.cfg for an example of EAP-TLS configuration. Heikki Sudhir H -Original Message- From: Heikki Vatiainen [mailto:h...@open.com.au] Sent: Thursday, April 12, 2012 2:52 PM To: Sudhir Harwalkar Subject: Re: FW: [RADIATOR] FW: RADIATOR: EAP-FAST-MSCHAPv2 On 04/12/2012 09:25 AM, Sudhir Harwalkar wrote: Thanks for helping me Heikki, when I flash the new code, then start the radius server it's working fine after that I restarted the radius server and power on the device then it's not authenticated. Again I flash the code and verified working fine. Ok. Good to hear it works. Problem arises only if I restart the radius server. This should not happen right. By default Radiator keeps PACs in memory and they are gone after a restart. There is a possibility to keep them in SQL so that they survive across reboots. Heikki Larsen Toubro Limited www.larsentoubro.com This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator Larsen Toubro Limited www.larsentoubro.com This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. eap_tls.cfg Description: eap_tls.cfg logfile Description: logfile ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Idle timeout issue
Acct terminate cause is User-Request, meaning the hotspot received a session
end instruction from the device, eg. logoff URL, or a disassociation which the
hotspot translates as User-Request (eg. laptop going to sleep). There is no
Session-Timeout or Idle-Timeout in the logs that would correspond to what you
describe.
On Apr 13, 2012, at 3:26 PM, Jennings Tuala jtu...@blueskysamoa.com wrote:
Hi there,
I’m having some issues with idle timeouts in radiator. Users are suddenly
being disconnected after say 25 minutes of inactivity. This never used to
happen before so I attached a trace 4 debug for you to have a look at. Would
greatly appreciate your assistance please.
Thanks,
Jay
Tue Apr 10 15:48:32 2012: DEBUG: Packet dump:
*** Received from 110.5.112.85 port 32817
Code: Access-Request
Identifier: 29
Authentic: 137202239165163W9Xfg168144174216
Attributes:
User-Name = 6100510
User-Password = @[4=161221154u141014351165_250
NAS-IP-Address = 110.5.112.85
Service-Type = Login-User
Framed-IP-Address = 10.17.4.212
Called-Station-Id = 00:90:0B:05:6B:14
Calling-Station-Id = 38:59:f9:80:c8:5d
NAS-Identifier = 110.5.112.85
Acct-Session-Id = 00:90:0B:05:6B:14:13341172017
NAS-Port-Type = Wireless-IEEE-802-11
Tue Apr 10 15:48:32 2012: DEBUG: Handling request with Handler '', Identifier
''
Tue Apr 10 15:48:32 2012: DEBUG: Deleting session for 6100510, 110.5.112.85,
Tue Apr 10 15:48:32 2012: DEBUG: do query is: 'delete from RADONLINE where
NASIDENTIFIER='110.5.112.85' and NASPORT=0':
Tue Apr 10 15:48:32 2012: DEBUG: Handling with Radius::AuthSQL:
Tue Apr 10 15:48:32 2012: DEBUG: Handling with Radius::AuthSQL:
Tue Apr 10 15:48:32 2012: DEBUG: Query is: 'select PASSWORD, SESSIONTIMEOUT
from SUBSCRIBERS where USERNAME='6100510' and SESSIONTIMEOUT 0':
Tue Apr 10 15:48:32 2012: DEBUG: Radius::AuthSQL looks for match with 6100510
[6100510]
Tue Apr 10 15:48:32 2012: DEBUG: Radius::AuthSQL ACCEPT: : 6100510 [6100510]
Tue Apr 10 15:48:32 2012: DEBUG: AuthBy SQL result: ACCEPT,
Tue Apr 10 15:48:32 2012: DEBUG: Access accepted for 6100510
Tue Apr 10 15:48:32 2012: DEBUG: Packet dump:
*** Sending to 110.5.112.85 port 32817
Code: Access-Accept
Identifier: 29
Authentic: 253;226m181{}V28250198209179151176224
Attributes:
Session-Timeout = 86400
Tue Apr 10 15:48:32 2012: DEBUG: Packet dump:
*** Received from 110.5.112.85 port 32817
Code: Accounting-Request
Identifier: 30
Authentic: {211=c;_160152Z1322210RE2533
Attributes:
User-Name = 6100510
Acct-Status-Type = Start
Acct-Session-Id = 00:90:0B:05:6B:14:13341172017
Acct-Authentic = Local
NAS-Identifier = 110.5.112.85
NAS-IP-Address = 110.5.112.85
Calling-Station-Id = 38:59:f9:80:c8:5d
Called-Station-Id = 00:90:0B:05:6B:14
Framed-IP-Address = 10.17.4.212
NAS-Port-Type = Wireless-IEEE-802-11
Tue Apr 10 15:48:32 2012: DEBUG: Handling request with Handler '', Identifier
''
Tue Apr 10 15:48:32 2012: DEBUG: Adding session for 6100510, 110.5.112.85,
Tue Apr 10 15:48:32 2012: DEBUG: do query is: 'delete from RADONLINE where
NASIDENTIFIER='110.5.112.85' and NASPORT=00':
Tue Apr 10 15:48:32 2012: DEBUG: do query is: 'insert into SUBSCRIBERS
(USERNAME, NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP, FRAMEDIPADDRESS,
NASPORTTYPE, SERVICETYPE, DNIS)':
Tue Apr 10 15:48:32 2012: ERR: do failed for 'insert into SUBSCRIBERS
(USERNAME, NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP, FRAMEDIPADDRESS,
NASPORTTYPE, SERVICETYPE, DNIS)': You have an error in your SQL syntax; check
the manual that corresponds to your MySQL server version for the right
syntax to use near '' at line 1
Tue Apr 10 15:48:32 2012: ERR: do failed for 'insert into SUBSCRIBERS
(USERNAME, NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP, FRAMEDIPADDRESS,
NASPORTTYPE, SERVICETYPE, DNIS)': You have an error in your SQL syntax; check
the manual that corresponds to your MySQL server version for the right
syntax to use near '' at line 1
Tue Apr 10 15:48:32 2012: DEBUG: Handling with Radius::AuthSQL:
Tue Apr 10 15:48:32 2012: DEBUG: Handling accounting with Radius::AuthSQL
Tue Apr 10 15:48:32 2012: DEBUG: AuthBy SQL result: ACCEPT,
Tue Apr 10 15:48:32 2012: DEBUG: Accounting accepted
Tue Apr 10 15:48:32 2012: DEBUG: Packet dump:
*** Sending to 110.5.112.85 port 32817
Code: Accounting-Response
Identifier: 30
Authentic: 1594g16154,Pq29169L159251160242
Attributes:
Tue Apr 10 16:14:18 2012: DEBUG: Packet dump:
*** Received from 110.5.112.85 port 32817
Code: Accounting-Request
Identifier: 29
Authentic: 1533B}f158172Pb3019213924623h148
Attributes:
User-Name = 6100510
Acct-Status-Type
Re: [RADIATOR] Tacacs Authentication to survive reloads ?
The patterns received with AuthorizeGroupAttr are stored in the context and override the patterns in the config file. Now when the context is gone with the reload, the possible overrides are gone too. I think this is the reason why it refuses to process authorization. The authorization patters may no longer be correct without the overrides. So.. downgrade to pre-4.8 ? or any way to re-instate the context(s) after a reload in some way ? or is there something in the configuration I can change to make it better for the tacacs server ? Regards, Patrik Forsberg ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Idle timeout issue
Hi Mike,
This never used to happen before. Prior to this issue, all sessions would
run continuously for the entire provisioned time (which was what we
wanted). Eg. A 2 hour pass would have a 2 hour continuous session until it
ran out, regardless of whether the laptop went into sleep
mode/shutdown/rebooted…etc.
This issue just cropped up recently. I read somewhere that the mysql
database might be sending a kill switch but I’m not sure as I’m a mysql
novice. I have however checked my database and can’t see anything regarding
idle timeout or session timeout, but then again, I could be looking in the
wrong place. L
Really appreciate your help and response as this is an issue I would love
to solve before we launch our hotspot service.
Best regards,
Jay
*From:* Mike Puchol [mailto:puc...@me.com]
*Sent:* Saturday, 14 April 2012 2:42 AM
*To:* Jennings Tuala
*Cc:* radiator@open.com.au
*Subject:* Re: [RADIATOR] Idle timeout issue
Acct terminate cause is User-Request, meaning the hotspot received a
session end instruction from the device, eg. logoff URL, or a
disassociation which the hotspot translates as User-Request (eg. laptop
going to sleep). There is no Session-Timeout or Idle-Timeout in the logs
that would correspond to what you describe.
On Apr 13, 2012, at 3:26 PM, Jennings Tuala jtu...@blueskysamoa.com wrote:
Hi there,
I’m having some issues with idle timeouts in radiator. Users are suddenly
being disconnected after say 25 minutes of inactivity. This never used to
happen before so I attached a trace 4 debug for you to have a look at.
Would greatly appreciate your assistance please.
Thanks,
Jay
Tue Apr 10 15:48:32 2012: DEBUG: Packet dump:
*** Received from 110.5.112.85 port 32817
Code: Access-Request
Identifier: 29
Authentic: 137202239165163W9Xfg168144174216
Attributes:
User-Name = 6100510
User-Password = @[4=161221154u141014351165_250
NAS-IP-Address = 110.5.112.85
Service-Type = Login-User
Framed-IP-Address = 10.17.4.212
Called-Station-Id = 00:90:0B:05:6B:14
Calling-Station-Id = 38:59:f9:80:c8:5d
NAS-Identifier = 110.5.112.85
Acct-Session-Id = 00:90:0B:05:6B:14:13341172017
NAS-Port-Type = Wireless-IEEE-802-11
Tue Apr 10 15:48:32 2012: DEBUG: Handling request with Handler '',
Identifier ''
Tue Apr 10 15:48:32 2012: DEBUG: Deleting session for 6100510,
110.5.112.85,
Tue Apr 10 15:48:32 2012: DEBUG: do query is: 'delete from RADONLINE where
NASIDENTIFIER='110.5.112.85' and NASPORT=0':
Tue Apr 10 15:48:32 2012: DEBUG: Handling with Radius::AuthSQL:
Tue Apr 10 15:48:32 2012: DEBUG: Handling with Radius::AuthSQL:
Tue Apr 10 15:48:32 2012: DEBUG: Query is: 'select PASSWORD, SESSIONTIMEOUT
from SUBSCRIBERS where USERNAME='6100510' and SESSIONTIMEOUT 0':
Tue Apr 10 15:48:32 2012: DEBUG: Radius::AuthSQL looks for match with
6100510 [6100510]
Tue Apr 10 15:48:32 2012: DEBUG: Radius::AuthSQL ACCEPT: : 6100510 [6100510]
Tue Apr 10 15:48:32 2012: DEBUG: AuthBy SQL result: ACCEPT,
Tue Apr 10 15:48:32 2012: DEBUG: Access accepted for 6100510
Tue Apr 10 15:48:32 2012: DEBUG: Packet dump:
*** Sending to 110.5.112.85 port 32817
Code: Access-Accept
Identifier: 29
Authentic: 253;226m181{}V28250198209179151176224
Attributes:
Session-Timeout = 86400
Tue Apr 10 15:48:32 2012: DEBUG: Packet dump:
*** Received from 110.5.112.85 port 32817
Code: Accounting-Request
Identifier: 30
Authentic: {211=c;_160152Z1322210RE2533
Attributes:
User-Name = 6100510
Acct-Status-Type = Start
Acct-Session-Id = 00:90:0B:05:6B:14:13341172017
Acct-Authentic = Local
NAS-Identifier = 110.5.112.85
NAS-IP-Address = 110.5.112.85
Calling-Station-Id = 38:59:f9:80:c8:5d
Called-Station-Id = 00:90:0B:05:6B:14
Framed-IP-Address = 10.17.4.212
NAS-Port-Type = Wireless-IEEE-802-11
Tue Apr 10 15:48:32 2012: DEBUG: Handling request with Handler '',
Identifier ''
Tue Apr 10 15:48:32 2012: DEBUG: Adding session for 6100510, 110.5.112.85,
Tue Apr 10 15:48:32 2012: DEBUG: do query is: 'delete from RADONLINE where
NASIDENTIFIER='110.5.112.85' and NASPORT=00':
Tue Apr 10 15:48:32 2012: DEBUG: do query is: 'insert into SUBSCRIBERS
(USERNAME, NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP,
FRAMEDIPADDRESS,
NASPORTTYPE, SERVICETYPE, DNIS)':
Tue Apr 10 15:48:32 2012: ERR: do failed for 'insert into SUBSCRIBERS
(USERNAME, NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP,
FRAMEDIPADDRESS,
NASPORTTYPE, SERVICETYPE, DNIS)': You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the right
syntax to use near '' at line 1
Tue Apr 10 15:48:32 2012: ERR: do failed for 'insert into SUBSCRIBERS
(USERNAME, NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP,
FRAMEDIPADDRESS,
NASPORTTYPE, SERVICETYPE, DNIS)': You have an error in
