VMG1312-B10A: Bugs: Difference between revisions

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 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 [[VMG1312-B10A:~~_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 348:

====Resolution====

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

See: [[VMG1312-B10A:~~_QoS~~]]

See: [[VMG1312-B10A: QoS]]