Experimental Physics and
Industrial Control System

Michael Davidsaver via Core-talk <core-talk at aps.anl.gov> · Fri, 25 Aug 2023 16:43:03 +0200

On 8/25/23 06:39, Murray, Doug wrote:

Hi Michael

The gethostbyname() is failing because it is being passed ‘[‘ as the hostname.

I should have included this trace; I haven’t had a chance to look much further.

Ah, well.  I see where the problem is:

https://github.com/mdavidsaver/p4p/blob/37747cf1c495e997a4c4bf67a8eba9a37c50a665/src/p4p/gw.py#L439

still assumes IPv4 addressing.  (sigh... more IPv6 fun)  This may not be so quick to fix.
The ACF logic needs to account for the ambiguity of IPv4 vs. IPv4 mapped into IPv6.

In the interim, disabling IPv6 on that host would avoid the issue.

sudo sysctl net.ipv6.conf.all.disable_ipv6=1

fyi. At the moment, PVXS detects runtime IPv6 support by attempting to bind to "::1".
I see now that I should add another, PVXS specific, way to do so.

2023-08-25 06:26:09,257 | p4p.server.thread: ERROR - Unexpected

Traceback (most recent call last):

   File "/afs/slac.stanford.edu/u/drm/work/p4p/bin/rhel6-x86_64/../../python3.6m/rhel6-x86_64/p4p/server/thread.py", line 19, in _on_queue

     M(*args)

   File "/afs/slac.stanford.edu/u/drm/work/p4p/bin/rhel6-x86_64/../../python3.6m/rhel6-x86_64/p4p/gw.py", line 35, in rpc

     ret = fn(self, op, **dict(op.value().query.items()))

   File "/afs/slac.stanford.edu/u/drm/work/p4p/bin/rhel6-x86_64/../../python3.6m/rhel6-x86_64/p4p/gw.py", line 445, in asTest

     peer = socket.gethostbyname(peer)

socket.gaierror: [Errno -2] Name or service not known

But I did add a print stmt in asTest which shows that op.peer is *[::ffff:134.79.216.6]:43960* explaining why ‘peer’ is “[“ after the split(‘:’)[0]

cheers

-doug

*From: *Michael Davidsaver <mdavidsaver at gmail.com>
*Date: *Thursday, August 24, 2023 at 10:42 PM
*To: *Murray, Doug <drm at slac.stanford.edu>
*Cc: *Heinz Junkes <junkes at fhi-berlin.mpg.de>, EPICS CoreTalk <core-talk at aps.anl.gov>
*Subject: *Re: PVA Gateway (p4p) is Missing some Status PVs

On 8/24/23 13:43, Murray, Doug wrote:

Thanks Heinz,

I just pulled the latest p4p (also version 4.1.10) and :cache is working fine for me now!

The ds:byhost:tx is doing something different,

failing on a call to gethostbyname() in gw.py,

Do you have a stack trace for this?

I like DNS names, but only when they arrive promptly.  Which may not be the
case with gethostbyname().  So as a general rule, I try to avoid lookups
after startup.

where the name is set to ‘[‘.  Why am I thinking this looks like IPv5? 😉 I’ll look into my network setup here…

drm@aird-b50-srv01 01:30 PM 1187>pvget PGW:LCLSPB:ds:byhost:tx

PGW:LCLSPUB:ds:byhost:tx 2023-08-24 13:31:01.656

Account                        Client "TX (B/s)"

      drm [::ffff:134.79.120.20]:52372    43.7333

      drm [::ffff:134.79.216.24]:35854    5.93333

      drm  [::ffff:134.79.216.6]:42150    5.93333

cheers

-doug

*From: *Heinz Junkes <junkes at fhi-berlin.mpg.de>
*Date: *Thursday, August 24, 2023 at 1:01 PM
*To: *Michael Davidsaver <mdavidsaver at gmail.com>
*Cc: *Murray, Doug <drm at slac.stanford.edu>, EPICS CoreTalk <core-talk at aps.anl.gov>
*Subject: *Re: PVA Gateway (p4p) is Missing some Status PVs

I can confirm that with p4p version: 4.1.10

(base) hactar:~ junkes$ pvget FHIFEL:PVA_GW:STS:cache

FHIFEL:PVA_GW:STS:cache <undefined>              []

Still an empty list there.

(base) hactar:~ junkes$ pvget FHIFEL:PVA_GW:STS:ds:byhost:tx

FHIFEL:PVA_GW:STS:ds:byhost:tx 2023-08-24 21:54:49.296

Account              Client  "TX (B/s)"

wieland 141.14.64.252:61925 1.20526e+06

But ds:byhost:tx is ok.

Heinz

     On 24. Aug 2023, at 11:43, Michael Davidsaver via Core-talk <core-talk at aps.anl.gov> wrote:

     On 8/23/23 09:56, Murray, Doug wrote:

         We’ve been setting up the latest version of the p4p PVA Gateway (R4.1.9) and have noticed that a couple status PVs are no longer providing expected results.
           * The *<statusprefix>cache* PV always returns an empty list, but previously provided “a list of channels to which the GW Client is connected”.

     This was an oversight when porting to PVXS.  I had a couple of TODO items
     which did not get marked as such.

    https://github.com/mdavidsaver/p4p/commit/2930d9fcc0370ef3f292f5d24a46d1b4ef98f314#diff-8061cbf72533fa48d08f5f9891a94f5ebeaaffbba7f9e5cdae7aa10d594d09deR945 <https://github.com/mdavidsaver/p4p/commit/2930d9fcc0370ef3f292f5d24a46d1b4ef98f314#diff-8061cbf72533fa48d08f5f9891a94f5ebeaaffbba7f9e5cdae7aa10d594d09deR945>

           * The *<statusprefix>ds:byhost:tx* PV always provides the same client host address as 255.255.255.255, regardless of the client’s true IP address.

     Can you provide some more detail?

     My usual testing is all on one host with different ports.  So I can see
     how I might not notice an issue like this.  However, I can check the port
     numbers with the output of `netstat -tpn`.  From what I see, I think the
     IP:port reported by in the ds: and us: tables are socket peer addresses.

         These were working well in previous versions.  Has anybody else encountered this?
         cheers
         -doug
         SLAC

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System