Showing posts with label networking. Show all posts
Showing posts with label networking. Show all posts

Jul 31, 2023

Force Apple Captive Portal Login

 If you try attaching to a guest wi-fi with an active portal that doesn't seem to want to trigger, try this:

http://captive.apple.com/hotspot-detect.html


Hope this helps!


Mar 5, 2021

Thin Client: Wyse WT1200Le (Updated: 03/15/2021)

 

Picked up this thin client hoping to make a fun little DOS machine out of it. Turns out, that's a bit of an issue. The device will not boot to USB. There is also no accessible BIOS/CMOS that anyone has discovered so far as my research goes. 

Let's look at specs and such.

CPU - AMD Geode GX

GPU - Geode GX CS5530A

RAM - 32MB (Soldered onto motherboard)

Sound - LM4546AVH (AC97)

Storage - 512kb SoC (System on Chip)

RJ45 - Pulse PE-68515L 10/100

USB Ports - 2 on back

Video Port -  VGA

Power Requirements -  12v 3.33a

Other Ports - Headphone, Mic

OS - Wyse ThinOS

BIOS - Winbond; not accessible by keyboard so far as I have been able to determine.


 

System booted and within seconds, presented a desktop that appears to be some kind of no-frills Windows 98 or XP, but is more likely some version of Linux. 

A "System Information" window opened up for a few minutes as the system grabbed an IP address. That screen disappeared and a "Connect Manager" screen popped up, trying to connect to "jtc-gp." Of course, that failed.

System Information shows Memory (32MB) and ROM (512k). There is a NAND Size option, but it shows zero, as there is not storage device on the unit. The 32MB RAM is soldered onto the motherboard but there are no means for expansion without soldering a SODIMM socket to the thing.


 

 

 

 

The "Start" button says "Desktop," and leads to a variety of applications to examine. System Setup provides options for setting preferences, configuring network and display, and setting serial/parallel ports (even though the unit doesn't actually have any).


System Preferences cover naming the device, time zone, DST, and other options.

 

The Network Setup allows for assigned or DHCP addressing.

There is a wireless setup screen, but there is no wireless adapter in the unit. There is a header for a micro-wifi card, but there is no socket soldered in the spot.

 

The Display setup auto-selects the resolution and color depth based on the monitor the system detects, but the user can override this, changing the resolution and/or the refresh rate.

 
 
The Serial Setup must be a holdover from an earlier version of the device, since there is no serial port nor is there a dial-up modem port.
 
 
Like the serial settings, there is a Printer Setup. The default is LPT1, however later versions of the software allow for various USB printers to be used.
 
 
We looked at the System Information earlier, so next we have Applications - which is empty by default.
 

 As you can see, there are a few more tools - PPOE Manager, Dialup Manager, and PPTP Manager for handling different types of connectivity. The Network Test section has Ping, Trace Route, and Print Queues.


Inside the Connection Settings, we can create new items to connect via ICA, which is a Citrix-based server, or via RDP, which is how most people connect remotely to servers.

 
I do not have a Citrix server on site, but I do have various Windows servers, so I created an RDP connection to a local server.

   

I did not provide a username/password combination when I set up the connection, and the server promptly provided the login screen for me to enter my credentials.

 

 All in all, this is a very simple device for folks who want to provide no-frills access to network resources. Parkytowers has a cool write-up about this thin client and addresses the limitations of not being able to access BIOS. 

I think if someone were capable, they could devise a way to sneak DOS into a firmware build and replace the built-in TOS with it. The main problem is the 512k "storage." One would basically have to keep the OS inside a 512k "drive." Not sure how feasible that is.

I think it would great if someone could hack the wt1200le to drop a DOS loader package. Basically, you would have enough OS to boot, then it would create a ramdrive that the OS in unpacked into with whatever games/apps you were going to run in DOS. The main issue I see with the 512kb boot space is that it would have to house the "MBR" etc PLUS the compressed disk image. The issue with the 32MB RAM is that the ramdrive would be limited to roughly 20-25MB. That's a 20MB hard drive. Not a lot to say the least. The other problem you have is that none of the data can be saved back out again. So, if you were playing a game, you could save the game as long as the unit was powered on, but once you turned it off, the ramdrive is gone and so is whatever save games you had.

Still, it would be a cool project if it were possible.


*Update 03/15/2021 - I found someone who provided the 4.4.079i firmware image and I setup my desktop as a FileZille FTP server. In the 1200LE, I configured the network settings to point to my desktop and it upgraded to the original OS. The person also provided 5.2_035 firmware, which I then tried on the device.  The updated OS runs VERY quickly, but the mouse wouldn't CLICK. I could move it around the screen, but the system would not register any mouse clicks. Weird.I reverted back to 4.4.079i and everything seems fine.

*Note: My unit was running v 4.4.079i when I got it. I found a firmware "update" that turned out to be a downgrade to 4.4.010i. That downgrade killed the USB mouse. Well, technically, a USB mouse kills the OS, causing it to throw up a "divide by zero" error. I am still looking for the firmware to upgrade back to where I was.

*Note: If you are presented with a login screen, turn off the device. Turn it back on. While it is booting, keep spamming the G key on your keyboard. The unit will force itself into a "Factory Reset" mode which will eliminate the login screen.

Jan 28, 2020

DEC Pathworks on WFW 3.11 - Group Creation Tool



Way back in the day (circa 1994 or so, I would venture), I worked for a university where they were using Digital Equipment Corporation (DEC) VAX servers. The workstations were a mix of Windows 3.1 and WFW 3.11, though when I arrived, we were moving everyone to WFW 3.11. As part of the general network installation, we installed DEC Pathworks (I believe it was version 4.x), which allowed Windows machines to have file storage access to the servers. While that's all well and good, the real her in this tale is a little program that ran during the installation of the software and drivers.

During the installation, Pathworks created its own Windows Program Groups - a common thing to do for program installations. For some reason, during one install, the creation routine failed with an error about a problem in a BLD file though the actual extension may have been different now that I am trying to recall). Being the nosy characters we are, the tech guys decided to investigate since we had never head of a BLD file.

Turns out, the BLD file, which I believe was called PATHWORK.BLD (or something similar) is just a text file outlining group names and the shortcuts to go into the groups. I have tried to locate the actual file, but can't at the moment, so here is the sample file from the program's webpage:

[CreateGroup(Test Main,TMAIN.GRP)]
[ShowGroup(Test Main,1)]
[AddItem(progman.exe,File Manager)]
[AddItem(control.exe,Control Panel)]
[AddItem(printman.exe,Print Manager)]
[AddItem(clipbrd.exe,Clipboard)]
[AddItem(command.com,DOS Prompt)]
[AddItem(setup.exe,Windows Setup)]

[CreateGroup(Test Accessories,TACCESS.GRP)]
[ShowGroup(Test Accessories,1)]
[AddItem(write.exe,Write)]
[AddItem(pbrush.exe,Paintbrush)]
[AddItem(terminal.exe,Terminal)]
[AddItem(notepad.exe,Notepad)]
[AddItem(recorder.exe,Recorder)]
[AddItem(cardfile.exe,Cardfile)]
[AddItem(calendar.exe,Calendar)]
[AddItem(calc.exe,Calculator)]
[AddItem(clock.exe,Clock)]
[AddItem(pifedit.exe,PIF Editor)]

As you can see, this file contains the structure to build groups. First, the CreateGroup command expects two arguments, the display name of the group ("Test Main") and the actual name of the GRP file for Windows ("TMAIN.GRP"). The next command tells Windows that the group is visible (that is, not hidden) and also expects two arguments: The display name of the group ("Test Main") and a 1 for yes or a 0 for no. Finally, the next series of lines build the items to be displayed within the newly created group. The AddItem command expects two arguments as well. The first is the name of the file to be referenced followed by the display name of the file. Note: If the filename is not available via the PATH statement, the full path to the file must be provided - ex: [AddItem(c:\games\duke3d\duke3d.exe, Duke Nuk'em)].

The BLD file is just the configuration, though. The actual program to run is BUILDGRP.EXE, though again I believe DEC used a custom name instead, if memory servers.

During setup, a:\BUILDGRP.EXE PATHWORK.BLD would be executed, with the EXE referencing the specific configuration.

As you might imagine, this suddenly opened a whole new world to us! We created a slew of custom group installations for the users, running the program from a batch file stored on a floppy disk or on the network itself. You see, once Pathworks was up and running, the WFW machine had access to the network. So, we could call a batch file from the workstation and tell our custom group(s) to install themselves on the client machines.

If you're interested in playing with GROUPBLD, you can find it (along with a help file and the sample configuration above) buried in this Windows 31 DOSBox package.

I have no idea what made me remember all this. Guess it just PoppedInMyHead!

Jan 22, 2019

#Ransomware Attack at School Triggers Best Practice Reminders

 
Recently, there was a ransomware incident at a nearby school district. The event occurred through a Remote Desktop Protocol Session (RDP) running on the Technology Coordinator's desktop. His machine had a publicly accessible RDP IP address so he could work from home, etc. Unfortunately, his computer was compromised and subsequently used to attack their servers.

If you are using RDP to get access to your network from outside, I recommend the following:
  1. Kill all RDP sessions accessible from outside your internal network. This may require editing your firewall settings to remove the public IP address(es) to your RDP computers.
  2. Change your password on any accounts used for accessing public RDP. The current en vogue system is to use passphrases rather than passwords.
  3. If you must have remote access, set up a VPN to handle that instead of RDP.Several companies offer secure VPN access.
  4. Do NOT put your own login account into the Domain Admins group.
  5. For internal RDP sessions, do *NOT* save the logon credentials. I know it is a pain, but better safe than sorry. :-)

Apr 18, 2018

Work Life: IP Address range Calculator

November 30, 2012
Need a quick way to find the IP address range for a network? There is an online calculator here:
You enter any address on the network, then input the subnet mask, tell the page to calculate the range and Voila! It will give you the 1st address in the range, the last address in the range and the broadcast address.

Work Life: Remote Shutdown Windows Server

November 30, 2012
I thought I had lost my old friend shutdown.exe that I found on one of the old Resource Kits, but found out I hadn't and with Windows Server 2003, it's included. I loved the ability to reboot computers when I was out of the office and of course before WSUS some updates required a restart so this tool came in real handy. With this tool you can restart, shutdown or Annotate Unexpected Shutdown. I won't use the last one but the first two are useful.
From the server, open a command prompt and type in shutdown /i. It's not the old GUI interface but it is workable. Select the system you wish to shutdown using the browse button or just type it in. You must give it a reason as the Event Tracker is back. I tend to turn it off on my servers, hate it...
This tool is great for administrators who have large sites and want to give their feet a break!

Sep 22, 2017

Work Life: VOIP Pass-Through for Dumb Switches

Are you implementing VOIP phones in your office but have certain places where you've got a dumb switch in place providing connectivity to computers, printers, etc? No problem! Here's all you do:

  1. Connect the network cable into the wall jack as you normally would.
  2. Plug the cable from the wall jack into the NETWORK jack on the phone.
  3. Plug a network cable into the COMPUTER jack on the phone.
  4. Plug the other end of the COMPUTER cable into the dumb switch. This gives your PC, printers, etc connectivity to the network!
This setup allows you to still pull your POE from the wall jack to the phone while giving the devices connected to the switch the network access they need via the phone's network pass-through. 

I have tested this on various brands of phones and various brands of POE switching. So far, they have each been able to provide the connectivity to the network needed by the dumb-switch devices while enabling the power and connectivity needed of the VOIP phone.

Hope this helps!

"Computer" jack (on left) goes to Dumb Switch

Connection from phone's Computer jack plugs into switch.
Note: This post assumes you have whatever equipment you need in place for the actual phones themselves (ex: POE switches and/or power injectors, etc)

Oct 28, 2016

Work Life: Dueling DHCP Servers (DNS Errors, Unauthenticated Networks)


Heya!
  Today, I visited a school that was having issues with some of their computers in specific locations. Usually, when a district calls with something like that, we start in the room(s) where the trouble seems to be and work our way outward from there. In this case, there was an elementary lab in which all but one row of computers was throwing up some weird errors.

The machines are running Windows 7, and the network icon in the system tray would change from the standard computer to one with a yellow warning triangle. Then, a message would pop up stating that the computer was connected to the local network but was "unauthenticated." Other computers showed the normal computer icon but when they tried to get online, the browser would throw up messages about unresolved DNS issues, etc.

When the tech would check the IP address on any of the errant machines, the initial address would show the local network scheme. However, when the warning icon appeared, an ipconfig revealed the address had been changed to a 192.168 range.

That range, as many of you know, is where things like wifi routers like to live. So, I asked about switches, other network equipment, etc.  The tech had put in a new switch (new to them) that they had received from another district. Since the "new" switch was an HP Procurve, I thought maybe something was going on there. Plus, that had been the most recent change the tech could remember at the time.

I removed the switch and was about to put in another switch, the tech came in and told me that she remembered they were testing their new Kajeet-based MiFi hotspots at about the same time everything went wacko.

Instantly, we had our answer. You see, when they were testing the hotspots, they were using them in tethered mode, meaning they hooked up the device to the computer via USB cable and let the computer use that as the connection. Well, the hotspot is set up to hand out IP addresses (DHCP). Normally, this is not an issue - the computer gets an IP address and life goes on.

Here is the rub: If the computer in question is ALSO connected to the local network (via Ethernet cable, for example), the hotspot actually communicates down that wired line through the computer it is connected to. So... The hotspot was answering DHCP requests from certain computers on the network. Of course, I want to know why only those specific computers and not, say, computers spread throughout the district. Unfortunately, we may never know the answer because all of the trouble took place the day before I arrived and the hotspots were already disbursed.

So, in a nutshell (the TL;DR version, I suppose you kids would say these days): Erratic computer connectivity might be blamed on multiple DHCP devices on your network. Check for Wireless Routers, tethered hotspots, internet connection sharing, etc.

Feb 23, 2016

Work Life: Two ports in the sea

An area school reached out because they were having some very bizarre network issues. They had replaced several switches on their network and things seemed to be going fine - for a while. Soon, they noticed segments of the network were crashing or coming to a grinding slowdown.  First inclination is to blame and look for a network loop in effect.

For those that may not know, a network loop happens when you take a network cable and plug both ends into the same switch. For example, you plug one end into port 1 and the other into port 8 on the same switch. Much like an echo between speakers and a microphone, the network traffic coming out of one end feeds into the other end, which then feeds it back to the first end. Lather, rinse, repeat. With microphones and speakers, we hear the loud squeal of feedback. On a network, traffic loops in an ever-increasing roundabout fashion, bringing things to a standstill.

The same thing (or similar, anyway) can happen if two network wires from one switch are plugged into two ports on another switch. For example, Port 3 and 4 on one switch are plugged into ports 1 and 4 on another switch (the actual port number do not matter). This is usually called "spanning tree" since it is between two switches, though the term can also be used within a single switch.*

So, you with me? Okay, here's the situation then:

When the tech plugged in a new switch via fiber, the network would come crashing down. Okay, we thought, must be a loop somewhere in the "new" network since things worked fine before hooking up the new switch. Except for one problem: it happened even when the new switch had NO OTHER connections attached - just the fiber from the main network switch. Unplug the fiber, and the network settled back to normal.

Okay, let's see what else we have then. We head to the main network switch (also referred to as the core switch) to see what we can figure out. As we looked over things, I had to climb a ladder in order to get to the core switch because it was mounted high in the network closet's rack.

After a few moments, I realized the problem: they didn't have a loop so much as they had two network lines plugged into the same port. Wait. What? How could they have two wires in the same port? Allow me to demonstrate. Note: The image below is NOT the actual switch in this post. I recreated the scenario using my own switch.


Now, you may be saying, "Those circled wires are not in the same port!" While that is true, physically, it is not true logically. Notice on the left, the port number is 23. On the right, it is also 23. In most switches that have CAT5 (left) and fiber (right), they share certain ports. In the image above, ports 21-24 are "shared." This means you can EITHER have a CAT5 wire in a port number *OR* you can fiber in the port number. At least, from a logical sense. In a physical sense, you can plainly see there is nothing stopping me from plugging a wire into both ports. The switch in this case sees both as perfectly legitimate and sends/receives traffic down BOTH of the Number 23 ports. Much like a network loop, traffic spins out of control as the switch sends and receives data down both paths.

That is what happened at the district. Now, seeing the example above makes it look like the problem is obvious, right? Well, in the example above, it is obvious. In the real world scenario, as I mentioned before, the switch was mounted up high. Additionally, that switch had the port numbers on the TOP of the ports, not the bottom. So, the tech could not see that the fiber ports were shared with ports 23 and 24 (that switch only had two fiber ports).

Because the tech could not see the numbers, the fiber was plugged into Port 24.  There was also a CAT5 wire plugged into Port 24. So long as the fiber was not plugged in on the other end, everything was fine. As soon as the fiber made the connection in the other switch, everything went crazy, as by now you might imagine.

The moral of the story here is that we can't always tell the exact nature of the problem due to the actual physical parameters of the environment. In this case, the tech could not see the numbers on the ports, thus not realize wires had been plugged into the shared ports on the switch.

Sometimes, it truly does take a different set of eyes to help solve a problem.

*Note: Some switches can be configured to handle such arrangements. This can take the shape of VLANS (virtual local area networks) or spanning tree detection/prevention. You may have heard these referred to as Layer 2 or Layer 3 switches.

Oct 29, 2013

#inacol13 - Tuesday: Is Your Network Ready for Digital Learning?

Please note: These are rough notes. Editing may be needed and clarification may be needed upon further review. I apologize for any typos and/or incomplete/inaccurate information. Information entered in this blog is replicated out to various online outlets automatically.

Why I chose this one:
I was asked to attend this one in order to see what other folks are saying regarding bandwidth.

What I learned/Am learning:

Presented by EducationSuperhighway. Link: http://www.educationsuperhighway.org/

Mission: Upgrade internet infrastructure of every k12 public school in America.

Infrastructure upgrades required to deploy initiatives:
Common Core
Next Gen Assessments
STEM (address teacher shortages)

The focus has shifted greatly from Admins/Teachers on the network to students getting online.

Recommended 100Mbps for districts at a minimum. Most schools have 10Mbps (if even that).

Less than 10 Kbps per student is "Pre-Basic"
10-50 k/student = Basic
50-100 k/student = Emerging Reliance 
100+ k/student = Technology Rich

Each school is a different stage in the "life cycle" in terms of what they need/should have. Don't buy bandwidth just to "have it" if you don't need it.

Minimum requirements cover basic usage and an "all call" to get off the network during PARCC assessments.

Next-step is Teacher-Driven adoption and growth

Student-Driven network means more bandwidth.

Ultimately 1:1 Media-Centric rollout - every student has a device and is connected. Leadership is on board with student in-hand technology. Network becomes critical in terms of uptime.

Potential bottlenecks: What is size of pipe coming into the district. Lots of places, you cannot GET the connectivity. Other times, it is an issue of not subscribing to enough bandwidth. Many times, the filter/firewall is outdated and cannot handle the throughput required. The physical wiring set up and be an issue. Managed switches can direct and/or throttle throughput. The wiring itself can be old and degrade the quality of connection. Wireless access is a bottleneck: Is there enough bandwidth? Is there enough coverage? Is there too much coverage? Is it a managed solution? Incredible demand on Wifi if devices are constantly switching between access points. The wifi equipment itself can be an issue. And, the device can be the bottleneck: speed, age, capability, etc.

Information Gap > Expertise Gap > Procurement Gap > Policy Gap

  • Which schools need to be upgraded?
  • Schools need help with upgrade paths and plans. Schools may not have the staff to handle everything involved.
  • Can we get cost lowered for additional bandwidth? What about equipment? (Internet Pricing Portal)
  • Policy Gap: E-Rate 2.0
Schools not getting volume discounts. Why not partner to receive certain services. 


School Speed Test: Collect information from classroom access. Goal is to get 10 tests from every district. Roughly one minute test. Confirm location, run the test. SchoolSpeedTest.net - usually partner with state dept of ed. Measures continuous-use bandwidth. 

Ideally, test is taken through different devices in different locations on different days during the month. Data given to state depts of ed (where there is partnership) in order to help the DOE understand what is happening in the state.

Test results assessed against two goals: Online Assessment (PARCC) and Digital Learning (Online courses). 1Mbps/students/sec in 2017-2018 (SETDA)

72% of schools not meeting the minimum as of latest test data.

Data Infrastructure Assessment

  • 45-minute phone call and a 1.5 hour on-site visit - Zero cost to school districts for the 75 pilot schools. Would need to work with the non-profit regarding on-site visit.
  • Phone interview - What equipment they have, are buying. Can follow up with on-site. Provide supts with specific upgrade needs.
  • Take snapshot of the network and provide feedback in a color-coded, easy to read format.
Internet Pricing Portal
  • Collect data on what is being paid. This is done via Item 21 attachments. And sometimes a 30-minute phone call.
  • Reports on cost per megabit and where those costs "should" sit for what schools can provide
  • Fiber transforms the costs. Of course, this assumes fiber is even available to the schools.
E-Rate
  • Create a one-time upgrade fund to enable schools to meet realistic broadband goals for the next generation (fiber/wifi/etc)
  • Reform E-Rate administration of E-Rate to reduce costs.
  • Focus funds to building broadband infrastructure
*Personal thought: E-Rate needs to separate phone service from internet services. Ex: AT&T provides phone and DSL, but those are both listed as "Telephony" according to E-Rate. That is ludicrous. As an aside, I have very 'radical' ideas on changes to E-Rate and may share those later.




Sep 8, 2009

Troubleshooting a Local Area Network Problem

Warning: Technical Info Ahead!

I visited a school district recently that experienced a complete network failure. Through some troubleshooting, the tech was able to narrow the culprit down to something happening at the high school.

This article discusses how to troubleshoot a local area network when something like this happens. The images are for reference only, but should give you an idea as how to at least START the troubleshooting process, and hopefully it will help someone out there find the demon that shut down the network.

First, let me talk about how the tech narrowed down the issue to one building. All the connections from campus come into one data closet. When his users started complaining that they could no longer get online or use their email application, the tech went to the closet and unplugged one connection at a time until the problem went away (a smaller scale will be discussed below). Once he determined the problem went away when he unplugged the high school, he knew where to to start looking for the problem. This is where I came in (with an extra set of hands/eyes to help me).

At the high school, I unplugged all the connections in the tech closet. I then only connected a nearby computer and the connection back to the central tech closet (which leads to the Internet):

The little black screen in the upper left corner is a simulated PING test. I ran a PING test on the computer out to the DNS server we use. You could also PING something like YAHOO.COM, if you so choose.

How do I run a PING test? Do this:
  1. In Windows XP, click START then RUN then type CMD and press ENTER. In Vista, Click the WINDOWS BUTTON, then in the search box, type CMD and press ENTER
  2. At the prompt now on the screen, type PING YAHOO.COM and press ENTER (or use whatever address you need/want, so long as that address LETS you ping. Some do not)
  3. You will get one of two BASIC responses: either "Reply From..." or "Request Times Out." "Reply From..." is a successful ping (you can reach the site you are trying to ping). "Request Timed Out," however, is a FAILED ping. It means your computer could not reach the computer you tried to ping. This is useful for troubleshooting!


Okay, so what if your one computer and one connection back to the Internet fails the ping test? At that point, you know you have a problem in the devices that run between the two sites (in this case, between the main closet and the high school).

Since we were able to ping the world, we are back to troubleshooting the network. Once you confirm that your network works with just one computer, you add ONE of the connections on your network back into the loop:


I prefer to always pick one port to use for ALL the remaining tests. That way, you are limiting the possible problems down to one actual "leg" of your network. As you can see above, I took the wire from "Connection 1" and plugged it into port 5. In our case, I have no idea where "Connection 1" goes on the high school network. And for now, I don't even care. My goal is to find the link that is crashing the network. Once I hooked up "Connection 1," I run the PING test again on the computer nearby. Now, what I really did was set the ping test to run indefinitely. The command for that is: PING -t YAHOO.COM

In the example above, I am able to ping the outside world. At the high school, I was able to get to the outside world.

In the next example, I UNPLUG "Connection 1" and plug "Connection 2" into the SAME PORT that I used for the first test. Again, this is because I know that port works now that it has passed the first test.


Once "Connection 2" is hooked up, I check my PING test to be sure i do not have failure messages. It's important to stop here a moment to say this: You will most likely have *SOME* failures. One or two over the course of dozens is not too bad. what we are looking for is a complete failure where you get "Timed Out" error after "Timed Out" error - many in a row.

As long as the PING test passes, you repeat the procedure for each of your connections: disconnect the wire, plug in the next wire, check the PING.

So, what happens when you get a FAIL?


Uh-oh! We failed our PING test!! Now, we know where the problem is. Or at least we know which part of the network is causing the problem.

What I did at this point at the high school was to unplug the error-causing wire, and check the PING. Everything looked good. I plugged the offending wire back in, and checked the PING - FAIL! I did this because I wanted to be sure it wasn't some fluke. It was not.

Now, I unplugged the errant wire again. Then, I plugged the other wires into the switch. I checked the PING to make sure that everything was working while all the other wires were plugged in. Everything worked.

Our next task is to find out where the errant wire goes and discover which devices on that part of the network might be causing the problem. I believe we will find a situation where someone plugged both ends of a network cable into one switch. Basically, it's taking one end and plugging it in to, say port 5, and then taking the other end of the same cable and plugging it in to port 7. The actual port numbers don't matter. what matters is that it creates a loop. Ever heard feedback when someone is speaking with a microphone because they get too close to the speaker system? Same idea, but with data spinning out of control in an infinite loop. It is not pretty, and it brings many networks to a screeching halt because nothing else can get through while all this other data is going round-and-round.*

Once we are able to hunt down the offending equipment, we take whatever steps we need to take in order to cure the problem. For example, if it is an issue where a wire is plugged back into the same switch, we unplug the wire. If it turns out to be an infected computer, we get it off the network and heal it.

One thing that should be done, though, is another PING test setup. The difference at this stage, though, is that you do not have to unplug everything else to run the test. all you have to do is plug in the wire that was causing the problem. If the problem persists, unplug it and hunt down another culprit. If everything works after you plug in the wire, then you have cured your network of the offending loop/computer!! Wahoo!

*For my truly techie friends: I am fully aware that many modern-day switches have measures that will shut down the offending ports in such a situation. But, you might be surprised at how many sites do not have such capabilities - case in point, the high school where I was troubleshooting.