Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could not find route info for Message key #174

Open
Jeevan-Rai opened this issue Sep 19, 2023 · 11 comments
Open

Could not find route info for Message key #174

Jeevan-Rai opened this issue Sep 19, 2023 · 11 comments

Comments

@Jeevan-Rai
Copy link

I have configured the jDiameter example server to handle requests from the seagull client, CER is getting processed and CEA is also being sent from the server but when the client sends CCR server logs warning

2023-09-19 12:48:25.402 WARN 17128 --- [ncConnull }_2-6] o.j.client.impl.router.RouterImpl : Could not find route info for message key [2482547001.DataChrgVCS.tayana.in;1096298391;120011001]. Table size is [0]

and the control is not entering the "processRequest(Request request)" method.
jdiameter message key issue

@aferreiraguido
Copy link

It seems your receiving endpoint does not have the credit-control application declared (probably app parameters not matching), I recommend extracting a tcpdump trace from the seagull sending box plus checking if your config file parameters match what jDiameter is receiving, eventually enabling debug logs to get as much as possible from the incoming code flow. At least that is what I do when configuring jDiameter...

@Jeevan-Rai
Copy link
Author

If the diameter stack is running after successful CEA the processRequest method request should be called for every request right but the method is not being called, is there any configuration to define the routing table in the server configuration?

@aferreiraguido
Copy link

It is a yes if your message is targeting the correct ApplicationID configured as Realm in Network.Realms tag. Are you using the original config-server.xml file (examples/charging-server-simulator/src/main/resources folder)? can you enable DEBUG logs to see in detail why the message is being dropped before routing? also, a tcpdump within the origin machine will help in checking what parameters are you sending in the CCR.

@Jeevan-Rai
Copy link
Author

this is my server-config file,

can you please let me know how to configure the message key or the route info in the server, because the log is showing that there is no route info for the message key, the message key is the session-id sent from the client. May I know how to add the route info..
server-jdiameter-config.txt

@Jeevan-Rai
Copy link
Author

Is there any documentation that helps for creating a server using jdiameter?

@Jeevan-Rai
Copy link
Author

and also how can I enable all the logs can you please help with that?

@Jeevan-Rai
Copy link
Author

I have enabled the DEBUG log, I will attach the text file of the log
debug logs.txt

@aferreiraguido
Copy link

aferreiraguido commented Sep 21, 2023

Hello Jeevan-Rai, great you made it! After reviewing the logs, it is there a 3007 - ResultCode.APPLICATION_UNSUPPORTED, meaning that your sending request is not targeting correctly AppId 4, either coz the realm does not match or you're sending a nonmatching 293 - Avp.DESTINATION_HOST in the request, the third possibility is not configured AppId in the server, which is not the case as per your XML config file. With that said, I guess my path would be to review the request message that is being sent from the original server using a tcpdump and a Wireshark or the like, so you'll be able to find out if you're sending that Destination-Host AVP (if sent, not being 10.0.4.61) or the realm is different than "tayana.in". Btw you can check that code yourself in core/jdiameter/impl/src/main/java/org/jdiameter/server/impl/PeerImpl.java

@aferreiraguido
Copy link

aferreiraguido commented Sep 21, 2023

Please disregard my last message, I just found that you're not setting the origin IP 10.0.5.84 as your peer in Networks.Realms.Realm tayana.in, also found in the logs that you reset the attempt_connect of the Neetworks.Peers.Peer aaa://10.0.5.84 (compared to the original config file you sent previously) and thus the origin host is now initiating the connection.

@Jeevan-Rai
Copy link
Author

The issue is resolved, the server has configured a listener for vendor-id: 10415 and application-id: 4 but the seagull client was sending a request with vendor-id: 0 and application-id: 4, so I configured another listener for the mentioned vendor id and application id.

Thank You

@Jeevan-Rai
Copy link
Author

I am facing trouble with sending CCR-T from the seagull client I will attach the log file can you please help me to resolve it?

ro_ccr_cca_client.2022-02-16.10-30-10.874.log

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants