VxWorks not processing HeartBeats

4 posts / 0 new
Log in or register to post comments
Last post
Wed, 08/28/2013 - 06:09
#1
Rodolf
Offline
Last seen: 10 years 7 months ago
Joined: 08/28/2013
Posts: 66
VxWorks not processing HeartBeats

Hi,

I am using Connext Micro Edition on an equipment (VxWorks @ 192.168.1.10) and on Windows Seven in point to point connection.
To boot the equipment, the PC shall be in @ 192.168.1.1, so i added it.

ipconfig gives:

Ethernet Local Area Connection :
Adresse IPv4. . . . . . . . . . . . . .: 10.208.xxxx
Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.1

Equipment contains a Pub with initial_peers to 192.168.1.1
PC contains a Sub with intial_peers to 192.168.1.10
Both have   discovery_plugin_properties.accept_unknown_peers = DDS_BOOLEAN_FALSE and use UDP_InterfaceFactoryProperty with
udp_property->allow_interface,0) ="Local Area Connection";

So for me, it should allowed udp communication only between 192.168.1.1 and 19.2.168.1.10

But application on 192.168.1.10 is trying to communicate also with 10.208.xxxx and for Heartbeats only  to that @

Here are the logs:

detected new participant                                            <- found the participant with Subsciber on the Computer
DataWriter: send topic: DCPSParticipant
DataWriter: route topic: DCPSParticipant/1
UDP Sending to : 0x101A8C0                                  <- @ is Ok, target is 192.168.1.1
UDP wrote: 280 bytes to 7410/c0a80101.0.0.0

UDP Sending to : 0x72A4D00A

UDP wrote: -1 bytes to 7410/ad0xxxx.0.0.0          <- @ is the second one, not expected 

compatible reader                                                      <- found that reader was compatible

Processing HEARTBEAT, first(0,1) last(0,1)
UDP Sending to : 0x....D00A                              <--10.208.....

UDP wrote: -1 bytes to 7410/ad0xxxx.0.0.0
Error sending: Msg:errno = 0x33                              <-- (ENETUNREACH).

And it doesnt try on the expected @ i.e. 192.168.1.1

I am bit lost with all the logs displayed and doesn't understand why it isnt working.
If someone has a clue.

Best Regards,

Rodolf

Top
Thu, 08/29/2013 - 06:25
Rodolf
Offline
Last seen: 10 years 7 months ago
Joined: 08/28/2013
Posts: 66

Is there a guide to understand better the logs ?

Top
Tue, 09/03/2013 - 15:08
edward
Offline
Last seen: 6 years 8 months ago
Joined: 01/17/2013
Posts: 22

Hi Rodolf,

By configuring your Windows "Local Area Connection" with two addresses (10.208.*.* and 192.168.1.1), and by setting udp_property->allow_interface to "Local Area Connection," your Windows Micro application will announce itself over discovery as being reachable over both 10.208.*.8 and 192.168.1.1.  Thus, your VxWorks Micro application tries sending to both of those addresses, as shown in your logs ("UDP Sending to: 0x72AD00A" and "UDP Sending to: 0x101A8C0").  

If you want communication to your Windows Micro application to use only 192.168.1.1, additional configuration can be done to set the enabled transports for user traffic and meta (discovery) traffic to that interface: DDS_DomainParticipantQos.user_traffic.enabled_transports and DDS_DomainParticpantQos.discovery.enabled_transports.  These can be configured in the following way (note: example code is untested, and includes multicast peer and loopback addresses):

/* dp_qos is struct DDS_DomainParticipantQos */
 
/* Discovery enabled_transports*/
DDS_StringSeq_set_maximum(&dp_qos.discovery.enabled_transports, 3);
DDS_StringSeq_set_length(&dp_qos.discovery.enabled_transports, 3);

*DDS_StringSeq_get_reference(&dp_qos.discovery.enabled_transports, 0) = 
    DDS_String_dup("_udp://239.255.0.1"); /* well-known multicast peer addr */ 

*DDS_StringSeq_get_reference(&dp_qos.discovery.enabled_transports, 1) = 
     DDS_String_dup("_udp://192.168.1.1"); /* specific addr*/ 

*DDS_StringSeq_get_reference(&dp_qos.discovery.enabled_transports, 2) = 
     DDS_String_dup("_udp://127.0.0.1");     /* loopback addr */

/* User enabled_transports*/
DDS_StringSeq_set_maximum(&dp_qos.user_traffic.enabled_transports, 3);
DDS_StringSeq_set_length(&dp_qos.user_traffic.enabled_transports, 3);

*DDS_StringSeq_get_reference(&dp_qos.user_traffic.enabled_transports, 0) = 
     DDS_String_dup("_udp://192.168.1.1"); /* specific addr */ 

*DDS_StringSeq_get_reference(&dp_qos.user_traffic.enabled_transports, 1) = 
     DDS_String_dup("_udp://127.0.0.1"); /* loopback */ 

*DDS_StringSeq_get_reference(&dp_qos.user_traffic.enabled_transports, 2) = 
     DDS_String_dup("_intra://");     /* intra-participant transport */

Finally, it is unexpected that the last "UDP wrote: -1 bytes to 7410/ad0xxxx.0.0.0" in your log, a couple lines after "Processing HEARTBEAT, first(0,1) last(0,1)," only sent to 10.208.*.*, and not 192.168.1.1, because the first line in your log showed the successful send to 192.168.1.1.  Can you review your logs for other any other occurences of "UDP Sending to : 0x101A8C0"?  Both discovery and user traffic should be sent to that address.       

Regards,

Edward

Edward Huang
Principal Software Engineer
RTI

 

 

Top
Mon, 09/16/2013 - 04:59
Rodolf
Offline
Last seen: 10 years 7 months ago
Joined: 08/28/2013
Posts: 66

Hi Edward,

thanks for your answer. Sorry to reply so late.


With route print command, i see that IPs 192.168.* go through interface 10.208.*
So i correct that and know everything is ok with 192.168.1.10 <-> 192.168.1.1
Best Regards,

Rodolf


 

Top