I installed FreeRADIUS 3.0.8 (built for Fedora 22) in Fedora 21.
This bug seems still existed. The different between 3.0.4 & 3.0.8 when writing to radacct table is that calledstationid value is shorter, but it's still too long to save to MySQL database.
Sorry, I didn't check doc/Changelog file of the latest version. I only search the issues here and not found a bug report about this.
I found this in doc/Changelog file according arr2036's comment. Since this bug had been closed and locked, I'll updated it here (in case other users may encountered similar issue).
Guess I need to wait for the release of Fedora 22 in several days. The newest version of FreeRADIUS in Fedora 21 is still 3.0.4.
Description
I'm creating a WiFi software AP with WPA2-Enterprise/RADIUS auth type.The SSID name in hostapd.conf is set to '烫烫烫 屯屯屯 锟斤拷' (UTF-8 encoding, so it's length should be 29(3*9+2) bytes).
The Called-Station-Id information received/logged by FreeRADIUS is 'D8-5D-4C-7A-CF-64:\\xe7\\x83\\xab\\xe7\\x83\\xab\\xe7\\x83\\xab \\xe5\\xb1\\xaf\\xe5\\xb1\\xaf\\xe5\\xb1\\xaf \\xe9\\x94\\x9f\\xe6\\x96\\xa4\\xe6\\x8b\\xb'. (the last byte should be '\\xb7', i don't know why 7 is missed here)
The calledstationid column value in INSERT sql statement is quoted-printable encoded string of Called-Station-Id: 'D8-5D-4C-7A-CF-64:=5C=5Cxe7=5C=5Cx83=5C=5Cxab=5C=5Cxe7=5C=5Cx83=5C=5Cxab=5C=5Cxe7=5C=5Cx83=5C=5Cxab =5C=5Cxe5=5C=5Cxb1=5C=5Cxaf=5C=5Cxe5=5C=5Cxb1=5C=5Cxaf=5C=5Cxe5=5C=5Cxb1=5C=5Cxaf =5C=5Cxe9=5C=5Cx94=5C=5Cx9f=5C=5Cxe6=5C=5Cx96=5C=5Cxa4=5C=5Cxe6=5C=5Cx8b=5C=5Cxb', which is too long (262 bytes) for varchar(50) datatype: Data too long for column 'calledstationid' at row 1'
I know I can change the data type of calledstationid to a longer data type as a workaround, but I'd like log the calledstationid using it's raw bytes code (which means 烫烫烫 屯屯屯 锟斤拷 string in UTF-8 encoding) rather than a quoted-printable encoded string.
The first two (烫 & 屯) comes from Visual C++ when debugging applications. Newly allocated memory in Visual C++ are all filled by 0xCC 0xCC... or 0xCD 0xCD..., which these bytes are 烫烫烫(HOT HOT HOT)... and 屯屯屯(collect/stock/station/village, but it sounds like 臀臀臀 which means BUTT BUTT BUTT)... in Simplifed Chinese Windows system (GBK encoding).
The last one had been described in wikipedia http://en.wikipedia.org/wiki/Specials_%28Unicode_block%29#Replacement_character . But in Simplified Chinese Windows system, when decoding 2 (or any even number) replacement character bytes (which is UTF-8 encoded: 0xEF 0xBF 0xBD, 0xEF 0xBF 0xBD) in GBK encoding (0xEF 0xBF, 0xBD 0xEF, 0xBF 0xBD), 锟斤拷 occurs!
Update 2
I installed FreeRADIUS 3.0.8 (built for Fedora 22) in Fedora 21.
This bug seems still existed. The different between 3.0.4 & 3.0.8 when writing to radacct table is that calledstationid value is shorter, but it's still too long to save to MySQL database.
3.0.4 '
D8-5D-4C-7A-CF-64:=5C=5Cxe7=5C=5Cx83=5C=5Cxab=5C=5Cxe7=5C=5Cx83=5C=5Cxab=5C=5Cxe7=5C=5Cx83=5C=5Cxab =5C=5Cxe5=5C=5Cxb1=5C=5Cxaf=5C=5Cxe5=5C=5Cxb1=5C=5Cxaf=5C=5Cxe5=5C=5Cxb1=5C=5Cxaf =5C=5Cxe9=5C=5Cx94=5C=5Cx9f=5C=5Cxe6=5C=5Cx96=5C=5Cxa4=5C=5Cxe6=5C=5Cx8b=5C=5Cxb
' (262 bytes)3.0.8 '
D8-5D-4C-7A-CF-64:=5Cxe7=5Cx83=5Cxab=5Cxe7=5Cx83=5Cxab=5Cxe7=5Cx83=5Cxab =5Cxe5=5Cxb1=5Cxaf=5Cxe5=5Cxb1=5Cxaf=5Cxe5=5Cxb1=5Cxaf =5Cxe9=5Cx94=5Cx9f=5Cxe6=5Cx96=5Cxa4=5Cxe6=5Cx8b=5Cxb
' (181 bytes)Update
Sorry, I didn't check doc/Changelog file of the latest version. I only search the issues here and not found a bug report about this.
I found this in doc/Changelog file according arr2036's comment. Since this bug had been closed and locked, I'll updated it here (in case other users may encountered similar issue).
Guess I need to wait for the release of Fedora 22 in several days. The newest version of FreeRADIUS in Fedora 21 is still 3.0.4.
Description
I'm creating a WiFi software AP with WPA2-Enterprise/RADIUS auth type.The SSID name in hostapd.conf is set to '
烫烫烫 屯屯屯 锟斤拷
' (UTF-8 encoding, so it's length should be 29(3*9+2) bytes).The Called-Station-Id information received/logged by FreeRADIUS is '
D8-5D-4C-7A-CF-64:\\xe7\\x83\\xab\\xe7\\x83\\xab\\xe7\\x83\\xab \\xe5\\xb1\\xaf\\xe5\\xb1\\xaf\\xe5\\xb1\\xaf \\xe9\\x94\\x9f\\xe6\\x96\\xa4\\xe6\\x8b\\xb
'. (the last byte should be '\\xb7
', i don't know why7
is missed here)The calledstationid column value in INSERT sql statement is quoted-printable encoded string of Called-Station-Id: '
D8-5D-4C-7A-CF-64:=5C=5Cxe7=5C=5Cx83=5C=5Cxab=5C=5Cxe7=5C=5Cx83=5C=5Cxab=5C=5Cxe7=5C=5Cx83=5C=5Cxab =5C=5Cxe5=5C=5Cxb1=5C=5Cxaf=5C=5Cxe5=5C=5Cxb1=5C=5Cxaf=5C=5Cxe5=5C=5Cxb1=5C=5Cxaf =5C=5Cxe9=5C=5Cx94=5C=5Cx9f=5C=5Cxe6=5C=5Cx96=5C=5Cxa4=5C=5Cxe6=5C=5Cx8b=5C=5Cxb
', which is too long (262 bytes) forvarchar(50)
datatype: Data too long for column 'calledstationid' at row 1'I know I can change the data type of calledstationid to a longer data type as a workaround, but I'd like log the calledstationid using it's raw bytes code (which means
烫烫烫 屯屯屯 锟斤拷
string in UTF-8 encoding) rather than a quoted-printable encoded string.My environment (all running in 1 pc):
Full log (3.0.8)
Full log (3.0.4):
Note: I have replaced my User-Name to
MY_USER_NAME
.About the SSID name
These 3 set of characters are 3 set famous malformed characters in GBK character encoding, see http://blog.csdn.net/jarelzhou/article/details/19013037 (Chinese) for details.
The first two (
烫
&屯
) comes from Visual C++ when debugging applications. Newly allocated memory in Visual C++ are all filled by 0xCC 0xCC... or 0xCD 0xCD..., which these bytes are烫烫烫
(HOT HOT HOT)... and屯屯屯
(collect/stock/station/village, but it sounds like 臀臀臀 which means BUTT BUTT BUTT)... in Simplifed Chinese Windows system (GBK encoding).The last one had been described in wikipedia http://en.wikipedia.org/wiki/Specials_%28Unicode_block%29#Replacement_character . But in Simplified Chinese Windows system, when decoding 2 (or any even number) replacement character bytes (which is UTF-8 encoded:
0xEF 0xBF 0xBD
,0xEF 0xBF 0xBD
) in GBK encoding (0xEF 0xBF
,0xBD 0xEF
,0xBF 0xBD
),锟斤拷
occurs!