So, the obvious question, is why does the boot loader does not immediately turn off the switch?
Another thing: How come that the BP-R is sold explicitly as a router then? (http://www.bananapi.com/index.php/component/content/article?layout=edit&id=59)
Solutions & Remedies, that would solve the issue:
1.) As you mentioned using an additional USB2 Ethernet dongle would solve the issue. (I've considered this, but before I go there, I do need to find my USB ethernet dongle, it's somewhere in my home office, sigh) But I've also considered it, because using the switch method to partion WAN/LAN VLANs, both the LAN and WAN share the 1gbit/s link, which is not an issue yet for me (my cable uses up to 275mbit/s, taken twice, that fits comfortably into the 1gbit/s link.)
2.) Put an additional switch between any ethernet devices and the BP-R => the "reproducability" of the issue stems that power cycling the BP-R triggers via media detection an immediate (and faster than the boot of the BP-R) DHCP request from my laptop. Removing the ability of the devices to detect reliably when the vulnerable 30 seconds are would make it much less of an issue.
3.) Activate a MAC filter on the cable modem. Don't think that's possible in my case, but I have to investigate it.
But back to situation, if the BP-R is flawed as a router design, what ARM based router-style solution is there that can run full Debian?
