EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
2002  2003  2004  2005  <2006>  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  <2006>  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>
Subject: Re: osiSockDiscoverBroadcastAddresses(): pointer not word-aligned?
From: Eric Norum <[email protected]>
To: Ralph Lange <[email protected]>
Cc: Jeff Hill <[email protected]>, "'EPICS Core Talk'" <[email protected]>, "'Ralf Hartmann'" <[email protected]>
Date: Wed, 23 Aug 2006 09:38:02 -0500
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.


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.


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.


-- 
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793

Replies:
Re: osiSockDiscoverBroadcastAddresses(): pointer not word-aligned? Ralph Lange
References:
RE: osiSockDiscoverBroadcastAddresses(): pointer not word-aligned? Jeff Hill
Re: osiSockDiscoverBroadcastAddresses(): pointer not word-aligned? Ralph Lange
Navigate by Date:
Prev: Re: osiSockDiscoverBroadcastAddresses(): pointer not word-aligned? Andrew Johnson
Next: Re: osiSockDiscoverBroadcastAddresses(): pointer not word-aligned? Ralph Lange
Index: 2002  2003  2004  2005  <2006>  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: osiSockDiscoverBroadcastAddresses(): pointer not word-aligned? Ralph Lange
Next: Re: osiSockDiscoverBroadcastAddresses(): pointer not word-aligned? Ralph Lange
Index: 2002  2003  2004  2005  <2006>  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·