Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Thu, 24 Aug 2006 18:07:48 +0200

OK - here are our latest findings:

First - the Bottom line: The RTEMS network code does not work as

expected. Calling socket_ioctl() with SIOCGIFCONF does return also

AF_LINK structures, not just AF_INET interfaces, as the linux man page says.

Here's some debugging output of what's coming up. The AF_LINK structures

have a length of 54 (0x36), which adds up to 70 adding the 16 characters

for the name. 70 is not divisable by 4, so the ARM crashes when the BSD

net code gets called with a pointer to the following structure.

rtems-4.6.99.3/cpukit/libnetworking/net/if.c :
(hex code shows sockaddr.sa_data)

ifconf() eth0 (IFACE 1)
ifnetdebuginfo() Flags: IFF_UP IFF_BROADCAST IFF_RUNNING
ifconf() ifa->ifa_addr

socketdebuginfo() adress len: 0x36

socketdebuginfo() AF_LINK

01 00 06 04 06 00 65 74 68 30 00 01 af 14 cd 5b 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ifconf() sa_len doesn't fit into struct sockaddr
ifconf() ifa->ifa_addr
socketdebuginfo() adress len: 0x10
socketdebuginfo() AF_INET
00 00 c1 95 0c cd 00 00 00 00 00 00 00 00 10 02
ifconf() sa_len fits into struct sockaddr
ifconf() lo0 (IFACE 2)
ifnetdebuginfo() Flags: IFF_UP IFF_LOOPBACK IFF_RUNNING IFF_MULTICAST
ifconf() ifa->ifa_addr
socketdebuginfo() adress len: 0x36
socketdebuginfo() AF_LINK

02 00 18 03 00 00 6c 6f 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ifconf() sa_len doesn't fit into struct sockaddr
ifconf() ifa->ifa_addr
socketdebuginfo() adress len: 0x10
socketdebuginfo() AF_INET
00 00 7f 00 00 01 00 00 00 00 00 00 00 00 00 00
ifconf() sa_len fits into struct sockaddr
ifconf() space: 2996, ifc_len: 3200

The linux manpage for netdevice says:
      SIOCGIFCONF
             Return  a  list  of interface (transport layer) addresses.
             This currently means only addresses of the AF_INET  (IPv4)
             family for compatibility.  The user passes a ifconf struc-
             ture as argument to the ioctl. It contains a pointer to an
             array  of  ifreq  structures  in ifc_req and its length in
             bytes in ifc_len.  The kernel fills the  ifreqs  with  all
             current  L3 interface addresses that are running: ifr_name
             contains the interface name (eth0:1  etc.),  ifr_addr  the
             address.   The  kernel  returns  with the actual length in
             ifc_len.  If ifc_len is equal to the original  length  the
             buffer probably has overflowed and you should retry with a
             bigger buffer to get all addresses.  When no error  occurs
             the ioctl returns 0; otherwise -1. Overflow is no error.

So - what to do?

We are suggesting to keep the double buffer: memcpy()ing whatever is

coming up into a local buffer which is word-aligned, and handing a

pointer to that copy down in subsequent socket_ioctl() calls. This

doesn't use much space and time and should be safe - no matter what is

coming up in the ifreq array. osiSockDiscoverBroadcastAddresses() isn't

called much anyway.

Jeff: should I commit that patch to the APS repository for 3.14 and the

trunk? Or send it to you first?

The CA data garble issue was solved by applying the patch from Peter

Denison. Do you want me to commit that, too?

Thanks again to both of you for your valuable help!!
Ralph & Ralf

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System