Ensure the expected default UEA configuration, which is always
reset properly even if one of the testcases aborts due to a DTE.
Change-Id: Ic2c5a11e86e4349796fa7508076ac27ef22815cd
Since recently, osmo-sgsn is requesting encryption (UEA1 + UEA2)
in RANAP Security Mode Command by default [1]. The testcase
TC_iu_attach is assuming no encryption (UEA0) and thus failing.
Fix this by explicitly setting UEA0 via the VTY, similarly to
what testcase TC_iu_attach_encr does.
Change-Id: Ibaf83db1ab0f82f7e934e89ae3f6c19d014be197
Related: [1] osmo-sgsn.git I4eb9451b4267fc1436ed90a55ff200cf36f16bf6
It's a good practice to tag Actions with an ActionID to do proper
matching of the response once it comes back. It also helps reading a
dump of the conversation if there were events in between.
Change-Id: Iec320762ff0cca86319f7374b53c642f08a6e6df
The AMI documentation webpage mentions "ActionId", but Asterisk is
always returning "ActionID" in all response messages.
Any of the 2 is parsed fine by Asterisk since the keys are case
insensitive, but anyway let's use same case as what Asterisk is actually
transmitting to make reading of output easier.
Change-Id: I8097e461fd0cadfa780d52ab1666e41b9d2b8a0e
Change Telnet_PT to a regular TCP socket for the AMI interface.
I started using Telnet_PT port since initial use of the interface
was done through telnet, but it's not really a telnet interface and
stuff starts becoming difficult to maintain properly when events
(generated by Asterisk at any time) arrive.
The current TEXT decoder/encoder from Titan seems to be struggling in 2
scenarios, so for now we are adding some workarounds in
dec_AMI_Msg_ext() before calling it in order to be able to go forward
and avoid errors:
1- Fields of format "MyFieldName: \r\n" (empty value). I tried changing
the "value" field in record AMI_Field to "optional", but then apparently
the TEXT decoder fails to decode values consisting of several words.
Ideally, I'd expect the TEXT decoder to put an empty "" string in the
"value" field in that case if "optional" is not flagged in the record.
2- Fields of format "MyFieldName: foobar: hey there \r\n" containing a
": " token in the value. I'd expect TEXT decoder to put all subsequent
strings in the last field "value" if no more fields are described in the
record.
Change-Id: Icaf2860c1dd4befa4498f0d176cfadf26cfa8d1d
This allows to keep string handling totally internal to the AMI_Adapter
component, which also means now the CLIENT port acts asynchronously on
full AMI messages.
This allows for instance using activated altsteps to ignore events or
answer to them.
Change-Id: Ibf230d2302fecf443f34e1c4d4acfd4802f4cc79
These are currently used by code in AMI_Functions doing some workaround
for TEXT decoder limitations.
They can be merged independently now since anyway they are totally
generic and may be useful for future users.
Change-Id: I3d6da125a10807b7a2f3ecad8145a046a322c7d6
Fix that 6 tests started failing on ttcn3-hnbgw-test-latest with e.g.:
Timeout waiting for metrics
HNBGW_Tests.ttcn:2885 HNBGW_Tests control part
HNBGW_Tests.ttcn:1536 TC_rab_assign_fail testcase
Fixes: 904b5f1a ("hnbgw: Implement validation of [some] counters")
Change-Id: I0cd47728308757fe6eaaaed1581fbbec03a09cf7
The function f_http_tx_request has two parameters to spcifiy the body
part of the HTTP request (body and binary_body). The function only
sends a request when either body or binary_body is populated, but not
when none of the two is populated. This means requests without body
part (e.g. a GET request) can not be sent.
There is also no proper interlocking between body and binary_body. We
should make sure that this situation does not occur.
Related: SYS#6824
Change-Id: I258ee6209c35d0601f5a4d82423d2f5c6fbb03cc
Add the initial infrastructure to manage 2 SIPmsg_PT ports, one for the
local SIP UAs and one for the IMS core.
Still missing:
* Trigger Asterisk (through AMI) to do the initial connect + register to it
* Configure ipsec after Unauthorized response from IMS core
Change-Id: Ibbbadd54b7facf4ef7384499704e742f482a1252
Remove the dash character, since it makes it impossible to reference the
component name under TESTPORT_PARAMETERS in .default/.cfg files.
While at it, actually, allow the test to provide a full id instead of
always appending the suffix to it. This provides more freedom on the
testsuite to provide a fitting component name.
Change-Id: Iecefe7d98a5842872f1efc55e013f672186ef1a8
This reverts commit e9c6c7b97e which
breaks all of the test cases reliably. I'm surprised how it got
submitted in the first place, as it can never have worked. It uses
127.0.0.1:2905 on both the STP and the HNBGW side.
Change-Id: Ia7d9a743e0359ce7220c42597ded670967d562a9
The template ts_authenticateClientResponseEs9 has no default values,
let's add some default values to make it easier to use
Related: SYS#6824
Change-Id: I07d942a58a3c1c29c37fcaa50d3a274ce8b026bc
Fields of type CtxParams1 are used in other messages too, so it might be
helpful to add a separate template for them.
Related: SYS#6824
Change-Id: Iba6c3780f9f3aec5742d53b3bd7b0c0392b25761
The field serverSigned1 is used in many messages, so it might be helpful
to add a separate template for it.
Change-Id: Ic50676ac2863173b72765afc44794a56d03413a5
Related: SYS#6824
At the moment the HTTP_Adaptor automatically creates a new connection,
performs the HTTP request and closes the connection again. This means
the connection lives only for a single request. Let's add some
flexibility so that we can perform multiple consecutive requests
through the same connection.
Change-Id: Ic6994c504143820dde498c1a2bad2ad6a523dd70
Related: SYS#6824
The HTTP_Adapter currently only supports text only HTTP messages. However,
the HTTPmsg testport API also has a way to deal with binary HTTP messages.
Related: SYS#6824
Change-Id: I18340f19ed462bf80af683dc9f2831b602f4bdf7
With this patch we add a testsuite that can be used to test an IPAd
implementation.
The testsuite emulates the ESipa and the ES10x (pcsc cardreader)
interface and is capable of testing a direct profile download and other
ESipa features like the execution of an eIM package (eCO, PSMO).
Change-Id: Ic9ea8c69e56a2e8ddf0f506861ece6d40cbcb06d
Related: SYS#6564
The template ts_initiateAuthenticationRequestEsipa has a field for smdpAddress and
euiccInfo1. Those fields are optional fields, but they still play a central role in
the protocol, so that they are effectively mandatory. Let's make the fields available
to the template user and populate them with meaningful default values.
Related: SYS#6824
Change-Id: I97aa039810ad9fffea4226254fa675fd24647de1
The map() is already done before the component is started, f_init_sip().
It's better doing it there because then it's up to the creator of the
SIP_Emulation component to establish the name of the system port, hence
allowing multiple instances which can be configured differently (eg.
different bind ip+port).
Change-Id: I5632c94d03a9dce0d04d94766ce72e6700b6116b
A recent commit added a new field to record HTTP_Adapter_Params, but
forgot to update the callers f_http_init() to actually set this field.
Change-Id: I534d087b71cefd683a0c7411a415049c5e1ee519
Fixes: 832b1efe "HTTP_Adapter: Allow API users to enable/disable SSL"
f_ami_wait_for_prompt_str had to be fixed since it was returning content
like this:
"Response: Success\nMessage: Authentication accepted"
Instead, the TEXT encoding expects:
"Response: Success\nMessage: Authentication accepted\n"
which is actually more in line with proper expectancies.
Change-Id: If179e45307a7e42b81b28db6ee4b7bf5eeb8b5f1
Add a new template to verify the provideEimPackageResult request (ESipa)
from the IPAd
Related: SYS#6563
Change-Id: I86231f0e9dcef90abf60757cc55895863ad2b1b3
The template tr_provideEimPackageResultResponse and ts_provideEimPackageResultResponse
should be renamed to tr_provideEimPackageResultResponse_eimAck and
ts_provideEimPackageResultResponse_eimAck as the TODO message says.
Related: SYS#6563
Change-Id: I68536eec6d04364efdbbbd5205788cf5c8ab3028
The function f_http_init currently takes only two config options. For the
moment this is not a problem, but the amount of additional options may grow
in the future. So let's put the options in a record to have them separate.
Change-Id: I4c1c204ea38d76d5fdd7e539d56ca2bf9f693d7d
Related: SYS#6824
In HTTP not all requests have a body. At the moment we describe a
missing body with body := "". This is not 100% correct since the rest of
the code interprets this as a present body with zero length and will put
a content_length = 0 header line into the HTTP header, even in the GET
request. This will most likely be ignored by any HTTP server, but it is
still not 100% spec compliant.
Related: SYS#6824
Change-Id: Ifedc8c2a590835663d1ba0b08b1fe4d54bdd0fff
At the moment HTTP_Adapter can only make requests with a fixed
pre-defined HTTP header. However, some application may require
additional custom header lines or different values than the ones
specified in the pre-defined HTTP header.
Related: SYS#6824
Change-Id: I115fd14254e0957c0955649aeb47059dc180bf57
In 1ee1edd2 I changed f_routing_area_update() to actually use the
given RAI as Old RAI in the Routing Area Update Request. Not only
this broke the testcase scenario (Old RAI shall remain unchanged!),
but also started triggering a use-after-free bug in osmo-sgsn.
Passing 'ran_index := 1' is enough for the second Routing Area Update
Request to show up with a different RAI (at BSSGP level), however the
Old RAI IE shall obviously indicate the *old* RAI, not the new one.
A follow-up commit will add a separate testcase to reproduce the
use-after-free problem in osmo-sgsn.
Change-Id: Ib16985cb08834a238ca4f7a747c43097f430ed6f
Fixes: 1ee1edd2 "sgsn: fix unused param in f_routing_area_update()"
Related: OS#6439