EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Possible Bug in 3.14.9 Access Security on mv2100
From: Steven Hartman <[email protected]>
To: Ralph Lange <[email protected]>
Cc: EPICS Tech Talk <[email protected]>
Date: Wed, 8 Aug 2007 10:46:41 -0400 (EDT)
On Wed, 8 Aug 2007, Ralph Lange wrote:

> Does anyone have similar experiences?

Yes! I have just been investigating the same problem, though my symptoms
are slightly different then yours (and even more strange).

The problem seems to be restricted to 3.14.9 IOCs (do not see it with
3.14.8.2 or 3.13.10). I have observed it with both VxWorks (5.5.1 on
MVME5110-2261 with WRS compilers) and Linux (2.6 kernel, x86) IOCs.

The stranger part is the client access side (using Linux and Solaris
clients).  Some 3.14.9 clients always work as expected (medm, camonitor,
alh, adt, burt).  Other 3.14.9 clients (same host, same user) sometimes
work but usually get a no read access error (caget, StripTool, probe). I
am not seeing any unexpected no write access errors. Caput often shows a
no read access error (from the caget() function) but then a successful
write. All 3.13.10 (Solaris) clients appear to work as expected. I have
not seen any read access errors over channel access from IOC to IOC.

Some additional observations: Linux 3.14.9 caget seems to have a much
higher unexpected no-read access error rate (>90%) then Solaris 3.14.9
caget (<40%).  Passing 2 PVs to caget (one PV on 3.14.9 IOC one on 3.13.10
IOC) always results in a successful read of both PVs.

Not enabling access security on the IOC makes the problem go away. But the
problem appears with an access_security.acf file which is used
successfully for IOCs at other EPICS versions. Even a minimal
access_security.acf file (default read and write access for anyone) shows
this problem. I have not seen any problem of access security not denying
when it should. Access security dump routines are consistent with the
input file and consistent with IOCs at < 3.13.10. I am not using any calc
expressions in this access_security.acf file.

There were changes in the calc expression parser between 3.14.8.2 and
3.14.9 which impacted asLib,
(http://www.aps.anl.gov/epics/base/R3-14/9-docs/RELEASE_NOTES.html), but
given the strange client side behavior, I suspect that this is not where
the problem lies.


-- 
Steve Hartman
[email protected] || 919-660-2650
Duke Free Electron Laser Laboratory

Replies:
Re: Possible Bug in 3.14.9 Access Security on mv2100 Ralph Lange
References:
Possible Bug in 3.14.9 Access Security on mv2100 Ralph Lange

Navigate by Date:
Prev: Possible Bug in 3.14.9 Access Security on mv2100 Ralph Lange
Next: Re: Possible Bug in 3.14.9 Access Security on mv2100 Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Possible Bug in 3.14.9 Access Security on mv2100 Ralph Lange
Next: Re: Possible Bug in 3.14.9 Access Security on mv2100 Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Nov 2011 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·