Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Fri, 25 Feb 2011 11:46:12 -0700

> epics> casr 100
> Channel Access Server V4.13
> No clients connected.
> [...]
> Channel Access Address List
> 10.117.255.255:5065
> 192.168.95.255:5065
> 10.15.254.2:5065
>
> However, it does not resolve from the FreeBSD machine itself:

So the FreeBSD local client is probably sending UDP search messages to at
least {10.117.255.255:5064, 192.168.95.255:5064}. On typical UNIX systems
this is seen by a server that listening to an any interface binding *:5064
as the rsrv server in the IOC is hard coded (you can check this by running
"netstat -a"), but perhaps there are differences with free bsd. The portable
server (as is used in the gateway is more flexible, and you can specify
exactly what interfaces it listens on. For example you could explicitly
specify the loopback interface 127.0.0.1. A new server will be in the IOC
soon in R3.15 which will allow this type of flexibility. 

There seems to be two possible solutions (to avoid the user seeing
inconsistencies):
1) On free bsd we might also create a specialized osdNetIntf.c which
provides the client/server with also the loopback interface's address for
their search/beacon list respectively. 
2) OS (IP kernel) specific inconsistencies might be resolved in the future
if the server is more explicit with its default interface bindings. Perhaps
it should bind to the loopback interface, the address of each interface, and
the broadcast address of each interface explicitly by default.

At the moment (2) seems to be a better solution, but perhaps I need a better
understanding of why this type of inconsistencies occur before making that
decision. Independent of that choice of course the users should be allowed
to hand configure.

> JH> #if ( defined (BSD) && ( BSD >= 44 ) )
> JH> #   define ifreq_size(pifreq) (pifreq->ifr_addr.sa_len +
> JH> sizeof(pifreq->ifr_name))
> JH> #else
> JH> #   define ifreq_size(pifreq) sizeof(*pifreq)
> JH> #endif
>
> Oh, I see
> (<http://www.freebsd.org/doc/en/books/porters-handbook/porting-
> versions.html>),
> it comes in via sys/param.h, which is already included:
> 
> ---
> #define BSD     199506          /* System version (year & month). */
> #define BSD4_3  1
> #define BSD4_4  1

so in the free bsd version of osdSock.h perhaps this is necessary

#if BSD4_4
#   define ifreq_size(pifreq) (pifreq->ifr_addr.sa_len +
sizeof(pifreq->ifr_name))
#else
#   define ifreq_size(pifreq) sizeof(*pifreq)
#endif

> One other thing I noted while installing the gateway extension is the
> following:
> I install to a different location using
> "INSTALL_LOCATION=/opt/epics/epics/" in CONFIG_SITE. With this setting I
> was not able to compile the gateway extension due to two missing headers
> I needed to copy manually:
> 
> ---
> cp /root/epics/base-3.14.12/src/cas/generic/caHdrLargeArray.h
> /opt/epics/epics/include/
> cp /root/epics/base-3.14.12/src/cas/generic/casCtx.h
> /opt/epics/epics/include/
> ---
> 
> Am I still doing something wrong with the INSTALL_LOCATION, or are these
> files just missed during the install phase?

These headers are intended to be private to the internal implementation of
the portable server, but the gateway has become dependent on them. Copying
them to the install location is probably the best workaround at the moment.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925

> -----Original Message-----
> From: Gerrit Kühn [mailto:[email protected]]
> Sent: Friday, February 25, 2011 2:10 AM
> To: Jeff Hill
> Cc: [email protected]
> Subject: Re: epics on FreeBSD: broadcast problem
> 
> On Thu, 24 Feb 2011 09:37:07 -0700 "Jeff Hill" <[email protected]> wrote
> about RE: epics on FreeBSD: broadcast problem:
> 
> Hi Jeff,
> 
> JH> In particular, you may, on this version of free bsd, need this
> JH>
> JH> #define ifreq_size(pifreq) ((pifreq)->ifr_addr.sa_len +
> JH> sizeof((pifreq)->ifr_name))
> 
> This mostly fixes the problem for me. Now casr gives me
> 
> ---
> epics> casr 100
> Channel Access Server V4.13
> No clients connected.
> [...]
> Channel Access Address List
> 10.117.255.255:5065
> 192.168.95.255:5065
> 10.15.254.2:5065
> ---
> 
> Now I can caget PVs from my subnet:
> 
> ---
> firefly1# /opt/epics/epics/bin/freebsd-x86_64/caget G3:PSL-OSC_PZTVOLT
> G3:PSL-OSC_PZTVOLT             0.00427259
> ---
> 
> One thing is left: With the softIOC I defined a TEST PV:
> 
> ---
> epics> dbl
> TEST
> ---
> 
> This resolves fine from a Linux machine in the subnet (already worked
> before changing the macro):
> 
> ---
> psl@psl-fe4 ~ $ caget TEST
> TEST                           0
> ---
> 
> However, it does not resolve from the FreeBSD machine itself:
> 
> ---
> firefly1# /opt/epics/epics/bin/freebsd-x86_64/caget TEST
> Channel connect timed out: 'TEST' not found.
> ---
> 
> This only changes if I put the machine's IP explicitely into the
> ADDR_LIST:
> 
> ---
> firefly1# setenv|grep EPICS
> EPICS_HOST_ARCH=freebsd-x86_64
> EPICS_CA_AUTO_ADDR_LIST=YES
> EPICS_CAS_AUTO_BEACON_ADDR_LIST=YES
> EPICS_CA_ADDR_LIST=192.168.64.254
> firefly1# /opt/epics/epics/bin/freebsd-x86_64/caget TEST
> TEST                           0
> ---
> 
> 
> JH> to support a range of free bsd versions you will most likely need a
> BSD
> JH> version switch - this is what we have currently for vxWorks
> JH>
> JH> #if ( defined (BSD) && ( BSD >= 44 ) )
> JH> #   define ifreq_size(pifreq) (pifreq->ifr_addr.sa_len +
> JH> sizeof(pifreq->ifr_name))
> JH> #else
> JH> #   define ifreq_size(pifreq) sizeof(*pifreq)
> JH> #endif
> 
> When I played around with the extensions yesterday, I mostly followed the
> settings for Apple/Darwin to get code working for FreeBSD. I don't know
> where I would have to get the BSD defined in the build chain... right now
> it seems not to be there:
> 
> ---
> ahvbuildbox-fbsd64# gcc -dM -E src/libCom/osi/osiSock.c | grep BSD
> #define __FreeBSD_cc_version 800001
> #define __BSD_VISIBLE 1
> #define __VERSION__ "4.2.1 20070719  [FreeBSD]"
> #define __FBSDID(s) __IDSTRING(__CONCAT(__rcsid_,__LINE__),s)
> #define __FreeBSD__ 8
> ---
> 
> Oh, I see
> (<http://www.freebsd.org/doc/en/books/porters-handbook/porting-
> versions.html>),
> it comes in via sys/param.h, which is already included:
> 
> ---
> #define BSD     199506          /* System version (year & month). */
> #define BSD4_3  1
> #define BSD4_4  1
> ---
> 
> Can't tell for sure if this is the right thing to do for other flavours
> like OpenBSD oder NetBSD, though.
> 
> JH> let us know how this goes so we can fix the distribution
> 
> Apart from the issue resolving PVs from the machine itself it looks fine
> so far. Thanks you very much for your support!
> 
> Background for me here is that I have FreeBSD-based router/infrastructure
> (dns, dhcp, cups, vpn etc.) servers for epics subnets. Now I want to use
> the gateway extension to provide channel access to the outside, and these
> FreeBSD machines would be the obvious location to run the gateway. I'll
> report back if I can get the gateway to work now.
> 
> 
> One other thing I noted while installing the gateway extension is the
> following:
> I install to a different location using
> "INSTALL_LOCATION=/opt/epics/epics/" in CONFIG_SITE. With this setting I
> was not able to compile the gateway extension due to two missing headers
> I needed to copy manually:
> 
> ---
> cp /root/epics/base-3.14.12/src/cas/generic/caHdrLargeArray.h
> /opt/epics/epics/include/
> cp /root/epics/base-3.14.12/src/cas/generic/casCtx.h
> /opt/epics/epics/include/
> ---
> 
> Am I still doing something wrong with the INSTALL_LOCATION, or are these
> files just missed during the install phase?
> 
> 
> cu
>   Gerrit

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System