top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Unable to find solution to send CER to Scapv1 diameter peer

+3 votes
663 views

I am sending CER to Scapv1 peer, but its sending 5015() result code with failed avp as Host-ip-Address.

Unable to solve the issue, help me please

posted Nov 27, 2014 by Narayana Manohar

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button
Can u provide more information :) can not makeout anything with this information
Diameter Protocol
    Version: 0x01
    Length: 228
    Flags: 0x80
    Command Code: 257 Capabilities-Exchange
    ApplicationId: Diameter Common Messages (0)
    Hop-by-Hop Identifier: 0x51982504
    End-to-End Identifier: 0x78600000
    [Answer In: 2]
    AVP: Origin-Host(264) l=73 f=-M- val=aaa://bulksms.esourceltd.com:1985;transport=tcp;protocol=diameter
    AVP: Origin-Realm(296) l=26 f=-M- val=mtnccn01.mtn.co.rw
    AVP: Host-IP-Address(257) l=14 f=-M- val=192.168.2.2 (192.168.2.2)
    AVP: Vendor-Id(266) l=12 f=-M- val=193
    AVP: Product-Name(269) l=39 f=--- val=OnlineServiceAndContentCharging
    AVP: Auth-Application-Id(258) l=12 f=-M- val=Unknown (19302)
    AVP: Firmware-Revision(267) l=12 f=--- val=1
    AVP: Origin-State-Id(278) l=12 f=-M- val=**********

No.     Time        Source                Destination           Protocol Length Info
      2 0.002558    10.0.5.242            192.168.2.2           DIAMETER 310    cmd=Capabilities-ExchangeAnswer(257) flags=---- appl=Diameter Common Messages(0) h2h=51982504 e2e=78600000

Frame 2: 310 bytes on wire (2480 bits), 310 bytes captured (2480 bits)
Ethernet II, Src: Cisco_4b:1e:20 (d4:8c:b5:4b:1e:20), Dst: Dell_ca:83:ac (d4:ae:52:ca:83:ac)
Internet Protocol Version 4, Src: 10.0.5.242 (10.0.5.242), Dst: 192.168.2.2 (192.168.2.2)
Transmission Control Protocol, Src Port: radius (1812), Dst Port: 56331 (56331), Seq: 1, Ack: 229, Len: 256
Diameter Protocol
    Version: 0x01
    Length: 256
    Flags: 0x00
    Command Code: 257 Capabilities-Exchange
    ApplicationId: Diameter Common Messages (0)
    Hop-by-Hop Identifier: 0x51982504
    End-to-End Identifier: 0x78600000
    [Request In: 1]
    [Response Time: 0.002558000 seconds]
    AVP: Result-Code(268) l=12 f=-M- val=DIAMETER_INVALID_MESSAGE_LENGTH (5015)
    AVP: Origin-Host(264) l=93 f=-M- val=aaa://mtnccn01.mtn.co.rw:1812;transport=tcp;protocol=diameter;transport-security=none
    AVP: Origin-Realm(296) l=26 f=-M- val=mtnccn01.mtn.co.rw
    AVP: Host-IP-Address(257) l=12 f=-M- val=05f2
    AVP: Vendor-Id(266) l=12 f=-M- val=193
    AVP: Product-Name(269) l=39 f=--- val=OnlineServiceAndContentCharging
    AVP: Failed-AVP(279) l=24 f=-M-
    AVP: Firmware-Revision(267) l=12 f=--- val=**********




So when ever iam Sending Host-Ip-Address as 10.77.11.194 IN is sending 5015 result code , if i am sending hex value then IN is not at all responding back, i tried all possible ways but no use. Thanks for your comment
Check Host-IP-Address in CEA , its a Hex value of Ip Address , if i send Host-IP-Address in same format, then no CEA from IN , IN is not at all responding, referred rfc3588, 4006, Scapv1 doc, and googled like any thing but there is no use and no clue, i tried with scapv1 test simulators, simulators are responding fine but when coming to real system , it is replying back with 5015 or there is no CEA.
The Host-IP-Address is consituted of IP address type (0001 for IPV4) and the IP address in hex form
so 10.77.11.194 should be coded as 0x00010a4d0bc2 or 0x0001c20b4d0a try both as I am not sure the correct coding.
Also 5015  is Invalid_message_length so cross check your message coding.
Tapesh has put a very nice blog  http://tech.queryhome.com/46345/diameter-protocol-result-code-summary

May be take a print and put it at your desk :)
Appending 0001 for Ipv4 happens only in SCAPv2.In SCAPv1 just the hex value of Ip Address is considered.Let me know if I am wrong
Not sure, just try both.

Similar Questions
0 votes

In one Diameter blog, I saw a statement in which mentioned, if a Diameter node receive CER from unknown peer it responds back to that peer with Result-Code AVP set to "DIAMETER_UNKNOWN_PEER".
Now my query, Does a Diameter node keep its potential peers information in advance ?

+5 votes

How the scenario will be handled in case both client as well as server sends CER towards each other ?

+2 votes

Recently I have faced situation described below. Please ignore the dots - there is no table so I could present this in a proper table form.

The question is, when the GGSN/PCEF is establishing the session on TCP level to exchange Capabilities with Diameter Peer, who should be sending the FIN? Or maybe the FIN should not be sent at all?

In the below example, is what I saw in .pcap trace. Strange for me is there is not FIN present just FIN-Ack in this situation.

This was a issue, as I was given different IP for PCRF but I was told "everything else is the same" but it wasnt - the peer name was different.

Packet No......Direction.......Packet/message
1..............Out.............Syn
2..............In..............Syn-Ack
3..............Out.............Ack
4..............Out.............CER (diameter)
5..............In..............Ack of CER (tcp)
6..............In..............CEA (diameter)
7..............Out.............Ack of CEA (tcp)
8..............Out.............***FIN-Ack***
9..............In..............Ack
+1 vote

I went through the following link:
http://diameter-protocol.blogspot.in/2011/03/diameter-peer-discovery.html

By going through the link, I came to know about two approaches to do peer discovery.
1. Selection Location Protocol (SLP)
2. DNS

I'm curious to know which one is the widely acceptable approach and on what basis acceptable option is better than the other one.

...