Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Wed, 23 Aug 2006 16:56:56 +0200

The name length -- sizeof(pifreq->ifr_name) -- is 16, correct.

It seems that the network init code writes something strange into the

buffer so that the RTEMS version of the ifrec_size macro fetches junk

trying to look at pifreq->ifr_addr.sa_len and sees a 54 there (adding up

to 70).

Eric Norum wrote:

You need to figure out why ifreq_size is returning the wrong value.

The macro definition for RTEMS (src/libCom/osi/os/RTEMS/osdSock.h) is:

#define ifreq_size(pifreq) (pifreq->ifr_addr.sa_len +

sizeof(pifreq->ifr_name))

You could add some code to check, but I'm pretty sure that

the sizeof(pifreq->ifr_name) is 16. So you need to figure out why

the pifreq->ifr_addr.sa_len is unreasonable. Check the network

driver initialization code and see if it's doing something odd.

On Aug 23, 2006, at 9:05 AM, Ralph Lange wrote:

Hm...

Ralf added some code to osiSockDiscoverBroadcastAddresses() that

memcpy-copies the odd-length ifreq into a word-aligned buffer, then

uses a pointer to this aligned copy to hand to the subsequent calls.

Effect: The RTEMS board boots, doesn't crash, and finds four

interfaces (lo: and eth0: both appear twice), two of which it

recognizes as AF_INET. External CA clients can connect, but get junk

in the monitor updates (time stamp and data are garbled).

I'm not sure what exactly you did here. Did you modify ifreqNext to

always use sizeof (*pifreq) as the offset to the next address entry?

I can't see how you could step through the addresses otherwise.

There's an additional local buffer, word-aligned. After stepping through

the array using ifreqNext, we're memcpy'ing from pifreq to our buffer,

using the same algorithm as ifreqNext to determine the number of bytes

to copy. That way we're creating an additional local copy of the ifreq

entry with the only difference of the pointer to it always being

word-aligned.

So it seems that the returned ifreq length of 70 for the first

interface really is the reason for crashing on the second entry which

is not aligned.

Yes, likely because the 70 is ridiculous and you end up looking at

some random memory contents for the second entry.

Well - we are identifying all network interfaces on the ARM board using

the original ifreqNext and our word-aligned copies. All the names are

there. So I guess it can't be really random memory. Is 70 really that

ridiculous? I mean, it does sound so, but why are we finding all

interfaces using that big step of 70 after the first ifreq entry?

Would you see the additional buffer as an adequate way to handle

this? (Probably not...)

If not, where in the BSD network code would we have to add the padding?

I don't think that this is an issue of padding. It's an issue of a

bad sa_len getting in there somewhere.

If you have the ability to put in watchpoints it would be useful to

see each time that memory location was written to.

Yes. No watchpoints, though. Ralf is trying to figure out looking at the

code who is filling the buffer with what, why, when, and where. Not a

trivial task.

Thanks for your help, which is greatly appreciated!
Ralph & Ralf

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System