Closed anjohnson closed 5 years ago
Please run
pvget -d anj:BaseVersion
Also, do you have any unit test failures in this configuration?
Anything distinguishing about the network configuration? (eg. multiple NICs, vlans, vpns, wifi)
PVA has it's own network interface discovery code. For which WIN32 is a special case. I've never tried to compare the WIN32 version with the one in Base. FYI, it's similar to what is in Base, but slightly more general. I'd like eventually to replace it with https://code.launchpad.net/~epics-core/epics-base/+git/osiaddrinfo/+merge/320279
Just to be clear. Does a MSVC build, run on the same host find interfaces?
I haven't tried MSVC yet, will be doing that shortly. This is with a linux IOC running on 164.54.9.24, which is in the same subnet as this PC on 8.217:
C:\epics\base-7.0>pvget -d anj:BaseVersion
2018-07-02T10:42:42.301 Client security plug-in 'ca' installed.
2018-07-02T10:42:42.302 Creating datagram socket to: 0.0.0.0:0.
2018-07-02T10:42:42.303 No broadcast addresses found or specified - empty address list!
2018-07-02T10:42:42.303 Setting up UDP for interface 164.54.8.217, broadcast 164.54.11.255, dest 0.0.0.0.
2018-07-02T10:42:42.303 Creating datagram socket to: 164.54.8.217:5076.
2018-07-02T10:42:42.304 Creating datagram socket to: 0.0.0.0:5076.
2018-07-02T10:42:42.304 Local multicast enabled on 127.0.0.1/224.0.0.128:5076.
Waiting...
Timeout
Done
2018-07-02T10:42:45.309 UDP socket 0.0.0.0:0 closed.
2018-07-02T10:42:45.309 UDP socket 164.54.8.217:5076 closed.
2018-07-02T10:42:45.309 UDP socket 0.0.0.0:5076 closed.
The unit tests all pass except for the isnan(NaN)
issue in epicsCalcTest that I already fixed on the 3.15 branch.
Ok, wtf... Is this a regression? Has PVA worked previously on these hosts, with the current network config? Also, please run ip link
and ip route
on the Linux host.
Also ip addr
please (ip link
doesn't actually tell me anything I care about here).
For reference, from my (Linux) laptop.
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: wlp58s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 9c:b6:d0:f3:0c:79 brd ff:ff:ff:ff:ff:ff
inet 198.129.217.138/21 brd 198.129.223.255 scope global dynamic wlp58s0
valid_lft 5299sec preferred_lft 5299sec
inet6 fe80::fef8:8fa:5d15:5c6c/64 scope link
valid_lft forever preferred_lft forever
3: tap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 2e:38:76:e8:6c:e2 brd ff:ff:ff:ff:ff:ff
inet 10.0.142.1/24 brd 10.0.142.255 scope global tap0
valid_lft forever preferred_lft forever
$ ip route
default via 198.129.216.1 dev wlp58s0 proto static metric 600
10.0.142.0/24 dev tap0 proto kernel scope link src 10.0.142.1 linkdown
169.254.0.0/16 dev tap0 scope link metric 1000 linkdown
198.129.37.13 via 198.129.216.1 dev wlp58s0 proto dhcp metric 600
198.129.216.0/21 dev wlp58s0 proto kernel scope link src 198.129.217.138 metric 600
$ pvget -d foo
2018-07-02T09:33:07.162 Client security plug-in 'ca' installed.
2018-07-02T09:33:07.163 Creating datagram socket to: 0.0.0.0:0.
2018-07-02T09:33:07.163 Broadcast address #0: 198.129.223.255:5076.
2018-07-02T09:33:07.163 Broadcast address #1: 10.0.142.255:5076.
2018-07-02T09:33:07.163 Setting up UDP for interface 198.129.217.138, broadcast 198.129.223.255, dest 198.129.223.255.
2018-07-02T09:33:07.163 Creating datagram socket to: 198.129.217.138:5076.
2018-07-02T09:33:07.163 Creating datagram socket to: 198.129.223.255:5076.
2018-07-02T09:33:07.163 Setting up UDP for interface 10.0.142.1, broadcast 10.0.142.255, dest 10.0.142.255.
2018-07-02T09:33:07.163 Creating datagram socket to: 10.0.142.1:5076.
2018-07-02T09:33:07.163 Creating datagram socket to: 10.0.142.255:5076.
2018-07-02T09:33:07.164 Creating datagram socket to: 224.0.0.128:5076.
2018-07-02T09:33:07.164 Local multicast enabled on 127.0.0.1/224.0.0.128:5076.
2018-07-02T09:33:07.164 Sending 49 bytes to 198.129.223.255:5076.
2018-07-02T09:33:07.164 Sending 49 bytes to 10.0.142.255:5076.
...
The problem is with the latest Windows a newer version of gcc (7.1.0) with a newer StrawberryPerl and MinGW than I have tested before. The PC was previously running Windows 7 and an older StrawberryPerl, gcc and minGW.
This is the config of the Linux box that was running the IOC I was testing pvget against, which works quite happily:
tux% ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 6c:3b:e5:2f:fd:7e brd ff:ff:ff:ff:ff:ff
inet 164.54.9.24/22 brd 164.54.11.255 scope global noprefixroute dynamic eth0
valid_lft 580694sec preferred_lft 580694sec
inet6 fe80::6e3b:e5ff:fe2f:fd7e/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 6c:3b:e5:2f:fd:7f brd ff:ff:ff:ff:ff:ff
tux% ip route
default via 164.54.8.1 dev eth0 proto dhcp metric 100
164.54.8.0/22 dev eth0 proto kernel scope link src 164.54.9.24 metric 100
tux% pvget -d anj:BaseVersion
2018-07-02T11:44:45.450 Client security plug-in 'ca' installed.
2018-07-02T11:44:45.450 Creating datagram socket to: 0.0.0.0:0.
2018-07-02T11:44:45.450 Broadcast address #0: 164.54.11.255:5076.
2018-07-02T11:44:45.451 Setting up UDP for interface 164.54.9.24, broadcast 164.54.11.255, dest 164.54.11.255.
2018-07-02T11:44:45.451 Creating datagram socket to: 164.54.9.24:5076.
2018-07-02T11:44:45.451 Creating datagram socket to: 164.54.11.255:5076.
2018-07-02T11:44:45.451 Creating datagram socket to: 224.0.0.128:5076.
2018-07-02T11:44:45.451 Local multicast enabled on 127.0.0.1/224.0.0.128:5076.
2018-07-02T11:44:45.451 Sending 61 bytes to 164.54.11.255:5076.
Waiting...
2018-07-02T11:44:45.452 Connecting to PVA server: 164.54.9.24:5075.
2018-07-02T11:44:45.452 Opening socket to PVA server 164.54.9.24:5075, attempt 1.
2018-07-02T11:44:45.452 Socket connected to PVA server: 164.54.9.24:5075.
2018-07-02T11:44:45.452 Acquiring transport to 164.54.9.24:5075.
2018-07-02T11:44:45.453 Connected to PVA server: 164.54.9.24:5075.
[anj:BaseVersion] channel get create: Status [type=OK]
[anj:BaseVersion] channel get: Status [type=OK]
anj:BaseVersion 7.0.1.2-DEV
Done
2018-07-02T11:44:45.456 Releasing TCP transport to 164.54.9.24:5075.
2018-07-02T11:44:45.456 TCP socket to 164.54.9.24:5075 is to be closed.
2018-07-02T11:44:45.456 UDP socket 0.0.0.0:0 closed.
2018-07-02T11:44:45.456 UDP socket 164.54.9.24:5076 closed.
2018-07-02T11:44:45.456 UDP socket 164.54.11.255:5076 closed.
2018-07-02T11:44:45.456 UDP socket 224.0.0.128:5076 closed.
Same problem with the MSVS-2017 build:
C:\epics\base-7.0>caget anj:BaseVersion
anj:BaseVersion 7.0.1.2-DEV
C:\epics\base-7.0>pvget -d anj:BaseVersion
2018-07-02T11:46:43.758 Client security plug-in 'ca' installed.
2018-07-02T11:46:43.759 Creating datagram socket to: 0.0.0.0:0.
2018-07-02T11:46:43.760 No broadcast addresses found or specified - empty address list!
2018-07-02T11:46:43.760 Setting up UDP for interface 164.54.8.217, broadcast 164.54.11.255, dest 0.0.0.0.
2018-07-02T11:46:43.760 Creating datagram socket to: 164.54.8.217:5076.
2018-07-02T11:46:43.760 Creating datagram socket to: 0.0.0.0:5076.
2018-07-02T11:46:43.760 Local multicast enabled on 127.0.0.1/224.0.0.128:5076.
Waiting...
Timeout
Done
2018-07-02T11:46:46.773 UDP socket 0.0.0.0:0 closed.
2018-07-02T11:46:46.773 UDP socket 164.54.8.217:5076 closed.
2018-07-02T11:46:46.773 UDP socket 0.0.0.0:5076 closed.
Same problem with the MSVS-2017 build:
Ok, that at least makes sense. I don't see any way the WIN32 implementation could depend on anything other than OS version/configuration.
I should have asked earlier, what EPICS_* environment variables are set on each host?
None that affect the networking:
tux% env | grep EPICS_
EPICS_EXTENSIONS=/usr/local/epics/extensions
EPICS_EXTENSIONS_BASE=/usr/local/epics/extensions-base/3.14.12.3-ext1
EPICS_TS_MIN_WEST=360
EPICS_HOST_ARCH=linux-x86_64
EPICS_AR_PORT=7002
EPICS_CA_MAX_ARRAY_BYTES=2500000
EPICS_DISPLAY_PATH=/usr/local/iocapps/adlsys:/usr/local/iocapps/adlsys/temp
C:\epics\base-7.0>set | find "EPICS_"
EPICS_HOST_ARCH=windows-x64-mingw
C:\epics\base-7.0>set | find "EPICS_"
EPICS_HOST_ARCH=windows-x64
I have WSL and the Ubuntu user-land installed on this box too, here's it's view of the network configuration:
anj@eclipse:/mnt/c/epics/base-7.0$ ip addr
6: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 group default qlen 1
link/ether ac:16:2d:0d:54:de
inet 164.54.8.217/22 brd 164.54.11.255 scope global dynamic
valid_lft 382612sec preferred_lft 382612sec
inet6 fe80::c088:e6aa:81c5:846f/64 scope global dynamic
valid_lft forever preferred_lft forever
1: lo: <LOOPBACK,UP> mtu 1500 group default qlen 1
link/loopback 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope global dynamic
valid_lft forever preferred_lft forever
inet6 ::1/128 scope global dynamic
valid_lft forever preferred_lft forever
anj@eclipse:/mnt/c/epics/base-7.0$ ip route
none default via 164.54.8.1 dev eth0 proto none metric 0
none 164.54.8.0/22 dev eth0 proto none metric 256
none 164.54.8.217 dev eth0 proto none metric 256
none 164.54.11.255 dev eth0 proto none metric 256
none 224.0.0.0/4 dev eth0 proto none metric 256
none 255.255.255.255 dev eth0 proto none metric 256
none 127.0.0.0/8 dev lo proto none metric 256
none 127.0.0.1 dev lo proto none metric 256
none 127.255.255.255 dev lo proto none metric 256
none 224.0.0.0/4 dev lo proto none metric 256
none 255.255.255.255 dev lo proto none metric 256
Currently building with that...
I think this confirms that the problem is in the WIN32 implementation:
anj@eclipse:~/epics/base-7.0$ bin/linux-x86_64/pvget -d anj:BaseVersion
2018-07-02T12:17:54.467 Client security plug-in 'ca' installed.
2018-07-02T12:17:54.468 Creating datagram socket to: 0.0.0.0:0.
2018-07-02T12:17:54.468 Broadcast address #0: 164.54.11.255:5076.
2018-07-02T12:17:54.468 Setting up UDP for interface 164.54.8.217, broadcast 164.54.11.255, dest 164.54.11.255.
2018-07-02T12:17:54.469 Creating datagram socket to: 164.54.8.217:5076.
2018-07-02T12:17:54.469 Creating datagram socket to: 164.54.11.255:5076.
2018-07-02T12:17:54.491 Error binding socket 164.54.11.255:5076: Cannot assign requested address.
2018-07-02T12:17:54.491 Creating datagram socket to: 224.0.0.128:5076.
2018-07-02T12:17:54.492 Error binding socket 224.0.0.128:5076: Cannot assign requested address.
2018-07-02T12:17:54.492 Failed to initialize local multicast, functionality disabled. Reason: Failed to bind UDP socket..
2018-07-02T12:17:54.492 Sending 61 bytes to 164.54.11.255:5076.
Waiting...
2018-07-02T12:17:54.494 Connecting to PVA server: 164.54.9.24:5075.
2018-07-02T12:17:54.494 Opening socket to PVA server 164.54.9.24:5075, attempt 1.
2018-07-02T12:17:54.495 Socket connected to PVA server: 164.54.9.24:5075.
2018-07-02T12:17:54.496 Acquiring transport to 164.54.9.24:5075.
2018-07-02T12:17:54.497 Connected to PVA server: 164.54.9.24:5075.
[anj:BaseVersion] channel get create: Status [type=OK]
[anj:BaseVersion] channel get: Status [type=OK]
anj:BaseVersion 7.0.1.2-DEV
Done
2018-07-02T12:17:54.500 Releasing TCP transport to 164.54.9.24:5075.
2018-07-02T12:17:54.501 TCP socket to 164.54.9.24:5075 is to be closed.
2018-07-02T12:17:54.501 UDP socket 0.0.0.0:0 closed.
2018-07-02T12:17:54.501 UDP socket 164.54.8.217:5076 closed.
I can run the IOC on either the MinGW or VS2017 builds and use the WSL+Ubuntu client to access them:
anj@eclipse:~/epics/base-7.0$ bin/linux-x86_64/pvget -d anj2:BaseVersion
2018-07-02T12:21:14.714 Client security plug-in 'ca' installed.
2018-07-02T12:21:14.715 Creating datagram socket to: 0.0.0.0:0.
2018-07-02T12:21:14.716 Broadcast address #0: 164.54.11.255:5076.
2018-07-02T12:21:14.716 Setting up UDP for interface 164.54.8.217, broadcast 164.54.11.255, dest 164.54.11.255.
2018-07-02T12:21:14.716 Creating datagram socket to: 164.54.8.217:5076.
2018-07-02T12:21:14.717 Creating datagram socket to: 164.54.11.255:5076.
2018-07-02T12:21:14.717 Error binding socket 164.54.11.255:5076: Cannot assign requested address.
2018-07-02T12:21:14.718 Creating datagram socket to: 224.0.0.128:5076.
2018-07-02T12:21:14.774 Error binding socket 224.0.0.128:5076: Cannot assign requested address.
2018-07-02T12:21:14.775 Failed to initialize local multicast, functionality disabled. Reason: Failed to bind UDP socket..
2018-07-02T12:21:14.776 Sending 62 bytes to 164.54.11.255:5076.
2018-07-02T12:21:14.777 Connecting to PVA server: 164.54.8.217:5075.
2018-07-02T12:21:14.777 Opening socket to PVA server 164.54.8.217:5075, attempt 1.
2018-07-02T12:21:14.777 Socket connected to PVA server: 164.54.8.217:5075.
2018-07-02T12:21:14.778 Acquiring transport to 164.54.8.217:5075.
2018-07-02T12:21:14.778 Connected to PVA server: 164.54.8.217:5075.
Waiting...
[anj2:BaseVersion] channel get create: Status [type=OK]
[anj2:BaseVersion] channel get: Status [type=OK]
anj2:BaseVersion 7.0.1.2-DEV
Done
2018-07-02T12:21:14.780 Releasing TCP transport to 164.54.8.217:5075.
2018-07-02T12:21:14.781 TCP socket to 164.54.8.217:5075 is to be closed.
2018-07-02T12:21:14.781 UDP socket 0.0.0.0:0 closed.
2018-07-02T12:21:14.781 UDP socket 164.54.8.217:5076 closed.
In both cases though the IOC shows these warnings on startup:
C:\epics\base-7.0>softIocPVA -x anj2
Starting iocInit
############################################################################
## EPICS R7.0.1.2-DEV
## EPICS Base built Jul 2 2018
############################################################################
2018-07-02T12:21:08.664 No broadcast addresses found or specified - empty address list!
iocRun: All initialization complete
2018-07-02T12:21:09.180 No broadcast addresses found or specified - empty address list!
epics> pvasr
VERSION : pvAccess Server v6.0.1-SNAPSHOT
PROVIDER_NAMES : QSRV,
BEACON_ADDR_LIST :
AUTO_BEACON_ADDR_LIST : 1
BEACON_PERIOD : 15
BROADCAST_PORT : 5076
SERVER_PORT : 5075
RCV_BUFFER_SIZE : 16384
IGNORE_ADDR_LIST:
INTF_ADDR_LIST : 0.0.0.0
My head is spinning. I'm remember why this code is on my TODO list under "replace".
void initializeUDPTransports(bool serverFlag,
BlockingUDPTransportVector& udpTransports,
const IfaceNodeVector& ifaceList,
const ResponseHandler::shared_pointer& responseHandler,
BlockingUDPTransport::shared_pointer& sendTransport,
int32& listenPort,
bool autoAddressList,
const std::string& addressList,
const std::string& ignoreAddressList)
That's quite an argument list!
BTW I got the same result building with VS-2010. Then I tried building the older V4 modules against Base-3.15: epics-4.7.0 — same pvutils.h problem with MinGW, no connection; epics-4.6.0 — nope, ditto; epics-4.5.0.1 — was obviously never built against windows.
Is it possible to configure the network using environment variables? Hmm, let's see...
C:\epics\base-7.0>set EPICS_PVA_ADDR_LIST=164.54.9.24
C:\epics\base-7.0>pvget -d anj:BaseVersion
2018-07-02T16:28:22.984 Client security plug-in 'ca' installed.
2018-07-02T16:28:22.985 Creating datagram socket to: 0.0.0.0:0.
2018-07-02T16:28:22.986 Broadcast address #0: 164.54.9.24:5076.
2018-07-02T16:28:22.986 Setting up UDP for interface 164.54.8.217, broadcast 164.54.11.255, dest 0.0.0.0.
2018-07-02T16:28:22.986 Creating datagram socket to: 164.54.8.217:5076.
2018-07-02T16:28:22.986 Creating datagram socket to: 0.0.0.0:5076.
2018-07-02T16:28:22.986 Local multicast enabled on 127.0.0.1/224.0.0.128:5076.
2018-07-02T16:28:22.986 Sending 61 bytes to 164.54.9.24:5076.
Waiting...
2018-07-02T16:28:22.987 Connecting to PVA server: 164.54.9.24:5075.
2018-07-02T16:28:22.988 Opening socket to PVA server 164.54.9.24:5075, attempt 1.
2018-07-02T16:28:22.988 Socket connected to PVA server: 164.54.9.24:5075.
2018-07-02T16:28:22.988 Acquiring transport to 164.54.9.24:5075.
2018-07-02T16:28:22.989 Connected to PVA server: 164.54.9.24:5075.
[anj:BaseVersion] channel get create: Status [type=OK]
[anj:BaseVersion] channel get: Status [type=OK]
anj:BaseVersion 7.0.1.2-DEV
Done
2018-07-02T16:28:23.008 Releasing TCP transport to 164.54.9.24:5075.
2018-07-02T16:28:23.008 TCP socket to 164.54.9.24:5075 is to be closed.
2018-07-02T16:28:23.009 UDP socket 0.0.0.0:0 closed.
2018-07-02T16:28:23.009 UDP socket 164.54.8.217:5076 closed.
2018-07-02T16:28:23.009 UDP socket 0.0.0.0:5076 closed.
Well, at least that's working.
@anjohnson please pull the lastest and re-test (including b97e37da98fd6d17f86c3255ad23587a3afb4c3c).
I've remove calls to osiSockDiscoverBroadcastAddresses()
in favor of the internal discoverInterfaces()
which also gets the broadcast addresses. At least this way there is only one "copy" of the NIC discovery code in play.
After remembering to remove the environment variable again, this is MinGW at b97e37d:
C:\epics\base-7.0\modules\pvAccess>pvget -d anj:BaseVersion
2018-07-02T17:32:12.546 Client security plug-in 'ca' installed.
2018-07-02T17:32:12.558 Creating datagram socket to: 0.0.0.0:0.
Detected inconsistent broadcast address on interface a43608d9/fffffc00. expect a4360bff found ~ffffffff.2018-07-02T17:32:12.559 Broadcast address #0: 255.255.255.255:5076. (not unicast)
2018-07-02T17:32:12.559 Setting up UDP for interface 164.54.8.217/255.255.252.0, broadcast 255.255.255.255, dest <none>.
2018-07-02T17:32:12.559 Creating datagram socket to: 164.54.8.217:5076.
2018-07-02T17:32:12.559 Creating datagram socket to: 0.0.0.0:5076.
2018-07-02T17:32:12.560 Local multicast enabled on 127.0.0.1/224.0.0.128:5076.
2018-07-02T17:32:12.560 Sending 61 bytes to 255.255.255.255:5076.
Waiting...
2018-07-02T17:32:12.802 Sending 61 bytes to 255.255.255.255:5076.
2018-07-02T17:32:13.256 Sending 61 bytes to 255.255.255.255:5076.
2018-07-02T17:32:14.177 Sending 61 bytes to 255.255.255.255:5076.
Timeout
Done
2018-07-02T17:32:15.569 UDP socket 0.0.0.0:0 closed.
2018-07-02T17:32:15.569 UDP socket 164.54.8.217:5076 closed.
2018-07-02T17:32:15.569 UDP socket 0.0.0.0:5076 closed.
With the environment variable set it still works. I also saw the Detected inconsistent broadcast address
message several times while running the tests, which all passed.
The VS-2017 compiler really wants you to know that the non-standard std::tr1 stuff is deprecated and is going to be REMOVED. Here's the output when built with the VS-2017 compiler, same result:
C:\epics\base-7.0>pvget -d anj:BaseVersion
2018-07-02T17:25:39.332 Client security plug-in 'ca' installed.
2018-07-02T17:25:39.334 Creating datagram socket to: 0.0.0.0:0.
Detected inconsistent broadcast address on interface a43608d9/fffffc00. expect a4360bff found ~ffffffff.2018-07-02T17:25:39.334 Broadcast address #0: 255.255.255.255:5076. (not unicast)
2018-07-02T17:25:39.336 Setting up UDP for interface 164.54.8.217/255.255.252.0, broadcast 255.255.255.255, dest <none>.
2018-07-02T17:25:39.336 Creating datagram socket to: 164.54.8.217:5076.
2018-07-02T17:25:39.336 Creating datagram socket to: 0.0.0.0:5076.
2018-07-02T17:25:39.337 Local multicast enabled on 127.0.0.1/224.0.0.128:5076.
2018-07-02T17:25:39.337 Sending 61 bytes to 255.255.255.255:5076.
Waiting...
2018-07-02T17:25:39.557 Sending 61 bytes to 255.255.255.255:5076.
2018-07-02T17:25:39.998 Sending 61 bytes to 255.255.255.255:5076.
2018-07-02T17:25:40.877 Sending 61 bytes to 255.255.255.255:5076.
Timeout
Done
2018-07-02T17:25:42.338 UDP socket 0.0.0.0:0 closed.
2018-07-02T17:25:42.338 UDP socket 164.54.8.217:5076 closed.
2018-07-02T17:25:42.338 UDP socket 0.0.0.0:5076 closed.
Despite the failure, it also passed all of the tests (with the same warning as above).
The VS-2017 compiler really wants you to know that the non-standard std::tr1 stuff is deprecated and is going to be REMOVED
Yes, very subtle I know. I complained about the std::auto_ptr deprecation warnings of GCC, but as always MS takes the cake. I cynically expect that at some point they'll unilaterally decide to make namespace tr1 {}
an error, which would put us in a tight spot to support both MSVC and vxWorks.
I also saw the Detected inconsistent broadcast address message several times while running the tests, which all passed.
yup, I'll make this go away now. This message explains some odd looking code in the win32 implementation of discoverInterfaces() which I removed to see if it was necessary. I'll put it back now, with a comment explain why it's needed.
@anjohnson Please re-test with 59a65ce317aee13c4c7b0883b436779e15de26be
I was able to resurrect at windows 10 VM and test some cross-built executables. In point of fact a basic "pvget" to an IOC running in the same VM worked before this last fix, as well as after. So if this doesn't have some effect, then I'll be out of ideas.
Looks like that did it:
C:\epics\base-7.0\modules\pvAccess>pvget -d anj:BaseVersion
2018-07-03T11:44:31.096 Client security plug-in 'ca' installed.
2018-07-03T11:44:31.097 Creating datagram socket to: 0.0.0.0:0.
2018-07-03T11:44:31.098 Broadcast address #0: 164.54.11.255:5076. (not unicast)
2018-07-03T11:44:31.098 Setting up UDP for interface 164.54.8.217/255.255.252.0, broadcast 164.54.11.255, dest <none>.
2018-07-03T11:44:31.099 Creating datagram socket to: 164.54.8.217:5076.
2018-07-03T11:44:31.099 Creating datagram socket to: 0.0.0.0:5076.
2018-07-03T11:44:31.099 Local multicast enabled on 127.0.0.1/224.0.0.128:5076.
2018-07-03T11:44:31.099 Sending 61 bytes to 164.54.11.255:5076.
Waiting...
2018-07-03T11:44:31.100 Connecting to PVA server: 164.54.9.24:5075.
2018-07-03T11:44:31.100 Opening socket to PVA server 164.54.9.24:5075, attempt 1.
2018-07-03T11:44:31.101 Socket connected to PVA server: 164.54.9.24:5075.
2018-07-03T11:44:31.101 Acquiring transport to 164.54.9.24:5075.
2018-07-03T11:44:31.102 Connected to PVA server: 164.54.9.24:5075.
[anj:BaseVersion] channel get create: Status [type=OK]
[anj:BaseVersion] channel get: Status [type=OK]
anj:BaseVersion 7.0.1.2-DEV
Done
2018-07-03T11:44:31.104 Releasing TCP transport to 164.54.9.24:5075.
2018-07-03T11:44:31.104 TCP socket to 164.54.9.24:5075 is to be closed.
2018-07-03T11:44:31.104 UDP socket 0.0.0.0:0 closed.
2018-07-03T11:44:31.105 UDP socket 164.54.8.217:5076 closed.
2018-07-03T11:44:31.105 UDP socket 0.0.0.0:5076 closed.
C:\epics\base-7.0\modules\pvAccess>set | find "EPICS_"
EPICS_BASE=C:\epics\base-7.0
EPICS_HOST_ARCH=windows-x64-mingw
and
C:\epics\base-7.0\modules\pvAccess>pvget -d anj:BaseVersion
2018-07-03T11:46:42.893 Client security plug-in 'ca' installed.
2018-07-03T11:46:42.895 Creating datagram socket to: 0.0.0.0:0.
2018-07-03T11:46:42.895 Broadcast address #0: 164.54.11.255:5076. (not unicast)
2018-07-03T11:46:42.895 Setting up UDP for interface 164.54.8.217/255.255.252.0, broadcast 164.54.11.255, dest <none>.
2018-07-03T11:46:42.895 Creating datagram socket to: 164.54.8.217:5076.
2018-07-03T11:46:42.896 Creating datagram socket to: 0.0.0.0:5076.
2018-07-03T11:46:42.896 Local multicast enabled on 127.0.0.1/224.0.0.128:5076.
2018-07-03T11:46:42.896 Sending 61 bytes to 164.54.11.255:5076.
Waiting...
2018-07-03T11:46:42.897 Connecting to PVA server: 164.54.9.24:5075.
2018-07-03T11:46:42.897 Opening socket to PVA server 164.54.9.24:5075, attempt 1.
2018-07-03T11:46:42.897 Socket connected to PVA server: 164.54.9.24:5075.
2018-07-03T11:46:42.898 Acquiring transport to 164.54.9.24:5075.
2018-07-03T11:46:42.898 Connected to PVA server: 164.54.9.24:5075.
[anj:BaseVersion] channel get create: Status [type=OK]
[anj:BaseVersion] channel get: Status [type=OK]
anj:BaseVersion 7.0.1.2-DEV
Done
2018-07-03T11:46:42.901 Releasing TCP transport to 164.54.9.24:5075.
2018-07-03T11:46:42.902 TCP socket to 164.54.9.24:5075 is to be closed.
2018-07-03T11:46:42.902 UDP socket 0.0.0.0:0 closed.
2018-07-03T11:46:42.902 UDP socket 164.54.8.217:5076 closed.
2018-07-03T11:46:42.902 UDP socket 0.0.0.0:5076 closed.
C:\epics\base-7.0\modules\pvAccess>set | find "EPICS_"
EPICS_BASE=C:\epics\base-7.0
EPICS_HOST_ARCH=windows-x64
Works against a local IOC too, and the warnings went away from the IOC startup.
Thanks! This issue can be closed from my perspective.
How difficult would it be to have a test to check (some of) this?
Quite difficult. In thinking about this yesterday, a test would either be comparing with values known at build time, or cross comparing with other values at runtime. This would mean either knowing ahead of time the network configuration, which loses generality, or finding something else to compare against (eg. parsing 'ifconfig' output). Neither seems feasible to me.
I considered cross comparing the low level sockets code with the high level 'getifaddrs()', but I don't think there is enough benefit. This would also be limited to those targets which provide 'getifaddrs()' (not windows).
Au contraire, it is pretty easy to write a test (for host targets) that would have failed for me. I can even do it without writing any C++ or even a .db file, it just requires automating exactly what I was doing above.
The code below is an example test script that uses the IOC.pm module to start softIocPVA
with the built-in database, then it asks both caget
and pvget
to fetch the BaseVersion PV. Since it uses the softIoc it does need pva2pva, so can't be included in the pvAccess module. It catches CTRL-C and stops the IOC in response, and this works on Windows.
It could look at an environment variable to tell it whether to run this check, so we could turn it on/off for particular test environments as needed. It could even be extended to check that all the EPICS_PVA_*
variables do what they are supposed to (starting and stopping the IOC as many times as needed with different environment settings).
use strict;
use warnings;
use lib '@TOP@/lib/perl';
use Test::More tests => 2;
use EPICS::IOC;
$ENV{HARNESS_ACTIVE} = 1 if scalar @ARGV && shift eq '-tap';
my $bin = "@TOP@/bin/@ARCH@";
my $prefix = "test-$$";
my $ioc = EPICS::IOC->new();
$SIG{__DIE__} = $SIG{'INT'} = $SIG{'QUIT'} = sub {
$ioc->kill
if ref($ioc) eq 'EPICS::IOC' && $ioc->started;
BAIL_OUT('Caught signal');
};
$ioc->start("$bin/softIocPVA", '-x', $prefix);
$ioc->cmd; # Wait for command prompt
like(`$bin/caget $prefix:BaseVersion`,
qr/^ $prefix:BaseVersion \s+ 7\.0\.\d /x, 'Got BaseVersion from ca');
like(`$bin/pvget $prefix:BaseVersion`,
qr/^ $prefix:BaseVersion \s+ 7\.0\.\d /x, 'Got BaseVersion from pva');
$ioc->kill;
Released with Base 7.0.2
Building the latest Base-7.0 branch on Windows using StrawberryPerl with MinGW gcc-7.1.0.
The problem appears to be unique to pvAccess, neither the CA server nor client are affected. I've tried talking to both local (same PC) and to an external server, and can't get a PVA client connection on the Windows box (I can connect to a Windows IOC over both CA and PVA from an external Linux client).
Starting an IOC: