Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: Re: Update CAJ to catch empty PV name
From: Andrew Johnson <anj@aps.anl.gov>
To: "Kasemir, Kay" <kasemirk@ornl.gov>, "matej.sekoranja@cosylab.com" <matej.sekoranja@cosylab.com>, EPICS core-talk <core-talk@aps.anl.gov>
Date: Mon, 8 May 2017 15:34:26 -0500
On 05/08/2017 02:59 PM, Kasemir, Kay wrote:
>> On 05/08/2017 02:22 PM, matej.sekoranja@cosylab.com wrote:
>>> Actually empty name check is already done in CAJ (see CAJContext.java,
>>> createChannel method):
> 
> Matej is correct.
> While the JCAChannel would allow a zero length PV name, the CAJContext
> wouldn't actually hand you such a channel.
> I see now that even if CS-Studio code tries to get a zero length PV from
> the CAJ lib, it will instead see
>  java.lang.IllegalArgumentException: null or empty channel name
> 	at com.cosylab.epics.caj.CAJContext.createChannel(CAJContext.java:942)
> 
> Based on the tech-talk message
> http://www.aps.anl.gov/epics/tech-talk/2017/msg00714.php and our own CA
> gateway log showing the same "zero length PV name in UDP search request?"
> error, originating from a CS-Studio client, I erroneously assumed we'd
> create such empty PV names on purpose.
> 
>>> If it wasn't added recently, how was it
>>> possible for CS-Studio to be sending out requests for zero-length names
>>> over the network?
>> Bug in constructing search request messages?
>>> Does Java's String class permit '\0' characters to be
>>> included in the string perhaps?
>> Yes, it does.
> 
> Would it make sense to add code to the CAJ client code that constructs
> search messages to guard against empty or "\000" PV names?
> That way we'd get a stack trace the next time the CAJ client tries to send
> such malformed search requests.

CAJ should reject any PV name that starts with a \0 character. Both the
RSRV and PCAS servers will reject names with a leading \0, and will
truncate a name at the first \0 they see after the first character, but
from CAS code comments it looks like it isn't illegal for non-zero
characters to follow a terminating \0 since older client versions might
not zero-fill their payload buffer.

> Finally, it's also possible that the PCAS server lib has a bug, i.e. the
> search requests aren't really for empty PV names.

There must be a bug somewhere since the gateway shouldn't be looping
when it sees a bad name request like was originally reported. The CAS
code looks right but whether the problem is in the CAS or the Gateway I
don't know. I did file a bug report against the Gateway since the CAS
code looks right at that point.

I believe Michael has some Python code for testing the CA protocol; this
would probably be a good test to add to that.

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Navigate by Date:
Prev: Re: windows build/test failures Andrew Johnson
Next: Build failed in Jenkins: epics-base-3.16-mac-test #97 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
Navigate by Thread:
Prev: Jenkins build is back to normal : epics-base-3.16-win64s #107 APS Jenkins
Next: Build failed in Jenkins: epics-base-3.16-mac-test #97 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
ANJ, 08 May 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·