Adding a binary null to a value using attr_rewrite
Hi. I'm using attr_rewrite to add a Class attribute in my auth- reply packets. I need to include a binary null-byte in the value, but I cannot figure out how to do so. If I add a verbatim null-byte in radiusd.conf, the string is truncated there in the reply packet (seems like the code interprets it at some point as the string terminator). If I write \0 instead, it is simply ignored. Does someone know how to accomplish this? Thanks -- Tore Anderson
Tore Anderson <tore@linpro.no> wrote:
Hi. I'm using attr_rewrite to add a Class attribute in my auth- reply packets. I need to include a binary null-byte in the value, but I cannot figure out how to do so.
That's why the Class attribute is "octets" in the dictionary file. Class = 0x000000000000 Sends a whole bunch of zeros.
If I add a verbatim null-byte in radiusd.conf
Huh? You don't configure reply attributes in radiusd.conf Alan DeKok.
* Tore Anderson
If I add a verbatim null-byte in radiusd.conf
* Alan DeKok
Huh? You don't configure reply attributes in radiusd.conf
Sure I do. Relevant parts of my radiusd.conf: modules { attr_rewrite add_class { attribute = Class searchfor = ignored searchin = reply replacewith = "SBR-CL DN=\"%{Calling-Station-Id}\" AT=\"0\"" new_attribute = yes } } post-auth { add_class } This works exactly as I want it to, but the stupid Siemens NAS seems to require a null-byte at the end of the value - at least that's the only difference I've found in the reply packet when I inspect dumps from when it's communicating with the old RADIUS server (which works) and the new FreeRADIUS-based one (which doesn't). Adding that null-byte to the replacewith string doesn't seem to work, unfortunately. At least not in any way I've tried - but the RFC mandate that a server implementation should handle null-bytes, so I would think there has to be /some/ way of doing it? Thanks -- Tore Anderson
Tore Anderson <tore@linpro.no> wrote:
Huh? You don't configure reply attributes in radiusd.conf
Sure I do. Relevant parts of my radiusd.conf:
modules { attr_rewrite add_class {
Ah. You're configuring a module. Most modules read the attributes from a database.
This works exactly as I want it to, but the stupid Siemens NAS seems to require a null-byte at the end of the value - at least that's the only difference I've found in the reply packet when I inspect dumps from when it's communicating with the old RADIUS server (which works) and the new FreeRADIUS-based one (which doesn't).
Submit a bug on bugs.freeradius.org, sayign "Seimens NAS product X" is broken. Maybe public shame will push them to fix it.
Adding that null-byte to the replacewith string doesn't seem to work, unfortunately. At least not in any way I've tried - but the RFC mandate that a server implementation should handle null-bytes, so I would think there has to be /some/ way of doing it?
Yes. But it's a little complicated, because you're now trying to treat "Class" as *both* a text string, and a sequence of binary bytes, and the server isn't really set up to do that easily. Hmmm... I'll have to think about that. I've *never* heard of this problem before, so it's not immediately obvious how to solve it. Alan DeKok.
* Alan DeKok
Submit a bug on bugs.freeradius.org, sayign "Seimens NAS product X" is broken. Maybe public shame will push them to fix it.
I will, if I can conclude that this is indeed the problem. Right now it's only a suspicion. I need to check out another loose end about how it's interpreting the encryption of User-Password as well. * Tore Anderson
Adding that null-byte to the replacewith string doesn't seem to work, unfortunately. At least not in any way I've tried - but the RFC mandate that a server implementation should handle null-bytes, so I would think there has to be /some/ way of doing it?
* Alan DeKok
Yes. But it's a little complicated, because you're now trying to treat "Class" as *both* a text string, and a sequence of binary bytes, and the server isn't really set up to do that easily.
Nevermind me, I have this tendency to run into strange setups that can't possibly work.. :-)
Hmmm... I'll have to think about that. I've *never* heard of this problem before, so it's not immediately obvious how to solve it.
Well, if I could add "\0" to the string and have that be interpreted as a zero-byte in the string instead of its terminator, it would be the easiest for me. Of course, that probably causes other problems under the hood that I don't really know anything about.. Thanks for your patience with me, I'll try some more to figure it out. Kind regards -- Tore Anderson
participants (2)
-
Alan DeKok -
Tore Anderson