Experimental Physics and
Industrial Control System

Michael Davidsaver via Core-talk <core-talk at aps.anl.gov> · Fri, 19 Nov 2021 12:26:49 -0800

On 11/19/21 6:05 AM, Zimoch Dirk (PSI) wrote:
> 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

You have omitted the two hex dumps, which I will assume means that
they were identical in length and content.

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

Well, this inconsistency is explain at least.

However, it doesn't explain where the buffer length of 71 bytes comes from,
and why it is not consistent with the the message dump shown.

> 0x00 ca024000 27000000 ...

This CMD_BEACON message should have only 47 (0x2f) bytes which is consistent
with the following from your original mail.

> 0x00 ca024000 27000000 73599561 00000000  ..@. '... sY.a ....
> 0x10 68ab0e1c 00680000 00000000 00000000  h... .h.. .... ....
> 0x20 0000ffff 00000000 3edd0374 6370ff    .... .... >..t cp.

> I have run tests for libCom, pvData and pvAccess and they succeed.

Ok, this rules out some possibilities.

> BTW: Some other tests harnesses require dbd files like linkTest.dbd that do not get installed (even though the *Harness.munch files are installed).

I'll defer this to Andrew.

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