ITS issueshttps://forge.etsi.org/rep/ITS/ITS/-/issues2019-08-08T06:51:16Zhttps://forge.etsi.org/rep/ITS/ITS/-/issues/1geonw_generate_makefile does not build2019-08-08T06:51:16Zritterthgeonw_generate_makefile does not buildAtsGeoNetworking misses reference to Pki. I have attached a patch to fix (based on branch STF525).
If you allow me push I could also create a merge request.
[geonw_generate_makefile.bash.patch](/uploads/193ae0fab8a213fe30e817783cb782d4...AtsGeoNetworking misses reference to Pki. I have attached a patch to fix (based on branch STF525).
If you allow me push I could also create a merge request.
[geonw_generate_makefile.bash.patch](/uploads/193ae0fab8a213fe30e817783cb782d4/geonw_generate_makefile.bash.patch)Yann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/ITS/-/issues/2Change Request on update_its_project.bash2019-08-08T06:51:14ZritterthChange Request on update_its_project.bashThis patch adds the possibility to have the sources outside HOME.
It should keeps existing behavior if other locations (VALIDATION_DIR) is not set.
Patch is based on branch STF525.
[update_its_project.bash.patch](/uploads/ec14206dfdc98...This patch adds the possibility to have the sources outside HOME.
It should keeps existing behavior if other locations (VALIDATION_DIR) is not set.
Patch is based on branch STF525.
[update_its_project.bash.patch](/uploads/ec14206dfdc989b643bce0eb7b56b77f/update_its_project.bash.patch)Yann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/ITS/-/issues/3Matching empty payload in TC_GEONW_FDV_SHB_BV_01 et.al.2019-08-08T06:49:59ZritterthMatching empty payload in TC_GEONW_FDV_SHB_BV_01 et.al.In this testcase an GN packet with empty payload is requested (len=0).
If that is sent as requested (GN frame w/o payload len=0) the TC following error is triggered:
MTC@md11e3tc: Matching on port geoNetworkingPort **.msgIn.gnPacket.p...In this testcase an GN packet with empty payload is requested (len=0).
If that is sent as requested (GN frame w/o payload len=0) the TC following error is triggered:
MTC@md11e3tc: Matching on port geoNetworkingPort **.msgIn.gnPacket.packet.payload := omit with ? unmatched**: First message in the queue does not match the template
Only if I add some payload (though not requested) the TC passes.Yann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/ITS/-/issues/4SEGV in TC_GEONW_PON_LOT_BV_03_012019-08-08T06:50:35ZritterthSEGV in TC_GEONW_PON_LOT_BV_03_01MTC log:
```
MTC@md11e3tc: Executing test case TC_GEONW_PON_LOT_BV_03_01 in module ItsGeoNetworking_TestCases.
MTC@md11e3tc: pcap_layer::pcap_layer: Filter: ( ether dst ffffffffffff or ether dst 0a0027000000 ) and not ether src 0a002700...MTC log:
```
MTC@md11e3tc: Executing test case TC_GEONW_PON_LOT_BV_03_01 in module ItsGeoNetworking_TestCases.
MTC@md11e3tc: pcap_layer::pcap_layer: Filter: ( ether dst ffffffffffff or ether dst 0a0027000000 ) and not ether src 0a0027000000 and ether proto 0x8947
MTC@md11e3tc: UpperTesterPort_Gn::outgoing_send: Execution duration: 0.499000 ms
MTC@md11e3tc: pcap_layer::Handle_Fd_Event_Readable: Execution duration: 4.629000 ms
MTC@md11e3tc: pcap_layer::Handle_Fd_Event_Readable: Execution duration: 3.660000 ms
MTC@md11e3tc: udp_layer::Handle_Fd_Event_Readable: Execution duration: 0.230000 ms
MTC@md11e3tc: Matching on port utPort succeeded: matched
MTC@md11e3tc: *** f_utInitializeIut: INFO: IUT initialized ***
MTC@md11e3tc: pcap_layer::Handle_Fd_Event_Readable: Execution duration: 1.836000 ms
MTC@md11e3tc: pcap_layer::Handle_Fd_Event_Readable: Execution duration: 1.729000 ms
MTC@md11e3tc: Matching on port acPort succeeded: matched
MTC@md11e3tc: GeoNetworkingPort::outgoing_send: Execution duration: 4.143000 ms
MTC@md11e3tc: **** f_selfSync: Successfully passed PREAMBLE synchronization point. ****
MTC@md11e3tc: UpperTesterPort_Gn::outgoing_send: Execution duration: 1.168000 ms
MTC@md11e3tc: Timeout operation on timer tc_ac failed: The timer is not started.
MTC@md11e3tc: udp_layer::Handle_Fd_Event_Readable: Execution duration: 0.133000 ms
MTC@md11e3tc: Matching on port utPort succeeded: matched
MTC@md11e3tc: Timeout operation on timer tc_wait failed: The timer is not started.
MTC@md11e3tc: pcap_layer::Handle_Fd_Event_Readable: Execution duration: 2.411000 ms
MTC@md11e3tc: Timeout operation on timer tc_wait failed: The timer is not started.
MTC@md11e3tc: pcap_layer::Handle_Fd_Event_Readable: Execution duration: 2.244000 ms
MTC@md11e3tc: Timeout operation on timer tc_wait failed: The timer is not started.
MTC@md11e3tc: pcap_layer::Handle_Fd_Event_Readable: Execution duration: 4.429000 ms
MTC@md11e3tc: Matching on port geoNetworkingPort .msgIn.gnPacket.packet.commonHeader.headerTST{ geoUnicastHdr := { headerType := e_geoUnicast (2), headerSubType := 0 } } with { lsHdr := { headerType := e_locationService (6), headerSubType := e_lsRequest (0) } } unmatched.msgIn.gnPacket.packet.extendedHeader{ geoUnicastHeader := { seqNumber := 0, reserved := 0, srcPosVector := { gnAddr := { typeOfAddress := e_initial (0), stationType := e_roadSideUnit (15), stationCountryCode := 0, mid := '08002729C3E8'O }, timestamp_ := 2412825221, latitude := 482673260, longitude := 164205690, pai := '1'B, speed := 0, heading := 0 }, dstPosVector := { gnAddr := { typeOfAddress := e_manual (1), stationType := e_passengerCar (5), stationCountryCode := 0, mid := '00000000000B'O }, timestamp_ := 2812659205, latitude := 482693260, longitude := 164205690 } } } with { lsRequestHeader := { seqNumber := ?, reserved := ?, srcPosVector := ?, gnAddress := { typeOfAddress := ?, stationType := ?, stationCountryCode := ?, mid := ? } } } unmatched: First message in the queue does not match the template:
MTC@md11e3tc: Matching on port geoNetworkingPort succeeded: matched
MTC@md11e3tc: "*** TC_GEONW_PON_LOT_BV_03_01: PASS: GUC packet received correctly ***"
MTC@md11e3tc: setverdict(pass): none -> pass
MTC@md11e3tc: **** f_selfSync: Successfully passed TEST BODY synchronization point. ****
Error: Unexpected end of MTC connection from 127.0.0.1 [127.0.0.1].
MC@md11e3tc: The control connection to MTC is lost. Destroying all PTC connections.
MC@md11e3tc: MTC terminated.
MTC terminated unexpectedly. Cannot continue in batch mode.
MC@md11e3tc: Shutting down session.
HC@md11e3tc: Exit was requested from MC. Terminating HC.
MC@md11e3tc: Shutdown complete.
log files were merged into ../logs/merged.log
```
PTCS log:
```
ASAN:DEADLYSIGNAL
=================================================================
==548==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000004 (pc 0x7efc6008a5de bp 0x7ffdf8310ae0 sp 0x7ffdf8310aa0 T0)
==548==The signal is caused by a READ memory access.
==548==Hint: address points to the zero page.
#0 0x7efc6008a5dd in timer_delete (/lib/x86_64-linux-gnu/librt.so.1+0x45dd)
#1 0x55d19c8b2f6f in geonetworking_layer::stop_beaconing() ../../../framework/src/geonetworking_layer.cc:477
#2 0x55d19c72ae21 in LibItsGeoNetworking__TestSystem::AdapterControlPort::outgoing_send(LibItsGeoNetworking__TypesAndValues::AcGnPrimitive const&) ../src/AdapterControlPort_GN.partC:89
#3 0x55d19ba4c73d in LibItsGeoNetworking__TestSystem::AdapterControlPort_BASE::send(LibItsGeoNetworking__TypesAndValues::AcGnPrimitive const&, COMPONENT const&) /home/rt_1804/etsi/dev/etsi_its/src/AtsGeoNetworking/objs/LibItsGeoNetworking_TestSystem.cc:151
#4 0x55d19ba4cd4f in LibItsGeoNetworking__TestSystem::AdapterControlPort_BASE::send(LibItsGeoNetworking__TypesAndValues::AcGnPrimitive_template const&) /home/rt_1804/etsi/dev/etsi_its/src/AtsGeoNetworking/objs/LibItsGeoNetworking_TestSystem.cc:175
#5 0x55d19b468d16 in LibItsGeoNetworking__Functions::f__acTriggerEvent(LibItsGeoNetworking__TypesAndValues::AcGnPrimitive_template const&) /home/rt_1804/etsi/dev/etsi_its/src/AtsGeoNetworking/objs/LibItsGeoNetworking_Functions.cc:5445
#6 0x55d19b451d59 in LibItsGeoNetworking__Functions::f__stopBeingNeighbour() /home/rt_1804/etsi/dev/etsi_its/src/AtsGeoNetworking/objs/LibItsGeoNetworking_Functions.cc:2873
#7 0x55d19b468979 in LibItsGeoNetworking__Functions::f__poNeighbour() /home/rt_1804/etsi/dev/etsi_its/src/AtsGeoNetworking/objs/LibItsGeoNetworking_Functions.cc:5418
#8 0x55d19b57b863 in ItsGeoNetworking__TpFunctions::f__TP__GEONW__PON__LOT__BV__03__main(LibItsGeoNetworking__TypesAndValues::LongPosVector_template const&) /home/rt_1804/etsi/dev/etsi_its/src/AtsGeoNetworking/objs/ItsGeoNetworking_TpFunctions.cc:3930
#9 0x55d19b572f09 in ItsGeoNetworking__TpFunctions::f__GEONW__PON__LOT__BV__03__01() /home/rt_1804/etsi/dev/etsi_its/src/AtsGeoNetworking/objs/ItsGeoNetworking_TpFunctions.cc:3373
#10 0x55d19aef3df6 in ItsGeoNetworking__TestCases::testcase_TC__GEONW__PON__LOT__BV__03__01(bool, double) /home/rt_1804/etsi/dev/etsi_its/src/AtsGeoNetworking/objs/ItsGeoNetworking_TestCases.cc:320
#11 0x55d19c94196a in TTCN_Communication::process_execute_testcase() (/data/develop/etsi-validation/dev/etsi_its/src/AtsGeoNetworking/bin/AtsGeoNetworking+0x21bc96a)
#12 0x55d19c942304 in TTCN_Communication::process_all_messages_tc() (/data/develop/etsi-validation/dev/etsi_its/src/AtsGeoNetworking/bin/AtsGeoNetworking+0x21bd304)
#13 0x55d19c9823e6 in TTCN_Runtime::mtc_main() (/data/develop/etsi-validation/dev/etsi_its/src/AtsGeoNetworking/bin/AtsGeoNetworking+0x21fd3e6)
#14 0x55d19aee9d89 in main (/data/develop/etsi-validation/dev/etsi_its/src/AtsGeoNetworking/bin/AtsGeoNetworking+0x764d89)
#15 0x7efc5e5edb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#16 0x55d19aeed219 in _start (/data/develop/etsi-validation/dev/etsi_its/src/AtsGeoNetworking/bin/AtsGeoNetworking+0x768219)
`Yann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/ITS/-/issues/5Bug in time/timestamp management2019-02-09T14:33:20ZYann Garciayann.garcia@fscom.frBug in time/timestamp managementReview the time value for CAM/DENM timestamps/generation times, GeoNetworking time stamp & secured generation timesReview the time value for CAM/DENM timestamps/generation times, GeoNetworking time stamp & secured generation timesYann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/ITS/-/issues/6Certificates generated by certificate generation tool already expired2019-08-08T06:50:25ZAndreas BergCertificates generated by certificate generation tool already expiredWhen generating certificates for the security conformance tests with the certificate generation tool, the certificates are already expired.
I generated certificate CERT_IUT_A_AT today at 2019-02-01. When looking at the validityPeriod, i...When generating certificates for the security conformance tests with the certificate generation tool, the certificates are already expired.
I generated certificate CERT_IUT_A_AT today at 2019-02-01. When looking at the validityPeriod, it is set to start from 2018-01-01 and is valid for one year.
When looking at the xml file used STF525_Its/data/v3/profiles/CERT_IUT_A_AT.xml, it looks like this:
...
<validity>
<restriction type="time" start="+0d" end="+365d"/>
<restriction type="region">
<none/>
</restriction>
</validity>
...Yann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/ITS/-/issues/7Unable to compile asn1certgen2019-08-08T06:50:30ZAndreas BergUnable to compile asn1certgenWhen trying to compile asn1certgen I get the following error:
~/dev/STF525_Its/tools/itscertgen/asn1certgens$ make
...
...
../build/x86_64-linux-gnu-d/libItsCertAsn.a(Time32.o): In function `Time32_print':
/home/etsi/dev/STF525_Its/tool...When trying to compile asn1certgen I get the following error:
~/dev/STF525_Its/tools/itscertgen/asn1certgens$ make
...
...
../build/x86_64-linux-gnu-d/libItsCertAsn.a(Time32.o): In function `Time32_print':
/home/etsi/dev/STF525_Its/tools/itscertgen/asn1certgen/asncodec/Time32.c:87: undefined reference to `stritsdate32'
collect2: error: ld returned 1 exit status
../common.mk:165: recipe for target '../build/x86_64-linux-gnu-d/asn1certgen' failed
make: *** [../build/x86_64-linux-gnu-d/asn1certgen] Error 1
If I go back to git commit from Feb 6 with SHA 214bddfe, then I can successfully compile.Yann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/ITS/-/issues/8Unable to execute ItsCam_TestCases.TC_CAM_MSP_BV_012019-08-08T06:50:49ZkronnebergUnable to execute ItsCam_TestCases.TC_CAM_MSP_BV_01Hi,
When running the CAM_MSP_BV_01 test, the CAM sent to the SUT has a geonet.BasicHeader.version = 0 instead of 1.
I can't find any PICS to change that behavior. Could you provide me with support, please?
Regards
Valérie KronnebergHi,
When running the CAM_MSP_BV_01 test, the CAM sent to the SUT has a geonet.BasicHeader.version = 0 instead of 1.
I can't find any PICS to change that behavior. Could you provide me with support, please?
Regards
Valérie KronnebergYann 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/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/11Security uses TAI not UTC: Need to add 4 Leap seconds2019-08-08T06:50:45ZritterthSecurity uses TAI not UTC: Need to add 4 Leap seconds@garciay
Here is a possible fix.
Possibly even better to add a "PICS variable" for Leap seconds, since they will differ in future.
```
diff --git a/ccsrc/Protocols/Security/security_services.cc b/ccsrc/Protocols/Security/security_serv...@garciay
Here is a possible fix.
Possibly even better to add a "PICS variable" for Leap seconds, since they will differ in future.
```
diff --git a/ccsrc/Protocols/Security/security_services.cc b/ccsrc/Protocols/Security/security_services.cc
index ff58bef4..5bb87746 100644
--- a/ccsrc/Protocols/Security/security_services.cc
+++ b/ccsrc/Protocols/Security/security_services.cc
@@ -160,6 +160,8 @@ int security_services::process_ieee_1609_dot2_signed_data(const IEEE1609dot2::Si
unsigned long long gt = ((INTEGER&)(*v.get_opt_value())).get_long_long_val();
// Get current time timestamp
unsigned long long us = base_time::get_instance().get_its_current_time_us(); // in microsecond
+ // ADD 4 leap seconds to convert to TAI (as Feb 2019)
+ us += 4000000;
loggers::get_instance().log("security_services::process_ieee_1609_dot2_signed_data: generation time check %ld / %ld, delta = %f", header_info.generationTime(), us, abs((double)gt - (double)us));
if (abs((double)gt - (double)us) >= 500000.0) { // TODO Use a params for generation_time_epsilon, 500ms differences
loggers::get_instance().warning("security_services::process_ieee_1609_dot2_signed_data: Invalid generation time, discard it");
```Yann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/ITS/-/issues/12DEN_EVRP_BV_11 understanding2019-08-09T08:32:29ZlandauDEN_EVRP_BV_11 understandingHello,
In the test case DEN_EVRP_BV_11, a DENM is triggered with a validityDuration absent and a repetitionDuration set to 700 sec.
(ttcn) const ValidityDuration c_duration1 := defaultValidity + 100;
...
f_utTriggerEvent( m_utTriggerEv...Hello,
In the test case DEN_EVRP_BV_11, a DENM is triggered with a validityDuration absent and a repetitionDuration set to 700 sec.
(ttcn) const ValidityDuration c_duration1 := defaultValidity + 100;
...
f_utTriggerEvent( m_utTriggerEvent( v_situation, omit, c_duration1, c_interval1 ) );
(traces TS) validityDuration := omit, repetitionDuration := 700,
(traces IUT) triggerDenm parameters validityDuration(absent) repetitionDuration=700
This results in the trigger DENM request to be rejected by our stack because the repetitionDuration (700 ) is detected as greater than the default validityDuration (600):
(traces IUT ) Error: 50271.79s Ev=0011 Unit:DENM validityDuration(600 Sec) < repetitionDuration(700 Sec)
in ETSI EN 302 637-3 V1.3.1 (2019-04), clause 8.2.1.5
..
the default offset of 600 s starting from the detectionTime, if the validityDuration is not provided by the application.
...
For all application request types, the T_Repetition and T_RepetitionDuration shall not be greater than the validityDuration
From the test case DEN_EVRP_BV_11, do we have to assume that:
WHEN the validityDuration is omitted AND the repetitionDuration is greater than 600 sec (in the trigger DENM request),
THEN the request is valid AND the validityDuration is set to the repetitionDuration (instead of the defaultValue).
Regards,
MarcYann 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/14GEONW_PON_FPB_BV_11_03 area latitude longitude doesn't fit SUT position2019-08-08T08:49:49ZkronnebergGEONW_PON_FPB_BV_11_03 area latitude longitude doesn't fit SUT positionThe test GEONW_PON_FPB_BV_11_03 triggers an UtGnTrigger_geoBroadcast(0x51). I expected the latitude and longitude take into account the psition of the SUT received in the Beacon. It isn't the case, so the SUT reject the command du to " D...The test GEONW_PON_FPB_BV_11_03 triggers an UtGnTrigger_geoBroadcast(0x51). I expected the latitude and longitude take into account the psition of the SUT received in the Beacon. It isn't the case, so the SUT reject the command du to " Destination too far, 4900239.000000 for 30000 in meters" .
For debug purpose, I get around this behaviour patching LibItsGeoNetworking_Templates.ttcn m_dummyLongPosVector with the position of the SUT. Is this patch suitable ? I'd rather configure the tester so that the position of the SUT is red from beacons.
I attached TITAN log.
Please, let me know how to fix this properly.
[AtsGeoNetworking.titan.merged-TC_GEONW_PON_FPB_BV_11_03.KO.log](/uploads/b744ebf99a4977987b8c7ba7f68183ff/AtsGeoNetworking.titan.merged-TC_GEONW_PON_FPB_BV_11_03.KO.log)
Regards,
Valerie Kronneberg
template (value) LongPosVector m_dummyLongPosVector := {
gnAddr := m_dummyLongPosVector,
timestamp_ := c_uInt32Zero,
latitude := 436175790 // PX_TS_LATITUDE // c_uInt32Zero
longitude := 70546480 // PX_TS_LONGITUDE // c_uInt32Zero
pai := int2bit(1,1),
speed := c_uInt16Zero,
heading := c_uInt16Zero
}
uppertester_geonetworking_codec::encode_: {
geoAreaPosLatitude := 20000,
geoAreaPosLongitude := 0,
distanceA := 166,
distanceB := 0,
angle := 0
}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.frhttps://forge.etsi.org/rep/ITS/ITS/-/issues/16Information on BTP Test Suite2019-08-08T06:45:12ZkronnebergInformation on BTP Test SuiteHello,
I would just like to know if the BTP test suite is available for execution. I ask you this question because there is no btp_generate_makefile.bash script nor a cfg file. I built them but the test failed.
If it is possible to laun...Hello,
I would just like to know if the BTP test suite is available for execution. I ask you this question because there is no btp_generate_makefile.bash script nor a cfg file. I built them but the test failed.
If it is possible to launch this suite, can you give me a model of cfg.
Thank you for your help.
Regards,
Valerie kronnebergYann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/ITS/-/issues/17Errors because of removing trailing 0A and 0D bytes from HTTP responses2019-08-22T09:36:14ZSzilveszter TÓTHErrors because of removing trailing 0A and 0D bytes from HTTP responsesDear ETSI ITS Team,
We are using the STF525 branch of the project to test our (Microsec's) V2X PKI infrastructure software. This is a great help and many thanks for building such a useful testing tool!
During our tests sometimes we get...Dear ETSI ITS Team,
We are using the STF525 branch of the project to test our (Microsec's) V2X PKI infrastructure software. This is a great help and many thanks for building such a useful testing tool!
During our tests sometimes we get a message from the test suite as follows:
```
fx__decrypt__aes__128__ccm__test: Failed to decrypt message
```
As we investigated further, we saw that the error was that the last byte of the authTag was changed to 00. When the HTTP response was read, it contained either 0A (LF) or 0D (CR) as the last byte:
```
MTC@aa2a65190077: http_codec::decode_body: Aligned body='...0EB347CDCF7EEDE541E20E517455770D'O
MTC@aa2a65190077: http_codec::decode_body: counter=1
MTC@aa2a65190077: http_codec::decode_body: body length=331
MTC@aa2a65190077: http_codec::decode_body: Finalised body='...0EB347CDCF7EEDE541E20E51745577'O
```
As you can see, here we have already lost the last byte (0D). The authTag is incorrect too:
```
MTC@aa2a65190077: fx__decrypt__aes__128__ccm__test: tag: '0EB347CDCF7EEDE541E20E5174557700'O
```
The following code snippet removes trailing CR/LF bytes from HTTP responses, which may be incorrect and causes the above phenomenon:
```
// Remove CRLF if any
int counter = 0;
if ((body[body.lengthof() - 1].get_octet() == 0x0d) || (body[body.lengthof() - 1].get_octet() == 0x0a)) {
counter += 1;
if ((body[body.lengthof() - 2].get_octet() == 0x0d) || (body[body.lengthof() - 2].get_octet() == 0x0a)) {
counter += 1;
}
}
loggers::get_instance().log("http_codec::decode_body: counter=%d", counter);
```
How can we correctly transfer an HTTP response which contains trailing 0A or 0D bytes to the test system? Now the only solution is re-running the test to see the error message (probably) disappear.
Thanks in advance for your response,
BR,
Szilveszter Tóth
MicrosecYann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://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/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!