tux$ EPICS_CAS_INTF_ADDR_LIST='0.0.0.0 224.0.2.9' EPICS_CA_ADDR_LIST=224.0.2.9 EPICS_CA_AUTO_ADDR_LIST=NO bin/linux-x86_64/softIoc -x anj
Starting iocInit
############################################################################
## EPICS R3.15.3-DEV $$Date: Sun 2015-11-22 18:10:40 +0100 $$
## EPICS Base built Jan 21 2016
############################################################################
CAS address list can not contain 0.0.0.0 and other addresses, ignoring...
iocRun: All initialization complete
epics>
I get the same output from 'casr 2' without the warning message by omitting the 0.0.0.0 interface address, so I'll assume including it was just a mistake in your instructions above.
Searches from the same subnet succeed with EPICS_CA_ADDR_LIST=224.0.2.9 EPICS_CA_AUTO_ADDR_LIST=NO. Do I need to have our network admins configure something for searches to work across subnets? They don't for me at the moment using the same unmodified 3.14-based client. This was only an experimental feature though so it's not a blocker at all.
If I configure the IOC to only use the localhost interface, why does it still send beacons through my primary interface?
tux$ EPICS_CAS_INTF_ADDR_LIST=localhost bin/linux-x86_64/softIoc -x anj
Starting iocInit
############################################################################
## EPICS R3.15.3-DEV $$Date: Sun 2015-11-22 18:10:40 +0100 $$
## EPICS Base built Jan 21 2016
############################################################################
iocRun: All initialization complete
epics> casr 2
Channel Access Server V4.13
No clients connected.
Server interface 127.0.0.1:5064
UDP receiver 1 127.0.0.1:5064
UDP receiver 2 127.255.255.255:5064
Beacon destination 127.255.255.255:5065
Beacon destination 164.54.11.255:5065
...
I had expected that explicitly setting the interface would also configure the beacons to be sent through the same interface(s), although I do realize the original code didn't work like that and it can be done manually. I'd be OK with leaving that change for later if there are objections to fixing it here though.
I also have some minor modifications to casr which I'll finish off next week.
Beacons fixed, thanks.
Trying multicast name resolution:
tux$ EPICS_CAS_ INTF_ADDR_ LIST='0. 0.0.0 224.0.2.9' EPICS_CA_ ADDR_LIST= 224.0.2. 9 EPICS_CA_ AUTO_ADDR_ LIST=NO bin/linux- x86_64/ softIoc -x anj ####### ####### ####### ####### ####### ####### ####### ####### ####### ###### ####### ####### ####### ####### ####### ####### ####### ####### ####### ######
Starting iocInit
#######
## EPICS R3.15.3-DEV $$Date: Sun 2015-11-22 18:10:40 +0100 $$
## EPICS Base built Jan 21 2016
#######
CAS address list can not contain 0.0.0.0 and other addresses, ignoring...
iocRun: All initialization complete
epics>
I get the same output from 'casr 2' without the warning message by omitting the 0.0.0.0 interface address, so I'll assume including it was just a mistake in your instructions above.
Searches from the same subnet succeed with EPICS_CA_ ADDR_LIST= 224.0.2. 9 EPICS_CA_ AUTO_ADDR_ LIST=NO. Do I need to have our network admins configure something for searches to work across subnets? They don't for me at the moment using the same unmodified 3.14-based client. This was only an experimental feature though so it's not a blocker at all.
If I configure the IOC to only use the localhost interface, why does it still send beacons through my primary interface?
tux$ EPICS_CAS_ INTF_ADDR_ LIST=localhost bin/linux- x86_64/ softIoc -x anj ####### ####### ####### ####### ####### ####### ####### ####### ####### ###### ####### ####### ####### ####### ####### ####### ####### ####### ####### ###### 255.255: 5064 255.255: 5065
Starting iocInit
#######
## EPICS R3.15.3-DEV $$Date: Sun 2015-11-22 18:10:40 +0100 $$
## EPICS Base built Jan 21 2016
#######
iocRun: All initialization complete
epics> casr 2
Channel Access Server V4.13
No clients connected.
Server interface 127.0.0.1:5064
UDP receiver 1 127.0.0.1:5064
UDP receiver 2 127.255.
Beacon destination 127.255.
Beacon destination 164.54.11.255:5065
...
I had expected that explicitly setting the interface would also configure the beacons to be sent through the same interface(s), although I do realize the original code didn't work like that and it can be done manually. I'd be OK with leaving that change for later if there are objections to fixing it here though.
I also have some minor modifications to casr which I'll finish off next week.