Correct way to deal with an 'incorrect' dictionary shipped by default
Hi, Recently (well, in the last year and a half or so) we got bit by FreeRADIUS shipping a 'dictinary.infinera' that's incorrect. Looking at the file, we see it's for vendor ID 8708 which according to IANA is "Lumentis AB". https://github.com/FreeRADIUS/freeradius-server/blob/master/share/dictionary... The actual Infinera dictionary (as given to our network team by the vendor) contains this data by contrast: # -*- text -*- # Dictiionary for Infinera # # VENDOR Infinera 21296 BEGIN-VENDOR Infinera ATTRIBUTE Infinera-User-Priv-SA 1 integer ATTRIBUTE Infinera-User-Priv-NA 2 integer ATTRIBUTE Infinera-User-Priv-NE 3 integer ATTRIBUTE Infinera-User-Priv-PR 4 integer ATTRIBUTE Infinera-User-Priv-TT 5 integer ATTRIBUTE Infinera-User-Priv-MA 6 integer ATTRIBUTE Infinera-User-Priv-RA 7 integer ATTRIBUTE Infinera-User-Priv-EA 8 integer ATTRIBUTE Infinera-User-SessionTimeout 17 integer ATTRIBUTE Infinera-User-LockedOut 18 integer ATTRIBUTE Infinera-User-CanUseResSession 19 integer ATTRIBUTE Infinera-User-MgtType-EMS 33 integer ATTRIBUTE Infinera-User-MgtType-GNM 34 integer ATTRIBUTE Infinera-User-MgtType-TL1 35 integer ATTRIBUTE Infinera-User-MgtType-CLI 36 integer ATTRIBUTE Infinera-User-MgtType-NETCONF 37 integer ATTRIBUTE Infinera-Rsvd-Str-Attribute1 240 string ATTRIBUTE Infinera-Rsvd-Str-Attribute2 241 string ATTRIBUTE Infinera-Rsvd-Int-Attribute1 249 integer ATTRIBUTE Infinera-Rsvd-Int-Attribute2 250 integer VALUE Infinera-User-Priv-NE NE-NONPRIVILEGED 0 VALUE Infinera-User-Priv-NE NE-PRIVILEGED 1 VALUE Infinera-User-Priv-PR PR-NONPRIVILEGED 0 VALUE Infinera-User-Priv-PR PR-PRIVILEGED 1 VALUE Infinera-User-Priv-TT TT-NONPRIVILEGED 0 VALUE Infinera-User-Priv-TT TT-PRIVILEGED 1 VALUE Infinera-User-Priv-MA MA-NONPRIVILEGED 0 VALUE Infinera-User-Priv-MA MA-PRIVILEGED 1 VALUE Infinera-User-Priv-RA RA-NONPRIVILEGED 0 VALUE Infinera-User-Priv-RA RA-PRIVILEGED 1 VALUE Infinera-User-Priv-EA EA-NONPRIVILEGED 0 VALUE Infinera-User-Priv-EA EA-PRIVILEGED 1 VALUE Infinera-User-CanUseResSession CANNOT-USE-RES-SESSION 0 VALUE Infinera-User-CanUseResSession CAN-USE-RES-SESSION 1 VALUE Infinera-User-MgmtType-EMS MGMTTYPE-EMS-DISALLOWED 0 VALUE Infinera-User-MgmtType-EMS MGMTTYPE-EMS-ALLOWED 1 VALUE Infinera-User-MgmtType-GNM MGMTTYPE-GNM-DISALLOWED 0 VALUE Infinera-User-MgmtType-GNM MGMTTYPE-GNM-ALLOWED 1 VALUE Infinera-User-MgmtType-TL1 MGMTTYPE-TL1-DISALLOWED 0 VALUE Infinera-User-MgmtType-TL1 MGMTTYPE-TL1-ALLOWED 1 VALUE Infinera-User-MgmtType-CLI MGMTTYPE-CLI-DISALLOWED 0 VALUE Infinera-User-MgmtType-CLI MGMTTYPE-CLI-ALLOWED 1 VALUE Infinera-User-MgmtType-NETCONF MGMTTYPE-NETCONF-DISALLOWED 0 VALUE Infinera-User-MgmtType-NETCONF MGMTTYPE-NETCONF-ALLOWED 1 END-VENDOR Infinera That vendor ID according to IANA is actually "Infinera". I've managed to work-around this by putting a hack in our RADIUS dictionary installation workflow to remove the shipped dictionary.infinera file from the shipped dictionary file, but that seems like a hack at bes. It means that someone from my team has to remember to run that workflow every time a box gets touched by patching automation since an updated FreeRADIUS RPM showing up from RedHat--or soon from your official packages--will overwrite our working copy. Is there a better way we should handle this? Thanks, -Coy
On 20/02/2025 12:51, Coy Hile (BLOOMBERG/ 919 3RD A) wrote:
That vendor ID according to IANA is actually "Infinera". I've managed to work-around this by putting a hack in our RADIUS dictionary installation workflow to remove the shipped dictionary.infinera file from the shipped dictionary file, but that seems like a hack at bes. It means that someone from my team has to remember to run that workflow every time a box gets touched by patching automation since an updated FreeRADIUS RPM showing up from RedHat--or soon from your official packages--will overwrite our working copy.
Is there a better way we should handle this?
Put your updated copy in raddb/dictionary, but just call it MyInfinera or similar so the vendor name doesn't clash. -- Matthew
On Feb 20, 2025, at 7:51 AM, Coy Hile (BLOOMBERG/ 919 3RD A) <chile1@bloomberg.net> wrote:
Recently (well, in the last year and a half or so) we got bit by FreeRADIUS shipping a 'dictinary.infinera' that's incorrect.
Hmm... OK. It would have been helpful to raise the issue then, so we could fix it. And you wouldn't have to maintain private patches.
Looking at the file, we see it's for vendor ID 8708 which according to IANA is "Lumentis AB". https://github.com/FreeRADIUS/freeradius-server/blob/master/share/dictionary...
I'm not sure how that happened. The git logs don't show where the wrong dictionary came from.
The actual Infinera dictionary (as given to our network team by the vendor) contains this data by contrast:
The vendor could also shared the dictionary with us. But that rarely happens. I don't know why. In any case, I've replaced the wrong one with the one you posted here. It will be available in the next release.
That vendor ID according to IANA is actually "Infinera". I've managed to work-around this by putting a hack in our RADIUS dictionary installation workflow to remove the shipped dictionary.infinera file from the shipped dictionary file, but that seems like a hack at bes. It means that someone from my team has to remember to run that workflow every time a box gets touched by patching automation since an updated FreeRADIUS RPM showing up from RedHat--or soon from your official packages--will overwrite our working copy.
Is there a better way we should handle this?
Report bugs when you see them, and they will generally be fixed quickly. We're happy to fix issues, but we can't fix issues if no one reports the issue. Vendors are encouraged to send us their updated dictionaries. But over 25+ years of doing this, I think that's happened three times. Most vendors are happy to put documentation up on their web site which says "use this dictionary. And by the way, you'll have to re-install it every time you update the server." Contributing the dictionaries back to FreeRADIUS avoids all of that work. Alan DeKok.
On Feb 20, 2025, at 4:43 PM, Alan DeKok <aland@deployingradius.com> wrote:
In any case, I've replaced the wrong one with the one you posted here. It will be available in the next release.
Double-checking it... I've fixed some typos which prevented it form working, and removed a lot of duplication. I find the following duplication hard to read: Foo-Bar-Baz-X = Foo-Bar-Baz-X-Allowed Foo-Bar-Baz-Y = Foo-Bar-Baz-Y-DisAllowed versus Foo-Bar-Baz-X = Allowed Foo-Bar-Baz-Y = Disallowed The second is much preferred, and is the style used elsewhere in the server. Alan DeKok.
If the nas client is present in nas table but radius in debug mode continues to give me this: Listening on auth address 127.0.0.1 port 18120 bound to server inner-tunnel Listening on auth address * port 1812 bound to server default Listening on acct address * port 1813 bound to server default Listening on auth address :: port 1812 bound to server default Listening on acct address :: port 1813 bound to server default Listening on proxy address * port 46618 Listening on proxy address :: port 38935 Ready to process requests Ignoring request to auth address * port 1812 bound to server default from unknown client 10.0.160.103 port 36881 proto udp Ready to process requests Ignoring request to auth address * port 1812 bound to server default from unknown client 10.0.160.103 port 36881 proto udp Ready to process requests where can be the issue ? Thank you ! --
If the nas client is present in nas table but radius in debug mode continues to give me this: Listening on auth address 127.0.0.1 port 18120 bound to server inner-tunnel Listening on auth address * port 1812 bound to server default Listening on acct address * port 1813 bound to server default Listening on auth address :: port 1812 bound to server default Listening on acct address :: port 1813 bound to server default Listening on proxy address * port 46618 Listening on proxy address :: port 38935 Ready to process requests Ignoring request to auth address * port 1812 bound to server default from unknown client 10.0.160.103 port 36881 proto udp Ready to process requests Ignoring request to auth address * port 1812 bound to server default from unknown client 10.0.160.103 port 36881 proto udp Ready to process requests where can be the issue ? Thank you ! --
On Feb 21, 2025, at 5:21 AM, Marco Miglietta <marco.miglietta@unisalento.it> wrote:
If the nas client is present in nas table but radius in debug mode continues to give me this:
The server reads the NAS table from SQL when that is configured. Debug mode or not doesn't make any difference.
Listening on auth address 127.0.0.1 port 18120 bound to server inner-tunnel Listening on auth address * port 1812 bound to server default Listening on acct address * port 1813 bound to server default Listening on auth address :: port 1812 bound to server default Listening on acct address :: port 1813 bound to server default Listening on proxy address * port 46618 Listening on proxy address :: port 38935 Ready to process requests Ignoring request to auth address * port 1812 bound to server default from unknown client 10.0.160.103 port 36881 proto udp Ready to process requests Ignoring request to auth address * port 1812 bound to server default from unknown client 10.0.160.103 port 36881 proto udp Ready to process requests
where can be the issue ?
Point the FULL DEBUG OUTPUT as suggested in all of the documentation. My guess is that the SQL module isn't configured to read clients from SQL. Alan DeKok.
Thanks Alan. In the meantime I searched online and that's exactly what you say, reading the NAS from the table was not enabled. B.R. Marco. Il 21/02/25 13:17, Alan DeKok ha scritto:
On Feb 21, 2025, at 5:21 AM, Marco Miglietta <marco.miglietta@unisalento.it> wrote:
If the nas client is present in nas table but radius in debug mode continues to give me this: The server reads the NAS table from SQL when that is configured. Debug mode or not doesn't make any difference.
Listening on auth address 127.0.0.1 port 18120 bound to server inner-tunnel Listening on auth address * port 1812 bound to server default Listening on acct address * port 1813 bound to server default Listening on auth address :: port 1812 bound to server default Listening on acct address :: port 1813 bound to server default Listening on proxy address * port 46618 Listening on proxy address :: port 38935 Ready to process requests Ignoring request to auth address * port 1812 bound to server default from unknown client 10.0.160.103 port 36881 proto udp Ready to process requests Ignoring request to auth address * port 1812 bound to server default from unknown client 10.0.160.103 port 36881 proto udp Ready to process requests
where can be the issue ? Point the FULL DEBUG OUTPUT as suggested in all of the documentation.
My guess is that the SQL module isn't configured to read clients from SQL.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
participants (4)
-
Alan DeKok -
Coy Hile (BLOOMBERG/ 919 3RD A) -
Marco Miglietta -
Matthew Newton