mensonen / diameter Goto Github PK

After receiving a DPR, the auto reconnect functionality should pause until a new CER has been received.

rfc6733 5.4. states:

The Disconnect-Peer-Request message is used by a Diameter node to inform its peer of its intent to disconnect the transport layer and that the peer shouldn't reconnect unless it has a valid reason to do so (e.g., message to be forwarded)

pysctp installation is checked when attempting to connect to peers, but not when starting the node itself. Currently simply raises an exception with "'NoneType' object has no attribute 'sctpsocket_tcp'", which is confusing.

rfc6733 6.2. defines:

Any Proxy-Info AVPs in the request MUST be added to the answer message, in the same order they were present in the request.

This is currently not done, the Proxy-Info AVP is ignored in the request. It should be copied automatically to the answer message in both Node._generate_answer and Application.generate_answer.

I can't get the app to receive messages to work.
Problem in _receive_app_request() in code

         if not hasattr(message, "destination_realm"):
             self.logger.warning(
                 f"{conn} realm name present in request "
                 f"{hex(message.header.hop_by_hop_identifier)}")

message doesn't have destination_realm in members. It's a encoded in avps. Every incoming message from DRA failed with

2024-01-17 14:07:19,008 diameter.node WARNING <PeerConnection(6f5d93471e9a, dra.mncXXX.mccXXX.3gppnetwork.org> realm name present in request 0x37ba11f5

rfc6733 5.3. describes:

A receiver of a Capabilities-Exchange-Request (CER) message that does not have any applications in common with the sender MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_APPLICATION and SHOULD disconnect the transport layer connection. Note that receiving a CER or CEA from a peer advertising itself as a relay (see Section 2.4) MUST be interpreted as having common applications with the peer.

Currently there exists no check for relay agents at all.

Collect various performance numbers in addition to the current peer message counters. Most of these probably as three separate values: last minute, last 5 minutes and last 15 minutes.

• Received messages per second (keep counts of requests for the last 60, 300, 900 seconds and calculate req/sec)
• Processed requests per second (derive from total sum of time between REQ and RES, e.g. for the past 1024 requests)
• Counters for sent 1xxx, 2xxx, 3xxx, 4xxx and 5xxx responses (for the last 60, 300 and 900 seconds)
• Average response time, separate for each command type (from sum of time between REQ and RES for the past 1024 request)
• Accumulated and average statistics on Node level
• Snapshot statistics at predetermined intervals, e.g. every 60 seconds, and keep a history of X amount of snapshots

rfc6733, 5.5.4 defines:

It is important to note that multiple identical requests or answers
MAY be received as a result of a failover. The End-to-End Identifier
field in the Diameter header along with the Origin-Host AVP MUST be
used to identify duplicate messages.

The "T" flag should be checked for every message and discarded if the end-to-end identifier has already been seen. Nokia docs has a suggestion how to do it.

rfc6733 5.3 describes incoming connections from unknown peers being a possibility:

If the local policy permits receiving CERs from unknown hosts, a successful CEA MAY be returned. If a CER from an unknown peer is answered with a successful CEA, the lifetime of the peer entry is equal to the lifetime of the transport connection. In case of a transport failure, all the pending transactions destined to the unknown peer can be discarded.

Currently only connections from known peers are permitted.

If unknown peers will be implemented, the application routing needs to be amended with a possibility for an application to communicate with "any" peer.

Hello!
I have a question. what's the best way to make a multiapp script? For example, I need to make some gx calls and some rx calls and both of them need to got replys ... I tried making several SimpleThreadingApplications in one script, but only one works ...

rfc6733 4.3.1 states, regarding the Time derived AVP data format:

Time
...
On 6h 28m 16s UTC, 7 February 2036, the time value will overflow. Simple Network Time Protocol (SNTP) [RFC5905] describes a procedure to extend the time to 2104. This procedure MUST be supported by all Diameter nodes.

This described procedure is currently neither implemented nor supported.

The Application class does not have support for setting a Vendor-Specific-Application-ID in generate_answer.

After receiving new diameter request I have error. I'm using SimpleThreadingApplication with request_handler

2024-01-17 18:52:53,575 diameter.peer.msg DEBUG RECV dra01.s2.nw.data.pcrf.mnc999.mcc999.3gppnetwork.org
Spending-Limit <Version: 0x01, Length: 456, Flags: 0xc0 (request, proxyable), Hop-by-Hop Identifier: 0x987b8ffe, End-to-End Identifier: 0x322479>
  Session-Id <Code: 0x107, Flags: 0x40 (-M-), Length: 97, Val: pccm04.s2.nw.data.pcrf.mnc999.mcc999.3gppnetwork.org;250010000000001;Sy;63841103573572481>
  Auth-Application-Id <Code: 0x102, Flags: 0x40 (-M-), Length: 12, Val: 16777302>
  Origin-Host <Code: 0x108, Flags: 0x40 (-M-), Length: 55, Val: b'pccm.nw.data.pcrf.mnc999.mcc999.3gppnetwork.org'>
  Origin-Realm <Code: 0x128, Flags: 0x40 (-M-), Length: 50, Val: b'nw.data.pcrf.mnc999.mcc999.3gppnetwork.org'>
  Destination-Realm <Code: 0x11b, Flags: 0x40 (-M-), Length: 44, Val: b'dra.nw.mnc999.mcc999.3gppnetwork.org'>
  SL-Request-Type <Code: 0xb58, Flags: 0xc0 (VM-), Length: 16, Vnd: TGPP, Val: 0>
  Subscription-Id <Code: 0x1bb, Flags: 0x40 (-M-), Length: 44>
    Subscription-Id-Type <Code: 0x1c2, Flags: 0x40 (-M-), Length: 12, Val: 1>
    Subscription-Id-Data <Code: 0x1bc, Flags: 0x40 (-M-), Length: 23, Val: 999990000000001>
  Subscription-Id <Code: 0x1bb, Flags: 0x40 (-M-), Length: 40>
    Subscription-Id-Type <Code: 0x1c2, Flags: 0x40 (-M-), Length: 12, Val: 0>
    Subscription-Id-Data <Code: 0x1bc, Flags: 0x40 (-M-), Length: 19, Val: 99999000001>
  Route-Record <Code: 0x11a, Flags: 0x40 (-M-), Length: 60, Val: b'pccm04.s2.nw.data.pcrf.mnc999.mcc999.3gppnetwork.org'>
  Framed-IP-Address <Code: 0x08, Flags: 0x40 (-M-), Length: 12, Val: b'\xa4kq\x12'>

===================== start thr
Exception in thread Thread-5 (_wait_for_recv_msg):
Traceback (most recent call last):
  File "/opt/python/3.12.1/lib/python3.12/threading.py", line 1073, in _bootstrap_inner
    self.run()
  File "/opt/python/3.12.1/lib/python3.12/threading.py", line 1010, in run
    self._target(*self._args, **self._kwargs)
  File "/opt/python/3.12.1/lib/python3.12/site-packages/diameter/node/application.py", line 324, in _wait_for_recv_msg
    process_message.start()
  File "/opt/python/3.12.1/lib/python3.12/threading.py", line 992, in start
    _start_new_thread(self._bootstrap, ())
RuntimeError: can't create new thread at interpreter shutdown