RE: CA Server (default configuration behaves strangely on linux)

[Jeff Hill <johill@lanl.gov>]

John,

Sorry about the late response. I was on vacation last week, and have had to
work through some E-mail buildup this week.

On Monday, March 30, 1998 2:27 PM, john sinclair [SMTP:sinclair@mail.phy.ornl.gov] wrote:
> I have built epics base under redhat linux 5 and am trying to
> run an example CA Server, excas, as follows:
> 
> caRepeater &
> excas &
> 
> At this point netstat shows a process listening on udp socket 5064.
> 
> I then run the utility ca_test as follows:
> 
> ca_test fred
> 
> >From another window, tcpdump sees the broadcast messages
> from ca_test, but excas never seems to respond.
> 
> Any suggestions?
>

I don't see this problem when I test on WINNT or Solaris. I suspect that
this is a linux specific problem. Perhaps the linux IP kernel does not forward 
locally generated IP broadcasts to the localhost (127.0.0.1).

The code involved is in 
$(EPICS)/base/src/cas/io/bsdSocket/casDGIntfIO.cc
$(EPICS)/base/src/cas/io/bsdSocket/casIntfIO.cc

If I had a linux box here I would step through the routines that
call bind() to determine what is going on, and also look at the
system with "netstat -a" to see what port, and what interface
the server attaches to. If you see that the server is attached
to UDP *.5064 then it should accept broadcasts sent from the
local host and also arriving on any one of the network interfaces
(that are sent to the default CA server port - 5064).

On Tuesday, March 31, 1998 12:05 PM, john sinclair [SMTP:sinclair@mail.phy.ornl.gov] wrote:
> I have found a solution:
> 
> There is an environment variable named EPICS_CAS_INTF_ADDR_LIST
> that may be set to the node address from which CA Server is
> running. It is nice having the source code!
> 
>

You might also find that adding 127.0.0.1 to EPICS_CA_ADDR_LIST
for the ca_test client will solve the problem. If nothing else testing this
will give us good information about the specific cause of this problem.

On Tuesday, March 31, 1998 4:20 PM, Hammonds, John [SMTP:JHammonds@pns.anl.gov] wrote:
> John,
> 
> Do you consider this a total fix?  I tested this out and it does work as
> long as excas is run on the same node that you do the ca_test from.  I
> set up to test this and if I run both of these on the same machine I get
> good results.  If I run ca_test (or some other ca utility) on another
> machine, I get a message that fred was not found.  This seems similar to
> the problem that I had when looking over this with Jeff Hill.  I even
> think that this may have been the same variable that we set to get it to
> work through localhost.
> 

Setting EPICS_CAS_INTF_ADDR_LIST to all of the interfaces seen by 
"netstat -a" (including 127.0.0.1) might be a more complete solution.
The question remains: why do linux systems behave differently than
other hosts when the server (I presume) binds to a wildcard local
address.

> There is a reference to
> several EPICS_CAS environmental variables in the channel access
> reference manual available at the LANL Epics site 
> Section  1.7  on Configurating a CA server.  There is also a comment that this
> chapter of the document is "under construction".  This probably explains why 
> EPICS_CAS_INTF_ADDR_LIST has not made it into the documentation yet.

There is documentation on the environmental variables used by the
new CA server library in $(EPICS)/base/config/CONFIG_ENV. I have
included it here for those of you that are interested.

#
# These parameters are only used by the CA server library
#
# EPICS_CA_BEACON_PERIOD 
#	quiescent sec between server beacons.
# EPICS_CAS_INTF_ADDR_LIST - list of IP addresses identifying
#	a limited set of network interfaces for server communication. 
#	Specifically, this parameter specifies the interfaces from
#	which the server will accept TCP/IP connections. It also 
#	specifies that UDP search messages addressed to both
#	the IP addresses in EPICS_CAS_INTF_ADDR_LIST and also
#	the broadcast addresses (or the destination addresses of 
#	point to point interfaces) of the corresponding interfaces
#	will be accepted by the server. If this parameter is empty 
#	then TCP/IP connections are accepted from any interface
#	(and any search messages addressed to the host are accepted). 
#	Beacons are sent only to the broadcast address of each interface 
#	in this list (or the destination address of point to point 
#	interfaces) if EPICS_CA_AUTO_ADDR_LIST is YES. 
#	Type "ifconfig -a" in order to determine which interfaces 
#	are available.
# EPICS_CAS_BEACON_ADDR_LIST - If this parameter is specified
#	or if EPICS_CAS_INTF_ADDR_LIST isnt empty then this parameter
#	is used instead of EPICS_CA_ADDR_LIST by the server library 
# 	to augment the list of addresses to send beacons to.
# EPICS_CAS_SERVER_PORT - If this parameter is specified then it
#	and not EPICS_CA_SERVER_PORT is used to determine the server's
# 	port number. It is possible to have multiple servers on the
#	same host on the same EPICS_CAS_SERVER_PORT port if the IP
#	kernel is modern (if it has multicast enhancements). In this
#	situation all servers will share the same user specified 
#	UDP port number and will be assigned unique TCP port numbers. 
#	The fact that the servers may not be using the user specified
#	port number for TCP will be completely transparent to EPICS 
#	3.13 or higher clients that will be locating the servers
#	using the user specified UDP port number, but will be connecting to
#	the servers using whatever TCP port has been assigned.
#

>
> 2) Change aitTypes.h as follows:
> 
> Note: aitTypes.h is found in .../epics/base/include and
>       .../epics/base/src/gdd - I have no idea why there
>       are two copies but, in any case, I changed both copies.

The EPICS base build installs all headers to the specified location so that
you can delete the source code after you have finished creating
the distribution. In your case you have installed header files to the default
location - .../epics/base/include. This approach also makes it clear that
each header file belong to certain portions of the EPICS source code.

> 
> OLD:
> 
>   #ifndef vxWorks
>   #if (_POSIX_C_SOURCE < 3) && !defined(solaris) && !defined(SOLARIS)
>   struct timespec
>   {
>           time_t tv_sec;
>           long tv_nsec;
>   };
>   typedef struct timespec timespec;
>   #endif
>   #endif
> 
> NEW:
> 
>   #if !defined(vxWorks) && !defined(__timespec_defined)
>   #define	__timespec_defined 1
>   #if (_POSIX_C_SOURCE < 3) && !defined(solaris) && !defined(SOLARIS)
>   struct timespec
>   {
>   	time_t tv_sec;
>   	long tv_nsec;
>   };
>   typedef struct timespec timespec;
>   #endif
>   #endif
> 
>   #if defined(linux)
>   typedef struct timespec timespec;
>   #endif
> 

The current version of the source code appears to take linux into account. If 
This version causes trouble under linux please let me know and we will make
additional changes.

#ifndef vxWorks
#if (_POSIX_C_SOURCE < 3) && !defined(solaris) && !defined(SOLARIS) && !defined(HP_UX) && !defined(linux)

struct timespec
{
	time_t tv_sec;
	long tv_nsec;
};
typedef struct timespec timespec;
#endif
#endif


Jeff

PS:

If experiencing trouble getting clients to connect:

o Make sure that the broadcast addresses are identical on the
server's host and on the client's host. This can be checked with
"netstat -i" or "ifconfig -a".

o Make certain that the client and server are using the same UDP
port. Check the server's port by running "netstat -a | grep nnn"
where nnn is the port number involved. If you do not set 
EPICS_CA_SERVER_PORT or EPICS_CAS_SERVER_PORT 
then the default port will be 5064.

o Two servers can run on the same host with the same server port number
if the following restrictions are understood (good luck). If the host has a
modern IP kernel it is possible to have two servers on the same UDP port.
It is not possible for two servers to run on the same host using the same 
TCP IP server port. If the CA server library detects that a 2nd server is attempting
to start on the same port as an existing CA server then both servers will use the 
same UDP port if it is a modern IP kernel, and the 2nd server will
be allocated a new TCP port. In this situation the clients will still be
configured to use the same port number for both servers. The clients
will find the 2nd server via the shared UDP port, and transparently
connect to the 2nd server's allocated TCP port. Be aware that If there are 
two server's running on the same host on the same UDP port then they will 
both receive all UDP search requests sent as broadcasts, but will unfortunately (due to 
what I consider to be a real weakness of most IP kernel implementations) only one 
of the servers will typically receive UDP search requests sent to unicast addresses (i.e. 
a specific host's ip address).