* RTNet and setsockopt
@ 2020-04-16 16:08 Per Oberg
[not found] ` <VI1PR05MB59172B3C0D8909BD37F9E947F6D80@VI1PR05MB5917.eurprd05.prod.outlook.com>
0 siblings, 1 reply; 4+ messages in thread
From: Per Oberg @ 2020-04-16 16:08 UTC (permalink / raw)
To: xenomai
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
^ permalink raw reply [flat|nested] 4+ messages in thread[parent not found: <VI1PR05MB59172B3C0D8909BD37F9E947F6D80@VI1PR05MB5917.eurprd05.prod.outlook.com>]
* Re: RTNet and setsockopt [not found] ` <VI1PR05MB59172B3C0D8909BD37F9E947F6D80@VI1PR05MB5917.eurprd05.prod.outlook.com> @ 2020-04-16 17:00 ` Per Oberg 2020-04-16 18:04 ` Per Oberg 0 siblings, 1 reply; 4+ messages in thread From: Per Oberg @ 2020-04-16 17:00 UTC (permalink / raw) To: xenomai ----- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RTNet and setsockopt 2020-04-16 17:00 ` Per Oberg @ 2020-04-16 18:04 ` Per Oberg 2020-04-17 6:18 ` Jan Kiszka 0 siblings, 1 reply; 4+ messages in thread From: Per Oberg @ 2020-04-16 18:04 UTC (permalink / raw) To: xenomai ----- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RTNet and setsockopt 2020-04-16 18:04 ` Per Oberg @ 2020-04-17 6:18 ` Jan Kiszka 0 siblings, 0 replies; 4+ messages in thread From: Jan Kiszka @ 2020-04-17 6:18 UTC (permalink / raw) To: Per Oberg, xenomai 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-04-17 6:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-16 16:08 RTNet and setsockopt Per Oberg
[not found] ` <VI1PR05MB59172B3C0D8909BD37F9E947F6D80@VI1PR05MB5917.eurprd05.prod.outlook.com>
2020-04-16 17:00 ` Per Oberg
2020-04-16 18:04 ` Per Oberg
2020-04-17 6:18 ` Jan Kiszka
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.