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
22.214.171.124 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
IOC) always results in a successful read of both PVs.
Not enabling access security on the IOC makes the problem go away.
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)
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
expressions in this access_security.acf file.
There were changes in the calc expression parser between 126.96.36.199 and
3.14.9 which impacted asLib,
given the strange client side behavior, I suspect that this is not where
the problem lies.