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. 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 any ideas? Regards, Leo A Dimecres 14 Novembre 2007, M. Koehrer va escriure: > Hi Leo, > > another thing comes into my mind. > The e1000 is fairly slow in detecting the line state (100/1000 Mbit, > half/full duplex). Thus, give it about three seconds after rtifconfig > before you continue. > > sudo mknod /dev/rtnet c 10 240; > sudo insmod modules/rtnet.ko; > sudo insmod modules/rtipv4.ko; > sudo insmod modules/rtpacket.ko; > sudo insmod modules/rt_e1000.ko; > sudo insmod modules/rt_loopback.ko; > sudo ./sbin/rtifconfig rtlo up 127.0.0.1 > sudo ./sbin/rtifconfig rteth0 up 10.0.0.1 netmask 255.255.255.0; > sleep 3 # NEW > for((i=0;i<5;i++)); do > ./sbin/rtroute solicit 10.0.0.$i dev rteth0 > done > sudo ./sbin/rtroute > > Maybe that helps... > > Regards > > Mathias > > > > One more thing, > > > > > > can you place a "sleep 1" before you do your final "rtroute" call to > > > display the routing information? rtroute solicit does not wait for any > > > response, it just sends out the ARP request messages. If you have a > > > very fast PC it might be that the ARP responses from your connected > > > device > > > > have > > > > > not been received yet when you do your final "rtroute" call. > > > > I can put it, but I cal rtroute many times after the script initialize > > the rtnet with the same behaviour. > > > > > What does "dmesg" tell you? > > > > a lot of things ;-) > > > > *** RTnet 0.9.10 - built on Nov 13 2007 17:40:50 *** > > > > RTnet: initialising real-time networking > > Intel(R) PRO/1000 Network Driver - version 7.1.9 > > Copyright (c) 1999-2006 Intel Corporation. > > PCI: Setting latency timer of device 0000:02:00.0 to 64 > > e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) > > 00:1b:21:05:0c:fc > > RTnet: registered rteth0 > > e1000: rteth0: e1000_probe: Intel(R) PRO/1000 Network Connection > > PCI: Setting latency timer of device 0000:03:00.0 to 64 > > e1000: 0000:03:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) > > 00:1b:21:05:0c:b6 > > RTnet: registered rteth1 > > e1000: rteth1: e1000_probe: Intel(R) PRO/1000 Network Connection > > e1000: rteth0: e1000_clean_tx_irq: Detected Tx Unit Hang > > Tx Queue <0> > > TDH <0> > > TDT <4> > > next_to_use <4> > > next_to_clean <0> > > buffer_info[next_to_clean] > > time_stamp <10007d40c> > > next_to_watch <0> > > jiffies <10007d506> > > next_to_watch.status <0> > > e1000: rteth0: e1000_clean_tx_irq: Detected Tx Unit Hang > > Tx Queue <0> > > TDH <0> > > TDT <4> > > next_to_use <4> > > next_to_clean <0> > > buffer_info[next_to_clean] > > time_stamp <10007d71a> > > next_to_watch <0> > > jiffies <10007d902> > > next_to_watch.status <0> > > e1000: rteth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex > > e1000: rteth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex > > > > > > and the rtroute > > > > Host Routing Table > > Hash Destination HW Address Device > > 02 10.0.1.2 00:1B:21:05:0C:B6 rteth1 > > 02 10.0.0.2 00:1B:21:05:0C:FC 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 > > > > > > Also I have found an strange trouble, and I don't know if it's > > significantly > > > > or not. With this configuration, I can make a ping to another box (and > > iMAc) > > > > and got response. Changing the cable the iMac can do a ping to the > > controller > > (same network config) but I (with rtnet) couldn't make a pint to the > > controller .... > > > > Any idea? > > > > Regards, > > > > Leo > > > > > Regards > > > > > > Mathias > > > > > > > Hi Leo, > > > > > > > > what happens if you do not use "rtlo" at all? > > > > I think it is not required if you want to communicate via rteth0 > > > > only. However, it is strange how it behaves... > > > > > > > > Regards > > > > > > > > Mathias > > > > > > > > > Hi, > > > > > > > > > > I know that this issue have been treated before but I'm having a > > > > > trouble > > > > > > > > and > > > > > > > > > I > > > > > don't know how to solve. I have a box with a xenomai-2.6.23 with > > > > > rtnet-trunk. > > > > > I have one network card that I want to use in rtnet (rteth0). I > > > > > don't > > > > > > > > want > > > > > > > > > to > > > > > use tdma. I have this script to load rtnet: > > > > ---------------------------------------------------------------------- > > > > > > > #!/bin/sh > > > > > sudo mknod /dev/rtnet c 10 240; > > > > > sudo insmod modules/rtnet.ko; > > > > > sudo insmod modules/rtipv4.ko; > > > > > sudo insmod modules/rtpacket.ko; > > > > > sudo insmod modules/rt_e1000.ko; > > > > > sudo insmod modules/rt_loopback.ko; > > > > > sudo ./sbin/rtifconfig rtlo up 127.0.0.1 > > > > > sudo ./sbin/rtifconfig rteth0 up 10.0.0.1 netmask 255.255.255.0; > > > > > for((i=0;i<5;i++)); do > > > > > ./sbin/rtroute solicit 10.0.0.$i dev rteth0 > > > > > done > > > > > sudo ./sbin/rtroute > > > > ---------------------------------------------------------------------- > > > > > > > I cannot understand why, when I run the rtroute at the end, I got > > > > this: > > > > > Host Routing Table > > > > > Hash Destination HW Address Device > > > > > 00 0.0.0.0 00:00:00:00:00:00 rtlo > > > > > 01 10.0.0.1 00:00:00:00:00:00 rtlo > > > > > 01 127.0.0.1 00:00:00:00:00:00 rtlo > > > > > 3F 10.0.0.255 FF:FF:FF:FF:FF:FF rteth0 > > > > > > > > > > the second entry.... > > > > > > > > > > I don't have assigned that 10.0.0.1 to rtlo. I have assigned it to > > > > > rteth0 and > > > > > the routes attached to it. So, I cannot make a simple ping to > > > > 10.0.0.2, > > > > > > > I > > > > > > > > > > got: > > > > > $ sudo sbin/rtping 10.0.0.2 > > > > > Real-time PING 10.0.0.2 56(84) bytes of data. > > > > > ioctl: No route to host > > > > > > > > > > however I must do it explicit: > > > > > sudo ./sbin/rtroute add 10.0.0.2 00:1B:21:05:0C:B6 dev rteth0 > > > > > > > > > > then > > > > > Host Routing Table > > > > > Hash Destination HW Address Device > > > > > 00 0.0.0.0 00:00:00:00:00:00 rtlo > > > > > 01 10.0.0.1 00:00:00:00:00:00 rtlo > > > > > 01 127.0.0.1 00:00:00:00:00:00 rtlo > > > > > 02 10.0.0.2 00:1B:21:05:0C:B6 rteth0 > > > > > 3F 10.0.0.255 FF:FF:FF:FF:FF:FF rteth0 > > > > > > > > > > en then I can do a rtping ... > > > > > > > > > > no success because I think that my vxworks controller is > > > > > missconfigured, > > > > > > > > but > > > > > > > > > I > > > > > got: > > > > > > > > > > sudo ./sbin/rtping 10.0.0.2 > > > > > Real-time PING 10.0.0.2 56(84) bytes of data. > > > > > > > > > > and the leds of the card are blinking > > > > > > > > > > someone can tell me why this behaviour? I have read the readmes but > > > > or > > > > > > > I don't > > > > > understand then, but I don't find my mistake. > > > > > > > > > > Regards, > > > > > > > > > > Leo > > > > > > > > -- > > > > Mathias Koehrer > > > > [EMAIL PROTECTED] > > > > > > > > > > > > Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + > > > > telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT FÜR > > > > ALLE > > > > NEUEINSTEIGER > > > > > > Jetzt bei Arcor: günstig und schnell mit DSL - das > > > > All-Inclusive-Paket für clevere Doppel-Sparer, nur 29,95 inkl. > > > > DSL- und > > > > ISDN-Grundgebühr! > > > > > > http://www.arcor.de/rd/emf-dsl-2 > > > > ------------------------------------------------------------------------- > > > > > > 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 > > > > ------------------------------------------------------------------------- > > 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 ------------------------------------------------------------------------- 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
