VMG1312-B10A: Bugs: Difference between revisions

← Older edit

VMG1312-B10A: Bugs (view source)

Revision as of 13:41, 16 June 2020

212 bytes added , 16 June 2020

m

no edit summary

AA-Andrew

autoreview, Bureaucrats, editor, Interface administrators, reviewer, Administrators

12,270

edits

Revision as of 16:54, 3 July 2018 (view source) Adsb (talk \| contribs) m (Link to the right QoS page) ← Older edit		Latest revision as of 13:41, 16 June 2020 (view source) AA-Andrew (talk \| contribs) mNo edit summary
(3 intermediate revisions by 3 users not shown)
====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== == 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~~block" some UDP packets after a PPP restart. Typically this affects VPN tunnels. The short term fix is to ~~unplugged~~unplug and ~~plugged~~plug back in! We now have what looks to be the same fault on the ZyXELs - both on ADSL and VDSL. ==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~~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==== ====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~~ QoS]]. ====Date Reported==== ====Resolution==== Disabling default classes, and enabling QoS on packet length seems an all-round good solution See: [[VMG1312-B10A:~~_QoS~~ QoS]]