document updated 18 years ago, on Apr 3, 2008
Goals:
- should be able to constantly show the alive/dead status of the link of each NIC (while being
versatile enough to avoid issues like the WRT54G filtering out ICMP requests, or our VPN going into
this crazy anti-port-scanning mode where it responds to SYNs in a strange way, but ICMP still works, and actually communicating over the TCP socket totally fails)
- as closely as can be established, give information about else is in the same collision/broadcast domain on each NIC (eg. just because a link is transfering data, doesn't mean it isn't connected to the wrong access point, or wrong ethernet socket, or whatnot)
Broader goals:
- Aid the user in determining "I'm trying to comminucate from the current computer (point A) to that service over there (point B). Is the communications channel between them working 100%, or down 100%, or somewhere in between? And when it's not working properly, what seems to be the most likely point of failure?
Uber-solution #1
Often, when a link doesn't appear to be working, if you're able to very quickly analyze the output of Wireshark, then Wireshark can be one of the most broadly useful tools in figuring out what's working and what's not. (eg. just based on broadcast traffic, who else seems to be on the line? (eg. DHCP requests, ARP requests) Maybe the DHCP/DNS/etc servers I was looking for aren't the correct ones, but seeing which ones are here may be useful information) At the same time, sometimes a link with no traffic isn't dead, it just has no traffic on it. Therefore, a tool comprised of:
- Passive sensor: A WinPcap-based analyzer, that synthesizes the "alive status" based purely on what it sees (eg. you don't necessarily need to run a ping, if you see a SYN go one way, and its SYN+ACK come back, then you know its response time). Benefits:
- There are times when network diagnosis requires a certain amount of guessing (eg. what might the correct gateway be? am I connected to this network or that?). Having the data come to you can sometimes take a lot of the guesswork out of it.
- When you're actively using the network link for a certain task, passive sensing allows you to determine a lot about the state of the link (including bandwidth limits) without disrupting the real work that's happening.
- it also means this kind of tool can run on top of/alongside other tools, and provide additional information based on what they're doing
(for instance, your browser doesn't explicitely tell you that a DNS server was responding before, but is no longer responding at all, but sometimes that's useful information to have... a sniffer can tell you this even when it's the browser that's doing the main work)
- While it's true that many networks are switched, greatly reducing the usefulness of passive diagnosis, the most troublesome networks (wireless) are not switched. Also, even on switched networks, there's still broadcast data.
- Also, the operating system tends to filter out layer-2 information from most diagnosis responses. However, it's sometimes some of the most useful data for solving link-level problems, so having direct access to it is a boon regardless of how much active sensing you do.
- Active sensor: Sends out pings/arps, if only to provide a base level of response traffic so we don't have to guess if the silence is due to the link going dead.
- Hyperactive sensor: Adding another dependency (winpcap) always sucks. However, winpcap gives you a bonus capability: the ability to inject raw packets. And, I believe these packets bypass any local VPN rules. As such, you can run "ping" and the like on normally totally-firewalled-off NICs. winpcap lists possible programs for this. Some that probably work include:
Might be the best?
Writeups