| 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 2025 | 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 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Interpreting pvget -d |
| From: | "Shankar, Murali via Tech-talk" <tech-talk at aps.anl.gov> |
| To: | Michael Davidsaver <mdavidsaver at gmail.com> |
| Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
| Date: | Fri, 11 Dec 2020 18:18:50 +0000 |
|
Thanks, I will switch to wireshark and comparing packet traces.
>> Is
the image meant to be "empty"?
I don't think it is empty. I think the "value" always has data.
>> Also,
can I take it that you see no timeouts when directly connecting
Yes; I think a direct connection in the IOC's VLAN consistently has a valid response. There is some evidence that there's a duplicate route out there somewhere; we're trying to track it down...
Thanks for the assist.
Regards,
Murali
From: Michael Davidsaver <mdavidsaver at gmail.com>
Sent: Thursday, December 10, 2020 10:38 PM To: Shankar, Murali <mshankar at slac.stanford.edu> Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov> Subject: Re: Interpreting pvget -d 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 > |