I was trying to use Seagull as a Diameter server for Cx interface. In response to a MAR request, the script needs to send a MAA response with “Digest-HA1” AVP (part of the grouped SIP-Digest-Authenticate AVP, which in turn is part of the SIP-Auth-Data-Item AVP) that contains H(A1). The Diameter Client(CSM) can use H(A1) to calculate the expected Digest response, according to this challenge.
Based on Seagull Documentation, I tried both ways i.e. SIP authentication and Radius authentication, but couldn’t succeed in getting HA1 calculated as expected.
When I tried the SIP Authentication way as below in my scenario file, it threw “2021-10-21.07:20:19.790|T|E_ACTION_SCEN_SET_VALUE_METHOD_EXTERN: problem when using external method (md5 or AKA)” error.
<set-value name="Digest-HA1" method="authenticationSip"
format="username=alice;password=12345;auth=Digest realm=\"open-ims.test\", algorithm=MD5;method=REGISTER;uri=sip:testuri.com"></set-value>
When I tried the Radius Authentication way as below in my scenario file, I see junk value being set for Digest-HA1 AVP.
<set-value name="Digest-HA1" method="authenticationRadius" message_part="all"
format="shared_secret=9000000009#open-ims.test:open-ims.test:12345"></set-value>
Digest-HA1 AVP filled with junk value in MAA response
AVP: Digest-HA1(121) l=24 f=-M- val=a\024\r\030�,����.�\032��\b
AVP Code: 121 Digest-HA1
AVP Flags: 0x40, Mandatory: Set
AVP Length: 24
Digest-HA1: a\024\r\030�,����.�\032��\b
I tried few combinations like hard coding few/all parameters, reading from previous message with the action “store” etc. but couldn’t succeed. Attaching scenario/dictionary files for your reference.
Can you please suggest if you are aware of any method (like crypto_method_radius for Radius Auth) which I can use to set Digest-HA1 AVP. Thanks in advance.
Downloaded source code and enhanced support for Diameter authentication via external-method functionality similar to SIP/Radius authentication. Seagull by default doesn't have support for Diameter Authentication.
Related
I've got a working local website that takes in HTML form data.
The fields are:
Temperature
Humidity
The server successfully receives the data and spits out a graph updated with the new entries.
Using a browser tool, I was able to capture the actual POST request as follows:
http://127.0.0.1:5000/add_data
Temperature=25.4&Humidity=52.2
Content-Length:30
Now, I want to migrate from using the human interface browser with manual entries to an ESP01 device using AT commands.
According to the ESP AT-commands documentation, a POST request is performed using the following command:
AT+HTTPCPOST=
Find the link below for the full description of the command.
I cannot seem to get this POST request working. The ESP01 device immediately returns an "ERROR" message without any delay, as though it did not even try to send the request, that the syntax might be wrong.
Among many variations, the following is my best attempt:
AT+HTTPCPOST="http://MYIPADDR:5000/add_data",30,2,"Temperature: 25.4","Humidity: 52.2"
With MYIPADDR above replaced with my IP address.
How do I translate a post request into ESP01 AT command format, and are there any prerequisites needed to be in place to perform such a request?
I did connect the ESP01 device to the WiFi network.
Here's the link to the POST AT command description:
https://docs.espressif.com/projects/esp-at/en/release-v2.2.0.0_esp8266/AT_Command_Set/HTTP_AT_Commands.html#cmd-httpcpost
The documentation says:
AT+HTTPCPOST=url,length[,<http_req_header_cnt>][,<http_req_header>..<http_req_header>]
Response:
OK
The symbol > indicates that AT is ready for receiving serial data, and you can enter the data now. When the requirement of message length
determined by the parameter is met, the transmission starts.
...
Parameters
: HTTP URL. : HTTP data length to POST. The maximum
length is equal to the system allocable heap size.
<http_req_header_cnt>: the number of <http_req_header> parameters.
[<http_req_header>]: you can send more than one request header to the
server.
You're sending:
AT+HTTPCPOST="http://MYIPADDR:5000/add_data",30,2,"Temperature: 25.4","Humidity: 52.2"
The length is 30. The problem is that everything after the length is HTTP header fields; you need to send the variables in the body. So the command is:
AT+HTTPCPOST="http://MYIPADDR:5000/add_data",30
followed on the next line by after the ESP-01 send the > character:
Temperature=25.4&Humidity=52.2
Because you passed 30 as the body length, the ESP-01 will read exactly 30 characters after the end of the AT command and send that data as the post body. If the size of that data changes (for instance, maybe the temperature is 2.2, so one digit less), you'll need to send the new length rather than 30.
I am using smstools3 for operating an USB-based surf stick for sending SMSes. I am working on querying the balance of a prepaid SIM card. The stick is a ZTE MF112 from China, the provider is eplus from Germany. This seems relevant as the response to a balance query contains an umlaut (ä).
Speaking directly to the modem (via cu /dev/ttyU0.2) I can perform a query:
AT+CUSD=1,"*100#",15
OK
+CUSD: 0,"00490068007200200047007500740068006100620065006E0020006200650074007200E400670074003A00200039002C003900370020002E",72
which response eventually translates to
Ihr Guthaben beträgt: 9,97 .
However, smstools3 has problems whith this. It appears that the encoding (,15) is omitted in the request and I have no way of supplying it.
Question: is there a way of setting the encoding globally in an init command like AT+CSCS?
I'm developing a product that need to integrate with RADIUS server as an authentication method.
When configuring the RADIUS server (IP Address, Port, Shared Secret) I would like to do a "test" in order to check that the configuration is valid - The server is available and it is indeed a RADIUS server, Shared secret is OK.
I did some research on how to do it,
My options are:
Send Access-Request message with fictional user name and password to the RADIUS server
Send Status-Server message to the RADIUS server
RFC 5997 introduces the use of Status-Server Packets in the RADIUS protocol.
This packet extension enabling clients to query the status of a RADIUS server.
The Status-Server is marked as experimental and as Informational RFC rather than as a Standards-Track RFC
My questions are:
Which are the most common \ in use RADIUS server vendors ? MS NPS, FreeRADIUS, Other?
Are these vendors supporting Status-Server request - Do they implementing this packet type ?
If i will use Access-Request, I will receive "Access-Reject" with a failure message in "Reply-Message" attribute. Can i understand the reason for the refusal from that text message? Is there any list of error codes\messages that are part of the Standard ?
Thanks a lot,
Yossi Zrahia
Ad 1) Exact (or even estimate) numbers are hard to come by, but you should expect to encounter FreeRADIUS, Microsoft NPS, Radiator and maybe Cisco ACS/ISE.
Ad 2) FreeRADIUS, Radiator support it. Microsoft NPS and Cisco ACS/ISE do not. If your "test" is used once (upon configuring) I would use option 1 with the Access-Request. If you wish to periodically check the availability and configuration of a RADIUS server, I would suggest implementing both options and allow for configuration of the check as part of the RADIUS configuration:
IP: 1.2.3.4
Port: 1812
Shared Secret: U7tr453cur3
Servercheck: [x] Status-Server
[ ] Access-Request
Ad 3) From RFC2865, section 5.18 (Reply-Message):
"[...] This Attribute indicates text which MAY be displayed to the user. [...] When used in an Access-Reject, it is the failure message. It MAY indicate a dialog message to prompt the user before another Access-Request attempt. [...] The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [7] characters."
There apparently are no standard messages specified; however if IP, Port or Shared Secret are configured incorrectly you should not get a response at all, because RFC 2865 specifies:
"A request from a client for which the RADIUS server does not have a shared secret MUST be silently discarded."
In all Diameter implementations I saw, the messages originating from the server is always sent towards the DNS resolved IP address of whats in the Destination-Host AVP. But, in commercial servers, we see an option to configure a DRA or a DEA which takes in all the messages and routes them.
Thus, when it comes to the mobicents diameter stack, this approach is sometimes hard to do. I can anyway re-configure the hosts file so that the message ends up in a DRA/DEA, yet, its a pain. I see no option to send these messages to a central diameter agent which will take care of all the dirty work for me.
The next issue is, if I plan to create such a DRA/DEA, the stack does not accept messages to a different host. Where, the message's Destination-Host parameter might contain a different hostname than ours. (which would be the ultimate destination it needs to go)
Is there a hack to achieve this without meddling with the internals of the jdiameter code and RA code?
If you change jdiameter's config to something like this:
<Network>
<Peers>
<Peer name="aaa://127.0.0.1:21812" attempt_connect="false" rating="1" />
<Peer name="aaa://CUSTOM_HOST:4545" attempt_connect="false" rating="1" />
</Peers>
<Realms>
<Realm name="custom.realm" peers="CUSTOM_HOST" local_action="LOCAL" dynamic="false" exp_time="1">
<ApplicationID>
...
</ApplicationID>
</Realm>
</Realms>
</Network>
In your sbb, then you'll need to create a client session providing your custom realm using this method:
DiameterCCAResourceAdaptor.CreditControlProviderImpl.createClientSession(DiameterIdentity destinationHost, DiameterIdentity destinationRealm)
Example:
ccaRaSbb.createClientSession(null, "custom.realm")
where ccaRaSbb is a CreditControlProvider instance (resource adaptor interface)
finally, when creating your CCR, the method CreditControlClientSession.createCreditControlRequest() will use the session' realm to find an available peer previously configured.
Let me know if this makes sense to you
Posting the method I used to solve this problem.
As it turns out its not possible out of the box to send a diameter message towards a peer which is not configured in the stack's jdiameter-config.xml file.
For me, the option to alter the stack in this case was also not feasible. So I devised a workaround for the problem by co-operating with the DRA we have. (most DRA's should be able to handle this method)
I added two custom AVPs to the outgoing request, namely Ultimate-Destination-Host and Ultimate-Destination-Realm.
In the DRA, I asked the admin to delete my Destination-Host and Destination-Realm AVPs and replace them with the ones created in step 1.
Now, whenever I send a packet destined to other diameter peers outside the configured peer, I target them towards the DRA and set these 'Ultimate' destination AVPs.
Ours is an Oracle DSR which is capable of doing this AVP manipulation. Most commercial ones should be able to handle it. Hope someone who wanted an answer for this question found this useful.
I've setup a radius server in our local network (using freeradius3), and now the clients are successfully login and send their accounting requests to the radius server.
What I need to accomplish is to pass the Accounting Requests (and their attributes) to an external program to process or filter some information. the external program however does not need to return anything to the radius server or change the normal workflow in the radius, so simply a copy of accounting requests has to be sent to the external program.
Couldn't find anything useful on web, so could you please point me to a tutorial or explain how would you implement that ?
Thank you
See the exec module config. The key thing is to set wait to no this means FreeRADIUS will not wait for the program to return.
You can then use the exec module instance as detailed in the header of that file i.e.
"%{exec:<path to program> '%{<attribute>}' '%{<attribute>}'}"