ippool 0.0.0.0 assignment problem
Mirko Alberio
mirko.alberio at telemar.it
Tue Dec 14 15:46:48 CET 2021
Mirko Alberio - Systems & Software Integration Manager
e-mail:mirko.alberio at telemar.it
Telemar SpA Internet Quality Provider
Via Enrico Fermi, 235 - 36100 Vicenza - Italia
Tel 0444 291302 - Fax 0444 566310 -www.telemar.it
Assistenza tecnica 0444 1420000
Reg. Imp. Di Vicenza /C.F./P.I. 02508710247
Cap. Soc. € 120.000,00 I.V.
R.E.A. VI-236292
Il 14/12/2021 15:25, Alan DeKok ha scritto:
> On Dec 14, 2021, at 3:31 AM, Mirko Alberio via Freeradius-Users<freeradius-users at lists.freeradius.org> wrote:
>> I found the base problem of my radius ippool assignment problem!
>>
>> Maybe for future reference for other users, the problem was: WHITESPACE in an ip pool address row!
> It's best to be careful about what goes into a database. :(
>
> Unfortunately, MySQL doesn't have a native "ip address" data type. So the "IP address" field in the IP Pool schema is just free-form text. Which can create this kind of issue.
>
> In contrast, PostgreSQL does have a native "ip address" data type. So it's impossible for PostgreSQL to have this issue.
Yes, I thought about using PostgreSQL, we are using it for an open
source IP management system and it is very well structured for
network type data storage, I must say.
Also I saw that performance-wise would be better than MySql, even
though now I am using MySql 8 and is performing well.
>
>> So in some way the NAS where assuming 0.0.0.0 as framed ip address for this.
>>
>> This is the radiusd -X output that helped me:
> Exactly!
>
>> (1675) sqlippool: Executing query: COMMIT
>> (1675) sqlippool: EXPAND START TRANSACTION
>> (1675) sqlippool: --> START TRANSACTION
>> (1675) sqlippool: Executing query: START TRANSACTION
>> (1675) sqlippool: EXPAND SELECT framedipaddress FROM radippool WHERE pool_name = '%{control:Pool-Name}' AND (expiry_time < NOW() OR expiry_time IS NULL) ORDER BY (username <> '%{User-Name}'), (callingstationid <> '%{Calling-Station-Id}'), expiry_time LIMIT 1 FOR UPDATE SKIP LOCKED
>> (1675) sqlippool: --> SELECT framedipaddress FROM radippool WHERE pool_name = 'pool1' AND (expiry_time < NOW() OR expiry_time IS NULL) ORDER BY (username <> 'xxxxxxxxx'), (callingstationid <> 'XX:XX:XX:75:36:B6'), expiry_time LIMIT 1 FOR UPDATE SKIP LOCKED
>> (1675) sqlippool: Executing select query: SELECT framedipaddress FROM radippool WHERE pool_name = 'pool1' AND (expiry_time < NOW() OR expiry_time IS NULL) ORDER BY (username <> 'xxxxxxxxx'), (callingstationid <> 'XX:XX:XX:75:36:B6'), expiry_time LIMIT 1 FOR UPDATE SKIP LOCKED
>> (1675) sqlippool: EXPAND COMMIT
>> (1675) sqlippool: --> COMMIT
>> (1675) sqlippool: Executing query: COMMIT
>> *(1675) sqlippool: Invalid IP number **[12.34.56.7__] **returned from instbase query.*
> I've fixed the typo ("instbase" ???). I've also double-checked the sqlippool module for other messages. It now produces ERROR messages when it can't assign an IP address. These messages should show up as red, with a big ERROR prefix in the debug output.
>
> Even using "tcpdump" or "wireshark" would have helped here. If a user is online with "0.0.0.0", then look at the Access-Accept packet sent back for that user. My guess is that there would be no Framed-IP-Address in the accept. Which suggests that the sqlippool module wasn't allocating IP addresses.
>
> I don't think it's a good idea to change the sqlippool module to be more "forgiving" about parsing IP addresses. The purpose of a database is to store data, and to store the data in a consistent format. If the data in the database is wrong, then no amount of poking FreeRADIUS will make things "just work". Instead, it's best to just fix the database.
>
> I'm happy to see this tracked down and fixed. And yes, ALWAYS run in it in debug mode! There are very few situations where doing that doesn't help.
>
> Alan DeKok.
I agree: you could add a "trim" function but then would be just a
temporary fix and other similar issue could go undetected without
checking the goodness of data input before.
Thanks for adding more ERROR messages anyway. Have a nice day!
More information about the Freeradius-Users
mailing list