VMG1312-B10A: Bugs

This page lists the problems we have found and raised regarding the ZyXEL VMG1312-B10A.

Openreach MCT Conformance Testing

ZyXEL have confirmed that the VMG1312-B10A was re-tested by BT just before Christmas 2015 and passed (note the firmware version is not that being used by AAISP).

Modem Firmware version: - V1.00(AAJZ.6)C1_20150911 
Modem HW Version/ Modem Model Number:- VMG1312-B10A
Modem Conformance Test Outcome:- Pass with condition around OAM3(BTW can connect this device to BT Openreach Network while OAM3 will not work)

Problem List

TL;DR (Brief overview of the problems listed below)

The main problems are:

• MTU 1500 is not supported on some setups (Internet access will still work fine, but we'd like 1500) - (ZyXEL will not provide firmware to resolve this)
• VPNs may not reconnect if PPP drops - until you unplug and replug the LAN-side ethernet cable! We saw this same thing last year with Huawei HG612, which use the same chipset. (ZyXEL HQ are investigating having seen this demonstrated in our offices)
• Many of these issues are being held up as ZyXEL's developers are working on getting the router through BT's 'conformance testing' (SIN 498). Some of the bugs below are actually requirements in BT's testing, so we expect them to be fixed as part of this.
• Sometimes slowness browsing the Web interface and static routes don't work via the web interface (adding via CLI works)

---

Bridging 1508 bytes ethernet

Issue Description

Bridging does work, but we'd very much like the router to support baby jumbo frames bridging to VDSL and ADSL, to support *at least* 1508 bytes to allow RFC4638 PPPoE to a connected device.

Date Reported

2015-02-19

Updates

• 2015-02-19 ZyXEL development team aware, and are looking in to whether they can support this feature.
• 2015-03-28 Still ZyXEL HQ are still evaluating the effort to make this change.
• 2015-04-14 ZyXEL are working on supporting larger Ethernet frame sizes as part of the 'BT Lab modem conformity tests' (SIN 498). No ETA though.
• 2015-06-02 This has been chased with ZyXEL, we expect some form of update in the next couple of days
• 2015-06-03 Software Patch 6 is nearing release but we don't have details of which open issues are solved in this.
• 2015-06-09 We are chasing for further updates
• 2015-06-10 ZyXEL R&D resource is tied up and focus is on getting BT testing completed/passed, this feature is required to pass BT testing anyway, so we need to wait for the testing to complete and pass and then we should expect new software
• 2015-06-25 ZyXEL UK have been reminded again, and in turn they will be chasing up ZyXEL HQ. We're still waiting for the router to pass BT conformance testing
• 2016-10-24 Sadly (even though the hardware can support it) ZyXEL have told us that they will not be adding support for baby jumbo frames.

Resolution

Not going to be supported. (sorry)

There is a 3rdparty build of firmware which adds support for 1508 byte MTU although AAISP are unlikely to support it.

IPv6 RA on LAN

Issue Description

We are seeing a slight issue with IPv6 RA on the LAN. We are getting a prefix from the PPP link on VDSL. When PPP comes up, several seconds later the router does a DHCPv6 on the WAN, and then does an RA on the LAN, which works. We are puzzled by the noticeable delay in DHCPv6 PD which delays IPv6 connectivity. If PPP drops for any reason it appears to withdraw the RA on the LAN immediately, which is fine. However, when PPP reconnects it does not re-send the DHCPv6 on the WAN. This may be deliberate, and in our case it is probably OK, but it is something of an assumption that the previous DHPCv6 remains valid on the PPP after a reconnect. I'd suggest a new WAN RA/DHCPv6 immediately on every reconnect. Also, it seems not to send an RA on the LAN again for some minutes. This means there is a significant gap in IPv6 availability if there is a PPP drop from any reason.

Date Reported

2015-02-19

Updates

• 2015-02-19 In hand with ZyXEL.
• 2016-03-11 Still with ZyXEL and has not been fixed in the later software versions. This has been chased.

Resolution

None yet.

MLD snooping

Issue Description

There is no way to enable MLD snooping on the LAN interface group without also enabling the router's Router Advertisement feature. This contrasts to IPv4, where I can disable the router's DHCP server but still enable IGMP snooping.

Date Reported

2015-03-06

Updates

None yet.

Resolution

None yet.

DNS Spoofing when PPP is Down

Issue Description

When PPP is down (i.e. no internet connection) the router will answer DNS queries and answer with its own IP. This means that the user will be taken to the ZyXELs own web interface when trying to access a website when the internet connection is down, this applies for http and https traffic. This is not a configurable option.

Updates

• 2015-11-12 ZyXEl HQ have confirmed that a solution will be included in software release 8, AAJZ8C0, 2016/1/B (i.e. early Jan).

PPPoE Session-ID caching bug (In Bridge mode)

Issue Description

Last year we had an problem with Huawei FTTC modems, the standard ones that Openreach supply The bug appears to be that the modem manages to "block" some UDP packets after a PPP restart. Typically this affects VPN tunnels. The short term fix is to unplug and plug back in!

We now have what looks to be the same fault on the ZyXELs - both on ADSL and VDSL.

When a PPPoE session finishes and a new one starts, ethernet frames containing IP packets with the same source and destination IP and port combination that were used in the previous session are received with the PPPoE Session-ID from the earlier session.

This affects long running sessions using protocols which use the same source port for all communications. This includes IPsec and (in some circumstances) SIP.

Our understanding of this, having talked to Huawei last year to get a very similar bug fixed is that the problem is with the packet accelerator feature in the Broadcom chipset. It is caching frame headers including the PPPoE Session-ID, but not checking if the Session-ID is the same when searching for the entry in the cache for subsequent packets. Unplugging the ethernet cable from the VMG1312 momentarily resolves the problem - that action must trigger a cache flush in the Broadcom chipset.

Possible fixes would be to either not store the Session-ID in the packet accelerator cache at all, or to check the Session-ID in addition to the IP and ports when searching the cache. A workaround would be to disable the packet accelerator.

(Side note for other ISPs looking at this: This does not affect lines that have dynamic WAN addresses, which none of our service do.)

Date Reported

2015-05-06

Updates

• 2015-05-06 - Escalated with ZyXEL/Broadcom
• 2015-05-15 - ZyXEL staff came to AAISP offices and we demonstrated and discussed the problem
• 2015-06-02 - Still in hand with ZyXEL HQ reproducing this in their lab
• 2016-10-01 - ZyXEL still unable to reproduce this, even though we have had customers recently seeing the issue with their VPN sessions

Resolution

None yet.

PPP Login passwords can't be 9 characters long

Issue Description

The ZyXELs don't like being sent a configuration file that has the PPP password length of 9 characters.

Date Reported

2015-05-21

Updates

• 2015-05-26 ZyXEL HQ investigating
• 2015-05-27 ZyXEL confirm that this is a bug. We expect a later firmware to fix this.

Resolution

For the time being we'll use line passwords that are longer than 9 characters.

Crash/Quit when resizing SSH window

Issue Description

The router supports access to its CLI via SSH. There is a bug when resizing the SSH terminal window in that the SSH session will disconnect. In one case at least the router has crashed. Sounds like SIGWINCH isn't being handled sensibly.

Date Reported

2015-05-29

Updates

• 2015-11-12 ZyXEL say that this one "scheduled" to be fixed. No ETA though.

Resolution

None yet.

HTTP & HTTPS Interception/spoofing (when router offline)

Issue Description

If the router loses its internet connection (e.g. drops sync, drops ppp) then it will intercept web page requests and will forward them to itself. This is meant to be 'helpful' in that the router will then have a page telling the user that internet is down etc. However, as it also intercepts https traffic this will cause certificate warnings in the browser which will alarm and the user and is much less useful.

Also discussed here: http://askubuntu.com/questions/577633/suspicious-ssl-certificate

For example: If you have https://facebook.com open, and the DSL drops for some reason, your browser will try to access https://facebook.com, the ZyXEL will intercept that traffic but will not be using the SSL certificate that the browser is expecting and the browser will therefore display a certificate warning message.

Date Reported

2015-06-03

Updates

• 2015-06-03 Reported to ZyXEL
• 2015-06-03 ZyXEL confirm that this is by design
• 2015-06-13 We explain further the issues with intercepting https traffic and certificate warnings. This has been passed on to ZyXEL. We'd prefer this to be a configurable option which we can disable.

Resolution

None yet.

WebUI on iPad fails to load with error

Issue Description

When loading the web interface on an iPad the error: "depend on simpleModal plugin" is shown and the web UI cannot be used.

Date Reported

2015-06-23

Updates

• 2015-11-16 ZyXEL unable to reproduce

Resolution

None yet.

Long PADI retry time

Issue Description

When PPP or sync drops, the router will need to reconnect. Once in sync, the router will send a PADI packet to start the process of logging back in. It seems the router sends a PADI every 100 seconds or so. This causes unnecessary delay in reconnecting. Our FireBrick product, for example, will start off trying every 100 milliseconds before it starts backing off to every 2 seconds and then a maximum of every 10 seconds. We've asked ZyXEL for more information on the PADI retry and if it can be made to try more often than every 100 seconds.

Date Reported

2015-06-24

Updates

None yet.

Resolution

None yet.

Web UI Hangs (Broken HTTP/1.1)

Issue Description

Also see 'Web UI slow over WiFi (DoS Protection)' on this page.

The Web UI hangs.

A customer has found that the web pages responses seem to violate the HTTP/1.1 spec in that they use Connection: keep-alive, but do not include a Content-Length header or use chunked encoding. This then leaves the client hanging around until it gives up and closes the connection some time later. The end result of this is a VERY slow to load web interface (680s from the first request to the final resources loading). This issue was seen with both IE11 and Firefox 32.0.1 on Windows 8.1, connected over wireless to an A&A supplied VMG1312 running V1.00(AAJZ.5) C0.

Workaround

1. Using a wired connection rather that Wifi helps.
2. Disabling QoS helps

Date Reported

2015-07-02

Updates

• 2015-07-06 Report sent to ZyXEL with example HTTP header, PCAP and config file

Resolution

None yet.

Static Routes

Issue Description

Static routes seem to be very temperamental, and don't work most of the time when adding via the Web UI

Date Reported

2015-07-02

Updates

• 2015-07-09 Escalated to ZyXEL
• 2015-11-12 - ZyXEL UK Had been able to replicate this issue in the UK lab, but ZyXEL HQ were not able to replicate it. ZyXEL UK Will re-create this scenario in the lab and provide remote access to HQ for further troubleshooting.

Resolution

Static routes can be added via the CLI. Alternatively you can use the ZyXEL as a bridge and perform PPPoE on your internal router/firewall device.

Intermittent loss of IPv6

Issue Description

Overview: We have had a number of customers report that after a while (many days) of working fine, IPv6 stops working.

Rebooting the router, or restoring a saved config does not solve the problem, it starts up with the same state. One thing which seems to fix it (until is stops again in a few days time) is sending a the config file from AAISP via the Control Pages (this sends a config via the TR069 protocol). This may point the fault being in the config file.

In the broken state, the Status page on the router will show a blank IPv6 address under LAN Information. Logs from the AAISP side show the router regularly asking for and being sent IPv6 details, but it fails to apply these to its LAN interface. A clue, is that running 'ps' from the CLI, dhcp6c will not be running in the broken state.

Workaround

1. Setting IPv6 addressing to be statically configured helps work around this problem:
   1. Router admin > Broadband > AAISP-VDSL (or AAISP-ADSL if you are on ADSL)
   2. change the IPv6 Address from Automatic to Static, paste in the router's WAN IPv6 address (2001:8b0:1111:1111:0:ffff:[your IPv4 WAN in HEX]) and 64 in "prefix length".
   3. IPv6 will still be lost if PPP reconnects, it should be ok after a reboot of the router though. This is related to the 'IPv6 RA on LAN' issue described above on this page.
2. Instead of the above, try disabling QoS

Date Reported

2015-07-06

Updates

• 2015-07-06 Initial reports from customers about loss of IPv6 connectivity
• 2015-07-10 Received a detailed report from a customer with further information
• 2015-07-13 We suspect that this may be a configuration issue, we are asking affected customers to contact us and share their config files so we can analyse them
• 2015-07-13 It may only be affecting customers who make further changes to the configuration after our own config file has been sent. Yet to be confirmed though (a counter example: one customer is having the problem with an unmodified AAISP config).
• 2016-03-11 This is in hand with ZyXEL.

Resolution

None yet.

Web UI - Times given under VDSL Counters are usually truncated

Issue Description

On the Web UI, System Monitor > xDSL Statistics. The times given under VDSL Counters are usually wrong - e.g. they get truncated: "Since Link Time" is usually missing the leading hour and/or day (e.g. it might say "21 min 33 sec" when it's actually 3 hours and 21 minutes)

Also, "Total time" (at the bottom) doesn't seem to fully or partially match either the system uptime, link uptime or IPv4/v6 uptime. We're not sure what that figure is representing.

Date Reported

2015-09-15

Updates

None yet.

Workaround

This is mostly a cosmetic bug.

Resolution

None yet.

Web UI - Input textbox for Static LAN IPv6 address too short

Issue Description

Suffering from IPv6 problems, even with a standard AAISP config file, the suggested workaround is to use a static IPv6 address assignment on the LAN. Visit 'Network Setting' > 'Home Networking', scroll down to 'LAN IPv6 Address Setup', select 'Static'. Now simply add IPv6_address/netmask.

Except the input textbox isn't quite long enough, the limit is 39 characters - one could enter '1234:5678:9abc:def0:1234:5678:9abc:def0' but that's it, there's no room for the netmask (e.g. /64). So one is restricted to using a subset of IPv6 addresses which are shorter.

Below the 'LAN IPv6 Address Setup' is 'ULA IPv6 Address Setup' - this has separate textboxes for the IPv6 Address and Prefix Length. The same length limit applies to the IPv6 Address textbox, but it's OK because one doesn't need to add the netmask.

Date Reported

2016-10-01

Updates

None yet.

Workaround

Use a shorter static IPv6 address.

Resolution

None yet.

Local DNS - can't have dashes in hostnames

Issue Description

When adding hostname/address pairs in the local DNS ("Network Setting" > "DNS") hostnames can't have dashes/hyphens in them. Error displayed when trying to apply the details is "Host Name is invalid".

Date Reported

2016-10-22

Updates

None yet.

Workaround

Enter the hostname(s) without dashes. Save the router's configuration to a local file ("Maintenance" > "Configuration" > "Backup"). Edit that local file to put the dashes into the hostname(s). Restore the router's configuration from that modified file ("Maintenance" > "Configuration", then "Restore Configuration" section).

Resolution

None yet.

Resolved Problems

Below are details of problems that have been fixed.

Dropping PPP for 15-20 mins RESOLVED

Issue Description

We are seeing some lines, when in router mode (i.e. plugged in to the phone line and used as the router) drop PPP and do not re-establish PPP for 15–20 minutes. This is very odd. AAISP are investigating this as a priority. A work around is to use a separate DSL modem and configure the ZyXEL as a PPPoE router. This is not ideal, do talk to staff about this.

• Setting the VMG to bridge mode and using a separate PPPoE router works fine.
• Setting the VMG to PPPoE mode and using a separate VDSL modem works fine.

Date Reported

2015-06-23

Updates

• 2015-06-22 Reported to ZyXEL, staff still investigating and trying various config changes in order to test where the problem is
• 2015-06-24 AAISP still trying config changes to find a resolve to this. Further updates tomorrow
• 2015-06-24 It looks related to routers having Remote Management allowed from the WAN (Not our default setting), we are trying to capture the traffic that causes the line to drop
• 2015-06-26 Traffic captures and enabling and disabling various services shows that this could be caused by an SSH attack of some sort. Progress is still being made
• 2015-06-26 As this bug can be worked around by disabling Remote Management (especially SSH), then this is likely to be treated as low priority by ZyXEL

Resolution

Disable Remote Management access to the router (http/https/ssh/telnet). This is the default as set on AAISP side, but can be overridden.

Web UI slow over WiFi (DoS Protection) RESOLVED

Issue Description

Also see 'Web UI Hangs (Broken HTTP/1.1)' on this page.

When using the router's own wifi, viewing the web pages (http) is very slow. e.g., 20 seconds to load the Wireless settings page. Switching to Wired the pages load as expected. Whilst the web UI is slow, telnet CLI and normal internet access is fine.

Date Reported

2015-06-16

Updates

2015-06-16 Preliminary investigations underway with AAISP staff looking in to it 2015-06-16 Disabling the DOS protection fixes this - it seems the router thinks it's being DOSd. We're still investigating this, for now we'll disable the DOS prevention setting in our configs

Resolution

Disable DoS protection as a work-around. Except one customer is still seeing this problem having disabled DoS Protection - it seems bad when the router has recently started, after several hours uptime the problem appears to go away.
Another reported fix is to add the router's LAN subnet to the trusted address list by entering rmtmgmt trust --add 192.168.1.1 --prefix 24 into the SSH command line interface for the router, which bypasses the DoS protection for the LAN subnet.

Port 1 - Ethernet settings wrong RESOLVED

Issue Description

It seems to be set to 100M fixed with no auto-negotiation. This results in a duplex mismatch when used with any auto-config port and results is slow speed and poor performance.

Date Reported

2015-02-16

Updates

• 2015-02-18 Inhand with ZyXEL.
• 2015-03-18 New software hopped for April
• 2015-04-14 New software available which fixes this issue, V1.00(AAJZ.5)C0

Resolution

Fixed in software release 5: V1.00(AAJZ.5)b1| 03/13/2015 has the following release note:

[BUG FIX]1.[ITS:#141200518][TSF] VMG1312-B10A LAN1 interface speed issue.

• File:VMG1312-B10A-Firmware-V1.00(AAJZ.5)C0.zip

QoS Issues RESOLVED

Issue Description

The QoS and traffic limiting features have the potential to be quite useful. However, the default QoS settings have problems if there is a large rsync (over ssh) upload in progress in that DNS queries time out. We have some QoS notes on VMG1312-B10A: QoS.

Date Reported

2015-05-08

Updates

2015-05-15 A suitable configuration has been found

Resolution

Disabling default classes, and enabling QoS on packet length seems an all-round good solution See: VMG1312-B10A: QoS

---

Template to use for new problems

Issue Title

Issue Description

Description of Issue.

Date Reported

2015-00-00

Updates

None yet.

Resolution

None yet.