Digging around I found a thread where customers were wondering what happened to bridge mode and why it had been removed. An obdurate admin informs everyone that D-Link decided it wasn't needed as a feature, so they removed it. The admin is very coarse and ends up locking the thread.
It seems ridiculous that, for a hardware product, a company would decide to remove features in a firmware upgrade. There is a work around, but even if it is a legitimate thing to do, it seems like a terrible product and engineering culture to be this condescending to customers.
Relevant thread: http://forums.dlink.com/index.php?topic=4542.0
End of story: The router ended up going in the trash after other issues, along with two different D-Link models.
It's not the best idea to use consumer grade gear in an office, but then I replaced it (as a temporary fix) with an even older Linksys WRT54GL flashed with DDWRT with no problems.
NOT that you should have to, by any means whatsoever.
The scheduler web interface would only accept a range in the same 24 hr day, if you tried to set it to e.g. start (WiFi off) at 11 pm and stop (WiFi on) at 5 am, it refused with an error (paraphrasing) "end time must be after begin time."
It was ONLY a JavaScript issue. You could trivially bypass it using a developer bar, and it worked perfectly. But they never fixed the JavaScript in all the years I owned it (and I doubt it is fixed right now today).
That thing has been working for almost ten years (granted it is not an office environment), once with openwrt and now with tomato, while rebooting its little and adorable self every night at 3am automatically so that I don't have to.
It's an amazing piece of hardware that makes one say "back in the day".
As to stability, I'd describe it has a mixed bag. I owned one for just under five years and had to do fortnightly restarts (which I eventually automated), and we also owned one at work which needed nightly reboots (DD-WRT provided that).
PS - In fairness to the work one, the building was insanely congested. It was one of these buildings which are shared by three dozens small businesses, and each had 1-2 WiFi networks, plus the local homes also. When you spun up a WiFi analyzer it could not find an empty piece of spectrum, and a lot of routes/APs would crash if you left the "find best frequency" option checked (as they would hop continuously and never find anything).
Then again I'm not hiding anything dubious - if I was I'd install a firewall box asap. (And yes I know the "nothing to hide" slippery slope etc argument)
This person does not do online banking, does not have a webcam or mic installed device such as a laptop, and does not have an email account.
The only reason I don't have a firewall box behind my residential router is because I don't have money to buy extra hardware.
Now, in many settings one do need a "LAN" in the sense of a firewalled playground for hopeless consumer devices, such as printers, ip web cameras etc.
Perhaps the biggest reason to have a firewall, is if you're running windows -- as unpatched windows machines live dangerously on the open Internet. And you'll be unpatched from initial install until you've patched up...
AFAIK there's been a while since any major Linux distro shipped with remote (no-action needed, like browsing) vulnerability out of the box.
As for "does not have an email account" -- I generally assume that anyone with half a brain can patch into the upstream DSLAM of my DSL line, so anything between me, and everywhere else is suspect. Which is of course why I protect my IMAP/SMTP with TLS.
[edit: consider people that use a laptop outside of the home -- they'll probably have to use dubious wireless links. It's more convenient to assume that the trust-boundary between you and the internet is at the local ethernet port/wireless card -- than anywhere else. That way you can have one set of "OpSec" that works (or not) wherever you are -- rather than fighting an uphill battle of situation awareness...]
I don't know a ton about networking (probably not too much in fact) but doesn't HTTPS fix most of this? And if your laptop grants access to its mic/webcam to any packet that manages to make it past your router, I think you have a bigger problem.
Its not perfect, but as I'm pretty comfortable with the risk balance. Things like all these android apps containing god knows what make me way more jittery (See google's recent cleanup).
Asus/Netgear/D-Link/etc follow the "If we don't release an 802.11ac router every week, we won't get enough press releases out!" model, and their firmware suffers as a result.
I'm not touching those unless I can wipe the stock firmware and replace it with Tomato or DD-WRT.
Personally I trust VxWorks over some patchwork router of the week by the usual vendors. It's used in many safety critical/medical applications, including the mars rovers.
The downside being that VxWorks has very low resource requirements, so some vendors use them to cut resources. Hence, You'd better be happy with the factory provided configuration because you can't flash them.
Does anyone do meticulous teardowns of routers, much less documenting what silicon is present?
As to inspecting the SoC itself, that would be certainly interesting. Most of them are just ARM SoCs; this might make for an interesting blog post looking at the silicon.
[1] http://wiki.openwrt.org/toh/tp-link/tl-mr3040#photos_v10 [2] http://wiki.openwrt.org/toh/linksys/wrt610n#opening_the_case [3] http://wiki.openwrt.org/toh/netgear/wndr3700#photos
d-link could do well by firing whatever uncaring 9-to-5 programmers they have and hiring him.
part of the problem is that people with this kind of passion and skill are few and far between... is very rare that good people want to work for a company like d-link on something like drivers or router software.
That's a great experiment to discover how long somebody can can stay passionate inside an uncaring corporation.
I give him 2 years to become an uncaring 9-to-5 programmer.
i do think it is pretty hard to stop caring though, what happens generally is that if you start to get that demoralised you will leave and find something else. :)
Also, they come with upnp and other unnecessary daemons disabled which greatly reduces their attack surface.
A funny analogy I've heard is "programmers who don't know the size of their buffers are like drivers who don't know the size of their cars."
From http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10..., PDF page 163:
>The Committee decided that gets was useful and convenient in those special circumstances when the programmer does have adequate control over the input, and as longstanding existing practice, it needed a standard specification.
edit: And that someone may not even be the developer, at the end of the day, the company does not have the systems in place for quality control.
Compiling C as C++ with a C++ compiler is not a bad idea though... many compilers which will deal with both and tend not to care about pure C very much at all. Modern, extremely popular compilers may not even support C89 features yet... not to mention that lots will allow dangerous things like returning nothing from a function with a non void return type without even a compile error.
Many tools can catch the bugs mentioned here though - things like PVS studio, cppcheck, or the built in visual studio or xcode analysers (I would never recommend pc-lint, sorry), and some of these things mentioned are compiler warnings in some cases (sprintf will trigger the endlessly annoying CRT_NO_SECURE_WARNINGS message from the ms compiler for instance).
What is really hard is finding decent firmware engineers. Ones who care, and who can write secure code.
Even harder, finding a management chain that values security and that is willing to pay for it, and its continual upkeep (because security is a process, not a feature that you can complete and move on from).
