The PED establishes two connections to the SDK Service Daemon (SSD) on startup:one connection for adding routes that are part of normal policies, and one for a service route to the PFD on the PIC. The second connection is used only if the PED is configured to use the PFD. If so, the PED sends a request to manage the service route when it connects to the PFD.
When the PED starts for the first time, it also registers KCOM message handlers for communicating with the other daemons. On startup, or when it gets a
MSG_POLICY_UPDATE message from the PSD, it also queries for all interfaces currently present (using KCOM APIs,) and updates the associated policies. The KCOM message handler also updates the associated policy whenever an interface is added, deleted, or changed for KCOM purposes (enabled or disabled).
To update an interface's policy, the PED compares the interface name received asynchronously from KCOM with the patterns in the PED's configured conditions. The address family must also match the address family specified in the same condition that is used for the interface pattern match (the
ANY keyword can be configured in a condition to match any address family, although this application currently supports only inet). The application code for this is in the function
update_interface(), in the file
The PED sends a policy request to the PSD only if a match is found; otherwise, the PED removes the interface and the associated policy for an individual interface from the policy table by acting as if it has received a
MSG_POLICY_NA for the interface.
When a policy is requested for an interface and successfully applied, regardless of the filters included in the policy, the PED attaches
pfd_filter as the input filter of every managed interface if
packet-filter-interface was configured (see Configuring the Application). If an interface becomes unmanaged (the policy is removed), this input filter is also removed.
At startup, the PED also starts a scheduler to schedule regular
MSG_HB heartbeat messages that verify the connection to the PSD. The PSD echoes the message back to the PED without data to notify the PED that the server is alive.
The PED could not act as the client at this point because it does not know the connection information for the PFD. The PED waits until it knows the internal connection information for the CPD as well, and then sends this information to the PFD.
The PED is also expected to send the PFD an address to use when re-sourcing ("NATing") packets and the public address of the CPD. This allows the PFD to properly steer packets to the CPD as required.
The PFD then starts a new internal connection to the CPD.
The code for connecting to the PED is in the file
pfd_conn.c, in function
connect_ped() is a static function that is calledthrough a timer. The function
pfd_conn.c sets up the timer.
Similarly, the connection to the CPD is performed in
pfd_conn.c. Again, the connection is made through a timer. Once the application connects to the PED and has obtained the PIC information for the CPD (on receiving
MSG_PEER), the application starts a timer that calls the function
connect_cpd() until the CPD is connected. The function
cpd_client_connection() is called when the connection to the CPD changes status (is
SHUTDOWN.) The function
ped_client_connection() is called in the same way whenever the connection to the PED changes.
Subsequently, the PFD requests the initial list of authorized users. At that point, the PFD goes into listening mode and waits to be notified of new authorized or unauthorized users. Essentially, the CPD configures the filtering list of the PFD via this channel. The request for the list of authorized users happens in the function
cpd_client_connection() in file
connect_ped(), in file
client_message(), in file
run_http_server(), in file
receive_message(), in file
Policy Enforcement and Policy Server Daemon Workflow