ITS issueshttps://forge.etsi.org/rep/ITS/ITS/-/issues2020-12-01T11:05:45Zhttps://forge.etsi.org/rep/ITS/ITS/-/issues/19Brainpool P384r1 support2020-12-01T11:05:45ZSzilveszter TÓTHBrainpool P384r1 supportHello!
We are using ITS on branch STF525 for testing our V2X PKI services. This is a great tool, and we find it very helpful. It can be used for keys on elliptic curves NIST P256 and Brainpool P256r1. However, we do not find a way to us...Hello!
We are using ITS on branch STF525 for testing our V2X PKI services. This is a great tool, and we find it very helpful. It can be used for keys on elliptic curves NIST P256 and Brainpool P256r1. However, we do not find a way to use it with Brainpool P384r1.
If we set LibItsPki_Pixits.PX_EC_ALG_FOR_EC := e_brainpool_p384_r1 in the config file, it fails with the following error message:
Wrong encryption variant
I suspect that this happens because it tries to use the same algorithm for encryption, too, which is not possible.
Is there a way to use key on curve Brainpool P384r1 extensively for testing, is it supported?
Thank you!https://forge.etsi.org/rep/ITS/ITS/-/issues/18HTTP 1.1 status reason-phrase (status text) is optional2019-08-27T09:49:58ZSzilveszter TÓTHHTTP 1.1 status reason-phrase (status text) is optionalDear ETSI Team,
We had an issue with the ITS testing tool on branch STF525.
Namely, it expects the reason-phrase to be present, which is optional according to RFC 7230 (https://tools.ietf.org/html/rfc7230#section-3.1.2):
> The rea...Dear ETSI Team,
We had an issue with the ITS testing tool on branch STF525.
Namely, it expects the reason-phrase to be present, which is optional according to RFC 7230 (https://tools.ietf.org/html/rfc7230#section-3.1.2):
> The reason-phrase element exists for the sole purpose of providing a
> textual description associated with the numeric status code, mostly
> out of deference to earlier Internet application protocols that were
> more frequently used with interactive text clients. A client SHOULD
> ignore the reason-phrase content.
>
> reason-phrase = *( HTAB / SP / VCHAR / obs-text )
(The asterisk there means that it may not appear at all.)
Some HTTP server implementations now omit this part of the status line, barely emitting
```
HTTP/1.1 200
```
(with no "OK" at the end).
The testing tool would fail with an error log like this:
```
MTC@13cb672994ff: Matching on port httpPort .response.statustext := "" with "OK" unmatched: First message in the queue does not match the template:
```
We had to change the web server implementation to include the reason-phrase to pass the test.
Thank you for your help!https://forge.etsi.org/rep/ITS/ITS/-/issues/10TC_CAM_MSD_GFQ_TI_03 unexpected CAM#"3 message not received2019-08-12T06:09:28ZkronnebergTC_CAM_MSD_GFQ_TI_03 unexpected CAM#"3 message not receivedHi,
I face the same issue as for TC_CAM_MSD_GFQ_TI_01. The ttcn script timer expires alghout it receives 3 CAM with delta time = 200 ms.
You can see that in the screenshot and wireshark capture provided in the attached tgz.
According to...Hi,
I face the same issue as for TC_CAM_MSD_GFQ_TI_01. The ttcn script timer expires alghout it receives 3 CAM with delta time = 200 ms.
You can see that in the screenshot and wireshark capture provided in the attached tgz.
According to my understanding of the issue, the script miss the 1srt CAM with delta time = 200 ms. It should not wait until it sends the "Change speed" command to start the CAM interval timer.
Regards
Valérie Kronneberg
[TC_CAM_MSD_GFQ_TI_03.tgz](/uploads/4c012c913b0290a3db075c85a01826c9/TC_CAM_MSD_GFQ_TI_03.tgz)Yann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/ITS/-/issues/9TC_CAM_MSD_GFQ_TI_01 unexpected timeout2019-08-12T06:07:05ZkronnebergTC_CAM_MSD_GFQ_TI_01 unexpected timeoutHi,
I suspect an isue in the ttcn script timer management.
Indeed, the test fails with the error "CAM message received BEFORE expiry of the minimum generation timer interval"
however you can see in the wireshark logs that time between C...Hi,
I suspect an isue in the ttcn script timer management.
Indeed, the test fails with the error "CAM message received BEFORE expiry of the minimum generation timer interval"
however you can see in the wireshark logs that time between CAM is 200 ms and thus not under minimum value.
Attached a zip that contains TITAN mtc log and wireshark capture.
[TC_CAM_MSD_GFQ_TI_01.zip](/uploads/4e27b6c62a932d05bdd63118ca4b9d45/TC_CAM_MSD_GFQ_TI_01.zip)
Regards
Valérie KronnebergYann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/ITS/-/issues/13TC_GEONW_PON_SQN_BV_01 invalid speed2019-08-09T08:01:54ZkronnebergTC_GEONW_PON_SQN_BV_01 invalid speedHello,
Exec of TC_GEONW_PON_SQN_BV_01 fails and I can't understand the reason why.
First steps are ok:
- UtInitialize/UtSuccess
- UtGnInitialize/UtGnInitializeResult:=true
Then, the IUT send a geobroadcast Circle which is rejected with t...Hello,
Exec of TC_GEONW_PON_SQN_BV_01 fails and I can't understand the reason why.
First steps are ok:
- UtInitialize/UtSuccess
- UtGnInitialize/UtGnInitializeResult:=true
Then, the IUT send a geobroadcast Circle which is rejected with the message below. The speed is inside the range, I can't understand the reject.
*22:30:14.762915 mtc MATCHING ../ttcn/ItsGeoNetworking_TestCases.ttcn:1523(testcase:TC_GEONW_PON_SQN_BV_01)->../ttcn/ItsGeoNetworking_TpFunctions.ttcn:1906(function:f_GEONW_PON_SQN_BV_01)->../ttcn/LibItsGeoNetworking_Functions.ttcn:1466(altstep:a_receiveGeoBroadcast) Matching on port geoNetworkingPort .msgIn.gnPacket.packet.extendedHeader.geoBroadcastHeader.srcPosVector.speed := 1600 with (15892 .. 16383) unmatched: First message in the queue does not match the template: *
Moreover in f_GEONW_PON_SQN_BV_01 alternatives at lines 1906 and 1913 are a like. I suspect a bug.
Please, could you give me feedback on this test.
Regards,
Valérie Kronneberg[AtsGeoNetworking.titan.merged.TC_GEONW_PON_SQN_BV_01.log](/uploads/c336bcc57da9cc9cc83e19f94862d1c7/AtsGeoNetworking.titan.merged.TC_GEONW_PON_SQN_BV_01.log)Yann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/ITS/-/issues/15GBC routerHopLimit invalid value2019-08-08T08:30:00ZkronnebergGBC routerHopLimit invalid valueHi,
When running the test TC_GEONW_PON_GBC_BV_07 , TITAN tester sends to the IUT a GBC which routerHopLimit=1 when a value > 1 is expected.
For debug purpose, I changed the c_defaultHopLimit value from 10 to 9
and also PICS_GN_DEFAULT_H...Hi,
When running the test TC_GEONW_PON_GBC_BV_07 , TITAN tester sends to the IUT a GBC which routerHopLimit=1 when a value > 1 is expected.
For debug purpose, I changed the c_defaultHopLimit value from 10 to 9
and also PICS_GN_DEFAULT_HOP_LIMIT := 9
However the titan traces shows at "build_geonetworking_pdu: gbc:"[TC_GEONW_PON_GBC_BV_07.zip](/uploads/8cf015611f2a8bd2b248b75c3caa1109/TC_GEONW_PON_GBC_BV_07.zip) that routerHopLimit = 1 (line 5105)
The point that is surprising is that at line 4649 the traces show routerHopLimi := 9
I join the titan , sut and wireshark traces and cfg file.
Please, could you tell me how setting up the Hop Limit .
Regards,
Valerie Kronneberg[TC_GEONW_PON_GBC_BV_07.zip](/uploads/5cb1635b6914b588a6ac46e7f924a980/TC_GEONW_PON_GBC_BV_07.zip)Yann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.fr