<div dir="ltr"><div>This turned out to be a trivial problem but hard to figure out. :(</div><div><br></div><div>The code has a POSIX_Init which initializes the stack and then calls the application's main() which spawns a number of threads which start using the stack. I disabled the POSIX_Init from calling main(), added mcast-listener and mcast-writer (standard net code I had) as shell programs, and then telnet'ed into the target. I could telnet in twice and run a listener in one session and a writer in another. This proved that multicast was working and made me wonder if there was a race condition on stack initialization since it takes a little while to login twice and run two programs.</div><div><br></div><div>I put a sleep(10) before calling main() and the program came up. Based on its output, it got through initialization but then faulted. I tracked that down to RTEMS implementation of posix_devctl() being correct and the adapter being used on Linux was incorrect. </div><div><br></div><div>*** Is there a reliable way to know the stack is settled out before the application can run?</div><div><br></div><div>*** I still have to get the multicast out of qemu but that's another issue.</div><div><br></div><div>Thanks for the suggestions everyone.</div><div><br></div><div>--joel</div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 19, 2020 at 2:35 PM Heinz Junkes <<a href="mailto:junkes@fhi-berlin.mpg.de">junkes@fhi-berlin.mpg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I can agree with Cedric.<br>
<br>
I use rtems5 with rtems-libbsd. I initialize the network interfaces of my target via dhcpcd <br>
and the interfaces are automatically multicast capable.<br>
<br>
This works without creating a route:<br>
<br>
if (setsockopt(conf->udp, IPPROTO_IP, IP_ADD_MEMBERSHIP,<br>
(char *) &mreq, sizeof(mreq))!=0) {<br>
struct sockaddr_in temp;<br>
char name[40];<br>
...<br>
<br>
Heinz<br>
<br>
<br>
> On 19. Jun 2020, at 17:53, Cedric Berger <<a href="mailto:cedric@precidata.com" target="_blank">cedric@precidata.com</a>> wrote:<br>
> <br>
> On 18.06.20 22:47, Joel Sherrill wrote:<br>
> <br>
>> Hi<br>
>> <br>
>> I have an example FACE application I am trying to port to RTEMS. This is a multi-question email:<br>
>> <br>
>> First, it fails with EADDRNOTAVAIL on this call:<br>
>> <br>
>> // Subscribe to multicast group<br>
>> struct ip_mreq mreq;<br>
>> rc = inet_pton(AF_INET, multicastGroup_m, &mreq.imr_multiaddr.s_addr);<br>
>> mreq.imr_interface.s_addr = htonl(INADDR_ANY);<br>
>> rc = setsockopt(<br>
>> new_socket, <br>
>> IPPROTO_IP, <br>
>> IP_ADD_MEMBERSHIP, <br>
>> &mreq, <br>
>> sizeof(mreq)<br>
>> );<br>
>> <br>
>> I assume that is because there is no multicast route. On Linux, you have to do an ifconfig and route to have a multicast route, but I haven't been able to find a multicast setup example for FreeBSD. The Linux commands are:<br>
>> <br>
>> ifconfig lo multicast<br>
>> route add -net 224.0.0.0 netmask 240.0.0.0 dev lo<br>
> This:<br>
> <br>
> <a href="https://gist.github.com/hostilefork/f7cae3dc33e7416f2dd25a402857b6c6" rel="noreferrer" target="_blank">https://gist.github.com/hostilefork/f7cae3dc33e7416f2dd25a402857b6c6</a><br>
> <br>
> Compiles and run without any special configuration on FreeBSD 12.1<br>
> <br>
> The handbook claims that "Multicast applications do not require any special configuration in order to run on FreeBSD"<br>
> <br>
> <a href="https://www.freebsd.org/doc/handbook/network-routing.html" rel="noreferrer" target="_blank">https://www.freebsd.org/doc/handbook/network-routing.html</a><br>
> <br>
> Following is the routing table on a FreeBSD jail with no special 224 route needed.<br>
> <br>
> Cédric<br>
> <br>
> # netstat -nr<br>
> Routing tables<br>
> <br>
> Internet:<br>
> Destination Gateway Flags Netif Expire<br>
> default 172.18.12.1 UGS epair25b<br>
> 127.0.0.1 link#1 UH lo0<br>
> <a href="http://172.18.12.0/24" rel="noreferrer" target="_blank">172.18.12.0/24</a> link#3 U epair25b<br>
> 172.18.12.25 link#3 UHS lo0<br>
> <br>
> Internet6:<br>
> Destination Gateway Flags Netif Expire<br>
> ::/96 ::1 UGRS lo0<br>
> ::1 link#1 UH lo0<br>
> ::ffff:<a href="http://0.0.0.0/96" rel="noreferrer" target="_blank">0.0.0.0/96</a> ::1 UGRS lo0<br>
> fe80::/10 ::1 UGRS lo0<br>
> fe80::%lo0/64 link#1 U lo0<br>
> fe80::1%lo0 link#1 UHS lo0<br>
> ff02::/16 ::1 UGRS lo0<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
<br>
</blockquote></div></div>