Troubleshooting Siemens LOGO! CMR2040 No Data Connection

Problem Overview

The Siemens LOGO! CMR2040 cellular router is the 4G/LTE member of the LOGO! CMR family and is designed to give LOGO! 8 logic modules and other Ethernet-attached equipment secure remote access over 2G/3G/4G mobile networks. A recurring field failure mode is a complete loss of the IP data connection when a roaming or multi-IMSI static-IP SIM is inserted, even though the same SIM registers, obtains a PDP context, and runs full IP traffic on a commercial consumer router such as a TP-Link MR600 or Archer MR200.

The CMR's diagnostic page then reports:

• Mobile network: registered, but no data connection
• DNS server address: 0.0.0.0
• IPv4 address: 0.0.0.0 (no PDP/EPS bearer activated)
• Connection-time counter advancing, but data-connection flag stuck on "No"

This article documents the verified root cause, the diagnostic procedure, the firmware-level behavior, and the field-proven workaround that restores HTTPS access to the CMR and full IPsec VPN access to the LOGO! 8 base module and its on-board web server.

Product Reference: LOGO! CMR2020 / CMR2040

The CMR2040 is the 4G/LTE variant of the LOGO! CMR family. The CMR2020 is the 3G/UMTS variant. Both share the same firmware architecture, web-based configuration pages, and SIM holder. Refer to the official Siemens operating instructions for the full specification set, the diagnostic page layout, and the configuration parameters:

• LOGO! CMR2020 / LOGO! CMR2040 Operating Instructions (PDF)

The same PDF describes the diagnostic page "Mobile wireless network", which shows how long the connection has been established since the last booking into the mobile wireless network, and a separate indicator confirming whether a data connection is currently established ("No" / "Yes, with IPv4").

How the CMR2040 Establishes a Data Connection

The cellular modem inside the CMR performs the following attach sequence on every power-up, SIM insertion, or re-registration event:

1. Read the IMSI from the inserted SIM and present it to the modem firmware.
2. PLMN scan; select the home PLMN, or, if the IMSI is foreign, a permitted roaming partner.
3. Attach to the packet-switched (PS) domain via LTE EPS attach or UMTS GPRS attach.
4. Activate a PDP context (UMTS) or default EPS bearer (LTE) using the configured APN. This is the step that returns the IP address and the DNS server addresses.
5. Bring up the internal "data connection" state machine. The web UI switches its data-connection indicator from "No" to "Yes, with IPv4".

Step 4 is the step that fails in the reported case. The PS attach succeeds, but the modem does not receive a DNS server from the operator and cannot complete the default bearer. The CMR therefore shows 0.0.0.0 for both IP and DNS, even though it is otherwise registered and would otherwise be billable to the network.

Network Standards and SIM Behavior

Single-provider SIM

A standard consumer or business SIM tied to a single mobile network operator (in the original UK case, Three UK) presents a single IMSI, registers on a single PLMN, uses a single APN, and receives a public DNS push. The CMR2040 negotiates the bearer in one shot, the DNS server appears in the diagnostics, and the data connection comes up within 30–90 seconds of insert.

Roaming / multi-IMSI static-IP SIM

A multi-IMSI "steering" SIM is provisioned with several IMSIs, one per partner operator, and a controller in the SIM applet selects the IMSI that maps to the strongest signal at attach time. The SIM may re-IMSIs within the same session if the signal degrades, and is typically paired with a private M2M APN that returns a static or pseudo-static address and a walled-garden DNS.

Most consumer cellular routers (TP-Link, Huawei consumer, Netgear LB1120/LB2120) use a Qualcomm MDM9xxx-class modem and a permissive Linux PPP/QMI stack that re-tries bearer activation, accepts private DNS, and works around APN variations. The Siemens cellular module inside the CMR is stricter: it expects the configured APN to match what the operator pushes, and it surfaces any DNS push that is missing or RFC1918-only as 0.0.0.0 in the diagnostic page.

Root Cause Analysis

The reported field fault is the combination of three conditions, any one of which is sufficient to cause the failure:

1. APN mismatch. The roaming SIM's bootstrap APN differs from the APN configured on the CMR. Without a working APN, the SGSN/MME rejects bearer activation. The CMR shows registered but no data connection.
2. Steering race condition. Multi-IMSI SIMs can re-select networks faster than the CMR's re-registration timer. The modem re-attaches before completing the previous PDP context, leaving DNS unassigned. Each re-IMSIs starts a new attach cycle that never completes.
3. DNS push suppression. Some M2M/IoT APNs deliver a private RFC1918 address and either no DNS or a DNS that is reachable only from the operator's walled garden. The CMR's internal DNS client then displays 0.0.0.0 and cannot resolve the public hostname used by the VPN endpoint or by HTTPS clients.

Diagnostic Procedure

1. Insert a known-good consumer SIM (e.g., a Three UK standard data SIM) into the CMR2040 and confirm that data connection establishes on UMTS, GPRS, or LTE. This verifies the radio chain, the antenna cabling, and the modem firmware.
2. Power-cycle the unit with the suspect static-IP SIM inserted. Open the CMR's web interface at https://<CMR-IP> (default https://192.168.1.1) and navigate to Diagnostics → Mobile wireless network.
3. Record the following values to a commissioning sheet:
   • Mobile network status (registered / not registered / searching)
   • PLMN code and operator name
   • Signal strength (CSQ value or RSSI in dBm; target > -90 dBm)
   • IP address
   • DNS address (the field of interest)
   • Connection time
   • Data connection flag (No / Yes, with IPv4)
4. Under System → Event log, look for APN-related messages, SIM PIN failures, PDP context errors, and "no DNS" messages. The event log persists across reboots and is the most reliable place to find intermittent APN negotiation failures.
5. Use the LOGO! CMR Configuration Tool (Windows) to read out the full configuration, including APN, authentication, DynDNS, and IPsec settings, without losing the running state. The tool can also export the configuration to a file that can be diff'd against the project documentation.
6. From a laptop on the LAN side, run ping 8.8.8.8 to confirm raw IP reachability. If ping works but DNS does not, the bearer is up but DNS is missing — confirm with the operator.
7. From a laptop on the LAN side, run nslookup siemens.com <operator-DNS> using the DNS address from the diagnostics page. If the operator's DNS is RFC1918 and unreachable, that is the source of the 0.0.0.0 display.

Step-by-Step Resolution

The verified fix from field reports is to use a single-provider, fixed-public-IP SIM card rather than a roaming multi-IMSI SIM. The procedural steps are:

1. Obtain a fixed public IPv4 SIM from a single mobile network operator. In the original UK case, the customer obtained a Three UK business SIM with a static public IP option. The SIM must be tied to a single PLMN, not a roaming aggregator.
2. Confirm with the operator the exact APN string, authentication type (PAP / CHAP / none), and the static IPv4 address that will be assigned to the device. Ask the operator to confirm the PDP type as IPv4 and to confirm that public DNS servers will be pushed.
3. Insert the SIM into the CMR2040. Power-cycle the unit. The SIM is hot-swappable on most firmware versions, but a power-cycle guarantees a clean attach sequence.
4. Open the CMR web UI → Interfaces → Mobile network. Enter the APN, username, password, and PIN exactly as provided by the operator. Trailing spaces in the APN string are a common commissioning error.
5. Set the PDP type to IPv4. Do not select IPv4/IPv6 unless the operator explicitly requires dual-stack; some operators' M2M APNs advertise IPv6 only, and the CMR will display 0.0.0.0 if it cannot acquire an IPv4 address.
6. Save and apply. The status page should transition from No data connection to Yes, with IPv4 within 30–90 seconds. The DNS field should populate with the operator's DNS server.
7. Confirm the public IP matches the address assigned by the operator. From the LAN side, browse to https://api.ipify.org to confirm the public IP seen by an external service.

Verification and Commissioning Checks

After the data connection is established, validate the following services in this order. Each check is independent; if one fails, the others are still meaningful diagnostic data.

field reports reported that HTTPS to the CMR worked directly from the public IP, but the LOGO! 8 web server on the LAN side of the CMR was not directly reachable on the WAN side. Routing the LOGO! 8 web server through the IPsec VPN tunnel restored full access, including the web server's variable monitoring and program upload.

VPN Configuration Reference

The CMR2040 supports IPsec VPN with the following parameters. The exact menu path is Security → VPN → IPsec.

Firewall Rules for LOGO! 8 Web Server Access

By default, the CMR's firewall denies all inbound traffic on the WAN side except the ports explicitly opened for VPN (UDP 500, UDP 4500, ESP) and the CMR's own HTTPS (TCP 443). The LOGO! 8 base module listens on TCP 80 and TCP 443 on its LAN IP (default 192.168.0.10 or 192.168.1.10, depending on the LOGO! 8 firmware).

Two approaches are valid:

1. Recommended: route through the IPsec VPN. The LOGO! 8 web server is reachable inside the tunnel. No firewall rule change is required on the CMR. The VPN tunnel terminates on the CMR and forwards traffic to the LOGO! 8 base module on the LAN side.
2. Direct: add a port-forwarding rule. Security → Firewall → Port forwarding: external port TCP 8443 → internal IP 192.168.0.10, internal port TCP 443. Restrict the source IP to known remote IPs. This is acceptable only if the LOGO! 8 web server's own authentication is sufficient and the public IP is static.

Antenna Selection and Placement

The CMR2040 has two SMA female antenna connectors. Both must be terminated for proper MIMO operation on LTE. The first connector is the main TX/RX antenna; the second is the diversity/MIMO RX antenna.

Power and PoE

The CMR2040 accepts 12–24 V DC on its removable terminal block. It is also a PoE Powered Device (PD), class 3, on the CMR2040 variant. The CMR2020 does not support PoE. The maximum current draw at 12 V is approximately 1.5 A during LTE attach peaks, falling to 0.5 A in steady state.

For PoE deployment, use a PoE+ (802.3at) switch or injector. PoE (802.3af, class 3, 12.95 W) is at the limit and may brown-out during attach peaks on long cable runs. If the installation is cable-limited, supply 24 V DC instead.

LED Indicators

Event Log Interpretation

The event log is the most reliable diagnostic for intermittent attach failures. The following patterns are common on the reported fault:

Troubleshooting Matrix

Field Deployment Best Practices

• Specify single-provider SIMs for CMR2040 deployments. Avoid multi-IMSI roaming SIMs unless they are explicitly validated against the deployed firmware on the actual network operators in the country of deployment.
• Document the APN, PDP type, authentication method, and assigned public IP in the project documentation. These are the four most common commissioning errors.
• Use an external LTE antenna mounted outside any metal enclosure. The internal antenna pads are not sufficient for industrial cabinets.
• Connect both SMA ports (main and diversity) for proper LTE MIMO operation. Leaving the second port un-terminated halves the downstream throughput and reduces cell-edge margin.
• Schedule a DynDNS update interval of 60 s or less if the operator's CGNAT is in use and you have a fixed public IP. The faster update reduces the window in which a stale DNS record can fail to reach the new IP after a network change.
• Always terminate the LOGO! 8 web server behind the IPsec VPN. Do not expose the LOGO! 8 base module's HTTP/HTTPS server directly to the internet, even on a fixed public IP.
• Enable the SMS wake-up feature on the CMR only if the SIM supports SMS on the same IMSI; some M2M data-only SIMs do not have SMS service activated.
• Apply the latest firmware to the CMR before commissioning. Firmware updates have historically improved the cellular modem's tolerance of operator-specific APN variations.

LOGO! 8 Web Server Side of the Configuration

The LOGO! 8 base module's web server is configured in LOGO! Soft Comfort (Programming → Web Server Access) or in the LOGO! 8's on-board display. For remote access over the CMR, the following settings are required:

• Web server access: enabled
• Web server port: 80 (HTTP) and 443 (HTTPS); both must remain on the LOGO! 8's default unless the operator blocks port 80 inbound on the cellular network
• LOGO! 8 LAN IP: a static IP on the CMR's LAN subnet (e.g., 192.168.1.10 if the CMR is on 192.168.1.1 with subnet 255.255.255.0)
• LOGO! 8 default gateway: the CMR's LAN IP (192.168.1.1)
• Web server user/password: set a strong password; the default is LOGO / LOGO and must be changed

Configuration Backup with the LOGO! CMR Configuration Tool

The Windows-based LOGO! CMR Configuration Tool allows the engineer to read the running configuration, edit it offline, and push it to one or many CMR units at once. This is the recommended workflow for fleet commissioning.

1. Connect a laptop to the CMR's LAN port. The Configuration Tool auto-discovers the unit on 192.168.1.1 by default.
2. Click Read to download the running configuration.
3. Set the APN, PDP type, and authentication under Mobile network.
4. Configure the IPsec tunnel under Security → VPN.
5. Save the configuration to a project file. The file is human-readable XML and can be diff'd against the project documentation.
6. Click Write to push the configuration back. The CMR will reboot and re-attach with the new settings.

Alternatives and Related Industrial Routers

If the CMR2040 cannot be made to work with a given operator's APN, the project may need to fall back to a different industrial router family. Common alternatives include:

FAQ