Client and server unintentionally sharing a UDP source port

[mdavidsaver]

2018-09-27T11:48:07.986 Undecipherable message (bad response type 4) from 127.0.0.1:51856.

I've seen this pop up 4 times during 2 days of stress testing of P4P. I was able to catch one instance with wireshark and confirm that somehow the PVA client is sending UDP searches with the same source port number which the server is listening on. So src.port==dst.port. This causes the server to see it's own replies.

Since the client operation is timing out, I take it that there are two sockets with the same source port. I'm not sure if bind() to port zero can do this?

The structure of these tests is to start the server first, then the client.

            self.server = Server(providers=[self.sprov], isolate=True)
...
            with Context('pva', conf=self.server.conf(), useenv=False, unwrap={}) as ctxt:
                    ...

Where isolate=True is a shorthand for setting the following, which should cause the server to choose a random port by binding to port 0 then finding which ports are used.

{
                'EPICS_PVAS_INTF_ADDR_LIST': '127.0.0.1',
                'EPICS_PVA_ADDR_LIST': '127.0.0.1',
                'EPICS_PVA_AUTO_ADDR_LIST': '0',
                'EPICS_PVA_SERVER_PORT': '0',
                'EPICS_PVA_BROADCAST_PORT': '0',
}

The self.server.conf() is calling https://github.com/epics-base/pvAccessCPP/blob/31261cee24754fd8f1cc2438d2947b535185cd85/src/server/serverContext.cpp#L216-L262 Which is producing a Configuration which can be use to configure a PVA client.

Previously noted on https://github.com/epics-base/pvAccessCPP/issues/104#issuecomment-424910005

[mdavidsaver]

As this is not occurring frequently, it is not a priority for me at present.

[mdavidsaver]

An offending CMD_SEARCH.

Frame 240205: 91 bytes on wire (728 bits), 91 bytes captured (728 bits) on interface 0
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
User Datagram Protocol, Src Port: 51856, Dst Port: 51856
    Source Port: 51856
    Destination Port: 51856
    Length: 57
    Checksum: 0xfe4c [unverified]
    [Checksum Status: Unverified]
    [Stream index: 16515]
Process Variable Access
    Magic: 0xca
    Version: 1
    Flags: 0x00
    Command: SEARCH (0x03)
    Size: 41
    Search Sequence #: 1
    Mask: 0x80
    Address: 00000000000000000000ffff00000000
    Port: 51856
    Transport Protocol: tcp
    CID: 1
    Name: foo

[anjohnson]

Might this issue cause the following error from VxWorks, which was reported to me earlier today:

At VME IOC boot time I get the following error :

2018-09-26T18:29:40.339 Error binding socket 164.54.164.35:5076: S_errno_EADDRINUSE.

I have built synApps and HPApp against base-7.0. In RELEASE.local of areadetector I have uncommented PVADRIVER=$(AREA_DETECTOR)/pvaDriver

What is it that I am doing wrong?

Dr. Arun Bommannavar HPCAT, Sector 16 Argonne, IL 60439 TEL : (630) 252-0497 Email: arun.at.anl.dot.gov

This was apparently from an EPICS 7 IOC build with QSRV and the AreaDetector pvaDriver (but it isn't 100% certain that's what he actually configured).

[mdavidsaver]

Seen again. Same situation.

2019-07-31T11:02:38.147 Undecipherable message (bad response type 4) from 127.0.0.1:48088.