>   Thank you Andreas and Christophe for helping resolve the rtroute issue.

No problem. Just a remark: I believe this mailing list doesn't like

> The messed up routing table was likely as a result of my various attempts
> to get it working.
> Unfortunately, now that I've hopefully corrected the RTnet routing table,
> rtping hangs after printing, "Real-time PING 56(84) bytes of
> data".
> Perhaps related, the receiver side (@ of a trivial UDP
> client/server
> utility does not receive the UDP packets the server side is sending (both
> when
> sent locally to receiver (compiled and linked against cobalt), and when
> sent
> from - these I can see being sent using wireshark).
> I've only configured the rteth0 interface, not rtlo.
> # ./rtroute
> Host Routing Table
> Hash?? ?Destination?? ?HW Address?? ??? ?Device
> 02?? ? ??? ?5C:F9:DD:74:9C:27?? ?rteth0 - local
> Xenomai/RTnet NIC
> 05?? ? ??? ?D4:BE:D9:1F:88:C2?? ?rteth0 - remote Linux
> 07?? ? ?? ?98:DE:D0:03:80:CA?? ?rteth0 - local 2nd NIC
> 3F?? ? ?FF:FF:FF:FF:FF:FF?? ?rteth0
> # ./rtping - never returns/
> Real-time PING 56(84) bytes of data.
> ^C
> --- rtping statistics ---
> 3 packets transmitted, 0 received, 100% packet loss
> worst case rtt = 0.0 us
> # ./rtping - and can ping successfully Xenomai/RTnet/
> Real-time PING 56(84) bytes of data.
> 64 bytes from icmp_seq=1 time=494.3 us
> 64 bytes from icmp_seq=2 time=442.9 us
> 64 bytes from icmp_seq=3 time=600.4 us
> ^C
> --- rtping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss
> worst case rtt = 600.4 us

It's good that rtping to works. So your kernel modules should be OK.

W/r to the other questions: I'm still unclear about your network
topology. As far as I understand: - rteth0 on one peer is configured
- there are 3 other peers in the network,,, and
- all the peers are connected together via a layer2 switch

rtping hanging and not complaining about a missing route is typically
the case if the ICMP packets from rtping cannot reach the adjacent
peer, which is generally related to a network configuration issue.

Another way to debug things is to load rtcap.ko before bringing up
rteth0. Then you bring up rteth0 with rtifconfig, followed by bringing
up rteth0 with ifconfig (on the Linux side). After that you can trace
the traffic going through rteth0 using tcpdump (e.g. see [1] how to
combine tcpdump and wireshark).

I would start investigating UDP after verifying that rtping works. In
my case I could get UDP working by compiling [2] using the gcc and ld
flags provided by xeno-config (note that there is an bug in this
example: the buffer needs to be 0 termintated between recvfrom() and
sendto()). I started this UDP server on Xenomai, whereas on the peer
running Linux I used a script [3] to send/receive UDP frames.


[2] http://www.binarytides.com/programming-udp-sockets-c-linux/

# StartScript

while true;
        echo hahu${idx} | socat - UDP:;

exit 0
# EndScript

Xenomai mailing list

Reply via email to