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

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

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