VMG1312-B10A: Bugs: Difference between revisions

(20 intermediate revisions by 5 users not shown)

Line 1:

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

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

Line 15:

The main problems are:

*MTU 1500 is not supported on some setups (Internet access will still work fine, but we'd like 1500) - (ZyXEL ~~say~~ ~~they~~ ~~should~~ ~~be able~~ to ~~support~~ this ~~soon~~)

*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

*Sometimes slowness browsing the Web interface and static routes don't work via the web interface (adding via CLI works)

----

Line 35:

*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)

None yet.

There is a [http://forums.thinkbroadband.com/aaisp/4591711-zyxel-vmg-1312-b10a-mtu-1508-fix-now-available.html 3rdparty build of firmware which adds support for 1508 byte MTU] although AAISP are unlikely to support it.

==IPv6 RA on LAN==

Line 66:

Line 69:

== DNS Spoofing when PPP is Down ==

====Issue Description====

When PPP is down (ie no internet connection) the router will answer DNS queries and answer with ~~it's~~ 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.

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====

Line 74:

Line 77:

== 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 "~~blacklist~~" some UDP packets after a PPP restart. Typically this affects VPN tunnels. The short term fix is to ~~unplugged~~ and ~~plugged~~ back in!

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.

Line 109:

Line 112:

*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====

Line 137:

Line 141:

==HTTP & HTTPS Interception/spoofing (when router offline)==

====Issue Description====

If the router ~~looses~~ its internet connection (eg 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.

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

Line 164:

Line 168:

None yet.

==~~Low~~ PADI retry time==

==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 of trying every 100 ~~miliseconds~~ 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 ~~secnds~~.

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

Line 199:

Line 204:

==Static Routes==

====Issue Description====

Static routes seem to be very temperamental, and don't work most of the time.

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

Line 207:

Line 212:

====Resolution====

~~For~~ ~~the~~ ~~time~~ ~~being~~ ~~and~~ ~~here~~ ~~possible,~~ ~~we'd~~ ~~suggest~~ ~~using~~ the ZyXEL as a bridge and perform PPPoE on your internal router/firewall device.

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

==Intermittent loss of IPv6==

Line 220:

Line 225:

#Setting IPv6 addressing to be statically configured helps work around this problem:

##Router admin > Broadband > AAISP-VDSL (or AAISP-ADSL if you are on ADSL)

##change the IPv6 Address from Automatic to Static, paste in the router's WAN IPv6 address (and 64 in "prefix length").

##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".

##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.

#Instead of the above, try disabling QoS

Line 286:

Line 291:

==Dropping PPP for 15-20 mins RESOLVED==

====Issue Description====

We are seeing some lines, when in router mode (ie 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.

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.

Line 305:

Line 310:

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. eg, 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.

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

Line 335:

Line 340:

====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 [[~~ZyXEL_VMG1312~~-QoS]].

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====

Line 343:

Line 348:

====Resolution====

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

See: [[~~ZyXEL~~ VMG1312-QoS]]

See: [[VMG1312-B10A: QoS]]

Line 360:

Line 365:

[[Category:~~ZyXEL_VMG1312~~|Bugs]]

[[Category:ZyXEL VMG1312-B10A|Bugs]]