AW: Strange UDP message on VxWorks 6.9

["Zimoch Dirk \(PSI\) via Core-talk" <core-talk at aps.anl.gov>]

> -----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