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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
