Leopold Palomo-Avellaneda wrote: > > > > > Hi Mathias, > > > > > > > > > > I got some differences. The route table seems better: > > > > > > > > > > Host Routing Table > > > > > Hash Destination HW Address Device > > > > > 00 0.0.0.0 00:00:00:00:00:00 rtlo > > > > > 01 10.0.1.1 00:1B:21:05:0C:B6 rteth0 > > > > > 01 10.0.0.1 00:1B:21:05:0C:FC rteth1 > > > > > 01 127.0.0.1 00:00:00:00:00:00 rtlo > > > > > 02 10.0.1.2 00:1B:21:05:0C:B6 rteth1 > > > > > 02 10.0.0.2 00:17:F2:26:BC:1C rteth0 > > > > > 03 10.0.0.3 00:17:F2:26:BC:1C rteth0 > > > > > 3F 10.0.1.255 FF:FF:FF:FF:FF:FF rteth1 > > > > > 3F 10.0.0.255 FF:FF:FF:FF:FF:FF rteth0 > > > > > > > > > > > > > > > no entry from 10.0.0.1 to the loopback device. > > > > > > > > That's because of your rtroute solicit loop: You are requesting also > > > > 10.0.0.1 to be resolved over rteth0, thus the entry for rtlo gets > > > > deleted while no one answers on your IP on the cable. > > > > > > ok, but the wait of 3 seconds has been important because the table > route > > > is > > > different. Now is "correct" I think. > > > > I didn't followed this thread until now, but I think you are using e1000 > > and you need an delay to get it working?! Then check this out: > > http://www.xenomai.org/index.php/RTnet:rt_e1000 > > well, I didn't see it before, I'm sorry :-( however I think that I was > using > rtnet trunk, not 0.9.9 ... but maybe I was confused.
I checked the SVN version and the patch is applied. Maybe you are using an old RTnet version (0.9.9). > > > > > However I'm figthing to some bizarre problem. > > > > > Scenario > > > > > - one box with rtnet, one imac box and one robot controller > > > > > - rtnet 10.0.0.1; imac 10.0.0.3; robot 10.0.0.2 > > > > > - connect the cable from rtnet to imac and can ping > > > > > ping 10.0.0.1 --> 10.0.0.3 no problem > > > > > > > > > > - connect the cable from the robot to the imac and can ping > > > > > ping 10.0.0.3 --> 10.0.0.2 no problem > > > > > > > > > > - connect the cable from the robot to the rtnet and no ping > > > > > ping 10.0.0.1 --> 10.0.0.2 problem, NO ping > > > > > > > > Again, use a packet sniffer to find out what is on the wire and what > is > > > > missing. > > > > > > packet sniffer .... Jan, I have one cable from one box to the other > > > directly > > > (crosscable .... is possible that this card has something about if and > > > make > > > some trouble with the controller card?). > > > Are you saying that I unplug the cable and put it in a hub, and > another > > > cable > > > to the hub with a sniffer to listen the transmission? because if not, > I > > > don't > > > know how to do it .. > > > > Just install wireshark (with RTcap enabled and started) and start > sniffing > > on your boxes. Of course using a hub is also possible, even a better > idea, > > but if you don't have this hardware available, sniffing on both boxes > with > > wireshark would be a good start. > > Ok, I can sniff the rtnet box, but not the robot (vxworks) box. I can > install > wireshark and use rtcap, but really, I'm sorry I'm not an expert network > guy, > what do I have to see? If you ping from rtnet box, you should capture those frames sent by your box in wireshark. If not, you know that sending the ping request already fails. If you see those frames, but not replys, you know that your vxworks box isn't answering. If you also see these reply frames then your network works at all, but maybe frames are corrupt. (Check the frames in wireshark) Karl -- von Karl Reichert Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ RTnet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-users
