[PLUG] Netgear Closes Support Request Without Response

[Keith Lofstrom]

On Sat, Nov 26, 2005 at 01:11:27PM -0800, Rich Shepard wrote:
>   Back on November 5 I entered an on-line request for technical
> support for my Netgear VFS318's lack of intranet transfer speed.
...
> This is the second VFS318 in succession that has failed.
> Anyone have suggestions for an affordable, quality solution?

PHILOSOPHY:

Cheap, fast, good, pick, er, one?

The metaproblem here is that you attempted to get a zillion features
in one box and you did not succeed.  Had the Netgear box succeeded
for you, you would have still been faced with future re-configuration
problems, the inability to adapt to new protocols, and probably a
windows-driven upgrade path.  So sooner or later, the VFS family would
break your heart.  It's actually a good thing that you got burned
right away, before you invested too much of your own spirit in it.

When a low-budget, culturally-different company like Netgear trolls
for sales bullet points by packing functionality into a big EPROM,
there is an awfully good chance that some of that functionality
will play badly with other functionality, or will be merely hard to
explain to a small businessman in Oregon.   Such oversized code wads
are often patched at ship time with a Windoze CDROM that does a
firmware or runtime patch on the software or the config.  Or the
firmware stays broken, with successful configuration possible only
using a Windows GUI. 

Or complete success is impossible under some circumstances.  Your
configuration was probably never considered or tested in Bangalore
or Shanghai or Taipai where your VFS was designed.  With two units
failing the same way, chances are your packets and connections and
setup do not match anything they ever tested, and some exception
condition is failing the fast path through hardware/firmware and is
falling down into some slow error-handling path, perhaps getting 
logged very slowly to the EPROM.  With closed source hardware and
firmware, you will never know, and without extensive testing, you
will not even be able to characterize the failure.  Call the VP of
anything at Netgear, and nobody will be able to tell you what is
going on or what fixes it - they haven't done enough engineering and
testing.  And enough people seem to like the VFS as-is that Netgear
has no need to make you happy.  I hope you can get a refund, but
chances are you are completely expendable to them.

Even if you paid big bux to a high-reputation outfit like Cisco
for the same functions, there will be some problems.  And you will
still end up speaking to some phone pool in Mumbai.  And you probably
wouldn't get an immediate fix, though I would expect Cisco to initiate
remediating engineering projects based on fewer complaints - at those
prices and with those expectations they must be more anticipatory. 
That still doesn't do much good for your problem right now.

As a hardware designer, it pains me to say this, but firmware and
hardware solutions are usually inferior to open-source software
solutions.  Everyone makes mistakes - software mistakes can usually
be fixed in the field.  Try to find an open software solution; 
either obsolete laptop based (nice low-power X86 Linux platforms)
or firmware solutions that support Linux in some way (WRT54G's or
Soekris for example).

SOLUTION:

At the risk of wasting space and burning electricity on multiple
boxes when theoretically you could get by with only one, you probably
want to break the function up.  A cheap internal multiport switch. 
A cheap external switch if needed.  An old laptop running Linux for
your firewall.  Reduced expectations about stateful routing inside
your secure zone.  That is my setup, and while configuring the Linux
laptop is a small annoyance, it does mean I am able to upgrade and
add new features, and work in a familiar environment.

Sorry I can't provide a more pleasing answer.

Keith

-- 
Keith Lofstrom          keithl at keithl.com         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs