Computers & Hardware > Networking

ZyXEL latest WAPS?

(1/1)

Weaver:
[If I had any money, then I would be looking at upgrading WAPs to 802.11ac wave 2 at some point. No hurry though. I have posted on this question before, so apol]

I’m wondering about which ZyXEL top-end WAP might be a good spiritual successor replacement for my current ZyXEL NWA3560-N WAPs? Need same sysadmin features, not just network performance.

Perhaps I could add one and keep my current devices too, and let clients just roam between them. But if roaming is much better on newer devices then that would be a reason to upgrade more units. Is that the case - is roaming better now?

My current devices can do superb stuff like listing the current connected devices, can be a RADIUS server, can speak https, generate their own certificates or load ones up, speaks SNMP, can email reports, can show graphs of WLAN tx/rx vs time, most important: can do traffic capture !, can load and save config that is human-readable plain text and so can be edited with s text editor and diff’ed or copied to another device. They can also be put under the control of a controller, which is another identical WAP but it has to be dedicated to the job of controller unfortunately, so that mean buying one extra unit.

So a replacement will have big shoes to fill.

I would be very happy if they kept the best aspects of the current software and kept it so that current customers are comfortable with changes.

Desperately needs a much much faster CPU though, a better compiler, or both, as the current web UI is horribly sluggish and boot time is a joke, at over four minutes.

burakkucat:

--- Quote from: Weaver on February 20, 2019, 07:32:48 AM ---Desperately needs a much much faster CPU though, a better compiler, or both, as the current web UI is horribly sluggish and boot time is a joke, at over four minutes.

--- End quote ---

The sluggish GUI is just a ZyXEL feature across all of their product range, as far as I can tell.  :(

A four minute boot time must be abnormal.  :-\  (My VMG1312-B10A takes between 90 - 120 seconds from a cold boot to device readiness.) If you have a spare device, stashed away in the office store-cupboard, it might be a worthwhile experiment to see how long it takes to become ready, following a cold boot and also a re-boot, when using the default ZyXEL configuration. (I guess I'm querying if it could be a Weaving-shed configuration that is causing the delay.)

Weaver:
I get the feeling somehow that the stupid WAP is interpreting the CLI commands as it boots rather than just setting the entire state in one go. The file in which the backed up configuration is stored looks just like a long list of ascii human-readable CLI commands. It’s insane having to parse and validate each one of these and also have a change of state each time. All the intermediate states are unwanted: the final state is the only one we want to get to, and all the intermediate ones are just (literally) a waste of time because the state-changes/transitions take time.

Evidence for this is that it can complain if there is something wrong with one of these commands and then optionally it can either stop or it can do a transactional rollback. Since there is a rollback capability and it seems like it has been implemented like a proper transactional database with ‘undo’. Making sure that the system can not end up in a half-baked state if a compound / multi-part operation fails halfway through so that all the sub-operations need to be executed or none, this is very good stuff indeed, very high quality design for the CLI. But it’s bound to be very slow. I just don’t know why initialisation should be done like that, like journal replay. I don’t know why it doesn’t just have a description of the values of the state in the file, not a list of operations, and it can just let the entirety of the hardware’s ‘desired state’ get set to become equal to that depicted in the file in one atomic operation. Then let the device execute all the required sequences of operations that are implied, and which need to be started up to get the device to where it should be.

I suppose there is another complication here. There are two cases. The first, case #1, is the boot-time case, when it’s reading this journal-like list of CLI commands instead of a proper state-variables’-values list. The second case case#2 is when the system is up and running. You can change the state of the system by getting it to read one of these files. Now this is where the transactional commit-rollback thing comes in. The way they have done it, the system can survive a situation #2 where there is bad stuff in the file that is read, bad commands. It just uses the commit/rollback thing to protect itself in the case of individual multi-part commands failing and it can optionally roll the entire thing back too, optionally, if a bad command is encountered. This is very good indeed. But I don’t think that it was a good idea to try and conflate the two cases, and use the same code to handle the boot-time situation #1 as it was obvious that painful slowness will be the result and case #2 is really rare. They should have written separate code and handle the two situations completely separately.

Navigation

[0] Message Index