Re: osiSockDiscoverBroadcastAddresses(): pointer not word-aligned?

[Ralph Lange <Ralph.Lange@bessy.de>]

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