Jump to content

This is the support site for Andrews & Arnold Ltd, a UK Internet provider. Information on these pages is generally for our customers but may be useful to others, enjoy!

VMG1312-B10A: Bugs: Difference between revisions

← Older edit
Content deleted Content added
Reedy (talk | contribs)
editor
706 edits
m clean up, typos fixed: with it's → with its, ie → i.e. (2), eg → e.g. (2)
AA-Andrew (talk | contribs)
autoreview, Bureaucrats, editor, Interface administrators, reviewer, Administrators
12,616 edits
mNo edit summary
 
(13 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{TOC limit|4}}
{{TOC limit|4}}
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: Line 15:
The main problems are:
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)
*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.
*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.
Line 38: Line 38:
====Resolution====
====Resolution====
Not going to be supported. (sorry)
Not going to be supported. (sorry)


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==
==IPv6 RA on LAN==
Line 74: Line 77:
== PPPoE Session-ID caching bug (In Bridge mode) ==
== PPPoE Session-ID caching bug (In Bridge mode) ==
====Issue Description====
====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.
We now have what looks to be the same fault on the ZyXELs - both on ADSL and VDSL.
Line 138: Line 141:
==HTTP & HTTPS Interception/spoofing (when router offline)==
==HTTP & HTTPS Interception/spoofing (when router offline)==
====Issue Description====
====Issue Description====
If the router looses 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.
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
Also discussed here: http://askubuntu.com/questions/577633/suspicious-ssl-certificate
Line 165: Line 168:
None yet.
None yet.


==Low PADI retry time==
==Long PADI retry time==
====Issue Description====
====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====
====Date Reported====
2015-06-24
2015-06-24
Line 221: Line 225:
#Setting IPv6 addressing to be statically configured helps work around this problem:
#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)
##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.
##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
#Instead of the above, try disabling QoS
Line 336: Line 340:
====Issue Description====
====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====
====Date Reported====
Line 344: Line 348:
====Resolution====
====Resolution====
Disabling default classes, and enabling QoS on packet length seems an all-round good solution
Disabling default classes, and enabling QoS on packet length seems an all-round good solution
See: [[ZyXEL VMG1312-QoS]]
See: [[VMG1312-B10A: QoS]]




Line 361: Line 365:




[[Category:ZyXEL VMG1312|Bugs]]
[[Category:ZyXEL VMG1312-B10A|Bugs]]
Retrieved from "http://support.aa.net.uk/VMG1312-B10A:_Bugs"