FWA515 V1.70: PPP IPCP Passthrough does not propagate the negotiated IPv4 address to the DHCP pool

Maverick87

Post
Hello Zyxel Support and Community,
I would like to report a reproducible IPCP Passthrough issue on an FWA515. This is a new and narrowly scoped report: PPPoE discovery, authentication, and IPCP negotiation all succeed. The failure occurs afterward, when the negotiated IPv4 information should be propagated to the configured DHCP pool.

Product and network

• Device: Zyxel FWA515
• Firmware: V1.70(ACPZ.1)C0/P1
• ISP: TIM Italy FTTH
• WAN: Ethernet WAN over VLAN 835, PPPoE, IPv4
• PPP interface: ppp0
• PPP base interface: eth1.835
• PPP connection type: IP_Routed
• MRU: 1492
• LAN bridge: br0
• DHCP server: dnsmasq

My goal is to let the FWA515 establish the FTTH PPPoE session, pass the negotiated public IPv4 address to a downstream router through IPCP Passthrough, and retain the FWA515 cellular connection as backup.

Working baseline
With IPCP Passthrough disabled, the Ethernet WAN works normally:

• PPPoE discovery completes.
• PAP authentication succeeds.
• IPCP negotiates a public local IPv4 address, peer address, and two DNS servers.
• IP.Interface.4.IPv4Address.1 is populated with the negotiated address and AddressingType=IPCP.
• Routed Internet access through the FWA515 works.
  This confirms that the ONT, VLAN, PPPoE credentials, ISP, and IPCP negotiation are working.
  

Minimal passthrough test
I created a test backup from the working routed configuration and changed only these two values:

1. Device.PPP.Interface.1.IPCP.PassthroughEnable = true
2. Device.PPP.Interface.1.IPCP.PassthroughDHCPPool = "Device.DHCPv4.Server.Pool.1"

The backup was restored normally. Both values were accepted, persisted, and were visible in the live TR-181 data model.
The referenced pool existed and was enabled:

• Device.DHCPv4.Server.Pool.1
  • Enable = true
  • Order = 1
  • Interface = "IP.Interface.1"
  • MinAddress = "192.168.1.2"
  • MaxAddress = "192.168.1.254"
  • SubnetMask = "255.255.255.0"
    

Steps to reproduce

1. Configure a working Ethernet WAN PPPoE connection in IP_Routed mode over VLAN 835.
2. Confirm that PPP reaches Up and IP.Interface.4.IPv4Address.1 contains the IPCP address.
3. Set PPP.Interface.1.IPCP.PassthroughEnable=true and point PassthroughDHCPPool to the enabled Device.DHCPv4.Server.Pool.1 shown above.
4. Reboot the FWA515, or force a complete PPP Down-to-Up renegotiation.
5. Renew the DHCP lease on a client connected to the LAN bridge and inspect Pool.1 and the generated dnsmasq configuration.
   

Expected result
After IPCP reaches the Up state, the FWA515 should apply the negotiated IPv4 parameters to the pool referenced by PassthroughDHCPPool, or otherwise make the negotiated address available to the downstream DHCP client according to the intended IPCP Passthrough implementation.

Actual result

• PPPoE, PAP, and IPCP still complete successfully.
• The public address is correctly written to the WAN IPv4Address object.
• Pool.1 remains unchanged with its private 192.168.1.0/24 range.
• The downstream client continues to receive a private 192.168.1.x lease.
• Forcing a genuine PPP Down-to-Up renegotiation does not change the pool.
• dnsmasq restarts after WAN setup but still advertises the original private range.
• No IPCP Passthrough or DHCP-pool error is logged.
  

Backend trace from the full syslog
The relevant object identifiers can be mapped from their adjacent backend callbacks:

OID 91656 = Device.PPP.Interface.{i}.IPCP
OID 94144 = Device.IP.Interface.{i}.IPv4Address
OID 124024 = Device.DHCPv4.Server.Pool

The successful boot sequence is:

pppd: PAP authentication succeeded
pppd: local IP address <PUBLIC_IPV4_REDACTED>
pppd: remote IP address <PEER_IPV4_REDACTED>
pppd: primary/secondary DNS address <REDACTED>
esmd: processPppdMsg : Enter
esmd: state up

bepppifaceipcpConfigStatsUpdate()
bepppifaceipcpConfigValidation()
zcmdReqObjApply: process oid[91656]
bepppifaceipcpConfigLoad : Enter
bePppIfaceIpcpSet : Enter
...
zcmdReqObjApply: process oid[94144]
...
beIpv4AddrConfigLoad : Enter
setDhcp4ServerSubnet : Enter
...
zcfgBeLanReRunDhcp4Server Enter
dnsmasq-dhcp: DHCP, IP range 192.168.1.2 -- 192.168.1.254

There is no apply of OID 124024 and no invocation of either of these pool callbacks as a consequence of IPCP:

beDhcp4ServerPoolConfigLoad
beDhcp4ServerPoolSet

The logging path is able to show these callbacks. When I later changed only the DHCP lease time manually, the log immediately showed:

zcmdReqObjApply: process oid[124024]
beDhcp4ServerPoolConfigLoad : Enter
beDhcp4ServerPoolSet : Enter
beDhcp4ServerPoolSet : Change of existing

Therefore the negotiated address is never copied to the DHCP pool. It is not copied and subsequently overwritten. The observable failure boundary is in, or immediately behind, the IPCP Passthrough handling in bePppIfaceIpcpSet.

Unrelated log messages already excluded

• Failed to create /etc/ppp/resolv.conf: unrelated. The negotiated DNS servers are subsequently installed and used by dnsmasq.
• IPPassthrough is not enabled, skip Boot RemoMgmtPassthru actions: this belongs to Cellular.Interface.X_ZYXEL_IP_PassThrough and its cellular remote-management rules. It is not the PPP.Interface.1.IPCP setting tested here.
• PPPoE Bridged/relay mode: not part of this report. This test uses a working IP_Routed PPP session and specifically targets IPCP Passthrough.
  

Questions for Zyxel R&D

1. Is Device.PPP.Interface.1.IPCP.PassthroughEnable supported on the FWA515 with firmware V1.70(ACPZ.1)C0/P1?
2. Is another object or feature flag required in addition to PassthroughEnable and PassthroughDHCPPool?
3. Why does bePppIfaceIpcpSet update the WAN IPv4Address object but never apply the referenced DHCP pool?
4. Can Zyxel reproduce this and provide a firmware fix or test build?
5. If this feature is intentionally unsupported, what is the supported method for handing the PPPoE public IPv4 address to a downstream router while retaining cellular failover on the FWA515?

I can provide the complete syslog archive and the two configuration backups privately to Zyxel staff. The public versions will be redacted because they contain PPP credentials, public addresses, device identifiers, and client MAC addresses.
Thank you.

Files to offer privately

• Complete syslog archive from the minimal Pool.1 test.
• Working routed backup with IPCP Passthrough disabled.
• Test backup whose only relevant delta is the two IPCP Passthrough fields shown above.
• Short redacted excerpt covering PPP Up, bePppIfaceIpcpSet, OID application, DHCP restart, and dnsmasq range.

Zyxel_Melen

Hi @Maverick87

Is Device.PPP.Interface.1.IPCP.PassthroughEnable supported on the FWA515 with firmware V1.70(ACPZ.1)C0/P1?

No, confirmed with our team that this firmware does not support PPPoE passthrough.

The rest of questions, I'm still checking with our team. I will update you once I get further information.

Maverick87

Hi @Zyxel_Melen,

Thank you, but my report is not about PPPoE passthrough. It concerns the separate TR-181 IPCP passthrough parameters:

Device.PPP.Interface.1.IPCP.PassthroughEnable

Device.PPP.Interface.1.IPCP.PassthroughDHCPPool

The two mechanisms are different:

• PPPoE passthrough:
  The FWA maintains its own PPPoE session on ppp0 and relays PPPoE Ethernet frames between the LAN bridge and eth1.835, allowing a downstream device to establish an additional PPPoE session. These are PPPoE frames being relayed, not IP packets being routed.
• IPCP passthrough:
  The FWA terminates PPPoE on ppp0 and receives the public IPv4 address through IPCP. The DHCP pool referenced by PassthroughDHCPPool should then lease that negotiated address to the WAN interface of a downstream client instead of a private 192.168.1.x address.

The physical ETHWAN and LAN1 ports do not own the IP address.
ppp0 remains the PPP endpoint, while the downstream client interface receives the DHCP lease.

My syslog shows successful IPCP and an update of OID 94144 (IP.Interface.IPv4Address), but no apply of OID 124024 (DHCPv4.Server.Pool) and no DHCP pool callback.

Could you please confirm specifically with R&D whether PPP.Interface.1.IPCP.PassthroughEnable and PassthroughDHCPPool are supported?

Thank you.

Maverick87

Hi @Zyxel_Melen,
do you have any news about this?

Thank you