- The purpose of the Protocol Navigator View is to significantly improve your ability to zero in on "the problem."
- It is naive to believe that all problems are colored red. It's just not that simple. Last year I had a computer
hooked up to an ISDN modem and on to an ISP. Once the system got logged into the ISP's system, everything was fine, but it took what seemed like
forever to get snugly logged in. It seemed as though something early in the process was not right. But what? Luckily I had ViewComm running on the
machine and could make capture files and play them back. Some of them got names like "PPP Link Control Protocol Explorations.cfa"
- Before the several parties (my computer, my TCP/IP setup, some modems and the front end of the ISP's system) were turned loose
to do actual work, they had to negotiate a list of about a dozen Link Control Protocol options. Either party can suggest values for these options;
they must agree or one party will hang up. The number of retries on any option was about 10. Ten strikes and you're hung up on. But that's life
in protocolLand. At least teo parties have to agree on a way of behaving, and the more options there are and the more parties
to the negotiation, the more tricky it can get.
- It turned out one of the LCP options, MultiLink MRRU, was the sticky problem. My system and the remote could not agree
on a number. Whichever system goes first proposes a number for "MultiLink MRRU" in a part of the negotiation called Link Configure Request, and
the other guy looks at the values for the various PPP link options suggested and either buys them or else issues a Configure Reject in which the end
rejecting one or more parameters may suggest alternate values for any of the values it wishes to complain about. This is a far better strategy
than just rejecting the whole link Configure Request out of hand.
- In my scenario, neither my computer nor the ISP's would do more than just reject the other guy's MRRU value; so the call ended
up dead in the water. The systems killed the call because ten rejections was the limit and neither station felt like suggesting an alternate value.
Once I realized that the problem was narcissistic Link Control, I used Protocol Navigator to open a bunch of packets to the PPP
level, revealing the reason for the final rejection notice. I called the ISP Tech Support; it turned out they were getting calls from other customers
but nobody (but me) had yet pinpointed the problem. Protocol Navigator to the rescue! The ISP guys rebooted their router and the system worked normally.
- Once we figured out where the problem was, it was fortuitous that a fix suggested itself: Reboot everything
in sight. That was the most economical thing we could do. Had that not worked, we'd have proceeded to some software reloads and such. But at least we'd have
been working in the light, instead of the dark.
- Incidentally, later that afternoon we sold a copy of ViewComm Ethernet to my ISP. Later, they ordered about a dozen copies
and we talk sometimes about problems that pop up with other of their users. It's really amazing sometimes what really great software can bring to
light. And the profit from the sale was nice too. The operations manager of the ISP told me (I'm paraphrasing) "It's too bad we didn't know about your
tool years ago---going to work here without ViewComm is like a plumber starting his day without a wrench!"
- Once the locus of the problem was identified, we could invoke quick filters from the left edge of the Protocol Navigator
view--to lighten the load. That is, we could Filter out anything that wasn't part of the problem. We had to take that slowly because we didn't want
to throw out "the baby with the bathwater,"
|
- On the left part of the screen appear three small panes for selecting protocols: One for what to Filter in, one to specify protocol
parts to hide, and one for user specified filters.
- These are all display filters, new in ViewComm. They look at data in the buffer or capture file and pick
out the specified portions of a packet to display. There are two ways to do this: pick what to display, and pick what NOT to display.
In addition to picking from among the protocols in the current protocol stack, you can choose a custom Filter that you've designed and named.
- There's a simple procedure for building a custom filter. In it you can choose graphically from an existing protocol
tree in Protocol Navigator and add items to show or hide to a Filter (a new one or one you've saved).
- Then you can just check the box beside the Named Filter you want to apply.
- Through creative names, you can pretty much describe your saved filters, so it becomes easy to set up Protocol
Navigator "the way you want it" and adjust it if you wish using the individual protocol show/hide filters.
- There's a dialog called "Quick Filters" that you can choose from the Filter menu and which shows a larger
- Filtering in shows only the frames containing the protocol, but it shows the entire frame.
- Hiding (filtering out) effectively removes the hidden protocol layer from displaying in any frame.
|
