Nadym Salem wrote: > On Wed, August 8, 2007 13:17, 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).
Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
