[OpenSIPS-Users] AAA_diameter usage

Thu Jul 11 14:49:19 UTC 2024

Hi Liviu,

Quick update from my side:
Your initial pointer was correct - the issue concerned the AVP definition.

Extending the dictionary using extensions (like dict_dcca_3gpp) seems
complicated due to the forking and library initialization. I have
temporarily solved this by manually including the dictionary definitions
from dict_dcca_3gpp and its dependencies in the aaa_diameter Module.
Including the dictionaries from the freeDiameter project revealed some
conflicts with the existing AVP definitions from the module, so I removed
those definitions for now.

Duplicating code is not ideal, so this is a temporary solution for me.

I've noticed that the "aka_av_diameter" Module requires some AVPs that
conflict with the standard definitions from the freeDiameter project - I've
noticed that you named some AVPs "3GPP-*". I have replaced these with the
standard definitions from the freeDiameter project and will do some further
testing.

Also, we should improve the way the aaa_diameter module handles situations
when no "Session-Id" is found in the crafted Diameter message. I
accidentally missed adding a "Session-Id"-AVP to my request, and the error
message from OpenSIPS was not very helpful.

I will do some further testing. However, I wanted to highlight that I can
finally send a server-assignment request (SAR) to our HSS!

Thanks again for your hard work, especially for useful feedback.

Thanks,
Carsten

--
Schöne Grüße aus Hamburg, dem Tor zur Welt,
Carsten Bock

Baron-Voght-Str. 128a I 22607 Hamburg I Germany
T +49 179 2021244 I carsten at bock.info
LinkedIn: https://www.linkedin.com/in/carstenbock/

Am Mi., 10. Juli 2024 um 12:22 Uhr schrieb Carsten Bock <
carsten.bock.private at gmail.com>:

> Hi Liviu,
>
> Thanks for getting back to me and for pointing me in some directions.
>
> So far, I did not loaded any extensions. Upon checking with
> dict_dcca_3gpp.fdx I've noticed that the extensions (and the lib) are
> initialized in the worker process, while the "extra-avps-file" is loaded
> from mod_init (so before).
>
> If I move the loading of the extra-avps-file to the worker process (so
> after loading extensions), the aka_av_diameter module complains about not
> finding the MAR request. After fixing this, there are apparently some
> conflicts in the custom-avp's registered by OpenSIPS and the AVPs defined
> in the extension dict_dcca_3gpp.fdx or it's dependencies....
>
> I will get there ;-)
>
> Anyway, pointing me in the right direction was already very helpful!
>
> Thanks,
> Carsten
> --
> Schöne Grüße aus Hamburg, dem Tor zur Welt,
> Carsten Bock
>
> Baron-Voght-Str. 128a I 22607 Hamburg I Germany
> T +49 179 2021244 I carsten at bock.info
> LinkedIn: https://www.linkedin.com/in/carstenbock/
>
>
> Am Di., 9. Juli 2024 um 16:28 Uhr schrieb Liviu Chircu <liviu at opensips.org
> >:
>
>> On 09.07.2024 14:18, Carsten Bock wrote:
>>
>> The definition itself seems to be fine: If I rename the
>> "Server-Assignment-Type" to "SAT" and "User-Data-Already-Available" to
>> "UDA-Available", OpenSIPS starts. However, if I follow the examples (e.g.
>> module docs for aaa_diameter and here
>> https://www.opensips.org/Documentation/Tutorials-Diameter-Client-Server),
>> I fail to send the Diameter-Request:
>>
>> 11:10:14  ERROR  ERROR: Invalid parameter '(((avp) && (((struct
>> msg_avp_chain *)(avp))->type == MSG_AVP) && (((struct avp
>> *)(avp))->avp_eyec == (0x11355467))) && pdata)', 22
>>
>> Am I missing something? Can someone share some example code for sending a
>> SAR request? Is the documentation missing something?
>>
>> Hello Carsten,
>>
>> It is great to hear you are having fun with the module!  With regards to
>> freeDiameter library errors (which are taken straight up from
>> /usr/include/asm-generic/errno-base.h, btw), I've typically seen two codes
>> being returned by the library:
>>
>> #define EINVAL      22  /* Invalid argument */   -- most frequent
>> #define EEXIST      17  /* File exists */
>>
>> Now, with *17* (already exists), this is returned if you are trying to
>> register a *duplicate* AVP as string name, but with different properties
>> (maybe diff type?  diff code?  etc.).  As a general rule, the library won't
>> complain if we define a perfectly (?) identical AVP twice - it will simply
>> move on and return *0 *(success).
>>
>> In your case, I suspect that the *22* (invalid arg) is still connected
>> to AVP duplication somehow, but the library returns *22* from some other
>> part of the error-handling code, as a small mistake.  Especially since
>> you're saying *it works* once you fix the name to something else.
>>
>> To begin the troubleshooting, which dictionaries / fd extensions are you
>> loading right now?  Because if you're loading the *dict_dcca_3gpp.fdx*
>> module, this one should already contain both of your AVPs (hence explaining
>> your errors!), check their definitions here on the *libfreeDiameter*
>> GitHub:
>>
>> Server-Assignment-Type
>> <https://github.com/freeDiameter/freeDiameter/blob/master/extensions/dict_dcca_3gpp/add_avps.c#L6999>
>> and User-Data-Already-Available
>> <https://github.com/freeDiameter/freeDiameter/blob/master/extensions/dict_dcca_3gpp/add_avps.c#L7138>
>>
>> Best regards,
>>
>> --
>> Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240711/a3f9bbf1/attachment.html>