re_auth.py

[hathos6]

Hello!

I just noticed that re_auth.py, which defines "class ReAuthRequest(ReAuth)" and "class ReAuthAnswer(ReAuth)" message is only good for Gx interface.

My problem is that these messages are available on Rx interface as well, but of course with totally different content.

Rx: 29.214
Message Format:
::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
[ DRMP ]
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
*{ Specific-Action }
[ OC-Supported-Features ]
[ Access-Network-Charging-Identifier ]
[ Access-Network-Charging-Address ]
02[ AN-GW-Address ]
[ AN-Trusted ]
*[ Flows ]
*[ Subscription-Id ]
[ Abort-Cause ]
[ IP-CAN-Type ]
[ MA-Information ]
[ NetLoc-Access-Support ]
[ RAT-Type ]
[ Sponsored-Connectivity-Data ]
[ 3GPP-User-Location-Info ]
[ User-Location-Info-Time ]
[ 3GPP-MS-TimeZone ]
[ Serving-Satellite-Identity ]
*[ RAN-NAS-Release-Cause ]
*[ 5GS-RAN-NAS-Release-Cause ]
[ 3GPP-SGSN-MCC-MNC ]
[ NID ]
[ TWAN-Identifier ]
[ TCP-Source-Port ]
[ UDP-Source-Port ]
[ UE-Local-IP-Address ]
[ Wireline-User-Location-Info ]
[ PC-Session-Recovery-Status ]
[ Origin-State-Id ]
*[ Class ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]

Gx: 29.212
Message Format:
::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
[ DRMP ]
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Re-Auth-Request-Type }
[ Session-Release-Cause ]
[ Origin-State-Id ]
[ OC-Supported-Features ]
*[ Event-Trigger ]
[ Event-Report-Indication ]
*[ Charging-Rule-Remove ]
*[ Charging-Rule-Install ]
[ Default-EPS-Bearer-QoS ]
*[ QoS-Information ]
[ Default-QoS-Information ]
[ Revalidation-Time ]
[ Usage-Monitoring-Information ]
[ PCSCF-Restoration-Indication ]
04[ Conditional-Policy-Information ]
[ Removal-Of-Access ]
[ IP-CAN-Type ]
[ PRA-Install ]
[ PRA-Remove ]
*[ CSG-Information-Reporting ]
[ PC-Session-Recovery-Status ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]

How to handle such scenarios in the framework?

[mensonen]

The current approach is to mostly ignore this and just add as many AVPs from as many specs and interfaces as we want. The current implementation for RAR/RAA already contains AVPs from at least three separate specs, rfc6733 , rfc7155 and 3gpp TS 32.299.

The reason why this works is that the python class attributes in ReAuthRequest and ReAuthAnswer only note the possible AVPs for that command, letting users set and read their values without having to construct AVPs manually using the AVP.new constructor. The command class does not enforce anything, it does not demand that every attribute is used or populated, and it does not care if "too many" attributes are defined.

This same issue is also present elsewhere, where same command message is shared between multiple specifications. Worst offender probably being CreditControl.

I know that @sliva0 has some rudimentary ideas on how to split the command codes so that they can be defined separately for each interface, but I don't know in which direction those ideas would go, and I haven't spent much time on the topic yet either.

If you want to implement Gx right now, I'd suggest just going ahead and filling in the missing AVP definitions for the existing ReAuthRequest and ReAuthAnswer classes, and worry about splitting things in future, when concrete plans to do so exist. We're going to have to split a lot of command implementations anyway, one more will not hurt.

Alternatively you can wait until we have splitting in place. If you have ideas how to do that, please share :)

[sliva0]

The only way to split command codes that I see is to just start a new folder separate from current message/commands one with implementations split by protocol, but discussions or any progress is yet to be made on this.

As was said in the previous message in this thread current idea is to extend a single DefinedMessage based class per message code and then in usage you can just not set any AVPs from other protocols, library will encode and decode messages just fine either way even is none of the AVPs is set.

[hathos6]

Thanks for the answers!

I felt deep inside, that this is the current approach (to put all possible AVPs in the code to support more interfaces) and select what needed, decode what arrived. In this exact case I saw, that this approach makes difficult (or impossible) to follow the standards completely, like:

AvpGenDef("re_auth_request_type", AVP_RE_AUTH_REQUEST_TYPE, is_required=True),

This makes every RAR message on Rx interface invalid like as follows:

RECV rx.pcf-1.default.be.ucore
Re-Auth <Version: 0x01, Length: 232, Flags: 0xc0 (request, proxyable), Hop-by-Hop Identifier: 0x1, End-to-End Identifier: 0x1>
Session-Id <Code: 0x107, Flags: 0x40 (-M-), Length: 45, Val: af-1.local;1635922800;1;2163021000001>
Origin-Host <Code: 0x108, Flags: 0x40 (-M-), Length: 33, Val: b'rx.pcf-1.default.be.ucore'>
Origin-Realm <Code: 0x128, Flags: 0x40 (-M-), Length: 24, Val: b'default.be.ucore'>
Destination-Realm <Code: 0x11b, Flags: 0x40 (-M-), Length: 19, Val: b'py.diameter'>
Destination-Host <Code: 0x125, Flags: 0x00 (---), Length: 27, Val: b'rx.host.py.diameter'>
Auth-Application-Id <Code: 0x102, Flags: 0x40 (-M-), Length: 12, Val: 16777236>
Specific-Action <Code: 0x201, Flags: 0xc0 (VM-), Length: 16, Vnd: TGPP, Val: 8>
Flows <Code: 0x1fe, Flags: 0xc0 (VM-), Length: 28, Vnd: TGPP>
Media-Component-Number <Code: 0x206, Flags: 0xc0 (VM-), Length: 16, Vnd: TGPP, Val: 1>

2026-04-08 17:19:55,355 diameter.node
mandatory AVP 285, vendor 0 is not set
2026-04-08 17:19:55,355 diameter.node
<PeerConnection(21fa01920636, rx.pcf-1.default.be.ucore> message failed AVP validation
2026-04-08 17:19:55,355 diameter.peer.msg
SENT rx.pcf-1.default.be.ucore
Re-Auth <Version: 0x01, Length: 176, Flags: 0x40 (proxyable), Hop-by-Hop Identifier: 0x1, End-to-End Identifier: 0x1>
Session-Id <Code: 0x107, Flags: 0x40 (-M-), Length: 45, Val: af-1.local;1635922800;1;2163021000001>
Result-Code <Code: 0x10c, Flags: 0x40 (-M-), Length: 12, Val: 5005>
Origin-Host <Code: 0x108, Flags: 0x40 (-M-), Length: 27, Val: b'rx.host.py.diameter'>
Origin-Realm <Code: 0x128, Flags: 0x40 (-M-), Length: 19, Val: b'py.diameter'>
Error-Message <Code: 0x119, Flags: 0x00 (---), Length: 30, Val: Mandatory AVPs missing>
Failed-AVP <Code: 0x117, Flags: 0x40 (-M-), Length: 16>
Re-Auth-Request-Type <Code: 0x11d, Flags: 0x40 (-M-), Length: 8, Val: (unset)>

So all-in-all, I need your confirmation, that we can "skip" these is_required and maybe other attributes if those collide with other interface specs for a particular message and I shall not be afraid of violating the specs.

[mensonen]

Unfortunately, yes. If one AVP is required in some interface, but not the other, the only option right now is to leave is_required out.

I'll try to put together a proof of concept for splitting the commands based on interfaces somehow. If we get that feature done, then I'd say we'll come back and put the is_required back everywhere where it's needed. Until then, leave out.

[hathos6]

Ok!

Until that point, I will add the necessary AVPs where needed, and add comment for such modifications!

Thanks