Resolving SCALANCE W748-1 DHCP Client IP Assignment Behind AP

1. Problem Overview

A SCALANCE W748-1 RJ45 operating as an IWLAN client frequently associates with the access point and receives its own IP address from the upstream DHCP server, but any device on the Ethernet side of the W748-1 (for example, a Linux PC, a controller, or a managed switch) fails to obtain an IP address. The downstream device either times out on DHCPDISCOVER, sees the lease table on the server remain empty, or only completes the four-way handshake after the operator forces the DHCP server to respond in broadcast mode.

The symptom is platform-agnostic on the wired side: it has been reproduced on Linux (dhclient, systemd-networkd, NetworkManager), on Windows, and on embedded devices using standard DHCP clients. On the wireless side, the SCALANCE W748-1 itself remains associated, the WLAN link quality is good, and the uplink DHCP lease is renewed normally. The condition is therefore a Layer 2/3 visibility problem, not a radio or association problem.

Operationally, this means a single wired host behind a W748-1 client cannot be commissioned in default configuration. In brownfield cabinets, the same problem often surfaces only after a firmware update, an AP swap, or a MAC Mode change on the client, so the root cause is not always recognized immediately.

2. Affected Hardware and Firmware

The behavior described in this article applies to the following IWLAN client family:

Firmware branches that expose the three MAC Mode options (Automatic, Own, Layer 2 Tunnel) are the relevant versions. Newer SCALANCE W firmware does not remove these options, but the default can differ between releases; the configuration paths below assume the W748-1 Web-Based Management (WBM) and the Command Line Interface (CLI via TELNET/SSH) for Primary Setup Tool (PST) and SINEC NMS management.

Reference documentation: Configuring SCALANCE X / W / M - DHCP Server, Address assignment with DHCP (ID: 109826940).

3. Technical Background: MAC Mode on IWLAN Clients

The W748-1 supports three MAC modes that determine how the device identifies itself on the WLAN segment. The choice has a direct impact on DHCP, ARP, and bridge learning upstream.

The Automatic and Own modes both deliberately hide or override the wired device's MAC. This is the root cause of the DHCP failure in the typical deployment: the DHCP server only ever sees one MAC address, and the lease it issues cannot be delivered to the right host because the W748-1's bridging logic in these modes is not designed to pass the DHCP transaction through with full per-host MAC identity.

4. Root Cause Analysis

In default Automatic or Own MAC mode, the IWLAN client inserts its own MAC address (or a shared MAC) into every frame sourced from the wired segment. The chain of events on a typical DHCP exchange is therefore:

1. Wired device sends DHCPDISCOVER with chaddr = AA:BB:CC:DD:EE:01 and giaddr = 0.0.0.0.
2. W748-1 bridges the frame upstream but rewrites the source MAC to AA:BB:CC:DD:EE:00 (its own WLAN MAC).
3. DHCP server logs the request from AA:BB:CC:DD:EE:00 and reserves a lease for that MAC, or, if the W748-1 already holds a lease for that MAC, sees a duplicate chaddr and either silently drops or NAKs the request.
4. Server replies DHCPOFFER unicast to AA:BB:CC:DD:EE:00. The W748-1 accepts the offer locally because chaddr matches its own MAC.
5. The wired device never sees DHCPOFFER because the reply was consumed by the W748-1 and not forwarded to the correct port (or it sees an offer whose chaddr does not match its own and discards it per RFC 2131).

The broadcast flag in the DHCP options field (option 53 with giaddr=0.0.0.0) is the standard mechanism the client uses to request DHCPOFFER/DHCPACK as broadcast frames. If the server, switch, or W748-1 is configured to drop broadcast suppression on the WLAN segment, the offer can be delivered; this is the "brutal broadcast solution" that has been observed to work in the field. It is, however, a workaround that masks the underlying MAC translation problem.

5. Why L2T Fails to Associate on Non-SCALANCE APs

Layer 2 Tunneling is a proprietary Siemens extension carried in proprietary 802.11 information elements between the SCALANCE client and the access point. The AP must understand and trust the L2T encapsulation; only SCALANCE W access points running a matching firmware branch and configured to accept L2T will preserve the tunneled frames and forward them with the original MAC addresses.

When the W748-1 is pointed at a third-party AP (Cisco, Aruba, Ruckus, generic, etc.), the association itself is standard 802.11 and succeeds. The L2T IE is sent in the association request, but the foreign AP discards the encapsulated information and only sees the W748-1 MAC. Some third-party APs treat the unknown vendor IE as a malformed association, which can produce the "will not associate" symptom seen in the field. The W748-1 then continuously retries, the link LED is solid, and WBM shows Not associated with no obvious error.

Consequence: L2T requires a SCALANCE W access point (or a third-party controller with an explicit L2T interop profile, which is uncommon). For installations that must remain on a non-SCALANCE AP, L2T is not a viable solution.

6. Solution 1: Manual MAC Mode (Mixed Use)

If L2T is not available because the AP is foreign, the next best option is Manual MAC mode (sometimes called Static). In this mode, the operator decides which device on the wired side is allowed to use the WLAN link, and the W748-1 itself does not perform a DHCP client on the wired segment.

1. Connect to the W748-1 WBM: https://<IP-of-W748> (default credentials: admin/admin).
2. Navigate to Layer 2 > WLAN > Client.
3. Set MAC Mode to Manual.
4. Enter the MAC address of the single downstream host that is allowed to use this radio link. Up to eight MACs are accepted on some firmware versions.
5. Click Set Values and reboot the client.
6. Re-associate and confirm the W748-1 is online (Information > WLAN > Client shows Associated).
7. From the downstream host, run ipconfig /renew (Windows) or dhclient -v eth0 (Linux) and verify a lease is granted.

Manual mode is suitable when only one device on the wired side needs network access, which is the common case for a controller cabinet. The DHCP server then sees a single, stable MAC and the W748-1 stays out of the way.

7. Solution 2: L2 Tunnel with a SCALANCE Access Point

For greenfield deployments, multi-device panels, or any site already running a SCALANCE W AP, L2T is the correct long-term solution. L2T preserves MAC identity for up to eight downstream devices, which means a SCALANCE W client can pass traffic for an HMI, a controller, and a network printer simultaneously without MAC collision.

1. On the SCALANCE W access point, navigate to Layer 2 > WLAN > AP and confirm Layer 2 Tunneling is enabled (default on most firmware versions).
2. On the W748-1, navigate to Layer 2 > WLAN > Client.
3. Set MAC Mode to Layer 2 Tunnel.
4. Set the SSID, Security, and Radio parameters identical to the original Automatic profile.
5. Click Set Values and reboot the W748-1.
6. On the AP, verify in Information > WLAN > Client List that the W748-1 is shown as Associated (L2T) with the tunneled downstream MACs listed in the detail view.
7. From the downstream host, run a DHCP renew and confirm the server log shows the host's MAC in the binding entry.

Once L2T is active, the W748-1 acts as a transparent Layer 2 bridge with a one-to-one MAC pass-through. DHCP, ARP, IPv6 ND, and 802.1X all work end-to-end as if the device were wired directly to the AP.

8. Solution 3: DHCP Server Broadcast Response

When neither L2T nor Manual mode fits the deployment, the operator can configure the DHCP server or the W748-1 to ensure DHCPOFFER and DHCPACK are always broadcast on the WLAN segment. This is the workaround that has been confirmed to work in production but is the least clean option because it floods the wireless segment with broadcast frames and stresses the AP.

8.1. Configure the wired client to set the broadcast flag

• Windows: The Microsoft DHCP client always sets the broadcast flag by default. No change is required. Reference: DHCP Client Fails to Obtain IP Address from DHCP Server.
• Linux (dhclient): The default /etc/dhcp/dhclient.conf already requests broadcast responses. To force it explicitly, add request subnet-mask, broadcast-address, routers, domain-name-servers; and verify with dhclient -v eth0.
• Linux (systemd-networkd): Add DHCPv4=true and RequestBroadcast=true to the [DHCPv4] section of the .network file.
• Linux (NetworkManager): Add ipv4.dhcp-broadcast=true to the connection profile: nmcli con mod <name> ipv4.dhcp-broadcast yes.

8.2. Configure the SCALANCE to allow broadcast forwarding

On the W748-1, the Layer 2 > WLAN > Client page includes a Broadcast or DHCP Broadcast option. Set it to Forward rather than Filter to permit DHCP broadcast frames to traverse the radio link. Apply, save, and reboot if required by the firmware version.

On the SCALANCE AP side, review the same setting on Layer 2 > WLAN > AP > Broadcast to make sure broadcast DHCP frames are not filtered at the AP.

8.3. Configure the DHCP server

Most enterprise DHCP servers (Windows DHCP, ISC DHCP, dnsmasq, Siemens SIMATIC NET DHCP) honor the broadcast flag by default. On ISC DHCP, confirm always-broadcast is not set; on dnsmasq, confirm --dhcp-broadcast is enabled. See SCALANCE X / W / M DHCP Server for the Siemens-side configuration example.

9. Step-by-Step Diagnostic Procedure

Use the following sequence to isolate the failure quickly on site.

1. Confirm radio association. WBM > Information > WLAN > Client: status Associated, RSSI > -75 dBm, TX rate matches the configured 802.11 standard.
2. Confirm the W748-1 has a DHCP lease. WBM > Information > System > IP & MAC: shows the IP from the server, lease time, and DHCP server address. If empty, the upstream DHCP problem is unrelated to the wired device.
3. Capture DHCP traffic on the wired port. Use a managed tap or mirror port. Run tcpdump -i eth0 -n port 67 or port 68 -vvv on the Linux client. Confirm whether DHCPDISCOVER is leaving the device and whether DHCPOFFER is being returned.
4. Capture DHCP traffic on the server side. Confirm the chaddr in the request. If it is the W748-1's MAC and not the downstream device's MAC, MAC Mode is the problem.
5. Check the AP vendor. If it is non-SCALANCE, expect L2T to fail to associate. Move directly to Solution 1 (Manual) or Solution 3 (Broadcast).
6. Apply the chosen fix and re-run steps 1-4 to verify the downstream MAC now appears in the binding table.
7. Verify connectivity: from the wired host, ping <DHCP-server-IP> and ping 8.8.8.8 (or any reachable external target) to confirm L3 reachability beyond the AP.

10. Verification Checklist

11. Best Practices and Field Notes

• Pick MAC Mode deliberately. Default Automatic is fine for a single direct-attached device with no other wired clients. For a panel with a controller, HMI, and managed switch on the same Ethernet segment, use L2T (with a SCALANCE AP) or Manual (with a single trusted MAC).
• Keep Alive. Per Siemens KB 109826940, disabling Keep Alive resets the IP to 0.0.0.0 and forces a full DHCP exchange. Enable Keep Alive in installations where link flapping would otherwise disrupt the lease.
• MAC allow-list on the AP. When you have moved to Manual mode, the W748-1 itself still presents a single MAC to the AP. Locking the AP's MAC filter to that single address is a simple defense-in-depth measure.
• Avoid mixing L2T and non-SCALANCE APs. If a brownfield expansion must add a third-party AP, prefer keeping the W748-1 in Manual mode for that segment rather than enabling L2T and breaking association.
• Document the MAC Mode in the project's networking standard. DHCP outages caused by MAC Mode drift are common after a swap-out; a single line in the cabinet documentation ("W748-1: MAC Mode = Manual, downstream MAC = AA:BB:CC:DD:EE:01") saves a half-day of troubleshooting.
• Update the DHCP server's view of the world. When L2T is enabled, the DHCP server will see the downstream device's real MAC. Pre-staging reservations and Option 82 information is recommended if the network relies on per-device policy.

12. Troubleshooting Matrix

FAQ