[Xenomai] rtnet/xenomai-3.0.1+3.18.20kernel: tdma & nomac issue

[Xenomai] rtnet/xenomai-3.0.1+3.18.20kernel: tdma & nomac issue

[Thierry Grandpierre]

Dear all,

I spent a week testing and browsing carefully the web but  didn't find 
any answer to my problems, so I am writing here..

1) RTNET/TDMA : I am unsuccessfully  trying to run rtnet/xenomai 3 on 2 
virtual machines : a VM as master and a VM as slave. Synchro frames are 
sent by the master and received on the slave machine (seen with 
wireshark on the rteth0 of each machine) but slave never answer. Both 
machine are VMs connected by a  VM to VM private network  (VMnet0 in 
VMware)

Rtnet on the slave machine is waiting with message :
     /usr/xenomai/sbin/rtcfg rteth0 add 10.0.0.2 -stage1 -
     Waiting for all slaves.../usr/xenomai/sbin/rtcfg rteth0 wait"

Rtnet on the master machine is also hanging with message
   /usr/xenomai/sbin/rtifconfig rteth0 up 10.0.0.2
   Stage 1: searching for master...

I think rtnet on the slave machine doesn't see/understand the sync 
frames. Below all details are given.

2)RTNET/NOMAC:
When trying nomac, once everything is configured, I'm getting " ioctl: 
Resource temporarily unavailable" when pinging. Details are also given 
at the end.

Many thank for your help or pointer to look for.
Regards,
Thierry G.

PS : I know that using rtnet/tdma on virtual machines shouldn't work 
since they are not real time and consequently impossible to synchronize 
in a slot, but they should at first be able to discover mutually during 
the init process of rtnet ?
Moreover I want to experiment with udp/nomac after that (see 2nd part of 
this mail where nomac doesn't work either).


Here are the details :
====================RTNET/TDMA=====================
1) ubuntu:~$ uname -a
Linux ubuntu 3.18.20 #1 SMP Wed Feb 24 09:41:38 PST 2016 x86_64 x86_64 
x86_64 GNU/Linux
(I used a VM build from a Ubuntu 15.04, 64 bits but I changed the 
default  3.19.0.15 kernel to 3.18.20 to be compatible with Ipipe)
2) ipipe-core-3.18.20-x86-4.patch
3) Xenomai-3.0.1
4) /usr/xenomai/etc/rtnet.conf is only modified for rt_e1000 support and 
only 1 slave

Then I  run :
ifconfig eth0 down
rmmod e1000
modprobe rt_e1000 (need to to rmmod/modprobe twice in order to be catch 
by the PCI ethernet card in lspci -k)
then I get : spci -k :
     02:01.0 Ethernet controller: Intel Corporation 82545EM Gigabit 
Ethernet Controller (Copper) (rev 01)
     Subsystem: VMware PRO/1000 MT Single Port Adapter
     Kernel driver in use: rt_e1000

Then I  started rtnet :
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtnet -v start
[sudo] password for esiee:
Turning on verbose mode
/usr/xenomai/sbin/rtifconfig rtlo up 127.0.0.1
/usr/xenomai/sbin/rtcfg rteth0 server
/usr/xenomai/sbin/rtifconfig rteth0 up 10.0.0.1
/usr/xenomai/sbin/tdmacfg rteth0 master 5000
/usr/xenomai/sbin/tdmacfg rteth0 slot 0 0
/usr/xenomai/sbin/rtcfg rteth0 add 10.0.0.2 -stage1 -
Waiting for all slaves.../usr/xenomai/sbin/rtcfg rteth0 wait 
<====================doesn't go further

On this master machine, wireshark show emitted sync frame :
100    0.494738000    Vmware_cc:8c:1b    Broadcast    TDMA    42 
Synchronisation (several time per second)

Now the slave side :
---------------------------
this VM is a clone of the master.
I just changed rtnet.conf : ethernet driver, slave mode, IP address
Then I unload the linux ethernet driver, load the real time one (same 
way as the master)
and ran rtnet:
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtnet -v start
Turning on verbose mode
/usr/xenomai/sbin/rtifconfig rtlo up 127.0.0.1
/usr/xenomai/sbin/tdmacfg rteth0 slave
/usr/xenomai/sbin/rtifconfig rteth0 up 10.0.0.2
Stage 1: searching for master...   <====================doesn't go further

and wireshark capture on this slave gave :
204    0.484035000    Vmware_cc:8c:1b    Broadcast    TDMA    64 
Synchronisation (several time per second)

dmesg on both machine doesn't give any error message :
a)dmesg on master:
   [  271.011125] Intel(R) PRO/1000 Network Driver - version 7.1.9
   [  271.011129] Copyright (c) 1999-2006 Intel Corporation.
   [  271.330610] e1000: 0000:02:01.0: e1000_probe: (PCI:66MHz:32-bit) 
00:0c:29:cc:8c:1b
   [  271.368979] RTnet: registered rteth0
   [  271.368982] e1000: rteth0: e1000_probe: Intel(R) PRO/1000 Network 
Connection
   [  332.364777] initializing loopback...
   [  332.364785] RTnet: registered rtlo
   [  332.373486] RTcap: real-time capturing interface
   [  332.509475] RTcfg: init real-time configuration distribution protocol
   [  332.545567] RTmac: init realtime media access control
   [  332.565151] RTmac/TDMA: init time division multiple access control 
mechanism
   [  332.572842] e1000: rteth0: e1000_watchdog: NIC Link is Up 1000 
Mbps Full Duplex
   [  373.353682] Bluetooth: Core ver 2.19
   [  373.353829] NET: Registered protocol family 31
   [  373.353830] Bluetooth: HCI device and connection manager initialized
   [  373.353836] Bluetooth: HCI socket layer initialized
   [  373.353838] Bluetooth: L2CAP socket layer initialized
   [  373.353845] Bluetooth: SCO socket layer initialized
   [  373.422197] Netfilter messages via NETLINK v0.30.
   [  377.406595] device rteth0 entered promiscuous mode
   [  386.228459] device rteth0 left promiscuous mode

b)dmesg on the slave :
   [   76.935549] Intel(R) PRO/1000 Network Driver - version 7.1.9
   [   76.935553] Copyright (c) 1999-2006 Intel Corporation.
   [   77.259212] e1000: 0000:02:01.0: e1000_probe: (PCI:66MHz:32-bit) 
00:0c:29:a5:4d:5c
   [   77.297059] RTnet: registered rteth0
   [   77.297062] e1000: rteth0: e1000_probe: Intel(R) PRO/1000 Network 
Connection
   [  155.912939] initializing loopback...
   [  155.912947] RTnet: registered rtlo
   [  155.921569] RTcap: real-time capturing interface
   [  155.999186] RTcfg: init real-time configuration distribution protocol
   [  156.014221] RTmac: init realtime media access control
   [  156.025028] RTmac/TDMA: init time division multiple access control 
mechanism
   [  156.045304] e1000: rteth0: e1000_watchdog: NIC Link is Up 1000 
Mbps Full Duplex
   [  204.929595] Bluetooth: Core ver 2.19
   [  204.930107] NET: Registered protocol family 31
   [  204.930109] Bluetooth: HCI device and connection manager initialized
   [  204.930115] Bluetooth: HCI socket layer initialized
   [  204.930116] Bluetooth: L2CAP socket layer initialized
   [  204.930121] Bluetooth: SCO socket layer initialized
   [  204.988581] Netfilter messages via NETLINK v0.30.
   [  210.730557] device rteth0 entered promiscuous mode
   [  427.270842] device rteth0 left promiscuous mode
   [  636.409601] device rteth0 entered promiscuous mode
  ==================================================================================
================================================================================== 

                                II - Issue with rtnet/nomac :
================================================================================== 

================================================================================== 


I restarted both VM, and execute the following commands on them after  :

esiee@ubuntu:~$ sudo ifconfig eth0 down
esiee@ubuntu:~$ sudo rmod e1000
esiee@ubuntu:~$ modprobe rt_e1000
esiee@ubuntu:~$ lspci -k <======no module attached to pci, I retry :
esiee@ubuntu:~$ rmmod rt_e1000
esiee@ubuntu:~$ modprobe rt_e1000
esiee@ubuntu:~$ lspci -k ======> this time it is attached
esiee@ubuntu:~$ sudo modprobe rtnet
esiee@ubuntu:~$ sudo modprobe rtipv4
esiee@ubuntu:~$ sudo modprobe rtudp
esiee@ubuntu:~$ sudo modprobe rtpacket
esiee@ubuntu:~$ sudo modprobe rtmac
esiee@ubuntu:~$ sudo modprobe nomac
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtifconfig rteth0 up 10.0.0.1 
netmask 255.0.0.0
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtifconfig
rteth0    Medium: Ethernet  Hardware address: 00:0C:29:CC:8C:1B
           IP address: 10.0.0.1  Broadcast address: 10.255.255.255
           UP BROADCAST RUNNING  MTU: 1500
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/nomaccfg rteth0 attach
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtroute solicit 10.0.0.2 dev rteth0
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtroute
     Host Routing Table
     Hash    Destination    HW Address        Device
     3F    10.255.255.255    FF:FF:FF:FF:FF:FF    rteth0 ========> no 
route discovered
sudo /usr/xenomai/sbin/rtroute add 10.0.0.2 00:0C:29:A5:4D:5C dev rteth0 
==> I add the route manually
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtroute
Host Routing Table
Hash    Destination    HW Address        Device
02    10.0.0.2      00:0C:29:A5:4D:5C    rteth0
3F    10.255.255.255    FF:FF:FF:FF:FF:FF    rteth0

================
on the second VM :
================
same commands, until :
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtifconfig
rteth0    Medium: Ethernet  Hardware address: 00:0C:29:A5:4D:5C
           IP address: 10.0.0.2  Broadcast address: 10.0.0.255
           UP BROADCAST RUNNING  MTU: 1500
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/nomaccfg rteth0 attach
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtroute solicit 10.0.0.1 dev rteth0
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtroute
Host Routing Table
Hash    Destination    HW Address        Device
3F    10.0.0.255    FF:FF:FF:FF:FF:FF    rteth0 ========> no route 
discovered
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtroute add 10.0.0.1 
00:0C:29:CC:8C:1B dev rteth0
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtroute
Host Routing Table
Hash    Destination    HW Address        Device
01    10.0.0.1      00:0C:29:CC:8C:1B    rteth0
3F    10.0.0.255    FF:FF:FF:FF:FF:FF    rteth0


Once configuration done, VM are still unable to ping themselves :
1) on first VM (IP= 10.0.0.1)
     esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtping 10.0.0.2
     Real-time PING 10.0.0.2 56(84) bytes of data.
     ioctl: Resource temporarily unavailable


2) on second VM (IP = 10.0.0.2)
     esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtping 10.0.0.1
     Real-time PING 10.0.0.1 56(84) bytes of data.
     ioctl: Resource temporarily unavailable

  I am also unable to use wireshark since rteth0  is not listed..
Does I need to load rtcfg ?

Many thanks again
Thierry

Re: [Xenomai] rtnet/xenomai-3.0.1+3.18.20kernel: tdma & nomac issue

[Gilles Chanteperdrix]

On Sun, Mar 06, 2016 at 03:36:49PM +0100, Thierry Grandpierre wrote:
> Dear all,
> 
> I spent a week testing and browsing carefully the web but  didn't find 
> any answer to my problems, so I am writing here..
> 
> 1) RTNET/TDMA : I am unsuccessfully  trying to run rtnet/xenomai 3 on 2 
> virtual machines : a VM as master and a VM as slave. Synchro frames are 
> sent by the master and received on the slave machine (seen with 
> wireshark on the rteth0 of each machine) but slave never answer. Both 
> machine are VMs connected by a  VM to VM private network  (VMnet0 in 
> VMware)

Are you sure the network emulation you use transmit all kinds of
packets? In qemu, for instance, the default network emulation is not
able to transmit icmp packets and probably not rtcfg packets (they
use a custom ethertype). I have tested rtcfg with Xenomai 3.0.1 and
it worked. I have not tried transmitting files though, just used it
as a kind of DHCP.

> 
> Rtnet on the slave machine is waiting with message :
>      /usr/xenomai/sbin/rtcfg rteth0 add 10.0.0.2 -stage1 -
>      Waiting for all slaves.../usr/xenomai/sbin/rtcfg rteth0 wait"
> 
> Rtnet on the master machine is also hanging with message
>    /usr/xenomai/sbin/rtifconfig rteth0 up 10.0.0.2
>    Stage 1: searching for master...
> 
> I think rtnet on the slave machine doesn't see/understand the sync 
> frames. Below all details are given.
> 
> 2)RTNET/NOMAC:
> When trying nomac, once everything is configured, I'm getting " ioctl: 
> Resource temporarily unavailable" when pinging. Details are also given 
> at the end.

This probably means that the network is not up, but I am a little
confused, as I thought I added this check after the 3.0.1 release.
Are you using the 3.0.1 release, or the current git?
Anyway, if that is the case, when you run rtifconfig you should not
see the RUNNING flag. You have to wait for the network to be up and
running before being able to actually send packets.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] rtnet/xenomai-3.0.1+3.18.20kernel: tdma & nomac issue

[Thierry Grandpierre]

Thanks for a so fast answer!


Le 06/03/2016 16:08, Gilles Chanteperdrix a écrit :
> On Sun, Mar 06, 2016 at 03:36:49PM +0100, Thierry Grandpierre wrote:
>> 1) RTNET/TDMA : I am unsuccessfully  trying to run rtnet/xenomai 3 on 2
>> virtual machines : a VM as master and a VM as slave. Synchro frames are
>> sent by the master and received on the slave machine (seen with
>> wireshark on the rteth0 of each machine) but slave never answer. Both
>> machine are VMs connected by a  VM to VM private network  (VMnet0 in
>> VMware)
> Are you sure the network emulation you use transmit all kinds of
> packets? In qemu, for instance, the default network emulation is not
> able to transmit icmp packets and probably not rtcfg packets (they
> use a custom ethertype). I have tested rtcfg with Xenomai 3.0.1 and
> it worked. I have not tried transmitting files though, just used it
> as a kind of DHCP.
I use VMware Workstation 11.0.0 build-2305329 and setup vm0 as a 
Host-only (connect VMs internally in a private network) without 
connecting any host virtual adapter to this network neither DHCP.

As explained, using wireshark on the second VM I saw the sync frame sent 
by the first VM so I think that yes the packets seems to be transmitted :
wireshark on the master : 100    0.494738000    Vmware_cc:8c:1b 
Broadcast    TDMA    42 Synchronisation
wireshark on the slave : 204    0.484035000    Vmware_cc:8c:1b 
Broadcast    TDMA    64 Synchronisation

==> the strange thing is the size difference 42 on the master versus 64 
received on the slave...22 bytes difference
I will try to get more info. on that..


>
>> Rtnet on the slave machine is waiting with message :
>>       /usr/xenomai/sbin/rtcfg rteth0 add 10.0.0.2 -stage1 -
>>       Waiting for all slaves.../usr/xenomai/sbin/rtcfg rteth0 wait"
>>
>> Rtnet on the master machine is also hanging with message
>>     /usr/xenomai/sbin/rtifconfig rteth0 up 10.0.0.2
>>     Stage 1: searching for master...
>>
>> I think rtnet on the slave machine doesn't see/understand the sync
>> frames. Below all details are given.
>>
>> 2)RTNET/NOMAC:
>> When trying nomac, once everything is configured, I'm getting " ioctl:
>> Resource temporarily unavailable" when pinging. Details are also given
>> at the end.
> This probably means that the network is not up, but I am a little
> confused, as I thought I added this check after the 3.0.1 release.
> Are you using the 3.0.1 release, or the current git?
> Anyway, if that is the case, when you run rtifconfig you should not
> see the RUNNING flag. You have to wait for the network to be up and
> running before being able to actually send packets.
>
I used the 3.0.1 release, not the git version.

How can I disable this RUNNING flag (I thought is was normal to have 
running..) ?  it never goes off by itself :-(

esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtifconfig rteth0 up
esiee@ubuntu:~$ sudo /usr/xenomai/sbin/rtifconfig rteth0
rteth0    Medium: Ethernet  Hardware address: 00:0C:29:A5:4D:5C
           IP address: 10.0.0.2  Broadcast address: 10.0.0.255
           UP BROADCAST RUNNING  MTU: 1500

Many thanks,
Thierry

Re: [Xenomai] rtnet/xenomai-3.0.1+3.18.20kernel: tdma & nomac issue

[Gilles Chanteperdrix]

On Sun, Mar 06, 2016 at 05:14:01PM +0100, Thierry Grandpierre wrote:
> Thanks for a so fast answer!
> 
> 
> Le 06/03/2016 16:08, Gilles Chanteperdrix a écrit :
> > On Sun, Mar 06, 2016 at 03:36:49PM +0100, Thierry Grandpierre wrote:
> >> 1) RTNET/TDMA : I am unsuccessfully  trying to run rtnet/xenomai 3 on 2
> >> virtual machines : a VM as master and a VM as slave. Synchro frames are
> >> sent by the master and received on the slave machine (seen with
> >> wireshark on the rteth0 of each machine) but slave never answer. Both
> >> machine are VMs connected by a  VM to VM private network  (VMnet0 in
> >> VMware)
> > Are you sure the network emulation you use transmit all kinds of
> > packets? In qemu, for instance, the default network emulation is not
> > able to transmit icmp packets and probably not rtcfg packets (they
> > use a custom ethertype). I have tested rtcfg with Xenomai 3.0.1 and
> > it worked. I have not tried transmitting files though, just used it
> > as a kind of DHCP.
> I use VMware Workstation 11.0.0 build-2305329 and setup vm0 as a 
> Host-only (connect VMs internally in a private network) without 
> connecting any host virtual adapter to this network neither DHCP.
> 
> As explained, using wireshark on the second VM I saw the sync frame sent 
> by the first VM so I think that yes the packets seems to be transmitted :
> wireshark on the master : 100    0.494738000    Vmware_cc:8c:1b 
> Broadcast    TDMA    42 Synchronisation
> wireshark on the slave : 204    0.484035000    Vmware_cc:8c:1b 
> Broadcast    TDMA    64 Synchronisation
> 
> ==> the strange thing is the size difference 42 on the master versus 64 
> received on the slave...22 bytes difference
> I will try to get more info. on that..

An ethernet packet is forbidden to occupy less than 64 bytes, so the
sender pads the packet to 64 bytes before sending it.

> 
> 
> >
> >> Rtnet on the slave machine is waiting with message :
> >>       /usr/xenomai/sbin/rtcfg rteth0 add 10.0.0.2 -stage1 -
> >>       Waiting for all slaves.../usr/xenomai/sbin/rtcfg rteth0 wait"
> >>
> >> Rtnet on the master machine is also hanging with message
> >>     /usr/xenomai/sbin/rtifconfig rteth0 up 10.0.0.2
> >>     Stage 1: searching for master...
> >>
> >> I think rtnet on the slave machine doesn't see/understand the sync
> >> frames. Below all details are given.
> >>
> >> 2)RTNET/NOMAC:
> >> When trying nomac, once everything is configured, I'm getting " ioctl:
> >> Resource temporarily unavailable" when pinging. Details are also given
> >> at the end.
> > This probably means that the network is not up, but I am a little
> > confused, as I thought I added this check after the 3.0.1 release.
> > Are you using the 3.0.1 release, or the current git?
> > Anyway, if that is the case, when you run rtifconfig you should not
> > see the RUNNING flag. You have to wait for the network to be up and
> > running before being able to actually send packets.
> >
> I used the 3.0.1 release, not the git version.
> 
> How can I disable this RUNNING flag (I thought is was normal to have 
> running..) ?  it never goes off by itself :-(

Sorry, you do not want to disable the RUNNING flag. What I meant is
that with current Xenomai 3.0 git, the flag is not set when the
network is not up, at which point sending a packet will cause
EAGAIN to be returned. When the network is up the RUNNING flag will
appear in rtifconfig output, and at that point, you can start
sending packets.

I would suggest you try Xenomai 3.0 git to see if any commit since
the release fix the issue you have.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] rtnet/xenomai-3.0.1+3.18.20kernel: tdma & nomac issue

[Thierry Grandpierre]

Le 06/03/2016 17:23, Gilles Chanteperdrix a écrit :
> On Sun, Mar 06, 2016 at 05:14:01PM +0100, Thierry Grandpierre wrote:
>> Thanks for a so fast answer!
>>
>>
>> Le 06/03/2016 16:08, Gilles Chanteperdrix a écrit :
>>> On Sun, Mar 06, 2016 at 03:36:49PM +0100, Thierry Grandpierre wrote:
>>>> 1) RTNET/TDMA : I am unsuccessfully  trying to run rtnet/xenomai 3 on 2
>>>> virtual machines : a VM as master and a VM as slave. Synchro frames are
>>>> sent by the master and received on the slave machine (seen with
>>>> wireshark on the rteth0 of each machine) but slave never answer. Both
>>>> machine are VMs connected by a  VM to VM private network  (VMnet0 in
>>>> VMware)
>>> Are you sure the network emulation you use transmit all kinds of
>>> packets? In qemu, for instance, the default network emulation is not
>>> able to transmit icmp packets and probably not rtcfg packets (they
>>> use a custom ethertype). I have tested rtcfg with Xenomai 3.0.1 and
>>> it worked. I have not tried transmitting files though, just used it
>>> as a kind of DHCP.
>> I use VMware Workstation 11.0.0 build-2305329 and setup vm0 as a
>> Host-only (connect VMs internally in a private network) without
>> connecting any host virtual adapter to this network neither DHCP.
>>
>> As explained, using wireshark on the second VM I saw the sync frame sent
>> by the first VM so I think that yes the packets seems to be transmitted :
>> wireshark on the master : 100    0.494738000    Vmware_cc:8c:1b
>> Broadcast    TDMA    42 Synchronisation
>> wireshark on the slave : 204    0.484035000    Vmware_cc:8c:1b
>> Broadcast    TDMA    64 Synchronisation
>>
>> ==> the strange thing is the size difference 42 on the master versus 64
>> received on the slave...22 bytes difference
>> I will try to get more info. on that..
> An ethernet packet is forbidden to occupy less than 64 bytes, so the
> sender pads the packet to 64 bytes before sending it.

oups, forgotten that point.
  So, no problem on that side, moreover with wireshark I dumped the 
synchro frame on the master side  and on the slave side : they are 
exactly the same (just the padding bytes difference).

So, since  VMware seems to transmit correctly the custom packets, I 
don't know what to do, how to understand why the slave doesn't answer.

Here are the frames dump :
emitted by the master VM :
1 0.000000000    Vmware_cc:8c:1b    Broadcast    TDMA    64 Synchronisation
2 0.005784000    Vmware_cc:8c:1b    Broadcast    TDMA    64 Synchronisation
ffffffffffff000c29cc8c1b902100010200020100000000000114394e346a67b75e14394e346a656843
ffffffffffff000c29cc8c1b902100010200020100000000000214394e346ac0762a14394e346ab1b383
ffffffffffff000c29cc8c1b902100010200020100000000000314394e346afe538914394e346afdfec3

received by the slave VM :
1 0.000000000    Vmware_cc:8c:1b    Broadcast    TDMA    42 Synchronisation
2 0.005816000    Vmware_cc:8c:1b    Broadcast    TDMA    42 Synchronisation
3 0.009871000    Vmware_cc:8c:1b    Broadcast    TDMA    42 Synchronisation
ffffffffffff000c29cc8c1b902100010200020100000000000114394e346a67b75e14394e346a65684300000000000000000000000000000000000000000000
ffffffffffff000c29cc8c1b902100010200020100000000000214394e346ac0762a14394e346ab1b38300000000000000000000000000000000000000000000
ffffffffffff000c29cc8c1b902100010200020100000000000314394e346afe538914394e346afdfec300000000000000000000000000000000000000000000




>>
>>>> Rtnet on the slave machine is waiting with message :
>>>>        /usr/xenomai/sbin/rtcfg rteth0 add 10.0.0.2 -stage1 -
>>>>        Waiting for all slaves.../usr/xenomai/sbin/rtcfg rteth0 wait"
>>>>
>>>> Rtnet on the master machine is also hanging with message
>>>>      /usr/xenomai/sbin/rtifconfig rteth0 up 10.0.0.2
>>>>      Stage 1: searching for master...
>>>>
>>>> I think rtnet on the slave machine doesn't see/understand the sync
>>>> frames. Below all details are given.
>>>>
>>>> 2)RTNET/NOMAC:
>>>> When trying nomac, once everything is configured, I'm getting " ioctl:
>>>> Resource temporarily unavailable" when pinging. Details are also given
>>>> at the end.
>>> This probably means that the network is not up, but I am a little
>>> confused, as I thought I added this check after the 3.0.1 release.
>>> Are you using the 3.0.1 release, or the current git?
>>> Anyway, if that is the case, when you run rtifconfig you should not
>>> see the RUNNING flag. You have to wait for the network to be up and
>>> running before being able to actually send packets.
>>>
>> I used the 3.0.1 release, not the git version.
>>
>> How can I disable this RUNNING flag (I thought is was normal to have
>> running..) ?  it never goes off by itself :-(
> Sorry, you do not want to disable the RUNNING flag. What I meant is
> that with current Xenomai 3.0 git, the flag is not set when the
> network is not up, at which point sending a packet will cause
> EAGAIN to be returned. When the network is up the RUNNING flag will
> appear in rtifconfig output, and at that point, you can start
> sending packets.
>
> I would suggest you try Xenomai 3.0 git to see if any commit since
> the release fix the issue you have.
>

Ok, I have already build a VM with xenomai-3.0-rc4 & kernel 3.18.12 : is 
it a good candidate for testing ?
  (I stopped working with it because of  some issues (running rtnet I 
got "couldn't insert rtudp : operation not permitted")  and then I 
realized that it wasn't the last version. But I can re-check the problem 
if necessary)

Best regards,
Thierry

Re: [Xenomai] rtnet/xenomai-3.0.1+3.18.20kernel: tdma & nomac issue

[Gilles Chanteperdrix]

On Sun, Mar 06, 2016 at 08:33:32PM +0100, Thierry Grandpierre wrote:
> 
> 
> Le 06/03/2016 17:23, Gilles Chanteperdrix a écrit :
> > On Sun, Mar 06, 2016 at 05:14:01PM +0100, Thierry Grandpierre wrote:
> >> Thanks for a so fast answer!
> >>
> >>
> >> Le 06/03/2016 16:08, Gilles Chanteperdrix a écrit :
> >>> On Sun, Mar 06, 2016 at 03:36:49PM +0100, Thierry Grandpierre wrote:
> >>>> 1) RTNET/TDMA : I am unsuccessfully  trying to run rtnet/xenomai 3 on 2
> >>>> virtual machines : a VM as master and a VM as slave. Synchro frames are
> >>>> sent by the master and received on the slave machine (seen with
> >>>> wireshark on the rteth0 of each machine) but slave never answer. Both
> >>>> machine are VMs connected by a  VM to VM private network  (VMnet0 in
> >>>> VMware)
> >>> Are you sure the network emulation you use transmit all kinds of
> >>> packets? In qemu, for instance, the default network emulation is not
> >>> able to transmit icmp packets and probably not rtcfg packets (they
> >>> use a custom ethertype). I have tested rtcfg with Xenomai 3.0.1 and
> >>> it worked. I have not tried transmitting files though, just used it
> >>> as a kind of DHCP.
> >> I use VMware Workstation 11.0.0 build-2305329 and setup vm0 as a
> >> Host-only (connect VMs internally in a private network) without
> >> connecting any host virtual adapter to this network neither DHCP.
> >>
> >> As explained, using wireshark on the second VM I saw the sync frame sent
> >> by the first VM so I think that yes the packets seems to be transmitted :
> >> wireshark on the master : 100    0.494738000    Vmware_cc:8c:1b
> >> Broadcast    TDMA    42 Synchronisation
> >> wireshark on the slave : 204    0.484035000    Vmware_cc:8c:1b
> >> Broadcast    TDMA    64 Synchronisation
> >>
> >> ==> the strange thing is the size difference 42 on the master versus 64
> >> received on the slave...22 bytes difference
> >> I will try to get more info. on that..
> > An ethernet packet is forbidden to occupy less than 64 bytes, so the
> > sender pads the packet to 64 bytes before sending it.
> 
> oups, forgotten that point.
>   So, no problem on that side, moreover with wireshark I dumped the 
> synchro frame on the master side  and on the slave side : they are 
> exactly the same (just the padding bytes difference).
> 
> So, since  VMware seems to transmit correctly the custom packets, I 
> don't know what to do, how to understand why the slave doesn't answer.
> 
> Here are the frames dump :
> emitted by the master VM :
> 1 0.000000000    Vmware_cc:8c:1b    Broadcast    TDMA    64 Synchronisation
> 2 0.005784000    Vmware_cc:8c:1b    Broadcast    TDMA    64 Synchronisation
> ffffffffffff000c29cc8c1b902100010200020100000000000114394e346a67b75e14394e346a656843
> ffffffffffff000c29cc8c1b902100010200020100000000000214394e346ac0762a14394e346ab1b383
> ffffffffffff000c29cc8c1b902100010200020100000000000314394e346afe538914394e346afdfec3
> 
> received by the slave VM :
> 1 0.000000000    Vmware_cc:8c:1b    Broadcast    TDMA    42 Synchronisation
> 2 0.005816000    Vmware_cc:8c:1b    Broadcast    TDMA    42 Synchronisation
> 3 0.009871000    Vmware_cc:8c:1b    Broadcast    TDMA    42 Synchronisation
> ffffffffffff000c29cc8c1b902100010200020100000000000114394e346a67b75e14394e346a65684300000000000000000000000000000000000000000000
> ffffffffffff000c29cc8c1b902100010200020100000000000214394e346ac0762a14394e346ab1b38300000000000000000000000000000000000000000000
> ffffffffffff000c29cc8c1b902100010200020100000000000314394e346afe538914394e346afdfec300000000000000000000000000000000000000000000
> 
> 
> 
> 
> >>
> >>>> Rtnet on the slave machine is waiting with message :
> >>>>        /usr/xenomai/sbin/rtcfg rteth0 add 10.0.0.2 -stage1 -
> >>>>        Waiting for all slaves.../usr/xenomai/sbin/rtcfg rteth0 wait"
> >>>>
> >>>> Rtnet on the master machine is also hanging with message
> >>>>      /usr/xenomai/sbin/rtifconfig rteth0 up 10.0.0.2
> >>>>      Stage 1: searching for master...
> >>>>
> >>>> I think rtnet on the slave machine doesn't see/understand the sync
> >>>> frames. Below all details are given.
> >>>>
> >>>> 2)RTNET/NOMAC:
> >>>> When trying nomac, once everything is configured, I'm getting " ioctl:
> >>>> Resource temporarily unavailable" when pinging. Details are also given
> >>>> at the end.
> >>> This probably means that the network is not up, but I am a little
> >>> confused, as I thought I added this check after the 3.0.1 release.
> >>> Are you using the 3.0.1 release, or the current git?
> >>> Anyway, if that is the case, when you run rtifconfig you should not
> >>> see the RUNNING flag. You have to wait for the network to be up and
> >>> running before being able to actually send packets.
> >>>
> >> I used the 3.0.1 release, not the git version.
> >>
> >> How can I disable this RUNNING flag (I thought is was normal to have
> >> running..) ?  it never goes off by itself :-(
> > Sorry, you do not want to disable the RUNNING flag. What I meant is
> > that with current Xenomai 3.0 git, the flag is not set when the
> > network is not up, at which point sending a packet will cause
> > EAGAIN to be returned. When the network is up the RUNNING flag will
> > appear in rtifconfig output, and at that point, you can start
> > sending packets.
> >
> > I would suggest you try Xenomai 3.0 git to see if any commit since
> > the release fix the issue you have.
> >
> 
> Ok, I have already build a VM with xenomai-3.0-rc4 & kernel 3.18.12 : is 
> it a good candidate for testing ?
>   (I stopped working with it because of  some issues (running rtnet I 
> got "couldn't insert rtudp : operation not permitted")  and then I 
> realized that it wasn't the last version. But I can re-check the problem 
> if necessary)

No. 3.0-rc4, as the name indicates, is a release candidate for the
3.0 version so is completely outdated. What I meant is to use the
TIP of the git repository stable-3.0.x branch.

The said git is at the following address:
git://git.xenomai.org/xenomai-3.git

Before going all the way with rtcfg and rtnet start up script, I
would recommend setting up the two machines with fixed IP address
and use rtroute solicit to create the root from one machine to the
other. As long as this does not work, there is no need to go any
further.

With the current state of the git repository, you will need to wait
for RUNNING to appear in rtifconfig before sending the arp request
with rtroute solicit.

You can even setup one machine with rtnet and the other without.

-- 
					    Gilles.
https://click-hack.org