Experimental Physics and
Industrial Control System

Michael Davidsaver via Core-talk <core-talk at aps.anl.gov> · Thu, 18 Nov 2021 08:29:49 -0800

Dirk,

Have you run the unit tests for Base, pvDataCPP, and pvAccessCPP?

On 11/18/21 6:08 AM, Zimoch Dirk (PSI) via Core-talk wrote:
> Hi everybody
> 
> For a while, I have EPICS 7.0.6.1 running on some vxWorks 6.7 IOCs. Now I upgraded one of them to vxWorks 6.9 and get those strange errors:
> 
> Error on UDP RX 172.20.4.25:48599 -> 172.20.255.255:5076 at 47 : no more data in UDP packet : 71:71 for 1
> 0x00 ca024000 27000000 73599561 00000000  ..@. '... sY.a ....
> 0x10 68ab0e1c 00680000 00000000 00000000  h... .h.. .... ....
> 0x20 0000ffff 00000000 3edd0374 6370ff    .... .... >..t cp.
...
> I found the messages to pvAccess/src/remote/blockingUDPTransport.c, but it is hard to understand what it means or why it appears on vxWorks 6.9 but not vxWorks 6.7.

I can't explain this.

This looks like a valid CMD_BEACON packet (see below), which is also implied by
silence from other PVA peers which presumably see this broadcast.

In particular, I don't see how "71" appears.  The message length is 47 bytes
(0x27 body + 8 header).  The fact that 0x47 == 71 is suggestive, but I don't
see where this confusion could be sneaking in.

It also isn't clear to me if this is simply when printing the message, or when
interpreting the packet.

The order of formatting is such that "no more data in UDP packet : 71:71 for 1"
is constructed first using a temporary std::ostringstream.  So I have confidence
that this stream _should_ be set to base 10.

The rest of the message is formatted using std::cerr, so it is possible that the
"47" is base 16.

I'm afraid I don't have any suggestion beyond ensuring that there isn't any mixing
of object code compiled for vx6.7 vs 6.9.

> It may be that I configured something wrong on vxWorks 6.9 as I had to migrate the BSP for the no longer supported architecture from 6.7 to 6.9 and had difficulties to get networking running initially.
> But networking works now and neither CA nor PVA nor NFS show any problems.
> 
> Any ideas? [Looking in Michael's direction]
> 
> Dirk
> 

> 0x00 ca024000 27000000

version=2 CMD_BEACON LSB length=0x27 (39 bytes)
total message length including header is 47 bytes

https://github.com/epics-base/pvAccessCPP/wiki/Protocol-Messages#message-header

https://github.com/epics-base/pvAccessCPP/wiki/Protocol-Messages#cmd_beacon-0x00

>    73599561 00000000
> 0x10 68ab0e1c

GUID 0x735995610000000068ab0e1c
This is consistent w/ pvAccessCPP/Java which use system boot time
as a "unique" ID...
0x61955973 -> Wed Nov 17 11:35:15 2021 PST

>    00680000

flags=0 beaconSequenceId=0x68 changeCount=0

>    00000000 00000000
> 0x20 0000ffff 00000000

server adddress is ::ffff:0.0.0.0
which is expected

>  3edd

port=56638

>  0374 6370

3 byte string "tcp"

>  ff

PVD NULL, which again is allowed

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System