Re: PVA Gateway (p4p) is Missing some Status PVs

["Murray, Doug via Core-talk" <core-talk at aps.anl.gov>]

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.

 

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