VMG1312-B10A: Bugs: Difference between revisions

(5 intermediate revisions by 3 users not shown)

Line 38:

====Resolution====

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

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 167:

Line 170:

==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 ~~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 seconds.

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

Line 337:

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 345:

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