On 12/10/20 10:05 AM, Shankar, Murali via Tech-talk wrote:
> Hello,
>
> We have a image that I believe is being accessed thru the gateway (one in a swarm of gateways, each proxying a different VLAN). I have some funky behavior that is probably a config issue. I am trying to interpret the output of pvget -d.
If it is feasible, you might do better to compare packet captures.
The output of '-d' doesn't seem to have enough detail in this case.
cf. https://github.com/mdavidsaver/cashark
> wireshark -X lua_script:pva.lua
> Without the -d, the behavior is as follows. Sometimes, I get this (the valid response)
> $ pvget -r dimension SL1K2:EXIT:CAM:DATA1:Pva:Image
> SL1K2:EXIT:CAM:DATA1:Pva:Image epics:nt/NTNDArray:1.0
> union value
> (none)
> codec_t codec
Is the image meant to be "empty"?
(It shouldn't make any difference)
Also, can I take it that you see no timeouts when directly connecting
to the IOC/server in question?
>
> Othertimes I get this (an invalid response)
> $ pvget -r dimension SL1K2:EXIT:CAM:DATA1:Pva:Image
> SL1K2:EXIT:CAM:DATA1:Pva:Image $
>
> And sometimes, I get a timeout.
>
>
> With a -d, the valid response looks like so
> $ pvget -d -r dimension SL1K2:EXIT:CAM:DATA1:Pva:Image
> 2020-12-10T09:50:38.242 Creating datagram socket from: 0.0.0.0:56065.
> 2020-12-10T09:50:38.242 Broadcast address #0: 172.21.159.255:5076. (not unicast)
> 2020-12-10T09:50:38.242 Broadcast address #1: 172.21.55.255:5076. (not unicast)
> 2020-12-10T09:50:38.242 Setting up UDP for interface 172.21.156.41/255.255.252.0, broadcast 172.21.159.255, dest <none>.
> 2020-12-10T09:50:38.242 Creating datagram socket from: 172.21.156.41:5076.
> 2020-12-10T09:50:38.242 Creating datagram socket from: 172.21.159.255:5076.
> 2020-12-10T09:50:38.242 Setting up UDP for interface 172.21.52.78/255.255.252.0, broadcast 172.21.55.255, dest <none>.
> 2020-12-10T09:50:38.242 Creating datagram socket from: 172.21.52.78:5076.
> 2020-12-10T09:50:38.242 Creating datagram socket from: 172.21.55.255:5076.
> 2020-12-10T09:50:38.242 Creating datagram socket from: 224.0.0.128:5076.
> 2020-12-10T09:50:38.242 Local multicast enabled on 127.0.0.1/224.0.0.128:5076.
> 2020-12-10T09:50:38.242 Sending 76 bytes 0.0.0.0:56065 -> 172.21.159.255:5076.
> 2020-12-10T09:50:38.242 Sending 76 bytes 0.0.0.0:56065 -> 172.21.55.255:5076.
> 2020-12-10T09:50:38.242 UDP Client Rx (76) 172.21.159.255:5076 <- 172.21.156.41:56065
> Waiting...
> 2020-12-10T09:50:38.242 UDP Client Rx (76) 172.21.55.255:5076 <- 172.21.52.78:56065
> 2020-12-10T09:50:38.243 UDP Client Rx (53) 0.0.0.0:56065 <- 172.21.156.251:60975
> 2020-12-10T09:50:38.243 Connecting to PVA server: 172.21.156.251:58333.
> 2020-12-10T09:50:38.243 Opening socket to PVA server 172.21.156.251:58333, attempt 1.
> 2020-12-10T09:50:38.243 Socket connected to PVA server: 172.21.156.251:58333.
> 2020-12-10T09:50:38.243 Acquiring transport to 172.21.156.251:58333.
> 2020-12-10T09:50:38.245 Connected to PVA server: 172.21.156.251:58333.
> SL1K2:EXIT:CAM:DATA1:Pva:Image epics:nt/NTNDArray:1.0
> union value
> (none)
> codec_t codec
> ...
> string format
> string units
> 2020-12-10T09:50:38.257 Releasing TCP transport to 172.21.156.251:58333.
> 2020-12-10T09:50:38.258 TCP socket to 172.21.156.251:58333 is to be closed.
> 2020-12-10T09:50:38.258 UDP socket 0.0.0.0:0 closed.
>
> The invalid response looks like so
>
> $ pvget -d -r dimension SL1K2:EXIT:CAM:DATA1:Pva:Image
> 2020-12-10T09:50:41.262 Creating datagram socket from: 0.0.0.0:36324.
> 2020-12-10T09:50:41.262 Broadcast address #0: 172.21.159.255:5076. (not unicast)
> 2020-12-10T09:50:41.262 Broadcast address #1: 172.21.55.255:5076. (not unicast)
> 2020-12-10T09:50:41.262 Setting up UDP for interface 172.21.156.41/255.255.252.0, broadcast 172.21.159.255, dest <none>.
> 2020-12-10T09:50:41.262 Creating datagram socket from: 172.21.156.41:5076.
> 2020-12-10T09:50:41.263 Creating datagram socket from: 172.21.159.255:5076.
> 2020-12-10T09:50:41.263 Setting up UDP for interface 172.21.52.78/255.255.252.0, broadcast 172.21.55.255, dest <none>.
> 2020-12-10T09:50:41.263 Creating datagram socket from: 172.21.52.78:5076.
> 2020-12-10T09:50:41.263 Creating datagram socket from: 172.21.55.255:5076.
> 2020-12-10T09:50:41.263 Creating datagram socket from: 224.0.0.128:5076.
> 2020-12-10T09:50:41.263 Local multicast enabled on 127.0.0.1/224.0.0.128:5076.
> 2020-12-10T09:50:41.263 Sending 76 bytes 0.0.0.0:36324 -> 172.21.159.255:5076.
> 2020-12-10T09:50:41.263 Sending 76 bytes 0.0.0.0:36324 -> 172.21.55.255:5076.
> 2020-12-10T09:50:41.263 UDP Client Rx (76) 172.21.159.255:5076 <- 172.21.156.41:36324
> Waiting...
> 2020-12-10T09:50:41.263 UDP Client Rx (76) 172.21.55.255:5076 <- 172.21.52.78:36324
> 2020-12-10T09:50:41.263 UDP Client Rx (53) 0.0.0.0:36324 <- 172.21.156.251:60975
> 2020-12-10T09:50:41.263 Connecting to PVA server: 172.21.156.251:58333.
> 2020-12-10T09:50:41.263 Opening socket to PVA server 172.21.156.251:58333, attempt 1.
> 2020-12-10T09:50:41.264 Socket connected to PVA server: 172.21.156.251:58333.
> 2020-12-10T09:50:41.264 Acquiring transport to 172.21.156.251:58333.
> 2020-12-10T09:50:41.266 Connected to PVA server: 172.21.156.251:58333.
> 2020-12-10T09:50:41.266 UDP Client Rx (53) 0.0.0.0:36324 <- 172.21.156.20:48998
> SL1K2:EXIT:CAM:DATA1:Pva:Image 2020-12-10T09:50:41.276 Releasing TCP transport to 172.21.156.251:58333.
> 2020-12-10T09:50:41.276 TCP socket to 172.21.156.251:58333 is to be closed.
> 2020-12-10T09:50:41.276 UDP socket 0.0.0.0:0 closed.
>
>
> The only different I see is this extra 2020-12-10T09:50:41.266 UDP Client Rx (53) 0.0.0.0:36324 <- 172.21.156.20:48998 in the invalid response.
>
>
> How would I interpret this? I think we are taking to the same gateway (TCP socket to 172.21.156.251:58333 ) but I can't explain the two different responses. Any help is appreciated.
>
> Regards,
> Murali
>
- Replies:
- Re: Interpreting pvget -d Shankar, Murali via Tech-talk
- References:
- Interpreting pvget -d Shankar, Murali via Tech-talk
- Navigate by Date:
- Prev:
Re: Timestamping Confusion Michael Davidsaver via Tech-talk
- Next:
Re: pvput to channelName of NTMultiChannel is having colon parsed Paduan Donadio, Marcio via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Interpreting pvget -d Shankar, Murali via Tech-talk
- Next:
Re: Interpreting pvget -d Shankar, Murali via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
| 
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·