Deeko,
Stock openwrt and luci does exactly what you mention. :) . you are 100% correct that what
you experienced is bad ux.
All,
not sure what sudomesh changes have been made, seems like they break standard
functionality. This is why I recommend using the qmp.cat firmware and not rolling ones
own. You just waste lots of effort and relearn many others mistakes. Which is useful in
its own way I suppose.
This is a major regression , when the functionality falls below what a stock openwrt +
luci experience provides.
Deekoo <deekoo_3291a(a)deekoo.net> wrote:
The NanoBridge doesn't show up on the lan at all for me - if I turn it
on,
usually the switch will have no link light and the feedhorn will have a
link
light; unplugging and replugging cables will sometimes switch this.
Other
lights appear to go on correctly (power, reds and oranges if I reset
it).
The NanoBridge and NanoStation spec sheets says they expect 24v 0.5A
PoE,
while the injectors I've got are 15v 0.8a, which is what the
PicoStation
wants. (The wiring is the same either way, pairs 4,5+ and 7,8 return.)
The NanoStation is fine on a 15v 0.8A injector, though.
Compiling for ar71xx gets me a binary that runs on the NanoStation.
Woot!
Haven't yet been able to get the NanoStation radio into master mode,
though.
IIRC someone was working on open-source drivers for it under FreeBSD -
what's
the status of that?
It looks like part of my patch is in the official firmware, but not all
of
it - the tweaks to telnetd and ntp hotplug aren't in.
HTTP interface feedback: (running a bastard hybrid of my
firmware and the github version, as of Dec 6):
The default hostname is picostation-juul, regardless of actual hardware
platform.
On initial HTTP connection to a passwordless router, I get both a
'No password set!' message instructing me to go to password
configuration
and an 'Authorization Required' dialog.
The intuitive behaviour for me was to enter desired username and
password
in the big fat boxes, when apparently the CORRECT thing was
to click 'Go to password configuration': which redirects to the
identical-appearing page
http://10.0.0.237/cgi-bin/luci/admin/system/admin
At that point, I'm supposed to ignore 'Go to password configuration'
and
instead log in, at which point I'll have both the auth config screen
and
a message admonishing me to go to password configuration.
When you scroll down to the bottom and click 'Save and apply', you get
a very small notification that the password has been changed and a
large
'Applying changes' animation that was still running a couple hours
later.
ps showed no obvious sign of any processes related to the 'Applying
changes'
message, though I might have missed something.
Typing your password twice (this time, on an actual picostation) and
then
pressing enter deletes your dropbear settings. Bad from a usability
perspective. The deletion also appears to be persistent, while the big
save buttons at the bottom would suggest that dropbear changes wouldn't
take effect until you save & apply.
Recommendations:
1) Take the user straight to passphrase configuration if they try to
admin
a router without a passphrase set.
2) Passphrase configuration should be just passphrase configuration;
dropbear
should have its own page.
3) Status reports should be prominent and not interleaved with the
rest of the design.
4) Links should be underlined and coloured; bold alone is too subtle.
5) Call it 'passphrase' rather than 'password', so we get more correct
horse
battery staples and fewer swordfish.
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh and guifi.us
--
Charles Wyble charles(a)thefnf.org
818 280 7059
CTO / co founder