ITS - Intelligent Transport Systems issueshttps://forge.etsi.org/rep/groups/ITS/-/issues2022-06-22T08:50:26Zhttps://forge.etsi.org/rep/ITS/TS.ITS/-/issues/11Load certificate on the flow2022-06-22T08:50:26ZYann Garciayann.garcia@fscom.frLoad certificate on the flowDo not load all certificates when starting the TestSystem but only when a certificate in requiredDo not load all certificates when starting the TestSystem but only when a certificate in requiredYann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/TS.ITS/-/issues/10Report EC comments into ETSI standard documents2022-06-22T08:50:41ZYann Garciayann.garcia@fscom.frReport EC comments into ETSI standard documentsCreate NWI to add EC comments (https://etsihq.sharepoint.com/:f:/r/teams/STF594/Shared%20Documents/General/2020-03_STF_594_Deliverables_JRC-Review?csf=1&web=1&e=fKGm6d)Create NWI to add EC comments (https://etsihq.sharepoint.com/:f:/r/teams/STF594/Shared%20Documents/General/2020-03_STF_594_Deliverables_JRC-Review?csf=1&web=1&e=fKGm6d)Yann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/TS.ITS/-/issues/9Add a PIXITs to omit geographicalRegion in innerEcRequest2022-03-31T13:21:25ZYann Garciayann.garcia@fscom.frAdd a PIXITs to omit geographicalRegion in innerEcRequestIn bot functions f_generate_inner_ec_request() and f_generate_inner_ec_request_with_wrong_parameters()In bot functions f_generate_inner_ec_request() and f_generate_inner_ec_request_with_wrong_parameters()Yann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/TS.ITS/-/issues/6Minimize size of virtualized image for ISG MEC MEC-030 simulation of Uu & PC52022-06-22T08:49:30ZYann Garciayann.garcia@fscom.frMinimize size of virtualized image for ISG MEC MEC-030 simulation of Uu & PC5Yann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/TS.ITS/-/issues/5Create a TITAN framework library sub-module2022-09-29T12:12:04ZYann Garciayann.garcia@fscom.frCreate a TITAN framework library sub-moduleYann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/TS.ITS/-/issues/2Add support of Nist-P384 signature2022-06-23T13:35:21ZYann Garciayann.garcia@fscom.frAdd support of Nist-P384 signatureYann Garciayann.garcia@fscom.frYann Garciayann.garcia@fscom.frhttps://forge.etsi.org/rep/ITS/asn1/cdd_ts102894_2/-/issues/4CDD DENM cause code name spelt incorrectly2022-08-25T02:01:40ZMatthew BanksCDD DENM cause code name spelt incorrectlyOne of the most recent DENM cause code names is spelt incorrectly...
In https://forge.etsi.org/rep/ITS/asn1/cdd_ts102894_2/-/blob/master/ITS-Container.asn there is a cause code:
```
aquaplannning (7),
```
This should "aquapla...One of the most recent DENM cause code names is spelt incorrectly...
In https://forge.etsi.org/rep/ITS/asn1/cdd_ts102894_2/-/blob/master/ITS-Container.asn there is a cause code:
```
aquaplannning (7),
```
This should "aquaplaning"
-- Thanks, Matthttps://forge.etsi.org/rep/ITS/asn1/cdd_ts102894_2/-/issues/2Release 2 message IDs2022-08-25T02:03:33ZMatthew BanksRelease 2 message IDsITS-Container.asn contains the PDU header message ID for each message type. Currently this lists up to the "rtcmem" ID of 13.
```
ItsPduHeader ::= SEQUENCE {
protocolVersion INTEGER (0..255),
messageID INTEGER{ denm(1), cam(2),...ITS-Container.asn contains the PDU header message ID for each message type. Currently this lists up to the "rtcmem" ID of 13.
```
ItsPduHeader ::= SEQUENCE {
protocolVersion INTEGER (0..255),
messageID INTEGER{ denm(1), cam(2), poi(3), spatem(4), mapem(5), ivim(6), ev-rsr(7), tistpgtransaction(8), srem(9), ssem(10), evcsn(11), saem(12), rtcmem(13) } (0..255), -- Mantis #7209, #7005
stationID StationID
}
```
However there are a number of newer message types that don't have a definition even though the specs refer to ETSI TS 102 894-2, this includes CPM, MCDM, VAM, PZM. Whilst these are Release 2 features I don't see where their message IDs are defined, especially since the BTP ports and ITS-AIDs are already defined for these services.https://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/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/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/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/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/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/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/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/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/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/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/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.fr