Experimental Physics and
Industrial Control System

"Zimoch Dirk \(PSI\) via Core-talk" <core-talk at aps.anl.gov> · Fri, 19 Nov 2021 14:05:09 +0000

I cross-checked with printf and found that the 47 is indeed hex!

I also found that the FIRST message is:
Error on UDP RX 172.20.4.26:57620 -> 172.20.255.255:5076 at 71 : no more data in UDP packet : 71:71 for 1

But all the next messages are:
Error on UDP RX 172.20.2.154:49166 -> 172.20.255.255:5076 at 47 : no more data in UDP packet : 71:71 for 1

The reason is HexDump operator << which switches the output stream to hex and leaves it like that.

I have run tests for libCom, pvData and pvAccess and they succeed.
BTW: Some other tests harnesses require dbd files like linkTest.dbd that do not get installed (even though the *Harness.munch files are installed).

> -----Ursprüngliche Nachricht-----
> Von: Zimoch Dirk (PSI)
> Gesendet: Freitag, 19. November 2021 09:56
> An: 'Michael Davidsaver' <mdavidsaver at gmail.com>
> Cc: 'core-talk at aps.anl.gov' <core-talk at aps.anl.gov>
> Betreff: AW: Strange UDP message on VxWorks 6.9
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Michael Davidsaver <mdavidsaver at gmail.com>
> > Gesendet: Donnerstag, 18. November 2021 17:30
> > An: Zimoch Dirk (PSI) <dirk.zimoch at psi.ch>
> > Cc: 'core-talk at aps.anl.gov' <core-talk at aps.anl.gov>
> > Betreff: Re: Strange UDP message on VxWorks 6.9
> >
> > Dirk,
> >
> > Have you run the unit tests for Base, pvDataCPP, and pvAccessCPP?
> 
> Not on vxWorks.
> 
> >
> >
> > 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 can check that by using printf. Just to be sure.
> I find it difficult to debug because I do not know which function has originally
> called the function that throws the exception. Maybe I abort() rather than throw
> and have a look at the call stack.
> 
> >
> > 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.
> 
> There isn't. Otherwise this would most probably not be the only problem.
> 
> >
> >
> > > 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