Segfault in module accessing custom attributes fields

Alan DeKok aland at deployingradius.com
Mon Feb 16 15:36:10 CET 2009


D'AVELLA STEFANO wrote:
> I am having some problems in trying to write a little module to handle
> some custom attributes. Because I have a project regarding very specific
> requirements I preferred to write a module instead of trying to use the
> existing ones, so I can know in a better way where to go to change
> things when I want a different behaviour.

  The existing modules have a lot of examples of working code, too.

> What I am doing right now is trying to have a testbed with a client, a
> proxy and a server, exchanging some custom attributes saved in the users
> file of the server and transmitted with auth-accept messages.

  Please use the *correct* names for everything.  Otherwise, we might
not be sure what you're talking about... and neither will you.

> The proxy should intercept these new attributes and save them in a
> specific syntax in a local file.
> 
> I managed to create and transfer successfully the custom attributes and
> to have them saved in a local file by the proxy.
> 
> The problem is that if these attributes have a string as a value, there
> is no problem in reading it using the field vp_strvalue.
> 
> If these attributes have the attribute ipv6address, when I try to access
> to them using vp_ipv6address I get a segFault. The values are correctly
> stored in the packets because I can see them with wireshark and the
> client receives them successfully.

  See doc/bugs for instructions on debugging the server with gdb.

  I suspect that your code is simply wrong.  There is no reason why one
data type should work, and another should fail.

  Again, existing modules && the server core have examples of working
with IPv6 attributes.  See those examples for what works.

> In the documentation (the wiki) there is written to access the
> attributes through request->packet->vps but I managed to do it only with
> request->reply->vps.

  You "managed to do it"?  There's a reason why one works and the other
doesn't.  Usually, it's a simple reason.

> (initially I wanted to save this local file using
> the post-proxy section because I was thinking that it was the best place
> to do it (it's an action to do when the proxy receives the reply from
> the server) but I couldn't access the right packet through the API and
> so I found out that I could do it in the post-auth phase)

  Nonsense.  You can access the proxy reply in the post-proxy section.
A lot of other code in the server already does this.

> I would not want to disturb you too much but the problem is that it
> seems to me that there is a bit of lack in the documentation regarding
> how write modules in the newer versions of freeradius and so I didn't
> know other places to look (I have been looking at the source code for
> all the day but maybe I can do it faster if pointed into the right
> direction)

  Again, there is 10's of 1000's of lines of code in the server that
accesses attributes in different lists, of different types.  That code
works, and can be used as a basis for your code, or as an opportunity to
learn.

  Alan DeKok.



More information about the Freeradius-Users mailing list