> > Thank you Andreas and Christophe for helping resolve the rtroute issue.
No problem. Just a remark: I believe this mailing list doesn't like top-posting... > > 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 10.0.0.2 56(84) bytes of > data". > > Perhaps related, the receiver side (@10.0.0.2) 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 10.0.0.5 - 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?? ?10.0.0.2 ??? ?5C:F9:DD:74:9C:27?? ?rteth0 - local > Xenomai/RTnet NIC > 05?? ?10.0.0.5 ??? ?D4:BE:D9:1F:88:C2?? ?rteth0 - remote Linux > 07?? ?192.168.1.71 ?? ?98:DE:D0:03:80:CA?? ?rteth0 - local 2nd NIC > 3F?? ?10.255.255.255?? ?FF:FF:FF:FF:FF:FF?? ?rteth0 > > # ./rtping 10.0.0.2/ - never returns/ > Real-time PING 10.0.0.2 56(84) bytes of data. > ^C > --- 10.0.0.2 rtping statistics --- > 3 packets transmitted, 0 received, 100% packet loss > worst case rtt = 0.0 us > > # ./rtping 10.0.0.5/ - and 10.0.0.5 can ping successfully Xenomai/RTnet/ > Real-time PING 10.0.0.5 56(84) bytes of data. > 64 bytes from 10.0.0.5: icmp_seq=1 time=494.3 us > 64 bytes from 10.0.0.5: icmp_seq=2 time=442.9 us > 64 bytes from 10.0.0.5: icmp_seq=3 time=600.4 us > ^C > --- 10.0.0.5 rtping statistics --- > 3 packets transmitted, 3 received, 0% packet loss > worst case rtt = 600.4 us It's good that rtping to 10.0.0.5 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 as 10.0.0.1 - there are 3 other peers in the network, 10.0.0.2, 10.0.0.5, and 192.168.1.71 - 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. A. [1] https://linuxexplore.com/2012/06/07/use-tcpdump-to-capture-in-a-pcap-file-wireshark-dump/ [2] http://www.binarytides.com/programming-udp-sockets-c-linux/ [3] # StartScript #!/bin/sh idx=0; while true; do echo hahu${idx} | socat - UDP:192.168.3.3:8888; idx=$((idx+1)); done exit 0 # EndScript _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
