Article View: comp.dcom.modems.cable
Article #568Re: New cox cable managed network
From: Arthur Hagen
Date: Wed, 20 Feb 2002 13:32
Date: Wed, 20 Feb 2002 13:32
90 lines
7004 bytes
7004 bytes
"Brian" <bswindle@charter.net> wrote in message news:3C72EA16.5FA77114@charter.net... > In those situations, the owner of the computer would be wise to install > the card himself. I think a lot of them would be the type of people who > wouldn't want anybody from outside in their machine anyway. Ah, but will the user *know*? Let's make a couple of trivial examples: A user has - without knowing it - an ASUS TUSL2/CUSL2 motherboard (a common enough thing), and the free slot is Slot 1. Will the tech be able to identify this motherboard and NOT install the NIC in slot 1 without going into the advanced settings of the BIOS to turn off slot 1 priority? Else he'll cause Big Problems for the user, who probably won't associate the resulting graphics glitches and audio stutters with the NIC install. Another user has an old scanner hooked up through an ISA card (common enough too). His shop installed the scanner for him a long time ago. While the machine works with ACPI IRQ assignments now, that will fail once another card is added. Will the tech be able to identify the IRQ conflicts, and turn off ACPI and set the BIOS to either PnP or manual IRQ assignments if that fails? A third user has Nortel Extranet Access installed, which she uses for periodical dial in to work using VPN. This creates a virtual NIC, whose settings Must Not Be Altered. She also had a NIC in the machine a long time ago, back when it was an office machine, and the settings for this will conflict with the new NIC. Will the cable guy uninstall all network devices to solve the problem, or will he know enough to only remove the unused NIC software and not touch the virtual one? If the cable guy doesn't know about issues like this, he *is* going to screw up. And the customer might not even know that he did because the Cable modem service may work. Then the customer might blame the *other* software/hardware that fails. None of the above scenarios should be particularly rare - they're all part of everyday setups. > There are always going to be exceptions; my point is that they > aren't going to be an everyday issue. So what's the acceptable failure rate? How many customer machines can be screwed up before it's unacceptable? What's the price of all the troubleshooting that goes on AFTER the cable guy has left? I've had to fix two machines so far where the cable company (one was AT&T, the other Cox) installed a NIC and configured the machine for the customer. One lost his ability to dial-up to work, and the other got audio glitches and stuttering frame rates. I'm sure that the technicians in both cases thought they installed everything sucessfully. My rate for looking at a machine is $100/hr plus expenses. And I'd prefer to have *less* work like this. > Our techs will call for assistance before > they get ito a computer that looks like it may have a different setup > procedure or is part of an existing network when they arrive. "Looks like" isn't good enough here. Unless you ARE either trained in or have special knowledge about PC networking and configurations, chances are good that you might not *see* that there's anything different. And chances are that even though the NIC works fine after this, other problems may occur, caused by the customer's machine being raped by an unskilled technician. I say it's much preferable to have a cable guy do the cable, and a PC tech do the PC's. There's no shame in not knowing something. The shame is in not knowing something and STILL doing it. > Servers are > off limits and most of our business customers with servers have network > support people they want working on their machines anyway; they usually take > care of the card installation since they know the existing network and how > it is set up better than anybody. CBN connects most business customers > through a router/firewall, preventing many issues with existing networks and > providing excellent security at the same time, while eliminating the > necessity of the second ethernet card. Must be very different from the residential service then, cause with residential service, Cox doesn't allow for direct TCP/IP communication between two customer machines even if they pay for an extra IP. Using a second NIC is the only way to be able to do this. With @home, the customer got fixed IPs in a situation like this, and could set up static routing between the two (or three) local machines. Even if using DHCP, they were given different subnets so they at least could bounce packets off the router (while slow, at least it worked). With Cox, you lose all TCP/IP communication between local machines unless you add a second NIC. Emailed questions to tech support about this has gone unanswered. Regards, -- *Art
Technical Details
Message-ID:
<rzNc8.896$XT1.64432@news1.east.cox.net>Path:
arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!gestalt.direcpc.com!cyclone2.usenetserver.com!usenetserver.com!newsfeeds-atl1.usenetserver.com!cox.net!news1.east.cox.net.POSTED!53ab2750!not-for-mailReferences:
<I0VX7.10375$B61.4953680@news1.rsm1.occa.home.com> <3C314C9C.DEDF0FCC@reece.net> <82lY7.33203$K36.11443500@news1.rdc1.va.home.com> <3C334AC0.7C6370B@reece.net> <bc5b60f8.0201170659.1fb61766@posting.google.com> <m_V48.3805$zR3.251588@news2.east.cox.net> <bc5b60f8.0201272107.82cbac8@posting.google.com> <dQo68.4657$Xk4.242975@news1.east.cox.net> <ggS68.7796$Xk4.425111@news1.east.cox.net> <y3U68.8160$Xk4.436368@news1.east.cox.net> <3%Z98.7525$zb.402885@news1.east.cox.net> <jQxa8.2975$SJ3.111671@news1.east.cox.net> <ShIa8.4164$SJ3.170583@news1.east.cox.net> <nnPa8.6168$SJ3.212179@news1.east.cox.net> <S4Ra8.6327$SJ3.221438@news1.east.cox.net> <Cagb8.10394$SJ3.374222@news1.east.cox.net> <gXib8.10520$SJ3.387856@news1.east.cox.net> <rLtb8.11334$SJ3.445265@news1.east.cox.net> <3C6E9AC8.41A0EAB4@charter.net> <vm6c8.5941$7Q6.215936@news1.east.cox.net> <3C72EA16.5FA77114@charter.net>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10f392,a7865c87070b0fcc X-Google-Attributes: gid10f392,public X-Google-Thread: 113850,a7865c87070b0fcc X-Google-Attributes: gid113850,public X-Google-Thread: 1136e3,710aa4d82544bdbb X-Google-Attributes: gid1136e3,public X-Google-ArrivalTime: 2002-02-20 05:46:47 PST Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!gestalt.direcpc.com!cyclone2.usenetserver.com!usenetserver.com!newsfeeds-atl1.usenetserver.com!cox.net!news1.east.cox.net.POSTED!53ab2750!not-for-mail From: "Arthur Hagen" <art@broomstick.com> Newsgroups: comp.dcom.modems.cable,cableinet.cable_modems,cox.internet.discussion.athomeconversion References: <I0VX7.10375$B61.4953680@news1.rsm1.occa.home.com> <3C314C9C.DEDF0FCC@reece.net> <82lY7.33203$K36.11443500@news1.rdc1.va.home.com> <3C334AC0.7C6370B@reece.net> <bc5b60f8.0201170659.1fb61766@posting.google.com> <m_V48.3805$zR3.251588@news2.east.cox.net> <bc5b60f8.0201272107.82cbac8@posting.google.com> <dQo68.4657$Xk4.242975@news1.east.cox.net> <ggS68.7796$Xk4.425111@news1.east.cox.net> <y3U68.8160$Xk4.436368@news1.east.cox.net> <3%Z98.7525$zb.402885@news1.east.cox.net> <jQxa8.2975$SJ3.111671@news1.east.cox.net> <ShIa8.4164$SJ3.170583@news1.east.cox.net> <nnPa8.6168$SJ3.212179@news1.east.cox.net> <S4Ra8.6327$SJ3.221438@news1.east.cox.net> <Cagb8.10394$SJ3.374222@news1.east.cox.net> <gXib8.10520$SJ3.387856@news1.east.cox.net> <rLtb8.11334$SJ3.445265@news1.east.cox.net> <3C6E9AC8.41A0EAB4@charter.net> <vm6c8.5941$7Q6.215936@news1.east.cox.net> <3C72EA16.5FA77114@charter.net> Subject: Re: New cox cable managed network Lines: 92 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <rzNc8.896$XT1.64432@news1.east.cox.net> Date: Wed, 20 Feb 2002 13:32:07 GMT NNTP-Posting-Host: 68.14.87.162 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1014211927 68.14.87.162 (Wed, 20 Feb 2002 08:32:07 EST) NNTP-Posting-Date: Wed, 20 Feb 2002 08:32:07 EST Organization: Cox Communications