[Xenomai] Odp: Re: RTnet -- receive broadcast frame at the local machine

[Xenomai] Odp: Re: RTnet -- receive broadcast frame at the local machine

[Mariusz Janiak]

Dnia Poniedziałek, 29 Lutego 2016 22:08 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisał(a) 
> On Mon, Feb 29, 2016 at 09:58:25PM +0100, Mariusz Janiak wrote:
> > Dnia Poniedziałek, 29 Lutego 2016 21:29 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisał(a) 
> > > On Mon, Feb 29, 2016 at 09:24:11PM +0100, Mariusz Janiak wrote:
> > > > Dear Xenomai users,
> > > > 
> > > > Since RTnet has been integrated with Xenomai I address this question to you. The question is, how to receive a broadcast frame at the local machine without using the localhost? The issue is following, we have two process with separate rtsockets at the single machine (of course we have different machines in the network but this is not a case). One process send a broadcast UDP frame to the specified UDP port -- we have one rteth device on the machine. The second process listen on that 
port 
> > > > (receivefrom) and does not receive the broadcast frame sent by first process. I have found the following thread on the RTnet mailing list 
> > > > 
> > > > https://sourceforge.net/p/rtnet/mailman/message/6787561/
> > > > 
> > > > Could you please point me the place which should be hacked to duplicate outgoing packets if there are multiple
> > > > matching routes?
> > > 
> > > I ma not sure I understand what you are looking for, but to receive
> > > on a host the frames sent by that host, you need to enable and load
> > > the loopback module. When you do that, no hack should be needed.
> > > 
> > > -- 
> > > 					    Gilles.
> > > https://click-hack.org
> > 
> > Hi Gilles,
> > 
> > I am pretty sure that loopback module has been loaded, this is standard RTnet configuration that has not been changed by me. Beside that, there is rtlo (127.0.0.1) device which is created when RT_LOOPBACK="yes" in rtnet.conf. 
> > 
> > Below you will find simple testcase. Compile this using Xenomai posix skin. 
> > 
> > 1) receiver.c
> > #include <stdio.h>
> > #include <unistd.h>
> > #include <stdlib.h>
> > #include <sys/mman.h>
> > #include <sys/socket.h>
> > #include <netinet/in.h>
> > #include <arpa/inet.h>
> > #include <rtnet.h>
> > #define DEF_REC_PORT 1883
> > 
> > int sock;
> > struct sockaddr_in rec_addr;
> > 
> > int main()
> > {
> >   int enable = 1;
> >   int buffer[100];
> >   socklen_t len = sizeof(rec_addr);
> > 
> >   mlockall(MCL_CURRENT|MCL_FUTURE);
> 
> 1->
> 
> > 
> >   sock = socket(AF_INET, SOCK_DGRAM, 0);
> 
> 2->
> 
> >   setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &enable, sizeof(enable));
> 
> 3->
> 
> > 
> >   memset(&rec_addr, 0, sizeof(struct sockaddr_in));
> >   rec_addr.sin_family      = AF_INET;
> >   rec_addr.sin_port        = htons(DEF_REC_PORT);
> >   rec_addr.sin_addr.s_addr = INADDR_ANY;
> >   bind(sock, (struct sockaddr *) &rec_addr, sizeof(struct
> >   sockaddr_in));
> 
> 4->
> 
> > 
> >   while (1) {
> >     memset(buffer, 0, 100);
> >     recvfrom(sock, buffer, 100, 0, &rec_addr, &len);
> 
> 5->
> 
> >     printf("%s\n", buffer);
> >   }
> >   close(sock);
> >   return 0;
> > }
> > 
> > 
> > 2. sender.c
> > #include <unistd.h>
> > #include <stdlib.h>
> > #include <sys/mman.h>
> > #include <sys/socket.h>
> > #include <netinet/in.h>
> > #include <arpa/inet.h>
> > #include <rtnet.h>
> > #include <rtnet_config.h>
> > #define DEF_SND_PORT 1883
> > #define DEF_SND_IP   "10.0.0.255"
> > 
> > int sock;
> > struct sockaddr_in snd_addr;
> > int ret, size;
> > 
> > int main()
> > {
> >   int enable = 1;
> >   struct in_addr  snd_ip;
> >   char buffer[] = "Hello";
> >   socklen_t len = sizeof(snd_addr);
> > 
> >   mlockall(MCL_CURRENT|MCL_FUTURE);
> 
> 6->
> 
> > 
> >   inet_aton(DEF_SND_IP, &snd_ip);
> 
> 7->
> 
> >   sock = socket(AF_INET, SOCK_DGRAM, 0);
> 
> 8->
> 
> >   setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &enable,
> >   sizeof(enable));
> 
> 9->
> 
> > 
> >   memset(&snd_addr, 0, sizeof(struct sockaddr_in));
> >   snd_addr.sin_family = AF_INET;
> >   snd_addr.sin_port = htons(DEF_SND_PORT);
> >   snd_addr.sin_addr = snd_ip;
> > 
> >   while (1) {
> >     ret = sendto(sock, buffer, 6, 0 , &snd_addr, len);
> 
> 10->
> 
> So, that is 10 function calls without checking the return value.
> Please check the function return values.
> 
> -- 
> 					    Gilles.
> https://click-hack.org

You are right the test case has not been perfect. The answer to the first question, sending to unicast cause that receiver get frames. Regarding the return values of the syscalls when broadcast

1 -> 0
2 -> 896
3 -> -1
4 -> 0

Five is not printed because of waiting on recvfrom

6 -> 0
7 -> 1
8 -> 897
9 -> -1
10 -> -1
10 -> -1
10 -> -1
10 -> -1
10 -> -1

Regards,
Mariusz

Re: [Xenomai] Odp: Re: RTnet -- receive broadcast frame at the local machine

[Gilles Chanteperdrix]

On Mon, Feb 29, 2016 at 10:57:53PM +0100, Mariusz Janiak wrote:
> Dnia Poniedzia³ek, 29 Lutego 2016 22:08 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisa³(a) 
> > On Mon, Feb 29, 2016 at 09:58:25PM +0100, Mariusz Janiak wrote:
> > > Dnia Poniedzia³ek, 29 Lutego 2016 21:29 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisa³(a) 
> > > > On Mon, Feb 29, 2016 at 09:24:11PM +0100, Mariusz Janiak wrote:
> > > > > Dear Xenomai users,
> > > > > 
> > > > > Since RTnet has been integrated with Xenomai I address this question to you. The question is, how to receive a broadcast frame at the local machine without using the localhost? The issue is following, we have two process with separate rtsockets at the single machine (of course we have different machines in the network but this is not a case). One process send a broadcast UDP frame to the specified UDP port -- we have one rteth device on the machine. The second process listen on that 
> port 
> > > > > (receivefrom) and does not receive the broadcast frame sent by first process. I have found the following thread on the RTnet mailing list 
> > > > > 
> > > > > https://sourceforge.net/p/rtnet/mailman/message/6787561/
> > > > > 
> > > > > Could you please point me the place which should be hacked to duplicate outgoing packets if there are multiple
> > > > > matching routes?
> > > > 
> > > > I ma not sure I understand what you are looking for, but to receive
> > > > on a host the frames sent by that host, you need to enable and load
> > > > the loopback module. When you do that, no hack should be needed.
> > > > 
> > > > -- 
> > > > 					    Gilles.
> > > > https://click-hack.org
> > > 
> > > Hi Gilles,
> > > 
> > > I am pretty sure that loopback module has been loaded, this is standard RTnet configuration that has not been changed by me. Beside that, there is rtlo (127.0.0.1) device which is created when RT_LOOPBACK="yes" in rtnet.conf. 
> > > 
> > > Below you will find simple testcase. Compile this using Xenomai posix skin. 
> > > 
> > > 1) receiver.c
> > > #include <stdio.h>
> > > #include <unistd.h>
> > > #include <stdlib.h>
> > > #include <sys/mman.h>
> > > #include <sys/socket.h>
> > > #include <netinet/in.h>
> > > #include <arpa/inet.h>
> > > #include <rtnet.h>
> > > #define DEF_REC_PORT 1883
> > > 
> > > int sock;
> > > struct sockaddr_in rec_addr;
> > > 
> > > int main()
> > > {
> > >   int enable = 1;
> > >   int buffer[100];
> > >   socklen_t len = sizeof(rec_addr);
> > > 
> > >   mlockall(MCL_CURRENT|MCL_FUTURE);
> > 
> > 1->
> > 
> > > 
> > >   sock = socket(AF_INET, SOCK_DGRAM, 0);
> > 
> > 2->
> > 
> > >   setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &enable, sizeof(enable));
> > 
> > 3->
> > 
> > > 
> > >   memset(&rec_addr, 0, sizeof(struct sockaddr_in));
> > >   rec_addr.sin_family      = AF_INET;
> > >   rec_addr.sin_port        = htons(DEF_REC_PORT);
> > >   rec_addr.sin_addr.s_addr = INADDR_ANY;
> > >   bind(sock, (struct sockaddr *) &rec_addr, sizeof(struct
> > >   sockaddr_in));
> > 
> > 4->
> > 
> > > 
> > >   while (1) {
> > >     memset(buffer, 0, 100);
> > >     recvfrom(sock, buffer, 100, 0, &rec_addr, &len);
> > 
> > 5->
> > 
> > >     printf("%s\n", buffer);
> > >   }
> > >   close(sock);
> > >   return 0;
> > > }
> > > 
> > > 
> > > 2. sender.c
> > > #include <unistd.h>
> > > #include <stdlib.h>
> > > #include <sys/mman.h>
> > > #include <sys/socket.h>
> > > #include <netinet/in.h>
> > > #include <arpa/inet.h>
> > > #include <rtnet.h>
> > > #include <rtnet_config.h>
> > > #define DEF_SND_PORT 1883
> > > #define DEF_SND_IP   "10.0.0.255"
> > > 
> > > int sock;
> > > struct sockaddr_in snd_addr;
> > > int ret, size;
> > > 
> > > int main()
> > > {
> > >   int enable = 1;
> > >   struct in_addr  snd_ip;
> > >   char buffer[] = "Hello";
> > >   socklen_t len = sizeof(snd_addr);
> > > 
> > >   mlockall(MCL_CURRENT|MCL_FUTURE);
> > 
> > 6->
> > 
> > > 
> > >   inet_aton(DEF_SND_IP, &snd_ip);
> > 
> > 7->
> > 
> > >   sock = socket(AF_INET, SOCK_DGRAM, 0);
> > 
> > 8->
> > 
> > >   setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &enable,
> > >   sizeof(enable));
> > 
> > 9->
> > 
> > > 
> > >   memset(&snd_addr, 0, sizeof(struct sockaddr_in));
> > >   snd_addr.sin_family = AF_INET;
> > >   snd_addr.sin_port = htons(DEF_SND_PORT);
> > >   snd_addr.sin_addr = snd_ip;
> > > 
> > >   while (1) {
> > >     ret = sendto(sock, buffer, 6, 0 , &snd_addr, len);
> > 
> > 10->
> > 
> > So, that is 10 function calls without checking the return value.
> > Please check the function return values.
> > 
> > -- 
> > 					    Gilles.
> > https://click-hack.org
> 
> You are right the test case has not been perfect. The answer to the first question, sending to unicast cause that receiver get frames. Regarding the return values of the syscalls when broadcast
> 
> 1 -> 0
> 2 -> 896
> 3 -> -1
> 4 -> 0
> 
> Five is not printed because of waiting on recvfrom
> 
> 6 -> 0
> 7 -> 1
> 8 -> 897
> 9 -> -1
> 10 -> -1
> 10 -> -1
> 10 -> -1
> 10 -> -1
> 10 -> -1

So, finally, the problem is that SO_BROADCAST is not implemented for
RTnet sockets, and that RTnet sendto does not work for a broadcast
address?

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Odp: Re: RTnet -- receive broadcast frame at the local machine

[Mariusz Janiak]

Dnia Wtorek, 1 Marca 2016 07:57 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisał(a) 
> On Mon, Feb 29, 2016 at 10:57:53PM +0100, Mariusz Janiak wrote:
> > Dnia Poniedziałek, 29 Lutego 2016 22:08 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisał(a) 
> > > On Mon, Feb 29, 2016 at 09:58:25PM +0100, Mariusz Janiak wrote:
> > > > Dnia Poniedziałek, 29 Lutego 2016 21:29 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisał(a) 
> > > > > On Mon, Feb 29, 2016 at 09:24:11PM +0100, Mariusz Janiak wrote:
> > > > > > Dear Xenomai users,
> > > > > > 
> > > > > > Since RTnet has been integrated with Xenomai I address this question to you. The question is, how to receive a broadcast frame at the local machine without using the localhost? The issue is following, we have two process with separate rtsockets at the single machine (of course we have different machines in the network but this is not a case). One process send a broadcast UDP frame to the specified UDP port -- we have one rteth device on the machine. The second process listen on 
that 
> > port 
> > > > > > (receivefrom) and does not receive the broadcast frame sent by first process. I have found the following thread on the RTnet mailing list 
> > > > > > 
> > > > > > https://sourceforge.net/p/rtnet/mailman/message/6787561/
> > > > > > 
> > > > > > Could you please point me the place which should be hacked to duplicate outgoing packets if there are multiple
> > > > > > matching routes?
> > > > > 
> > > > > I ma not sure I understand what you are looking for, but to receive
> > > > > on a host the frames sent by that host, you need to enable and load
> > > > > the loopback module. When you do that, no hack should be needed.
> > > > > 
> > > > > -- 
> > > > > 					    Gilles.
> > > > > https://click-hack.org
> > > > 
> > > > Hi Gilles,
> > > > 
> > > > I am pretty sure that loopback module has been loaded, this is standard RTnet configuration that has not been changed by me. Beside that, there is rtlo (127.0.0.1) device which is created when RT_LOOPBACK="yes" in rtnet.conf. 
> > > > 
> > > > Below you will find simple testcase. Compile this using Xenomai posix skin. 
> > > > 
> > > > 1) receiver.c
> > > > #include <stdio.h>
> > > > #include <unistd.h>
> > > > #include <stdlib.h>
> > > > #include <sys/mman.h>
> > > > #include <sys/socket.h>
> > > > #include <netinet/in.h>
> > > > #include <arpa/inet.h>
> > > > #include <rtnet.h>
> > > > #define DEF_REC_PORT 1883
> > > > 
> > > > int sock;
> > > > struct sockaddr_in rec_addr;
> > > > 
> > > > int main()
> > > > {
> > > >   int enable = 1;
> > > >   int buffer[100];
> > > >   socklen_t len = sizeof(rec_addr);
> > > > 
> > > >   mlockall(MCL_CURRENT|MCL_FUTURE);
> > > 
> > > 1->
> > > 
> > > > 
> > > >   sock = socket(AF_INET, SOCK_DGRAM, 0);
> > > 
> > > 2->
> > > 
> > > >   setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &enable, sizeof(enable));
> > > 
> > > 3->
> > > 
> > > > 
> > > >   memset(&rec_addr, 0, sizeof(struct sockaddr_in));
> > > >   rec_addr.sin_family      = AF_INET;
> > > >   rec_addr.sin_port        = htons(DEF_REC_PORT);
> > > >   rec_addr.sin_addr.s_addr = INADDR_ANY;
> > > >   bind(sock, (struct sockaddr *) &rec_addr, sizeof(struct
> > > >   sockaddr_in));
> > > 
> > > 4->
> > > 
> > > > 
> > > >   while (1) {
> > > >     memset(buffer, 0, 100);
> > > >     recvfrom(sock, buffer, 100, 0, &rec_addr, &len);
> > > 
> > > 5->
> > > 
> > > >     printf("%s\n", buffer);
> > > >   }
> > > >   close(sock);
> > > >   return 0;
> > > > }
> > > > 
> > > > 
> > > > 2. sender.c
> > > > #include <unistd.h>
> > > > #include <stdlib.h>
> > > > #include <sys/mman.h>
> > > > #include <sys/socket.h>
> > > > #include <netinet/in.h>
> > > > #include <arpa/inet.h>
> > > > #include <rtnet.h>
> > > > #include <rtnet_config.h>
> > > > #define DEF_SND_PORT 1883
> > > > #define DEF_SND_IP   "10.0.0.255"
> > > > 
> > > > int sock;
> > > > struct sockaddr_in snd_addr;
> > > > int ret, size;
> > > > 
> > > > int main()
> > > > {
> > > >   int enable = 1;
> > > >   struct in_addr  snd_ip;
> > > >   char buffer[] = "Hello";
> > > >   socklen_t len = sizeof(snd_addr);
> > > > 
> > > >   mlockall(MCL_CURRENT|MCL_FUTURE);
> > > 
> > > 6->
> > > 
> > > > 
> > > >   inet_aton(DEF_SND_IP, &snd_ip);
> > > 
> > > 7->
> > > 
> > > >   sock = socket(AF_INET, SOCK_DGRAM, 0);
> > > 
> > > 8->
> > > 
> > > >   setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &enable,
> > > >   sizeof(enable));
> > > 
> > > 9->
> > > 
> > > > 
> > > >   memset(&snd_addr, 0, sizeof(struct sockaddr_in));
> > > >   snd_addr.sin_family = AF_INET;
> > > >   snd_addr.sin_port = htons(DEF_SND_PORT);
> > > >   snd_addr.sin_addr = snd_ip;
> > > > 
> > > >   while (1) {
> > > >     ret = sendto(sock, buffer, 6, 0 , &snd_addr, len);
> > > 
> > > 10->
> > > 
> > > So, that is 10 function calls without checking the return value.
> > > Please check the function return values.
> > > 
> > > -- 
> > > 					    Gilles.
> > > https://click-hack.org
> > 
> > You are right the test case has not been perfect. The answer to the first question, sending to unicast cause that receiver get frames. Regarding the return values of the syscalls when broadcast
> > 
> > 1 -> 0
> > 2 -> 896
> > 3 -> -1
> > 4 -> 0
> > 
> > Five is not printed because of waiting on recvfrom
> > 
> > 6 -> 0
> > 7 -> 1
> > 8 -> 897
> > 9 -> -1
> > 10 -> -1
> > 10 -> -1
> > 10 -> -1
> > 10 -> -1
> > 10 -> -1
> 
> So, finally, the problem is that SO_BROADCAST is not implemented for
> RTnet sockets, and that RTnet sendto does not work for a broadcast
> address?
> 
> -- 
> 					    Gilles.
> https://click-hack.org

It does work, but when you receive on remote host, and it doesn't when receive on the same host. According to this post on the RTnet forum 

https://sourceforge.net/p/rtnet/mailman/message/26686897/

the RT-UDP sockets have SO_BROADCAST automatically enabled.

Mariusz

Re: [Xenomai] Odp: Re: RTnet -- receive broadcast frame at the local machine

[Gilles Chanteperdrix]

On Tue, Mar 01, 2016 at 10:59:03PM +0100, Mariusz Janiak wrote:
> Dnia Wtorek, 1 Marca 2016 07:57 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisa³(a) 
> > On Mon, Feb 29, 2016 at 10:57:53PM +0100, Mariusz Janiak wrote:
> > > Dnia Poniedzia³ek, 29 Lutego 2016 22:08 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisa³(a) 
> > > > On Mon, Feb 29, 2016 at 09:58:25PM +0100, Mariusz Janiak wrote:
> > > > > Dnia Poniedzia³ek, 29 Lutego 2016 21:29 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisa³(a) 
> > > > > > On Mon, Feb 29, 2016 at 09:24:11PM +0100, Mariusz Janiak wrote:
> > > > > > > Dear Xenomai users,
> > > > > > > 
> > > > > > > Since RTnet has been integrated with Xenomai I address this question to you. The question is, how to receive a broadcast frame at the local machine without using the localhost? The issue is following, we have two process with separate rtsockets at the single machine (of course we have different machines in the network but this is not a case). One process send a broadcast UDP frame to the specified UDP port -- we have one rteth device on the machine. The second process listen on 
> that 
> > > port 
> > > > > > > (receivefrom) and does not receive the broadcast frame sent by first process. I have found the following thread on the RTnet mailing list 
> > > > > > > 
> > > > > > > https://sourceforge.net/p/rtnet/mailman/message/6787561/
> > > > > > > 
> > > > > > > Could you please point me the place which should be hacked to duplicate outgoing packets if there are multiple
> > > > > > > matching routes?
> > > > > > 
> > > > > > I ma not sure I understand what you are looking for, but to receive
> > > > > > on a host the frames sent by that host, you need to enable and load
> > > > > > the loopback module. When you do that, no hack should be needed.
> > > > > > 
> > > > > > -- 
> > > > > > 					    Gilles.
> > > > > > https://click-hack.org
> > > > > 
> > > > > Hi Gilles,
> > > > > 
> > > > > I am pretty sure that loopback module has been loaded, this is standard RTnet configuration that has not been changed by me. Beside that, there is rtlo (127.0.0.1) device which is created when RT_LOOPBACK="yes" in rtnet.conf. 
> > > > > 
> > > > > Below you will find simple testcase. Compile this using Xenomai posix skin. 
> > > > > 
> > > > > 1) receiver.c
> > > > > #include <stdio.h>
> > > > > #include <unistd.h>
> > > > > #include <stdlib.h>
> > > > > #include <sys/mman.h>
> > > > > #include <sys/socket.h>
> > > > > #include <netinet/in.h>
> > > > > #include <arpa/inet.h>
> > > > > #include <rtnet.h>
> > > > > #define DEF_REC_PORT 1883
> > > > > 
> > > > > int sock;
> > > > > struct sockaddr_in rec_addr;
> > > > > 
> > > > > int main()
> > > > > {
> > > > >   int enable = 1;
> > > > >   int buffer[100];
> > > > >   socklen_t len = sizeof(rec_addr);
> > > > > 
> > > > >   mlockall(MCL_CURRENT|MCL_FUTURE);
> > > > 
> > > > 1->
> > > > 
> > > > > 
> > > > >   sock = socket(AF_INET, SOCK_DGRAM, 0);
> > > > 
> > > > 2->
> > > > 
> > > > >   setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &enable, sizeof(enable));
> > > > 
> > > > 3->
> > > > 
> > > > > 
> > > > >   memset(&rec_addr, 0, sizeof(struct sockaddr_in));
> > > > >   rec_addr.sin_family      = AF_INET;
> > > > >   rec_addr.sin_port        = htons(DEF_REC_PORT);
> > > > >   rec_addr.sin_addr.s_addr = INADDR_ANY;
> > > > >   bind(sock, (struct sockaddr *) &rec_addr, sizeof(struct
> > > > >   sockaddr_in));
> > > > 
> > > > 4->
> > > > 
> > > > > 
> > > > >   while (1) {
> > > > >     memset(buffer, 0, 100);
> > > > >     recvfrom(sock, buffer, 100, 0, &rec_addr, &len);
> > > > 
> > > > 5->
> > > > 
> > > > >     printf("%s\n", buffer);
> > > > >   }
> > > > >   close(sock);
> > > > >   return 0;
> > > > > }
> > > > > 
> > > > > 
> > > > > 2. sender.c
> > > > > #include <unistd.h>
> > > > > #include <stdlib.h>
> > > > > #include <sys/mman.h>
> > > > > #include <sys/socket.h>
> > > > > #include <netinet/in.h>
> > > > > #include <arpa/inet.h>
> > > > > #include <rtnet.h>
> > > > > #include <rtnet_config.h>
> > > > > #define DEF_SND_PORT 1883
> > > > > #define DEF_SND_IP   "10.0.0.255"
> > > > > 
> > > > > int sock;
> > > > > struct sockaddr_in snd_addr;
> > > > > int ret, size;
> > > > > 
> > > > > int main()
> > > > > {
> > > > >   int enable = 1;
> > > > >   struct in_addr  snd_ip;
> > > > >   char buffer[] = "Hello";
> > > > >   socklen_t len = sizeof(snd_addr);
> > > > > 
> > > > >   mlockall(MCL_CURRENT|MCL_FUTURE);
> > > > 
> > > > 6->
> > > > 
> > > > > 
> > > > >   inet_aton(DEF_SND_IP, &snd_ip);
> > > > 
> > > > 7->
> > > > 
> > > > >   sock = socket(AF_INET, SOCK_DGRAM, 0);
> > > > 
> > > > 8->
> > > > 
> > > > >   setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &enable,
> > > > >   sizeof(enable));
> > > > 
> > > > 9->
> > > > 
> > > > > 
> > > > >   memset(&snd_addr, 0, sizeof(struct sockaddr_in));
> > > > >   snd_addr.sin_family = AF_INET;
> > > > >   snd_addr.sin_port = htons(DEF_SND_PORT);
> > > > >   snd_addr.sin_addr = snd_ip;
> > > > > 
> > > > >   while (1) {
> > > > >     ret = sendto(sock, buffer, 6, 0 , &snd_addr, len);
> > > > 
> > > > 10->
> > > > 
> > > > So, that is 10 function calls without checking the return value.
> > > > Please check the function return values.
> > > > 
> > > > -- 
> > > > 					    Gilles.
> > > > https://click-hack.org
> > > 
> > > You are right the test case has not been perfect. The answer to the first question, sending to unicast cause that receiver get frames. Regarding the return values of the syscalls when broadcast
> > > 
> > > 1 -> 0
> > > 2 -> 896
> > > 3 -> -1
> > > 4 -> 0
> > > 
> > > Five is not printed because of waiting on recvfrom
> > > 
> > > 6 -> 0
> > > 7 -> 1
> > > 8 -> 897
> > > 9 -> -1
> > > 10 -> -1
> > > 10 -> -1
> > > 10 -> -1
> > > 10 -> -1
> > > 10 -> -1
> > 
> > So, finally, the problem is that SO_BROADCAST is not implemented for
> > RTnet sockets, and that RTnet sendto does not work for a broadcast
> > address?
> > 
> > -- 
> > 					    Gilles.
> > https://click-hack.org
> 
> It does work, but when you receive on remote host, and it doesn't when receive on the same host. According to this post on the RTnet forum 
> 
> https://sourceforge.net/p/rtnet/mailman/message/26686897/
> 
> the RT-UDP sockets have SO_BROADCAST automatically enabled.

>From what I understand from this post, it is not easy to fix, as it
requires duplicating packets. So, patch welcome.

The thing that I do not understand though, is that according to what
you said, "sendto" fails, what is the value of errno when it fails.
Maybe you do not know it, because you do not seem to be used to
checking for errors, but when a unix call fails, it returns -1 and
sets errno, the interesting information is errno.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Odp: Re: RTnet -- receive broadcast frame at the local machine

[Mariusz Janiak]

Dnia Wtorek, 1 Marca 2016 23:05 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisał(a) 
> On Tue, Mar 01, 2016 at 10:59:03PM +0100, Mariusz Janiak wrote:
> > Dnia Wtorek, 1 Marca 2016 07:57 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisał(a) 
> > > On Mon, Feb 29, 2016 at 10:57:53PM +0100, Mariusz Janiak wrote:
> > > > Dnia Poniedziałek, 29 Lutego 2016 22:08 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisał(a) 
> > > > > On Mon, Feb 29, 2016 at 09:58:25PM +0100, Mariusz Janiak wrote:
> > > > > > Dnia Poniedziałek, 29 Lutego 2016 21:29 Gilles Chante7erdrix <gilles.chanteperdrix@xenomai.org> napisał(a) 
> > > > > > > On Mon, Feb 29, 2016 at 09:24:11PM +0100, Mariusz Janiak wrote:
> > > > > > > > Dear Xenomai users,
> > > > > > > > 
> > > > > > > > Since RTnet has been integrated with Xenomai I address this question to you. The question is, how to receive a broadcast frame at the local machine without using the localhost? The issue is following, we have two process with separate rtsockets at the single machine (of course we have different machines in the network but this is not a case). One process send a broadcast UDP frame to the specified UDP port -- we have one rteth device on the machine. The second process listen on 
> > that 
> > > > port 
> > > > > > > > (receivefrom) and does not receive the broadcast frame sent by first process. I have found the following thread on the RTnet mailing list 
> > > > > > > > 
> > > > > > > > https://sourceforge.net/p/rtnet/mailman/message/6787561/
> > > > > > > > 
> > > > > > > > Could you please point me the place which should be hacked to duplicate outgoing packets if there are multiple
> > > > > > > > matching routes?
> > > > > > > 
> > > > > > > I ma not sure I understand what you are looking for, but to receive
> > > > > > > on a host the frames sent by that host, you need to enable and load
> > > > > > > the loopback module. When you do that, no hack should be needed.
> > > > > > > 
> > > > > > > -- 
> > > > > > > 					    Gilles.
> > > > > > > https://click-hack.org
> > > > > > 
> > > > > > Hi Gilles,
> > > > > > 
> > > > > > I am pretty sure that loopback module has been loaded, this is standard RTnet configuration that has not been changed by me. Beside that, there is rtlo (127.0.0.1) device which is created when RT_LOOPBACK="yes" in rtnet.conf. 
> > > > > > 
> > > > > > Below you will find simple testcase. Compile this using Xenomai posix skin. 
> > > > > > 
> > > > > > 1) receiver.c
> > > > > > #include <stdio.h>
> > > > > > #include <unistd.h>
> > > > > > #include <stdlib.h>
> > > > > > #include <sys/mman.h>
> > > > > > #include <sys/socket.h>
> > > > > > #include <netinet/in.h>
> > > > > > #include <arpa/inet.h>
> > > > > > #include <rtnet.h>
> > > > > > #define DEF_REC_PORT 1883
> > > > > > 
> > > > > > int sock;
> > > > > > struct sockaddr_in rec_addr;
> > > > > > 
> > > > > > int main()
> > > > > > {
> > > > > >   int enable = 1;
> > > > > >   int buffer[100];
> > > > > >   socklen_t len = sizeof(rec_addr);
> > > > > > 
> > > > > >   mlockall(MCL_CURRENT|MCL_FUTURE);
> > > > > 
> > > > > 1->
> > > > > 
> > > > > > 
> > > > > >   sock = socket(AF_INET, SOCK_DGRAM, 0);
> > > > > 
> > > > > 2->
> > > > > 
> > > > > >   setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &enable, sizeof(enable));
> > > > > 
> > > > > 3->
> > > > > 
> > > > > > 
> > > > > >   memset(&rec_addr, 0, sizeof(struct sockaddr_in));
> > > > > >   rec_addr.sin_family      = AF_INET;
> > > > > >   rec_addr.sin_port        = htons(DEF_REC_PORT);
> > > > > >   rec_addr.sin_addr.s_addr = INADDR_ANY;
> > > > > >   bind(sock, (struct sockaddr *) &rec_addr, sizeof(struct
> > > > > >   sockaddr_in));
> > > > > 
> > > > > 4->
> > > > > 
> > > > > > 
> > > > > >   while (1) {
> > > > > >     memset(buffer, 0, 100);
> > > > > >     recvfrom(sock, buffer, 100, 0, &rec_addr, &len);
> > > > > 
> > > > > 5->
> > > > > 
> > > > > >     printf("%s\n", buffer);
> > > > > >   }
> > > > > >   close(sock);
> > > > > >   return 0;
> > > > > > }
> > > > > > 
> > > > > > 
> > > > > > 2. sender.c
> > > > > > #include <unistd.h>
> > > > > > #include <stdlib.h>
> > > > > > #include <sys/mman.h>
> > > > > > #include <sys/socket.h>
> > > > > > #include <netinet/in.h>
> > > > > > #include <arpa/inet.h>
> > > > > > #include <rtnet.h>
> > > > > > #include <rtnet_config.h>
> > > > > > #define DEF_SND_PORT 1883
> > > > > > #define DEF_SND_IP   "10.0.0.255"
> > > > > > 
> > > > > > int sock;
> > > > > > struct sockaddr_in snd_addr;
> > > > > > int ret, size;
> > > > > > 
> > > > > > int main()
> > > > > > {
> > > > > >   int enable = 1;
> > > > > >   struct in_addr  snd_ip;
> > > > > >   char buffer[] = "Hello";
> > > > > >   socklen_t len = sizeof(snd_addr);
> > > > > > 
> > > > > >   mlockall(MCL_CURRENT|MCL_FUTURE);
> > > > > 
> > > > > 6->
> > > > > 
> > > > > > 
> > > > > >   inet_aton(DEF_SND_IP, &snd_ip);
> > > > > 
> > > > > 7->
> > > > > 
> > > > > >   sock = socket(AF_INET, SOCK_DGRAM, 0);
> > > > > 
> > > > > 8->
> > > > > 
> > > > > >   setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &enable,
> > > > > >   sizeof(enable));
> > > > > 
> > > > > 9->
> > > > > 
> > > > > > 
> > > > > >   memset(&snd_addr, 0, sizeof(struct sockaddr_in));
> > > > > >   snd_addr.sin_family = AF_INET;
> > > > > >   snd_addr.sin_port = htons(DEF_SND_PORT);
> > > > > >   snd_addr.sin_addr = snd_ip;
> > > > > > 
> > > > > >   while (1) {
> > > > > >     ret = sendto(sock, buffer, 6, 0 , &snd_addr, len);
> > > > > 
> > > > > 10->
> > > > > 
> > > > > So, that is 10 function calls without checking the return value.
> > > > > Please check the function return values.
> > > > > 
> > > > > -- 
> > > > > 					    Gilles.
> > > > > https://click-hack.org
> > > > 
> > > > You are right the test case has not been perfect. The answer to the first question, sending to unicast cause that receiver get frames. Regarding the return values of the syscalls when broadcast
> > > > 
> > > > 1 -> 0
> > > > 2 -> 896
> > > > 3 -> -1
> > > > 4 -> 0
> > > > 
> > > > Five is not printed because of waiting on recvfrom
> > > > 
> > > > 6 -> 0
> > > > 7 -> 1
> > > > 8 -> 897
> > > > 9 -> -1
> > > > 10 -> -1
> > > > 10 -> -1
> > > > 10 -> -1
> > > > 10 -> -1
> > > > 10 -> -1
> > > 
> > > So, finally, the problem is that SO_BROADCAST is not implemented for
> > > RTnet sockets, and that RTnet sendto does not work for a broadcast
> > > address?
> > > 
> > > -- 
> > > 					    Gilles.
> > > https://click-hack.org
> > 
> > It does work, but when you receive on remote host, and it doesn't when receive on the same host. According to this post on the RTnet forum 
> > 
> > https://sourceforge.net/p/rtnet/mailman/message/26686897/
> > 
> > the RT-UDP sockets have SO_BROADCAST automatically enabled.
> 
> From what I understand from this post, it is not easy to fix, as it
> requires duplicating packets. So, patch welcome.

Ok, we went back to the original question, could someone point the place that has to be modified. I have played a little bit with the RTnet stack recently, but this task require far better understanding of the stack. Maybe someone more advanced can give some guidelines. 

> The thing that I do not understand though, is that according to what
> you said, "sendto" fails, what is the value of errno when it fails.
> Maybe you do not know it, because you do not seem to be used to
> checking for errors, but when a unix call fails, it returns -1 and
> sets errno, the interesting information is errno.

My fault, I forgot to add broadcast address that is used in example. Anyway, changing to default broadcast 10.255.255.255 or adding 10.0.0.255 with rtroute give the same result 

6 -> 0
7 -> 1
8 -> 896
9 -> -1
10 -> 6
10 -> 6
10 -> 6
10 -> 6

Mariusz

> -- 
> 					    Gilles.
> https://click-hack.org

Re: [Xenomai] Odp: Re: RTnet -- receive broadcast frame at the local machine

[Gilles Chanteperdrix]

On Tue, Mar 01, 2016 at 11:24:55PM +0100, Mariusz Janiak wrote:
> > From what I understand from this post, it is not easy to fix, as it
> > requires duplicating packets. So, patch welcome.
> 
> Ok, we went back to the original question, could someone point the
> place that has to be modified. I have played a little bit with the
> RTnet stack recently, but this task require far better
> understanding of the stack. Maybe someone more advanced can give
> some guidelines.

It is not that complicated. The udp send function (rt_udp_sendmsg)
is in udp.c, it calls rt_ip_route_output (found in route.c) to find
the output route, than rt_ip_build_xmit (found in ip_output.c) to
build the packet and send in on the device. rt_ip_build_xmit calls
rt_eth_header to build the ethernet header (found in eth.c), then
rtdev_xmit (found in dev.c) to send the packet.

So you can do this either at the IP level in rt_ip_build_xmit, or at
the ethernet level in rtdev_xmit. What you need to do is that when
the destination is broadcast (there should be a macro to test that
an IP address is broadcast if you want to do it at IP level, and the
mac address for broadcast is just ff:ff:ff:ff:ff:ff if you want to
do it at ethernet level) you need to duplicate the packet, and
either trigger a receive on the same device, or send the packet on
the loopback device. If you go the ethernet route, you will have to
use a per-device callback to test if the destination is broadcast,
as rtdev_xmit is supposed to not be specific to ethernet, like is
done with the hard_header and start_xmit callbacks.

Hope this helps.
Regards.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Odp: Re: RTnet -- receive broadcast frame at the local machine

[Gilles Chanteperdrix]

On Wed, Mar 02, 2016 at 02:07:33PM +0100, Gilles Chanteperdrix wrote:
> On Tue, Mar 01, 2016 at 11:24:55PM +0100, Mariusz Janiak wrote:
> > > From what I understand from this post, it is not easy to fix, as it
> > > requires duplicating packets. So, patch welcome.
> > 
> > Ok, we went back to the original question, could someone point the
> > place that has to be modified. I have played a little bit with the
> > RTnet stack recently, but this task require far better
> > understanding of the stack. Maybe someone more advanced can give
> > some guidelines.
> 
> It is not that complicated. The udp send function (rt_udp_sendmsg)
> is in udp.c, it calls rt_ip_route_output (found in route.c) to find
> the output route, than rt_ip_build_xmit (found in ip_output.c) to
> build the packet and send in on the device. rt_ip_build_xmit calls
> rt_eth_header to build the ethernet header (found in eth.c), then
> rtdev_xmit (found in dev.c) to send the packet.
> 
> So you can do this either at the IP level in rt_ip_build_xmit, or at
> the ethernet level in rtdev_xmit. What you need to do is that when
> the destination is broadcast (there should be a macro to test that
> an IP address is broadcast if you want to do it at IP level, and the
> mac address for broadcast is just ff:ff:ff:ff:ff:ff if you want to
> do it at ethernet level) you need to duplicate the packet, and
> either trigger a receive on the same device, or send the packet on
> the loopback device. If you go the ethernet route, you will have to
> use a per-device callback to test if the destination is broadcast,
> as rtdev_xmit is supposed to not be specific to ethernet, like is
> done with the hard_header and start_xmit callbacks.

Note that doing this at ethernet level is better, as it will also
work for packets sent with raw sockets, and also note that to test
if a MAC address is broadcast, you only need to test the most
significant byte least significant bit. If you do it that way, it
also gets the trick working with multicast addresses.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Odp: Re: RTnet -- receive broadcast frame at the local machine

[Mariusz Janiak]

Dnia Środa, 2 Marca 2016 14:07 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisał(a) 
> On Tue, Mar 01, 2016 at 11:24:55PM +0100, Mariusz Janiak wrote:
> > > From what I understand from this post, it is not easy to fix, as it
> > > requires duplicating packets. So, patch welcome.
> > 
> > Ok, we went back to the original question, could someone point the
> > place that has to be modified. I have played a little bit with the
> > RTnet stack recently, but this task require far better
> > understanding of the stack. Maybe someone more advanced can give
> > some guidelines.
> 
> It is not that complicated. The udp send function (rt_udp_sendmsg)
> is in udp.c, it calls rt_ip_route_output (found in route.c) to find
> the output route, than rt_ip_build_xmit (found in ip_output.c) to
> build the packet and send in on the device. rt_ip_build_xmit calls
> rt_eth_header to build the ethernet header (found in eth.c), then
> rtdev_xmit (found in dev.c) to send the packet.
> 
> So you can do this either at the IP level in rt_ip_build_xmit, or at
> the ethernet level in rtdev_xmit. What you need to do is that when
> the destination is broadcast (there should be a macro to test that
> an IP address is broadcast if you want to do it at IP level, and the
> mac address for broadcast is just ff:ff:ff:ff:ff:ff if you want to
> do it at ethernet level) you need to duplicate the packet, and
> either trigger a receive on the same device, or send the packet on
> the loopback device. If you go the ethernet route, you will have to
> use a per-device callback to test if the destination is broadcast,
> as rtdev_xmit is supposed to not be specific to ethernet, like is
> done with the hard_header and start_xmit callbacks.

Thank you Gilles, I see it more clearly now. I think I will go the ethernet route. I will back with patch soon. 

Regards,
Marisz 

> Hope this helps.
> Regards.
> 
> -- 
> 					    Gilles.
> https://click-hack.org

Re: [Xenomai] Odp: Re: RTnet -- receive broadcast frame at the local machine

[Mariusz Janiak]

Dnia Środa, 2 Marca 2016 14:25 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> napisał(a) 
> On Wed, Mar 02, 2016 at 02:07:33PM +0100, Gilles Chanteperdrix wrote:
> > On Tue, Mar 01, 2016 at 11:24:55PM +0100, Mariusz Janiak wrote:
> > > > From what I understand from this post, it is not easy to fix, as it
> > > > requires duplicating packets. So, patch welcome.
> > > 
> > > Ok, we went back to the original question, could someone point the
> > > place that has to be modified. I have played a little bit with the
> > > RTnet stack recently, but this task require far better
> > > understanding of the stack. Maybe someone more advanced can give
> > > some guidelines.
> > 
> > It is not that complicated. The udp send function (rt_udp_sendmsg)
> > is in udp.c, it calls rt_ip_route_output (found in route.c) to find
> > the output route, than rt_ip_build_xmit (found in ip_output.c) to
> > build the packet and send in on the device. rt_ip_build_xmit calls
> > rt_eth_header to build the ethernet header (found in eth.c), then
> > rtdev_xmit (found in dev.c) to send the packet.
> > 
> > So you can do this either at the IP level in rt_ip_build_xmit, or at
> > the ethernet level in rtdev_xmit. What you need to do is that when
> > the destination is broadcast (there should be a macro to test that
> > an IP address is broadcast if you want to do it at IP level, and the
> > mac address for broadcast is just ff:ff:ff:ff:ff:ff if you want to
> > do it at ethernet level) you need to duplicate the packet, and
> > either trigger a receive on the same device, or send the packet on
> > the loopback device. If you go the ethernet route, you will have to
> > use a per-device callback to test if the destination is broadcast,
> > as rtdev_xmit is supposed to not be specific to ethernet, like is
> > done with the hard_header and start_xmit callbacks.
> 
> Note that doing this at ethernet level is better, as it will also
> work for packets sent with raw sockets, and also note that to test
> if a MAC address is broadcast, you only need to test the most
> significant byte least significant bit. If you do it that way, it
> also gets the trick working with multicast addresses.

Ok, I will do that that way, but unfortunately RTnet does no support multicast yet. 

Regards,
Mariusz

> -- 
> 					    Gilles.
> https://click-hack.org