On Wed, August 8, 2007 15:06, Jan Kiszka wrote:
>>>> trying to send data via rtnet without ip on raw socket I have a
>>>> problem.
>>>> Using the native API it doesn't work at all, using the posix API it
>>>> works
>>>> exactly once.
>>> If your native example doesn't create a real-time context for the
>>> sender
>>> (rt_task_shadow etc.), that would be expected: -ENOSYS. The POSIX skin
>>> does so automatically for the main thread, thus sending works in
>>> principle.
>> Ah ok, I overlooked that.
>>>> Since I tried everything I tried to rewrite the raw-ethernet example
>>>> in
>>>> my
>>>> project (my source code is attached). The first call of that program
>>>> sends
>>>> the buffer as it should (checking via wireshark). All further calls do
>>>> not
>>>> send anything. All functions return without any error, send function
>>>> returns with 36, the amount of bytes to be sent.
>>>> I have no more idea where my mistake is.
>>>> the raw-ethernet example works fine.
>>>> sorry for chatoical code, it changed a lot of time for testing
>>>> purpose.
>>> What is your setup? TDMA or plain RTnet? What happens when you issue
>>> those frames over rtlo? I only have a virtual box at hand right now,
>>> but
>>> the loopback path works fine for me with your code (with some additions
>>> to make it compile): on each invocation of the program, RTcap collects
>>> one frame on rtlo.
>> It's TDMA...attached my rtnet start script. In rtlo it's exactly the
>> same,
>> the firt invocation creates a frame on rtlo, the further ones not.
> So TDMA/RTmac is not involved here, as rtlo is free of this. Also, the
> NIC driver or the hardware cannot make a difference.
>> What additions to compile did you do, except includes and constants.
> Only includes and constants:
> #include <stdio.h>
> #include <signal.h>
> #include <sys/socket.h>
> #include <sys/mman.h>
> #include <string.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <errno.h>
> #include <netpacket/packet.h>
>
> #include <net/ethernet.h>
>
> #include <sys/ioctl.h>
>
> #include <net/if.h>
>
> #include <arpa/inet.h>
>
> #define MAXNETWORKFRAMESIZE 1400
> #define SINT16 short
> #define ETH_TYPE_RTDATA 0x4567
> #define NETWORK_DEVICE "rtlo"
> #define ETH_PROTOCOL 0x4567
> #define UINT8 unsigned char
> void catch_signal(int s) { }
> And then:
> # gcc -o <target> source.c -Wall \
> `.../xeno-config --posix-ldflags --posix-cflags`
> Note that I checked over Xenomai 2.4-rc1 which has different
> device/socket cleanup code. But I don't think this should make a
> difference, because a stalled socket should cause visible errors on the
> second invocation. Still, what is the state of
> /proc/xenomai/rtdm/open_fildes after the first run?
> Well, then low-level debugging would be next: You could start with
> taking an I-pipe trace by putting xntrace_user_freeze(0, 0) right before
> the return of main(). You will also need "#include <nucleus/trace.h>"
> then. The tracer (with appropriately large backtrace_points, see Xenomai
> homepage) should show what kernel functions were called around send()
> and then close(). May give some hints, specifically when comparing run
> #1 and #2. You are welcome to post the traces as well (compressed or
> privately).
I tried it with native API and rt_task_shadow etc....and it works. Since
I'm running out of time, I will use the native API, which was my first
intend anyway.
If it's important for you, I could do those tests after I finished my
project (in september there will be time :) ). If not, I will leave it as
it is.
Tx and greets,
Nadym
-------------------------------------------------------------------------
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
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
