Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Porting the ETSI IPv6 test suite to Titan part II
Porting the ETSI IPv6 test suite to Titan part II [message #1783136] Thu, 08 March 2018 12:17
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1120
Registered: January 2015
Senior Member
Dear all,

OK, let's continue and add LibIpv6 to the mix; LibIpv6 has a number of subdirectories with files that are referring each other so let's throw all in;

the new install.script becomes:

#!/bin/bash

ln -s ../EtsiLibrary/LibCommon/LibCommon_AbstractData.ttcn     .
ln -s ../EtsiLibrary/LibCommon/LibCommon_BasicTypesAndValues.ttcn     .
ln -s ../EtsiLibrary/LibCommon/LibCommon_DataStrings.ttcn     .
ln -s ../EtsiLibrary/LibCommon/LibCommon_SyncExamples.ttcn     .
ln -s ../EtsiLibrary/LibCommon/LibCommon_Sync.ttcn     .
ln -s ../EtsiLibrary/LibCommon/LibCommon_TextStrings.ttcn     .
ln -s ../EtsiLibrary/LibCommon/LibCommon_Time.ttcn     .
ln -s ../EtsiLibrary/LibCommon/LibCommon_VerdictControl.ttcn     .


ln -s ../EtsiLibrary/LibScop/LibScop_CodecTests.ttcn  .
ln -s ../EtsiLibrary/LibScop/LibScop_Codec.ttcn  .
ln -s ../EtsiLibrary/LibScop/LibScop_Functions.ttcn  .
ln -s ../EtsiLibrary/LibScop/LibScop_Interface.ttcn  .
ln -s ../EtsiLibrary/LibScop/LibScop_Templates.ttcn  .
ln -s ../EtsiLibrary/LibScop/LibScop_TypesAndValues.ttcn  .


ln -s ../EtsiLibrary/LibIpv6/LibCommonRfcs/LibIpv6_CommonRfcs_Functions.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCommonRfcs/LibIpv6_CommonRfcs_Templates.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCommonRfcs/LibIpv6_CommonRfcs_TypesAndValues.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCommonRfcs/LibIpv6_ExternalFunctions.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCommonRfcs/LibIpv6_Interface_Functions.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCommonRfcs/LibIpv6_Interface_Templates.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCommonRfcs/LibIpv6_Interface_TypesAndValues.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCommonRfcs/LibIpv6_ModuleParameters.ttcn     .


ln -s ../EtsiLibrary/LibIpv6/LibCore/LibIpv6_Rfc2461NeighborDiscovery_Functions.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCore/LibIpv6_Rfc2461NeighborDiscovery_Templates.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCore/LibIpv6_Rfc2461NeighborDiscovery_TypesAndValues.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCore/LibIpv6_Rfc2462StatelessAddressAutoconf_Functions.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCore/LibIpv6_Rfc2462StatelessAddressAutoconf_Templates.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCore/LibIpv6_Rfc2462StatelessAddressAutoconf_TypesAndValues.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCore/LibIpv6_Rfc2463Icmpv6_Functions.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCore/LibIpv6_Rfc2463Icmpv6_Templates.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCore/LibIpv6_Rfc2463Icmpv6_TypesAndValues.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCore/LibIpv6_Rfc2894RouterRenumbering_Functions.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibCore/LibIpv6_Rfc2894RouterRenumbering_TypesAndValues.ttcn     .

ln -s ../EtsiLibrary/LibIpv6/LibMobility/LibIpv6_Rfc3775Mipv6_Functions.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibMobility/LibIpv6_Rfc3775Mipv6_Templates.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibMobility/LibIpv6_Rfc3775Mipv6_TypesAndValues.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibMobility/LibIpv6_Rfc4068FastHandovers_Functions.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibMobility/LibIpv6_Rfc4068FastHandovers_Templates.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibMobility/LibIpv6_Rfc4068FastHandovers_TypesAndValues.ttcn     .

ln -s ../EtsiLibrary/LibIpv6/LibMultiRfcs/LibIpv6_MultiRfcs_Functions.ttcn     .



ln -s ../EtsiLibrary/LibIpv6/LibSec/LibIpv6_Rfc4306Ikev2_Functions.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibSec/LibIpv6_Rfc4306Ikev2_Templates.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibSec/LibIpv6_Rfc4306Ikev2_TypesAndValues.ttcn     .


ln -s ../EtsiLibrary/LibIpv6/LibTransitioning/LibIpv6_CommonTrans_Functions.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibTransitioning/LibIpv6_Rfc792Icmpv4_Functions.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibTransitioning/LibIpv6_Rfc792Icmpv4_Templates.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibTransitioning/LibIpv6_Rfc792Icmpv4_TypesAndValues.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibTransitioning/LibIpv6_Rfc826Arp_Functions.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibTransitioning/LibIpv6_Rfc826Arp_Templates.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibTransitioning/LibIpv6_Rfc826Arp_TypesAndValues.ttcn     .



ln -s ../EtsiLibrary/LibIpv6/LibUdp/LibIpv6_Rfc0768Udp_Templates.ttcn     .
ln -s ../EtsiLibrary/LibIpv6/LibUdp/LibIpv6_Rfc0768Udp_TypesAndValues.ttc
 

1. Codecs not declared

and we will receive a heap of errors like:
    LibIpv6_CommonRfcs_TypesAndValues.ttcn:153.6-39: In union field `homeAddressOption':
     LibIpv6_CommonRfcs_TypesAndValues.ttcn:331.4-335.4: In type definition `OptHomeAddress':
      LibIpv6_CommonRfcs_TypesAndValues.ttcn:337.5-87: error: No encoding rules defined for type `@LibIpv6_CommonRfcs_TypesAndValues.OptHomeAddress'
 


The meaning of the error is that for the types defined in the XXX_TypesAndValues.ttcn files there's no codec declared;

If we look into the "TypesAndValues" files we will see codec declarations like this below
with {
					encode "present=bytes(0,1,0);intTag='hdrExtIntLen',getIntTag('hdrExtIntLen')-1";
	} 

which resemble the RAW codec declarations used by Titan; however they are not, they are for a different implementation, so Titan will not digest them.
Remember that the encoding is no standardized so each implementation will be different.

In order to get rid of the codec errors (or rather errors originated in the lack thereof),
we need to do the following:


Step 1. for all the files below

LibIpv6_CommonRfcs_TypesAndValues.ttcn
LibIpv6_Interface_TypesAndValues.ttcn
LibIpv6_Rfc2461NeighborDiscovery_TypesAndValues.ttcn
LibIpv6_Rfc2462StatelessAddressAutoconf_TypesAndValues.ttcn
LibIpv6_Rfc2463Icmpv6_TypesAndValues.ttcn
LibIpv6_Rfc2894RouterRenumbering_TypesAndValues.ttcn
LibIpv6_Rfc3775Mipv6_TypesAndValues.ttcn
LibIpv6_Rfc4068FastHandovers_TypesAndValues.ttcn
LibIpv6_Rfc4306Ikev2_TypesAndValues.ttcn
LibIpv6_Rfc792Icmpv4_TypesAndValues.ttcn
LibIpv6_Rfc826Arp_TypesAndValues.ttcn
LibScop_TypesAndValues.ttcn 


we need to add a codec declaration at the end of the module:
module XXX_TypesANdValues {
:
}with {encode "RAW"} 

Step 2. in all these files, all the encoding instructions will have to be get rid of, as they are not intelligible for Titan.

What I have done is that I have deactivated them with a search-and-replace:

e.g.
with {
			encode "present=bytes(0,1,0);intTag='hdrExtIntLen',getIntTag('hdrExtIntLen')-1";
	} 

changed to:
with {
			encode ""//present=bytes(0,1,0);intTag='hdrExtIntLen',getIntTag('hdrExtIntLen')-1""//;
	} 

which effectively means
with {
			encode ""
	} 

an empty encoding instruction.

From now on Titan is capable of encoding the types, but will apply the defaults associated with an empty encoding instruction, which is probably not something you are after.
To produce the correct encoding all encoding instructions will have to be in place and tested, which is a significant amount of work and it is not the subject of this post.
(Note: to make sure encoding-decoding works as desired, this has to be tested; our practice is to create a number of templates, test encoding-decoding in a loop.
and if possible in comparison with a similar, but independent implementation.)

Step 3. Optionally , external codec functions can be declared; else the codecs can be referred to via encvalue/decvalue , which , in case there's only
one possible encoding for a given type, will automatically find it.




2. Aliases in port message list

The next type of error that pops up is something like this:
LibIpv6_Interface_TypesAndValues.ttcn: In TTCN-3 module `LibIpv6_Interface_TypesAndValues':
 LibIpv6_Interface_TypesAndValues.ttcn:42.3-57.3: In type definition `LibIpv6Node':
  LibIpv6_Interface_TypesAndValues.ttcn:42.8-57.3: In component element definitions:
   LibIpv6_Interface_TypesAndValues.ttcn:43.18-25: In port definition `ipv4Port':
    LibIpv6_Interface_TypesAndValues.ttcn:147.3-167.3: In type definition `Ipv4Port':
     LibIpv6_Interface_TypesAndValues.ttcn:148.4-166.13: In `inout' list:
      LibIpv6_Interface_TypesAndValues.ttcn:151.4-16: error: Duplicate incoming message type `@LibIpv6_Interface_TypesAndValues.Ipv4Packet'
      LibIpv6_Interface_TypesAndValues.ttcn:150.4-18: note: Type `@LibIpv6_Interface_TypesAndValues.Ipv4Packet' is already listed here
      LibIpv6_Interface_TypesAndValues.ttcn:151.4-16: error: Duplicate outgoing message type `@LibIpv6_Interface_TypesAndValues.Ipv4Packet'
      LibIpv6_Interface_TypesAndValues.ttcn:150.4-18: note: Type `@LibIpv6_Interface_TypesAndValues.Ipv4Packet' is already listed here 




Let's look into the definition of the Ipv4Port port type in LibIpv6_Interface_TypesAndValues.ttcn :
	  
		type port Ipv4Port message {
			inout
			//Ipv4
			Ipv4EchoRequest,
			Ipv4EchoReply,
			Ipv4InformationRequest,
			Ipv4InformationReply,
			Ipv4TimestampRequest,
			Ipv4TimestampReply,
			Ipv4MaskRequest,
			Ipv4MaskReply,
			Ipv4RouterAdvertisement,
			Ipv4RouterSolicitation,
			Ipv4Unknown,
			Ipv4DestinationUnreachable,
			Ipv4Redirect,
			Ipv4SourceQuench,
			Ipv4TimeExceeded,
			Ipv4ParameterProblem,
			Ipv4Packet
		}

and we will quickly find the answer: all types listed here are aliases of the Ipv4Packet type.
Titan is telling us that it will not be able to distinguish between these types.

Exactly the same type of error is received for the Ipv6Port for the same reason:
 type port Ipv6Port message {
			inout
			//Imported from Rfc 2463
			DestinationUnreachable,
			PacketTooBig,
			TimeExceeded,
			ParameterProblem,
			EchoRequest,
			EchoReply,
			//Imported from Rfc 2461
			RouterAdvertisement,
			RouterSolicitation,
			NeighborSolicitation,
			NeighborAdvertisement,
			Redirect,
			//Imported from Rfc 2894
			RouterRenumbering,
			//Imported from Rfc 3775 Mipv6
			HomeAgentAddressDiscoveryRequest,
			HomeAgentAddressDiscoveryReply,
			MobilePrefixSolicitation,
			MobilePrefixAdvertisement,
			MipRouterAdvertisement,
			BindingRefreshRequest,
			HomeTestInit,//Hoti
			CareOfTestInit,//Coti
			HomeTest,//Hot
			CareOfTest,//Cot
			BindingUpdate,//BU
			BindingAcknowledgement,//BA
			BindingError,//BE
			FastBindingUpdate,//FBU
			FastBindingAcknowledgement,//FBA
			FastNeighborAdvertisement,
			//Imported from Rfc 4068
			RouterSolicitationForProxyRtAdv,
			ProxyRouterAdvertisement,
			HandoverInitiate,
			HandoverAcknowledge,
			OtherIcmpv6,
			//hand encoded IPv6 packets
			RawIpv6Packet,
			//UDP
			UdpPacket,
			//IKE
			IkeSaInitRequest,
			IkeSaInitResponse,
			IkeAuthRequest,
			IkeAuthResponse,
			CreateChildSaRequest,
			CreateChildSaResponse,
			InformationalRequest,
			InformationalResponse,
			//MetaPdu
			Ipv6Packet
		}//end type port Ipv6Port 


The solution is simple: we can get rid of these aliases:
		
type port Ipv4Port message {
			inout Ipv4Packet
		}
type port Ipv6Port message {
			inout 	Ipv6Packet
		}//end type port Ipv6Port
 

Luckily these types are not being used directly , as in
port.receive (AliasTypeToIpv4Packet :? ) 

but indirectly , through templates :
template AliasTypeIpv4Packet t_AliasTypeIpv4Packet_template
port.receive(t_AliasTypeIpv4Packet_template) 

which is exactly the same as
template Ipv4Packet t_Ipv4Packet_template
port.receive(t_Ipv4Packet_template) 

How do I now they are not being used directly? Well, if they would have been, I'd receive compilation errors .



3. First argument of match() should be a value
Next error:
		LibIpv6_CommonRfcs_Functions.ttcn: In TTCN-3 module `LibIpv6_CommonRfcs_Functions':
 LibIpv6_CommonRfcs_Functions.ttcn:1052.2-1066.2: In function definition `f_getLenSaTransformAttributeList':
  LibIpv6_CommonRfcs_Functions.ttcn:1056.3-1058.3: In if statement:
   LibIpv6_CommonRfcs_Functions.ttcn:1056.8-71: In the first argument of `match()' operation:
    LibIpv6_CommonRfcs_Functions.ttcn:1056.14-39: error: Reference to a value was expected instead of template parameter `p_saTransformAttributeList' 

Well, this is a simple one, unrelated to Titan:
if ( match(p_saTransformAttributeList, SaTransformAttributeList:omit)) {

has to be replaced with
if ( match(valueof(p_saTransformAttributeList), SaTransformAttributeList:omit)) { 

see definition of match in the standard


4. Function end without return

OK , the next type of error is a bit trickier:
LibIpv6_Rfc2463Icmpv6_Functions.ttcn: In TTCN-3 module `LibIpv6_Rfc2463Icmpv6_Functions':
 LibIpv6_Rfc2463Icmpv6_Functions.ttcn:92.2-119.2: In function definition `f_getIpPktAfterEchoReq':
  LibIpv6_Rfc2463Icmpv6_Functions.ttcn:92.2-119.2: error: The function has return type, but control might leave it without reaching a return statement 


Let's look at f_getIpPktAfterEchoReq in LibIpv6_Rfc2463Icmpv6_Functions.ttcn:
function f_getIpPktAfterEchoReq( 	in  UInt8 			p_hops,
							  		   	in  template Ipv6Address 	p_llaAddrTn,
										in  template Ipv6Address 	p_llaAddrNut,
							  		   	out Ipv6Packet		p_ipPkt)
	runs on LibIpv6Node
	return FncRetCode {

		var FncRetCode v_ret;

		v_ret := f_sendEchoRequest (
			m_echoRequest_noExtHdr_noData_hop (
				p_llaAddrTn,
				p_llaAddrNut,
				p_hops,
				c_defId,
				c_defSeqNo ) );
		if ( v_ret != e_success ) {return v_ret;}
		tc_ac.start;
		alt {
			[]	ipPort.receive(mw_ipPkt) -> value p_ipPkt {
					tc_ac.stop;	
					return e_success;
				}
			[]	tc_ac.timeout{
					return e_timeout;
				}		
		} // end alt
	} // end f_getIcmpAfterEchoReq


Titan, being paranoid as it is, complains that the function can terminate without a return statement;
Obviously , it can't as the final alt will will resolve either in a reception or a timeout with the proper return;
this is a deficiency in Titan, which can be pacified with adding a dummy return right before function end:

function f_getIpPktAfterEchoReq( 	in  UInt8 			p_hops,
							  		   	in  template Ipv6Address 	p_llaAddrTn,
										in  template Ipv6Address 	p_llaAddrNut,
							  		   	out Ipv6Packet		p_ipPkt)
	runs on LibIpv6Node
	return FncRetCode {

		var FncRetCode v_ret;

		v_ret := f_sendEchoRequest (
			m_echoRequest_noExtHdr_noData_hop (
				p_llaAddrTn,
				p_llaAddrNut,
				p_hops,
				c_defId,
				c_defSeqNo ) );
		if ( v_ret != e_success ) {return v_ret;}
		tc_ac.start;
		alt {
			[]	ipPort.receive(mw_ipPkt) -> value p_ipPkt {
					tc_ac.stop;	
					return e_success;
				}
			[]	tc_ac.timeout{
					return e_timeout;
				}		
		} // end alt
		
			return e_timeout; //dummy	
		
	} // end f_getIcmpAfterEchoReq 
	


The same thing has to be done for a number of similar functions in LibIpv6_CommonTrans_Functions.ttcn.


5. Fault in the original code

OK, now a weird one:
LibIpv6_Rfc4306Ikev2_Templates.ttcn: In TTCN-3 module `LibIpv6_Rfc4306Ikev2_Templates':
 LibIpv6_Rfc4306Ikev2_Templates.ttcn:1688.2-1700.2: In template definition `m_tsInitiatorPayload':
  LibIpv6_Rfc4306Ikev2_Templates.ttcn:1691.19-1699.4: In template for union field `tsInitiator':
   LibIpv6_Rfc4306Ikev2_Templates.ttcn:1695.24-70: In template for record field `payloadLength':
    LibIpv6_Rfc4306Ikev2_Templates.ttcn:1695.24-70: In the operands of operation `+':
     LibIpv6_Rfc4306Ikev2_Templates.ttcn:1695.28-70: In the operands of operation `*':
      LibIpv6_Rfc4306Ikev2_Templates.ttcn:1695.28-65: In the operand of operation `sizeof()':
       LibIpv6_Rfc4306Ikev2_Templates.ttcn:1695.35-64: error: Operation is not applicable to `valueof(p_trafficSelectorList)' 

and this is the definition in question:

	template IkePayload m_tsInitiatorPayload(
		UInt8					p_nextPayload,
		template TrafficSelectorList 	p_trafficSelectorList) := {
			tsInitiator := {
				nextPayload			:= p_nextPayload,
				criticalFlag 		:= 0,
				reserved1	 		:= c_uInt7Zero,
				payloadLength 		:= 8,  + sizeof(valueof(p_trafficSelectorList)) * 40,  
			 	numberOfTs			:= sizeof(valueof(p_trafficSelectorList)), 				
				reserved2			:= c_uInt24Zero,
				trafficSelectorList	:= p_trafficSelectorList
			}
	}

as p_trafficSelectorList is a structured type

	
type set length(1 .. c_maxTrafficSelectors) of TsTrafficSelector TrafficSelectorList ;

type union TsTrafficSelector {
					TsIpv4TrafficSelector	tsIpv4TrafficSelector,
					TsIpv6TrafficSelector	tsIpv6TrafficSelector
				} 


and so on

the sizeof operation cannot be applied to it, so I'm guessing there is an implicit decoding applied here;

I have tried to replace it with something similar that makes sense in the Titan world, but this part has to be verified.

template IkePayload m_tsInitiatorPayload(
		UInt8					p_nextPayload,
		template TrafficSelectorList 	p_trafficSelectorList) := {
			tsInitiator := {
				nextPayload			:= p_nextPayload,
				criticalFlag 		:= 0,
				reserved1	 		:= c_uInt7Zero,
			//	payloadLength 		:= 8,  + sizeof(valueof(p_trafficSelectorList)) * 40,  
				payloadLength 		:= 8 + lengthof((bit2oct(encvalue(valueof(p_trafficSelectorList))))) * 40,  //FIXME!!!							
			//	numberOfTs			:= sizeof(valueof(p_trafficSelectorList)), 				
			    numberOfTs			:= lengthof(bit2oct(encvalue(valueof(p_trafficSelectorList)))), //FIXME!!!
				reserved2			:= c_uInt24Zero,
				trafficSelectorList	:= p_trafficSelectorList
			}
	}
	
	
	template IkePayload m_tsResponderPayload(
		UInt8					p_nextPayload,
		template TrafficSelectorList 	p_trafficSelectorList) := {
			tsResponder := {
				nextPayload			:= p_nextPayload,
				criticalFlag 		:= 0,
				reserved1	 		:= c_uInt7Zero,
			//	payloadLength 		:= 8,  + sizeof(valueof(p_trafficSelectorList)) * 40,  
				payloadLength 		:= 8 + lengthof((bit2oct(encvalue(valueof(p_trafficSelectorList))))) * 40,  //FIXME!!!							
			//	numberOfTs			:= sizeof(valueof(p_trafficSelectorList)), 				
			    numberOfTs			:= lengthof(bit2oct(encvalue(valueof(p_trafficSelectorList)))), //FIXME!!!
				reserved2			:= c_uInt24Zero,
				trafficSelectorList	:= p_trafficSelectorList
			}
	} 

6. Component type compatibility

Now something familiar, component type compatibility again:
LibIpv6_Rfc4306Ikev2_Functions.ttcn: In TTCN-3 module `LibIpv6_Rfc4306Ikev2_Functions':
 LibIpv6_Rfc4306Ikev2_Functions.ttcn:6013.2-6068.2: In function definition `f_rcvSaInitReqAndRsp':
  LibIpv6_Rfc4306Ikev2_Functions.ttcn:6064.3-164: In if statement:
   LibIpv6_Rfc4306Ikev2_Functions.ttcn:6064.118-162: In function instance:
    LibIpv6_Rfc4306Ikev2_Functions.ttcn:6064.118-162: error: Runs on clause mismatch: A definition that runs on component type `@LibIpv6_Interface_TypesAndValues.LibIpv6Node' cannot call function `@LibCommon_Sync.f_selfOrClientSyncAndVerdict', which runs on `@LibCommon_Sync.SelfSyncComp'
Notify: Error found in the input modules. Code will not be generated.
Makefile:154: recipe for target 'compile' failed


and the solution:

in LibIpv6_Interface_TypesAndValues

	
		type component LibIpv6Node {
			port Ipv4Port ipv4Port;
			port Ipv6Port ipPort;
			port ArpPort arpPort;
			timer tc_ac:= PX_TAC;
			timer tc_noAc:= PX_TNOAC;
			timer tc_wait:= PX_TWAIT;
			var MipSec vc_mobileSec;
			var Sad vc_sad;
			var IkeSad vc_ikeSad;
			timer tc_loop := PX_LOOP ;
			var StringStack v_stateStack:= c_initStringStack;
			port SyncPort syncSendPort;
			port SyncPort syncPort;
			timer tc_sync := PX_TSYNC_TIME_LIMIT;
		}

changed to :
		
	type component LibIpv6Node extends SelfSyncComp {
			port Ipv4Port ipv4Port;
			port Ipv6Port ipPort;
			port ArpPort arpPort;
			timer tc_ac:= PX_TAC;
			timer tc_noAc:= PX_TNOAC;
			timer tc_wait:= PX_TWAIT;
			var MipSec vc_mobileSec;
			var Sad vc_sad;
			var IkeSad vc_ikeSad;
			timer tc_loop := PX_LOOP ;
		/*	var StringStack v_stateStack:= c_initStringStack;
			port SyncPort syncSendPort;
			port SyncPort syncPort;
			timer tc_sync := PX_TSYNC_TIME_LIMIT;
		*/}
 



7. Port declarations to internal

Next , again something we've seen before:
In file included from LibIpv6_ExternalFunctions.hh:20:0,
                 from LibIpv6_CommonRfcs_Functions.hh:20,
                 from LibIpv6_CommonRfcs_Functions.cc:11:
LibIpv6_Interface_TypesAndValues.hh:6498:23: fatal error: Ipv6Port.hh: No such file or directory
compilation terminated. 	 


The newly included ports have to be decorated with:
with { extension "internal "}  


8. External functions

Something new this time:
	LibIpv6_ExternalFunctions.o: In function `LibIpv6__ExternalFunctions::pre_init_module()':
LibIpv6_ExternalFunctions.cc:(.text+0x49): undefined reference to `LibIpv6__ExternalFunctions::fx__translateIpv6Address(CHARSTRING const&)'



The problem here is that Titan can only see the external function declarations, and not the C/C++ body which is missing.
These bodies will have to be added ultimately , but for the moment I have replaced the external function declarations
with equivalent dummy internal functions.
external function fx_translateIpv6Address( in charstring p_address ) 
	return Ipv6Address };

changed to
	/*external*/ function fx_translateIpv6Address( in charstring p_address ) 
	return Ipv6Address {  var Ipv6Address v_ret; return v_ret }; 



With this, LibCommon, LibScope and LibIpv6 compile together.


To be continued.

Best regards
Elemer

[Updated on: Thu, 08 March 2018 18:38]

Report message to a moderator

Previous Topic:Is Neon still required for Titan Eclipse plugin?
Next Topic:Porting the ETSI IPv6 test suite to Titan part III
Goto Forum:
  


Current Time: Fri Apr 26 08:44:02 GMT 2024

Powered by FUDForum. Page generated in 5.04290 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top