RTNet and setsockopt

RTNet and setsockopt

[Per Oberg]

Dear list

I am "porting" a posix application using raw network packages to RTNet. The old code is trying to use setsockopt and ioctl. The calls I am trying to use are 

setsockopt: 
 SO_RCVTIMEO
 SO_SNDTIMEO
 SO_DONTROUTE

These return "No such device". I guess that this is because setsockopt is not rt-compatible, correct ? ( There seem to be no corresponding rt_setsockopt... )

ioctl :
 IFF_PROMISC | IFF_BROADCAST

These return "Operation not supported". 

My code works fairly well as it is, and I probably do not need SO_DONTROUTE, IFF_PROMISC, and IFF_BROADCAST with rtnet. I would, however, like to have SO_RCVTIMEO, SO_SNDTIMEO or nonblock. Do I need to use O_NONBLOCK together with send() instead or am I missing something ?

Best Regards
Per Öberg 

Re: RTNet and setsockopt

[Per Oberg]

----- Den 16 apr 2020, på kl 18:32, Lange Norbert norbert.lange@andritz.com skrev:

> Hello Per,

> setsockopt is supported by rtnet (and wrapped with the POSIX skin). That said,
> it supports very little options you are used from Linux. Do a grep -r on
> xenomais sources.
> Xenomai mostly uses ioctls for bringing up Interfaces, etc.

> There are subtile differences and limitations aswell. I am pretty sure now that
> most operations
> are behaving like you have an nonblocking filedescriptor / socket. The RT focus
> means that there
> typically is just a check if buffers are available, and no effort is made for
> waiting.
> So select will be your best friend.
> (I am just using packet sockets, but I believe it’s the same for all of them).

Thanks, I readded the list again. The reason I started looking into this is that I had issues with blocking sends. I wanted to see what happened if I pulled the plug on the ethernet and tried to recover afterwards. 

Digging around a bit is seems like I might actually have a compiler flag issue (again...). I tried compiling my network code as a shared library.

> Norbert Lange

> > -----Original Message-----
> > From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Per Oberg via
> > Xenomai
> > Sent: Donnerstag, 16. April 2020 18:08
> > To: xenomai <xenomai@xenomai.org>
> > Subject: RTNet and setsockopt

> > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> > ATTACHMENTS.


> > Dear list

> > I am "porting" a posix application using raw network packages to RTNet. The
> > old code is trying to use setsockopt and ioctl. The calls I am trying to use are

> > setsockopt:
> > SO_RCVTIMEO
> > SO_SNDTIMEO
> > SO_DONTROUTE

>> These return "No such device". I guess that this is because setsockopt is not
> > rt-
> > compatible, correct ? ( There seem to be no corresponding rt_setsockopt... )


> > ioctl :
> > IFF_PROMISC | IFF_BROADCAST

> > These return "Operation not supported".

> > My code works fairly well as it is, and I probably do not need SO_DONTROUTE,
> > IFF_PROMISC, and IFF_BROADCAST with rtnet. I would, however, like to have
> > SO_RCVTIMEO, SO_SNDTIMEO or nonblock. Do I need to use O_NONBLOCK
> > together with send() instead or am I missing something ?

> > Best Regards
> > Per Öberg

> ________________________________

> This message and any attachments are solely for the use of the intended
> recipients. They may contain privileged and/or confidential information or
> other information protected from disclosure. If you are not an intended
> recipient, you are hereby notified that you received this email in error and
> that any review, dissemination, distribution or copying of this email and any
> attachment is strictly prohibited. If you have received this email in error,
> please contact the sender and delete the message and any attachment from your
> system.

> ANDRITZ HYDRO GmbH

> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

> Firmensitz/ Registered seat: Wien

> Firmenbuchgericht/ Court of registry: Handelsgericht Wien

> Firmenbuchnummer/ Company registration: FN 61833 g

> DVR: 0605077

> UID-Nr.: ATU14756806

> Thank You
> _________

Thanks
Per Öberg

Re: RTNet and setsockopt

[Per Oberg]

----- Den 16 apr 2020, på kl 19:00, xenomai xenomai@xenomai.org skrev:
> ----- Den 16 apr 2020, på kl 18:32, Lange Norbert norbert.lange@andritz.com
> skrev:

> > Hello Per,

> > setsockopt is supported by rtnet (and wrapped with the POSIX skin). That said,
> > it supports very little options you are used from Linux. Do a grep -r on
> > xenomais sources.
> > Xenomai mostly uses ioctls for bringing up Interfaces, etc.

> > There are subtile differences and limitations aswell. I am pretty sure now that
> > most operations
> > are behaving like you have an nonblocking filedescriptor / socket. The RT focus
> > means that there
> > typically is just a check if buffers are available, and no effort is made for
> > waiting.
> > So select will be your best friend.
> > (I am just using packet sockets, but I believe it’s the same for all of them).

> Thanks, I readded the list again. The reason I started looking into this is that
> I had issues with blocking sends. I wanted to see what happened if I pulled the
> plug on the ethernet and tried to recover afterwards.

> Digging around a bit is seems like I might actually have a compiler flag issue
> (again...). I tried compiling my network code as a shared library.

Progress, i guess. It was the read that was became non blocking.

Still: I believe that "setsockopt" is missing for PF_PACKET, SOCK_RAW. I can se that it is implemented for some of the packet types but there is no reference to it in af_packet.c.

That said, I don't see how setsockopt is mapped to the different variants. I can se how recv and recfrom is mapped using the structure with the ".recvfrom = xxx" syntax but setsockopt seems to be different.

Also, when looking in the code i see that "MSG_DONTWAIT" is supported for rt_packet_recvmsg and that it sets sock->timeout to -1. So it seems a small fix to make this work, if I only knew where how setsockopt was mapped..

> > Norbert Lange

> > > -----Original Message-----
> > > From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Per Oberg via
> > > Xenomai
> > > Sent: Donnerstag, 16. April 2020 18:08
> > > To: xenomai <xenomai@xenomai.org>
> > > Subject: RTNet and setsockopt

> > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> > > ATTACHMENTS.

> > > Dear list

> > > I am "porting" a posix application using raw network packages to RTNet. The
> > > old code is trying to use setsockopt and ioctl. The calls I am trying to use are

> > > setsockopt:
> > > SO_RCVTIMEO
> > > SO_SNDTIMEO
> > > SO_DONTROUTE

> >> These return "No such device". I guess that this is because setsockopt is not
> > > rt-
> > > compatible, correct ? ( There seem to be no corresponding rt_setsockopt... )

> > > ioctl :
> > > IFF_PROMISC | IFF_BROADCAST

> > > These return "Operation not supported".

> > > My code works fairly well as it is, and I probably do not need SO_DONTROUTE,
> > > IFF_PROMISC, and IFF_BROADCAST with rtnet. I would, however, like to have
> > > SO_RCVTIMEO, SO_SNDTIMEO or nonblock. Do I need to use O_NONBLOCK
> > > together with send() instead or am I missing something ?

> > > Best Regards
> > > Per Öberg

> > ________________________________

> > This message and any attachments are solely for the use of the intended
> > recipients. They may contain privileged and/or confidential information or
> > other information protected from disclosure. If you are not an intended
> > recipient, you are hereby notified that you received this email in error and
> > that any review, dissemination, distribution or copying of this email and any
> > attachment is strictly prohibited. If you have received this email in error,
> > please contact the sender and delete the message and any attachment from your
> > system.

> > ANDRITZ HYDRO GmbH

> > Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

> > Firmensitz/ Registered seat: Wien

> > Firmenbuchgericht/ Court of registry: Handelsgericht Wien

> > Firmenbuchnummer/ Company registration: FN 61833 g

> > DVR: 0605077

> > UID-Nr.: ATU14756806

> > Thank You
> > _________

> Thanks
> Per Öberg

Thanks
Per Öberg 

Re: RTNet and setsockopt

[Jan Kiszka]

On 16.04.20 20:04, Per Oberg via Xenomai wrote:
> ----- Den 16 apr 2020, på kl 19:00, xenomai xenomai@xenomai.org skrev:
>> ----- Den 16 apr 2020, på kl 18:32, Lange Norbert norbert.lange@andritz.com
>> skrev:
> 
>>> Hello Per,
> 
>>> setsockopt is supported by rtnet (and wrapped with the POSIX skin). That said,
>>> it supports very little options you are used from Linux. Do a grep -r on
>>> xenomais sources.
>>> Xenomai mostly uses ioctls for bringing up Interfaces, etc.
> 
>>> There are subtile differences and limitations aswell. I am pretty sure now that
>>> most operations
>>> are behaving like you have an nonblocking filedescriptor / socket. The RT focus
>>> means that there
>>> typically is just a check if buffers are available, and no effort is made for
>>> waiting.
>>> So select will be your best friend.
>>> (I am just using packet sockets, but I believe it’s the same for all of them).
> 
>> Thanks, I readded the list again. The reason I started looking into this is that
>> I had issues with blocking sends. I wanted to see what happened if I pulled the
>> plug on the ethernet and tried to recover afterwards.
> 
>> Digging around a bit is seems like I might actually have a compiler flag issue
>> (again...). I tried compiling my network code as a shared library.
> 
> Progress, i guess. It was the read that was became non blocking.
> 
> Still: I believe that "setsockopt" is missing for PF_PACKET, SOCK_RAW. I can se that it is implemented for some of the packet types but there is no reference to it in af_packet.c.
> 
> That said, I don't see how setsockopt is mapped to the different variants. I can se how recv and recfrom is mapped using the structure with the ".recvfrom = xxx" syntax but setsockopt seems to be different.
> 
> Also, when looking in the code i see that "MSG_DONTWAIT" is supported for rt_packet_recvmsg and that it sets sock->timeout to -1. So it seems a small fix to make this work, if I only knew where how setsockopt was mapped..
> 

There is RTNET_RTIOC_TIMEOUT to set the timeout of blocked operations on 
the socket. I honestly do not recall right now what the reasoning for 
going separate was, but adding SO_RCVTIMEO compatibility would sure be 
doable.

Note that RT-TCP already supports SO_SNDTIMEO.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux