It was
Ixel in this old thread who gave me this most excellent tip in the first place.
Could I power each of my modems on one? That unfortunately would mean 4 * £25 approx.
It is all a bit mad though as the whole lot of modems are already powered by a UPS anyway, so we would have one UPS feeding another. The traditional mains synthesising UPS powers a gigabit switch and my Firebrick router too as well as the four modems, or rather that would be the four DC UPS bricks. Madness.
So I would definitely need some help splitting that lot up. The modems are supposed to be on a heavily anti-interference filtered mains supply and the switch and the Firebrick router of course don’t need any such thing. Having the whole lot run off one UPS makes sense because if any part of this critical chain fails then I lose internet access, so we need to keep it all running for the same amount of time. Splitting it up means that would not be the case, one part would have a shorter run time.
I have already broken this all-or-nothing rule anyway though in that the WAPs which are critical have a different run-down time now, being in different UPSs, their own little fat li-ion 12v dc bricks. Since I work on an iPad a lot, the ideal sequence is (bizarrely) that the WAPs run down first, before the core network infrastructure - the router plus switch - or the internet access kit, the modems. This is true because that way the iPad will switch to 4G when it sees the loss of 802.11. The worst thing is seeing an isolated WLAN being advertised, one that has no internet access but good signal strength. Perhaps Apple needs to test whether or not a candidate WLAN actually has internet access before it chooses it in preference to another interface such as 4G.
Perhaps an enhancement to the 802.11 family specs would be to include an indication as to whether or not a WLAN with BSS whatever actually has internet access it is isolated in the advertisement of its availability so that a machine is scanning for available networks it can skip those that do not offer working internet access, rather than lamely picking the loudest signal strength and fastest road to literally nowhere, if it’s the internet that you might need. This would be a number of hint flags in some header which originates in something produced in a state machine that exploits higher layer protocols (L3) and calls down to a lower layer to offer information to that lower layer ‘hint: has potential internet access capability; hint: internet access is currently up/down’, which can either take it or leave it, depending on its support for the feature. More information could be published: state=‘internet access coming up’; eta=n seconds; next status report time is=m seconds, m being the suggested delta time when the status should next be polled. A push event-driven interface would be a nice addition where an application is interested in a particular WLAN and wants to know if the internet access that it indirectly provides is coming up or not and how far it has got, in order to give dynamic status info and attractive feedback to the user. The application could then send a low-level event solicitation message on the particular WLAN in question ‘send me internet access status info and state change events’ this might be preferable to polling and it has far more general capabilities.
