Network Packet Capture Reference

[unisys12]

Sup guys? I thought it would be helpful to have a thread that we could all reference for help and info on packet captures and performing packet captures.

So, I guess the best way to start this off would be to cover exactly what a "packet capture" is and why you might want to do one. Then we can cover a few specific things you will need to capture network traffic. Followed by how to properly set up for the procedure. As for covering how to read the captures and troubleshoot using the info you gather, I think that might be better left to others that have a hella lot more experience than me. So, I will resort to posting link to articles and wiki's that cover this topic and can be better used to research this topic further.


What is a Packet Capture and why would I want to do this?
Lets start with a little coverage of network basics; All information that travels across a network does so in packets. Think of it this way - take a file and break it apart into small bits. These bits are then wrapped with other bits of information, which tells the network what the bits are and where the bits are suppose to go, etc etc. Those bits of info that "wraps" the file segments are called packets.

When performing a packet capture, you are doing just that. Capturing all those packets and displaying them in a way that makes them easier to understand. This way, if your having network problems, you can actually see whats going on and where it's going wrong.

Note: Traffic analysis, network analysis, protocol analysis, packet analysis and packet sniffing (capturing) all typically refer to the same thing.

Before we go any further, I feel very compelled to explain that this should not be done without the consent of the IT staff for the network. If you are going to do this and are thinking of doing this at an account that has an IT staff on site, talk to the about your plans. You will probably find that they already have the necessary things in place to do this for you. All you have to do at this point is ask them to filter out the IP of the MFP or printer in question and have them print it out for you. As you can see, from the above explanation, that you will be looking at every single bit of information traveling across or through the segment of the network in which you are connected. So, let's cover a few legitimate and illegitiment uses for performing this procedure.

Legitimate

• Identify network or communication issues
• Monitor network performance
• Verify network security
• Track communication transactions
• Log network traffic
• Discover source of unwanted traffic
• Discover compromised workstations
• Ensure users are adhering to AUP

Illegitimate

• Capture passwords
• Capture network information
• Read confidential information
• Determine network information

Consider this your warning. If you do this on someone's network without their consent... it's basically the same as spying, stealing and hacking all wrapped up in one.

What you need to perform a packet capture -
First things first and that's software. Best, well free, is Wireshark formally Ethereal. There a lot of others which can be found by doing a Google search using the term "packet capture".

Second is a "non-switching" hub. This is a true hub (repeater) and not a hub with a built in switch or a switch re badged as a hub. In general, if you find something with "full-duplex" in the device description, this is in fact a switch and not a hub. This is often the case with 100MBit Ethernet devices. If you use a 10MBit hub, and it's stated to be a hub, it will be a hub.

These can be pretty hard to find, well I have had a hell of a hard time find one. So I checked the Wireshark Wiki and found a hub reference. There I found a hub, which is sold at Best Buy for $20.

Finally, a laptop and few patch cable long enough to connect everything together. There are packet sniffing tools avaliable that will run from a flash drive, but you will still need to have the hub, so you can plug it into the PC you plain to use for the capture and the network. We will cover how to connect everything and why next.

How to Set-Up for a capture -

taken from the Wireshark wiki

Look at Host A as the MFP you want to monitor and Host B as the network or wall outlet that the MFP plugs into.

When trying to do this from a PC, located on the network, you will run into problems because most every network now days uses switches to connect different segments of their network. Reason is for performance, but it makes life hard for capture info. The reason is because a switch literly reads the packet information and sees where it needs to go. Because of this, you will not see all the packets and will miss information. This is explained in the picture below.






I will cover capturing and what to look for in those captures in another thread. If anyone actually reads this whole thing... I will be surprised. For those who do read all this and would like to add to it. Please... Feel free! That's what this board is all about.

[random]

Also, bit out of a usual techys scope. You can use an old PC and have two NIC's in it and act as a pass thru so all the data goes from network to the pc and from the PC to the engine. Using software like IP cop all data can be captured. Also you can block ports so only 515, 9100, 10001, 25,21 can get thru. We have had instances when this was the only way to stop a machine's nic crashing. We suspect some pimply student was attempting D.O.S attacks on the controller for a laugh.

If you find you have this problem you can buy routers with port blocking functions. Quite easy to set up.

Look forward to the rest of unisys12's feature.

[blackcat4866]

I can't anything technical to this dicussion. Just to say, whenever the data capture was necessary the local IT guys knew exactly what I needed and got it to me quick. Apparently its not a big deal at thier end.

[random]

You are lucky! Most of clients go thru I.T contractors like there is no tomorrow. Generally you are lucky to find one that can set a raw port let alone troubleshoot. You must deal with a lot of corporates with in house IT

[unisys12]

Just thought I would add to this thread some info that has come up a time or two.

When using WireShark (newer version of Ethereal), there is a handy little tool called the "Wiki Protocol Page". To access it, all you have to do is hi-lite the packet in the top pane (dark blue line packet 96). Then right click on the corresponding info in the lower pane. Either will work, but stick with the one that has the error in it. This can done by simply following the hi-lite lines in the second pane. In the menu that pops up, choose "Wiki Protocol Page". This will take you to a Wiki hosted by Wireshark, that contains tons of info on the protocol chosen along with sample captures posted by others. This not only allows you get answers to questions you have, but to also see how things should look in different situations.

Hope this helps someone out in the future!

[Nathaniel]

Also a little feature in wireshark that is really great for troubleshooting is the "Follow TCP Stream" option in unisys12's screen shot above. Click it and will rerun wireshark and combine the bits and pull the data. Simply select raw as the option and save out the file in the file name and type you expect it to be in (example: tiff or pdf) and view the document on the laptop.

This option is great for troubleshooting a MFP setup in a existing workflow that is immediately processed by an application (like Livelink, Documentum, Sharepoint) where you can not access the file from the share (SMB, WebDAV, FTP, etc). Keep in mind without customer consent this is stealing.

[blackcat4866]

Slow printing

Unisys,

Can a packet capture help with this issue:

I have a slow printing issue on a Kyocera product. I've done data captures, and I've gotten pretty much what I expected. But what a data capture doesn't tell me is if the packets came as a steady stream, or if there was a gap in the transmission, then continued.

Does the packet capture contain a time factor, or is it just the sequence of packets without regard for time between?

[unisys12]

Does the packet capture contain a time factor, or is it just the sequence of packets without regard for time between?

Yes. Referencing the image I posted above, you will notice that there is a time stamp for each capture. This is noted in the second column of information displayed about each capture.

Now! Will it help in troubleshooting slow printing? Well, possibly so now that I think about it.

First off though, ask yourself if the slow printing is happening to a group of people in the office or a single person.

- If it's a group, or set of PC's, then I would tell their IT guy to start checking his switches/hubs for bad packet references.
- If it's just one PC, then try to figure out how long this has been going on. If it printed fine before now, then what's changed on the PC.

Now that we have the basic troubleshooting stuff out of the way, which I am more than sure you have worked through, then this is how I would go about it from there...

Set up Wireshark to capture (or isolated out) the IP of the MFP in question and send a test print job over to it from the offending MFP. Pay attention to how much time passes before the packets come flying by. You don't have to be accurate, just pay attention to the packets. After the job, stop the capture. But save it! Something like PC to Kyrocera. Then set up another capture, but from the offending PC to another printer in the office, if possible. Save it as PC to HP or whatever works for ya there.

At this point, go back your observation of the packets during the capture.

- Is there a long pause between the time Print is clicked on the PC `til the time it takes for the packets to come flying by.

If so, there's a few things to observe here as well. When the packets do come flying by, do they come in one big wave or is a small groups of packets.

- If you see a big wave of packets and the printer just sits there, taking a while for it to response, then you have a issue with your machine.
- If you see small groups of packets coming in, then I would say it's a network issue and you will probably see a lot of RST (reset packets) sent back and forth as well. This means that the machine and/or the PC is recieveing what it feels to be corrupted packets and it is asking whoever sent them to send them again.

Assuming the two printers are on the same subnet, check between the two and see if the average time between packets is about the same for both devices.

- If they are, then we could probably rule out any network issues.
- If their not, welll.... you know.

That's about how I would approach the situation. You might skip whatever steps you like or modify it of course. Please, let me know what you find.

[blackcat4866]

Yes this looks to be helpful.

The symptom is 11 single ledger pages followed by a 2 to 3 minute hesitation, 11 more pages, 2 to 3 minute hesitation, etc.

What I'm trying to determine is if the data is coming in at a speedy consistent rate, and the printer is just taking a while to process it; or is the data coming in sporatically from the print server, and the printer processing the data it has and waiting for more data. It seems to be affecting several Kyocera machines/models in a similar fashion. I just find it hard to believe that this is a hardware issue, seeing it affect several machines/models similarly all from the same single enterprise application.

They're new placements, and they never had digital, so there is no real issue of "It worked before...", it never really did. It keeps coming back to "The HPs don't do this...". So what does that mean? Nothing.

I'll give this a shot. Thanks for the info.

[unisys12]

It keeps coming back to "The HPs don't do this...". So what does that mean? Nothing.

I wouldn't be so quick to judge here. Remember, not long ago I had a print issue that would not go away and it always came back to... "Well, our 3 and 5 year old HP's don't do this!" And once I did make some comparisons, I found that it was a configuration issue. Or compatibility issue, however you prefer to word it.

Check your packet capture, but keep in mind the configuration of the job coming off of the print server. It interacts with the HP's the same way it does the Kyrocera's. If it's one particular job or application that the job is coming from that is causing the issue, then I would open those data captures you did earlier back up. Start comparing the specs of the HP's currently in the office that aren't having the problem to the specs of your new MFP's and you will probably find what you need to change.

Before you say to yourself, "Why should I change my MFP's, or downgrade their settings? This takes away from the machine!" On most all MFP's, the print driver overrides whatever is set on the machine. For instance, if you have to lower the default print DPI from 600 to 300 to resolve the issue, this is no big deal. Your driver should still be set to your machine defaults, so when a print job is sent, this will override the lower 300 DPI setting and change it to 600 DPI for that job.

Either way though, I will be very interested to hear what you find. Keep me posted and good luck!

[blackcat4866]

This brings up another issue I'm a little fuzzy on:

This customer uses a proprietary utility that they wrote just for this purpose. It takes multiple page AutoCad documents and breaks them up into individual 1 page print jobs, does the translating into PS 2.0, then send it to a Unix Pass Thru print queue, then to the printer.

I have had several suggestions of changing driver settings, but the print driver settings seem to have no effect. The commands written in by thier utility override anything I set.

Am I correct in my conclusion that any 'driver' settings that I make will have to be written in PostScript or Printer Job Language and prepended to the print jobs? This actually is not that difficult, since I wrote the header that they are currently using now....

One last question: Do you think that it makes any difference that the print job is written in PS 2.0, and the printer is expecting PS 3.0? One of my theories is that there are some differences. Another theory is that some of the delay comes from reading and interpreting the header on each page, instead of a header followed by several pages.

Any theories of your own?

=^..^=