Yep, OK, when things work there are indeed three API commands as you suggest. The first, type=wl command returns a stack of records of the form [0,”wl”,100,1517618908], many more than the number of log messages returned by the ‘no type’ command. The second, type=fl command result is empty (just “[]”), and the third ‘no type’ command returns the log entries as I posted previously.
When things don’t work, the problem occurs with the first, type=wl command and never proceeds beyond that. If I use the API directly, the type=wl command hangs, as described previously, the type=fl command just returns the empty set “[]”, and the ‘no type’ command returns the log entries.
The problem certainly seems to be with the controller and/or its software, noting that the only thing that results in the ‘hang’ or ‘network disconnect’ is a jl command that includes the “type=wl” parameter.
The signal strength is fine as measured by the OS X Wireless Diagnostics tool—remember there are two controllers running off the same extender, and the one that is failing is only a couple of metres away from the extender (the other one is 10-15 metres away). Ping delay times are typically 5-10ms.
Unfortunately it’s not practical to move the controller anywhere else, because that’s where all the control wires come in. Remember, there’s another controller, using exactly the same network path, that is working just fine. But yes, pretty much the only thing left to do is to swap in another controller. But I’ll wait a couple more days and see if the same problem occurs with the other controllers when their logs fill up a little.
Now, in running those API tests above, I noted that there are many, many more “type=wl” entries than there are ‘regular’ log entries returned. In one of my controllers there are just four log entries returned, but 105 “wl” records. In another there are 62 log entries and 189 “wl” records. So just on a hunch, I reduced the Start time on the jl command I sent to the problem controller right down so that the command returned only a couple of log entries and the API “type=wl” command worked! There does not, however, seem to be any way of setting the Start date on the web interface without first initiating the View Log command, and that results in the ‘hang’.
So it seems that the problem is that, on the controller that is causing the problem, there are too many log entries in the default, one week period. This would be entirely consistent with the previous observation that I could not retrieve more than 7 days worth of log entries. The 7 days may well just be coincidental and it’s really the number of log entries that is the limiting factor, although they will pretty much increase, perhaps not exactly linearly, with the number of days. The problem is not the log entries themselves though, because we can retrieve them through the API. The real problem seems to be the number of entries generated by the “type=wl” parameter because, if we reduce the Start time sufficiently, the jl command will work with the “type=wl” parameter.