> For the complete documentation index, see [llms.txt](https://help.security.gallagher.com/knowledge-hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.security.gallagher.com/knowledge-hub/products/cc-hardware/controllers/controller-7000-and-7000-sdc/configure/controller-7000-bringing-online-and-ne.md). # Bring a controller online and configure networking Bring a Controller 7000 online and configure its IP address, server connection, and network settings. > 📋 **Prerequisites:** Know the [Ports](/knowledge-hub/products/cc-hardware/controllers/controller-7000-and-7000-sdc/reference/controller-7000-ports.md) the controller uses, and have the [Controller 7000](broken://pages/873trKCrdhjXzfqYdsdU) overview to hand. This procedure also applies to Controller 7000 SDC. ## This page answers * How does the controller connect to the server? * How do I assign the controller an IP address? * Why won't my controller come online, and how do I test the connection? Controllers establish a network connection to the server to enable communication of configuration and access data. The connection is **outbound TCP** from the controller to the server on port `1072`: ``` Controller → port 1072 → Server ``` > **Note (v8.50+):** From version 8.50 onwards the controller is the device that makes the initial TCP connection to the server. The server does NOT send a TCP connection request to the controller. *** ## Assigning an IP address ### Method 1: BootP (controller on same subnet as server, no DHCP) Use this method when the controller and server are on the same subnet and there is no DHCP server on the network. 1. Ensure the "FT Bootstrap Protocol Service" is running on the server (Control Panel > Administrative Tools > Services). 2. In Command Centre, go to **Configure > Hardware > Controller Properties > Setup** tab. Set the MAC Address, Controller IP Address, and Gateway (if required). 3. If the controller is connecting via the Internet or the server has multiple adapters and the controller is not on the primary adapter, enter the server's IP Address in the "Use different IP for Server" field. 4. Confirm the server IP Address that will be sent to the controller by pinging its HOST name: * Run `C:\>ipconfig /all` to find the server HOST name. * Ping the server HOST name. The resolved IP Address is what will be stored in Command Centre and sent to controllers. 5. Ensure a network cable with an active connection is plugged into the controller **before** powering it on. 6. Power on the controller with **DIP switch 2 ON**. When it reaches a 3-flash state it will broadcast, requesting an IP address. 7. The FT Bootstrap Protocol Service replies with the controller's configuration, including the server IP Address. > **Note:** If a DHCP server is also on the network, it may reply to the controller's broadcast before BootP does. DHCP configuration always takes precedence over BootP. On most networks, broadcast messages are suppressed across different subnets, so BootP will not work if the controller is on a different subnet to the server. > **Note:** An event in Command Centre confirms the controller's MAC address and that the IP configuration was sent. This event does not confirm the controller will actually use the configuration. Verify by checking the controller's TCP Sender web page. *** ### Method 2: Default IP address (DIP switch 1, 2, 3) Use this method to manually assign the controller's IP address via its web interface. 1. In Command Centre, configure the controller as per Method 1 (set MAC, IP, Gateway). 2. Ensure DIP Switches 1, 2, and 3 are all **ON** (up). 3. Ensure a network cable with an active connection is plugged into the controller. 4. Restart the controller by cycling the power. The controller will use these default addresses: * IP Address: `192.168.1.199` * Server IP: `192.168.1.198` * Gateway: `192.168.1.198` * Subnet: `255.255.255.0` 5. Connect a laptop with an IP address in the same subnet (192.168.1.xxx) to the controller. 6. Open a browser and navigate to: `192.168.1.199/config.` (note the trailing full stop, which is required). 7. Enter credentials: User Name = `config` (all lowercase), Password = `[REDACTED]` (contact Tech Support). 8. The Gallagher Controller Configuration screen displays. Select **LAN Configuration**. 9. Complete the Ethernet LAN Configuration fields: | Field | Description | | ------------------ | ------------------------------------------------------------------------------------------ | | IP address | The IP address for the Controller, and must match the IP configured in CC Controller Setup | | Server IP address | The IP address of the Command Centre Server | | Gateway IP address | The gateway for the Controller's network segment | | Subnet | The subnet for the Controller | 10. Click **Save**, then click **Set** in the LAN Configuration. 11. The controller should go to a 2-flash state. 12. Turn OFF DIP switches 1, 2, and 3. 13. Disconnect the network cable from the laptop and plug the controller into the site network. 14. The controller should come online to the server. 15. Upgrade the controller to the correct firmware version for the server. The controller will restart. 16. If upgrading from WinCE to Linux, apply the override "**Revalidate Certificate**". *** ## Notes on first-time connection **First connection:** If a controller has never connected to the server, it must have the correct IP Address for the Server PC on its first connection. The server checks this IP and will actively refuse the connection if it does not match. This is due to how Command Centre manages certificates. **Subsequent connections (after DHCP or reset):** If the controller has previously connected and has been reset, the server will update the controller with the correct server IP Address even if the controller initially has the wrong one. **Checking what IP the controller holds for the server:** web browse to the controller and check the **TCP Sender** page (see Web browsing the controller below). *** ## Dynamic DNS (DNS disaster recovery) The DNS setting allows Domain Name Servers (DNS) to be used in disaster recovery situations, especially where backup servers reside on different subnets. * If DNS is configured and the server stops responding for **at least 10 minutes**, controllers start querying the specified DNS servers in order, and try to connect to the listed IP address. * If it cannot connect, the controller cycles continuously through the DNS servers. * Once it connects to a server, it stays with that server until the connection is lost for 10 minutes, then queries DNS again starting with the primary server. * The controller looks for the server CNAME on the DNS server, which points to the A record (containing the server IP address). The A record must be manually updated to the new server IP (unless the site has Dynamic DNS) before controllers can find the backup server. * The backup server must use the same FQDN as the production server. *** ## Troubleshooting: controller won't come online * If the server has more than one network interface, ensure the "Use different IP for Server" field contains the IP address for the network interface connecting to the controllers. > **Note (upgrading):** During an upgrade using the BootP addressing option, DIP Switch 2 must remain ON. * If the site must assign IP addresses using the DIP Switch 1,2,3 procedure, turn OFF all DIP Switches once the IP address is set. * Upgrading via USB is an alternative upgrade option. Refer to the release notes for the correct procedure. ### Controller drops offline immediately after coming online Symptom: After initial connection, the controller shows online (or online with purple question mark) then goes offline and stays offline. Likely cause: When services started, an invalid IP address was resolved and sent to the controller (e.g. no network connection at that moment). Typical invalid addresses: `127.0.0.1` or `169.254.x.x`. **Fix:** 1. Check what the controller has stored for the Server IP address via TCP Sender (web browse). 2. Confirm the server has the correct IP Address (ping the host name). 3. Restart the FT Services. 4. Perform a **Push Configuration** to the controller (right-click context menu on the controller in CC). **Alternative cause, IPv6 enabled but no IPv6 address configured:** This happens when the controller's IP address was assigned by web browsing but IPv6 was enabled without an IPv6 address. The controller works initially but fails after restart/power cycle. Web browsing to the TCP Sender page will show the Server IP is missing from the node table. Check `Main.ini` (via the controller's directory listing page): ``` [Network] DHCP=0 IP1= ← this field is empty; IPv6 was selected but not configured Port1=1072 ``` **Fix:** Uncheck the IPv6 option in CC controller settings, then push configuration to the controller. ### Command Centre server has multiple network adapters CC resolves the server's IP by pinging the HOST name of the PC. The IP returned is the address sent to controllers as the server IP. From CC version 6 onwards, this is resolved every time the FT Services start. * Use `ipconfig /all` to list all IP addresses on the PC. * If a Wireless Adapter is enabled, it may become the primary adapter and cause CC to resolve the wrong IP. **Test:** Disable the wireless adapter, restart the FT Services, and DIP switch 2 the controller. If controllers come online, the wireless adapter was the issue. **Windows 10 and above:** Contact your local IT representative. Typically no additional configuration is required. Adjusting the NIC metric may be needed but can affect other systems. **Windows 7 and Windows 2008 (changing adapter binding order):** 1. Go to Control Panel > Network and Internet > Change adapter settings (or run `ncpa.cpl`). 2. Press the **Alt** key to reveal the hidden menu beneath the location bar. 3. Under the **Advanced** menu, click **Advanced Settings**. 4. The connections are shown in the order network services access them. 5. Use the **Up** and **Down** buttons to adjust the order of priority. *** ## Network connectivity tools (v9.30+) A built-in tool on controllers running firmware v9.30 or later allows the controller itself to test TCP connections to a specified IP and port. **Access:** * If web browsing is enabled (or the controller hasn't connected to CC yet, turn on DIP Switch 1): browse to `{controller-ip}/debug.` * Log in with user `debug` and the debug password (contact Tech Support for the password; a default applies if the controller hasn't connected to a server yet). * Select **Network Connectivity Tools**. ![Network Connectivity Tools entry link](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-d5f6fb7ffbc95c0f3a7752fdce0744b26936419b%2FSECHUB-C7000-NETWORKING-01-network-connectivity-tools.png?alt=media) The tool page: ![Network Connectivity Tools dialog](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-9aed1370c132751710210543702e224e4cf5efc8%2FSECHUB-C7000-NETWORKING-02-network-connectivity-tools-dialog.png?alt=media) Enter the IP address and port to test, then click **ConnectToIPAddress**: ![Entering IP and port](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-cb5feda6ce948bf11df7d37574ea90d0c037e537%2FSECHUB-C7000-NETWORKING-03-network-connectivity-enter-ip.png?alt=media) Successful connection result: ![Successful connection](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-cf815f09783cd1bc4ed5a831323a3c86c0c04e7e%2FSECHUB-C7000-NETWORKING-04-network-connectivity-success.png?alt=media) Failed connection result (port not active or unreachable): ![Failed connection result](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-fb34ffdef2e3eeea645215b3a4aa989df1e39711%2FSECHUB-C6000-TESTING-04-network-connectivity-tools-fail.png?alt=media) The tool is also accessible from the Default IP configuration page: ![Network Connectivity Tools from debug page](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-13a87fdc9101fc5488038041f774f441b59919ab%2FSECHUB-C6000-TESTING-05-network-connectivity-tools-debug.png?alt=media) *** ## Testing network connectivity (from laptop/server) > **Best practice:** Run these tests from the controller's network connection point using a laptop configured with the same IP settings as the controller. ### Ping ``` C:\>ping C:\>ping ``` A reply confirms a network connection exists. Also adds an entry to the ARP cache (required for the ARP command below). Ping may fail if: * No route exists to the controller * ICMP protocol is disabled on the site network Check the **Link Light** (green LED next to the Ethernet port on the controller). It should be solid on. > **Note:** If ping returns an IPv6 address, use `ping -4 ` to force IPv4. > **Cross-subnet:** If the controller is on a different subnet to the server, the switch the controller is plugged into must reply to pings. The controller pings the gateway to confirm connectivity before transmitting to the server. *** ### Listen port Default communication port: **Port 1072** (defined as the Listen Port in the Gallagher Registry). Unless a unique Listen Port has been configured, 1072 is always used after installing Command Centre. > **Note:** If the site uses a non-standard listen port, the controller must first connect to the server to pick up that port. *** ### Telnet ``` C:\>telnet 1072 ``` Tests TCP port 1072 (used for controller-to-server and controller-to-controller communication). Must be run in both directions. > **Note (v8.50+):** From version 8.50, controllers communicate only outbound to the server on port 1072. The server no longer reaches out to the controller on the listen port. Only one connection will be visible (not two as in earlier versions). > **Note:** If `'telnet' is not recognized`, install from Control Panel > Programs and Features > Turn Windows features on or off. Install both **Telnet Client** and **Telnet Server**. **Interpretation:** | Result | Meaning | | -------------------------------------- | ---------------------------------------------------------------------------------------------- | | Screen blanks, cursor flashes top-left | Port is OPEN (OK) | | Cursor returns to C: prompt | Port is OPEN (OK), and may also get a connection-lost message or alarm if controller is online | | Connection refused / error message | Port is BLOCKED (FAIL) | **If port is blocked, check:** 1. Windows Firewall or third-party firewall 2. Ask IT if the port is blocked at Switch/Router level 3. Anti-virus software, since some prevent controller connections; try temporarily disabling *** ### Telnet alternative: PowerShell TNC (preferred, no install required) ```powershell PS C:\Users\Gallagher> tnc [ip address] -p [port number] ``` Example: `tnc 10.20.82.199 -p 1072` ![TNC command result](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-d41b4dd7cf77c363efbde40a14aba9c233919d75%2FSECHUB-C7000-TESTING-01-tnc-command-result.png?alt=media) Advantages over Telnet: 1. No Telnet client installation required on Windows 2. Shows which Server IP and Network Adapter are being used to communicate with the controller *** ### ARP ``` C:\>arp -a ``` Run after pinging the controller. Confirms you are receiving a reply from an actual Gallagher controller. Find the Internet Address you pinged. **If the Physical Address starts with `00-90-1d`, it is a Gallagher controller.** *** ### Netstat ``` C:\>netstat -an C:\>netstat -ano ``` **CC version 9.00 and above (one connection):** ![Netstat v8.50+ result](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-e3334d104c03516ab0d397348abc8949017716de%2FSECHUB-C6000-TESTING-08.png?alt=media) From v8.50, only ONE connection is established (controller to server). This is expected. **Checking the server is listening on port 1072:** ![TCP netstat port 1072 listening](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-de7fd967c4643b2da91425d3a52855ce5b950fb3%2FSECHUB-C6000-TESTING-03-netstat-ano-port-1072.png?alt=media) Run `netstat -ano`. The server should show LISTENING on port 1072. Confirm the PID shown is the FT Controller Service via Windows Task Manager. > **Important:** If the PID of 'FT Controller Service' does NOT match the PID using port 1072, another application is locking port 1072, causing the controller to fail to come online. ![Port conflict — wrong PID](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-fb969a9af508e273f4591dbf8f26749d763f026c%2FSECHUB-C7000-TESTING-05-tcp-netstat-port-conflict.png?alt=media) **Solutions:** * **Option 1:** Get the third-party application to change or stop using port 1072. * **Option 2:** Change the listen port of the server-controller communication to a custom port. (See Listen Ports for Controllers in the Command Centre documentation.) *** ### Web browsing the controller Web browsing lets you confirm the IP configuration the controller is using, check certificates and keys, review the error log, and verify the node number. **URL format:** `{controller-ip}/debug.` (the trailing full stop is required) Example: `172.16.243.56/debug.` **Credentials:** | Condition | Logon | Password | | --------------------------- | ------------ | ------------------------------------------------------------------------------------- | | Controller in 2-flash state | `diagnostic` | `[REDACTED]` (default - contact Tech Support) | | Controller in 1-flash state | `diagnostic` | `[REDACTED]` (site-specific value based on Site Serial number - contact Tech Support) | | CC v8.40+ | `diagnostic` | May be a configured password, check with Tech Support | **Key pages:** **TCPSender.** Primary page. Check the "Server IP" field. If it does not match the actual server IP, the controller will not come online. Active sessions show if the server is connected. **TCPExchange.** Confirms keys and certificates are valid and the correct Master certificate is selected (should match the Certificate setting on the Controller's Setup tab in CC). Active sessions show if the controller is connected to the server. **Errorlog.** Check as a last resort for recurring errors or restarts. **Node Number.** Ensure the node number on the web page matches the node number in CC. To find the Node Number in Command Centre: 1. Open Controller Properties and select the **Setup** tab. 2. Hold the **Ctrl** key down and double-click with the left mouse button in a clear area of the Setup tab. 3. A popup window displays the controller's node number. ![Node number popup in CC](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-cb27ae4dc9075405ff3e9d48cda59b9fce7d6037%2FSECHUB-C7000-TESTING-07-node-number-popup.png?alt=media) *** ## Firewall configuration Command Centre installs firewall rules during setup. If controllers stay offline, verify firewall configuration. For a focused walkthrough, see [Firewall Issues](/knowledge-hub/products/cc-hardware/controllers/controller-7000-and-7000-sdc/troubleshoot/controller-7000-firewall-issues.md). **Quick test:** Temporarily disable the Windows Firewall. If controllers come online, the firewall is blocking them. **Installation option:** If controllers or workstations are on different subnets to the server PC, untick "**Allow communication on local subnet only**" during Command Centre installation. **Adding firewall rules after installation:** 1. Open Windows Firewall (Start > Control Panel > type "firewall" > Windows Firewall). 2. In the left pane, click **Advanced settings**. 3. Click **Inbound Rules** > **New Rule**. 4. Follow the New Inbound Rule wizard. 5. Add the following programs: * `CCNTBertServ.exe` (FT Controller Service) * `CCNTSad.exe` (FT Command Centre Service) **Updating existing rules:** * From Inbound Rules, click the rule to modify (e.g. FT Controller Service). * On the **Scope** tab of Inbound Rules Properties, either add additional scope IP ranges or select "Any IP address". *** 🔗 **Related** * [Ports](/knowledge-hub/products/cc-hardware/controllers/controller-7000-and-7000-sdc/reference/controller-7000-ports.md). The ports and protocols behind these tests. * [Firewall Issues](/knowledge-hub/products/cc-hardware/controllers/controller-7000-and-7000-sdc/troubleshoot/controller-7000-firewall-issues.md). When a firewall is what keeps controllers offline. * [Controller 7000](broken://pages/873trKCrdhjXzfqYdsdU). Variants, specifications, and accessories. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.security.gallagher.com/knowledge-hub/products/cc-hardware/controllers/controller-7000-and-7000-sdc/configure/controller-7000-bringing-online-and-ne.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.