invalid DBR type not screened in client library when doing a put

[Jeff Hill]

Based on the latest R3.13 sources, and assuming that they are doing a put (I didn’t look at the source for put callback) I see that the server is validating the incoming request message and disconnecting the client if one of the following is true.

O The channel identifier specified in the put request message is invalid
O The data type specified in the put request message is invalid

Based on the "type=DBR_invalid" diagnostic in the exception we can guess that it’s the latter.

I had a look at the R3.14 source code and I see that the data type identifier screening that was in the R3.13 client library was in fact dropped on the editing room floor when the ca client library was split into 3 parts: old API replicating, network remoting service, and an in memory db service.

I will need to create an entry in Mantis.

I will need to check the put callback, get, get callback, and subscribe request stubs to see if they might suffer from similar vulnerabilities.

Jeff

> -----Original Message-----
> From: Andrew Johnson
> Sent: Tuesday, March 14, 2006 9:00 AM
> To: Jeff Hill
> Subject: [Fwd: CA Question]
>
> Hi Jeff,
>
> Can you work out what might be going on from the messages below - the
> IOC iocinjtime is an R3.13.10 IOC, and the tcl script client is most
> probably using R3.14.7, although it might be R3.14.8.2. I looked up the
> IOC message in the rsrv source, which occurs "when there are severe
> message errors"; I wondered if there is anything useful you can extract
> from the client side messages?
>
> The IOC has been running happily since January 10th. We're pretty sure
> that OAG changed their tcl script since it was last used, and this is
> probably a direct result of that, but it seems strange that they're able
> to generate this kind of effect from high level tcl code.
>
> Thanks,
>
> - Andrew
>
> -------- Original Message --------
> Subject: CA Question
> Date: Tue, 14 Mar 2006 05:55:34 -0600
> From: Frank Lenkszus <email address hidden>
> Organization: Advanced Photon Source
> To: <email address hidden>
> CC: Ned Arnold <email address hidden>, Frank Lenkszus <email address hidden>
>
> Andrew,
>
> Ops had problems with a PV this morning:
>
> escription----Per Louis Emery: A PV It:Ddg2chan6.GATE is connected
> to a tcl variable in a tcl script. When it comes time (in about 2
> minutes) to put a value, we get this error message: CA exception
> handler entered CA status=Virtual circuit disconnect CA
> context=iocinjtime:5064 CA op=5 data type=DBR_invalid count=0 CA
> exception handler entered CA channel name=It:Ddg2chan6.GATE CA
> status=Virtual circuit disconnect CA context=iocinjtime:5064 CA op=1
> data type=DBR_invalid count=0
>
> Looking at iocConsole on iocinjtime I see:
>
> iocinjtime> 0x438708 (CA_client): CAS: forcing disconnect from
> 164.54.2.131:57072
> 0x438708 (CA_client): CAS: forcing disconnect from 164.54.2.131:57078
> 0x438708 (CA_client): CAS: forcing disconnect from 164.54.2.131:57083
> 0x438708 (CA_client): CAS: forcing disconnect from 164.54.2.131:57084
> 0x438708 (CA_client): CAS: forcing disconnect from 164.54.2.131:57100
>
> 2006-03-14 03:00 iocinjtime> 0x438708 (CA_client): CAS: forcing
> disconnect from 164.54.2.131:57202
> 0xf7af4 (CA_client): CAS: forcing disconnect from 164.54.2.131:56611
> 0xf7af4 (CA_client): CAS: forcing disconnect from 164.54.2.131:57280
>
> What does the message mean.
>
>
> --
> There is no S in exprexxo.

Original Mantis Bug: mantis-242
    http://www.aps.anl.gov/epics/mantis/view_bug_page.php?f_id=242

[Jeff Hill (johill-lanl)]

It seems to work okay if using ca_array_put but fails when using
ca_sg_array_put. We will be rebooting the IOC the next chance we get to
see if anything changes.

--Bob Soliday

[Jeff Hill (johill-lanl)]

> It seems to work okay if using ca_array_put but fails when using
> ca_sg_array_put. We will be rebooting the IOC the next chance we get
> to see if anything changes.

This is hard to explain because, as I recall, ca_sg_array_put is layered on top of ca_array_put.

[Jeff Hill (johill-lanl)]

I was just informed that the IOC was rebooted yesterday and the problem
has disappeared. Our CA code has not been changed.

--Bob

[Jeff Hill (johill-lanl)]

committed a fix

[Andrew Johnson (anj)]

I think it's safe to assume this bug has been fixed — no repetition in 3 years and Jeff did say he committed a fix for it back in 2006.

[Andrew Johnson (anj)]

R3.14.11 released.