If you have tried to sniff the packet traffic of an ongoing MSN chat (with a Wireshark client), you will notice that the protocol used between the sender and the recipient is msnp (1863).

Enter "msnms" in the Wireshark display Filter text box to narrow down the display packets if you did not use any capture filter during the Wireshark capture.

In the screen capture below, ip address 192.168.1.106 is my desktop.



To figure out the "owner" of ip address 64.4.37.20, I use the Whois feature from the website www.samspade.org. If you would like to resolve the ip_address-to-dns_name, use nslookup.



From the information gathered from this snoop capture, we find out that my desktop establishes a connection to the MSN Hotmail server instead of a direct connection to the ip address of the remote MSN friend whom I was having a text conversation with.

As I was working on a pile of paperwork, I realized that I need to convert a pdf document into a MS-word document format for some extensive editing. Previously, I was able to retrieve the documents in pdf and MS-word format. However, recently the document creator decided to stick with publishing the documents in pdf and sdif format. (What in the world is sdif format anyway? Who uses it?)

At about the same time as I was pulling my hair over the issue above, my colleague had a requirement to convert a pdf document to Excel format and he asked me for some help. Great!

I googled around and found a pretty cool software which could handle the document conversions from PDF to Excel/Word and more! Able2Extract 5.0

It is relatively simple to get the hang of using the software, and you can select portions of the document for conversion into the desired format.

If you are not convinced, download the 7-Day Trial copy and try it out for yourself. And in case you are wondering about the difference between the Able2Extract 5.0 and the Able2Extract 5.0 Professional, you can check out the product comparison here.

Hope you find this recommendation beneficial!

Protocol Data Unit (PDU)
- comprises of the Layer's Header + Upper Layer's Data
- The figure below shows an example of a PDU:











Service Data Unit (SDU)
- a subset of PDU
- comprises of the Upper Layer's PDU
- In the OSI Layer encapsulation, where the OSI Layer goes from N to N-1, the Upper Layer's PDU becomes the SDU in Layer N-1. The figure below shows the example:

To translate an IP address from a string of decimals (in little endian* order) into a real IP address, follow this procedure:

Using the decimal number 26999818 as an example.

1) Convert the number to hex

    26999818 (in dec) = 19BFC0A (in hex)

2) If the hex number is 7 digits long, add a leading 0. If the hex number is 8 digits, skip to step 3.

    => 019BFC0A (in hex)

3) Split this value into 4 bytes

     01 9B FC 0A

4) Reverse the order of the bytes, as this value is little endian*

    0A FC 9B 01

5) Convert each byte (in hex) back to decimal

    10 252 155 1

This is the real IP address in dot-decimal notation: 10.252.155.1


*The least significant byte (LSB) value, 0x01, is stored in memory at the lowest address. And the most significant byte (MSB) value, 0x0A, is stored in memory at the highest address.

Note: For a better understanding on "Endian", check out the explanation here.

snoop & tcpdump belongs to the class of tools known as packet sniffers. If you had worked on troubleshooting IT systems, and you can't quite figure out if the issue lies at the application or network, you can use these packet sniffers to help narrow down on where the problem lies.


Solaris includes the packet sniffer: snoop.
To setup, you need to know on which interface (device) you want to run the snoop command. Use ifconfig -a to find out.

# snoop -d device -o filename

Example:
# snoop -d bge0 -o /var/tmp/snoop_activity_name.cap

If there are no interfaces specified, snoop collects packets from the first interface it finds. This is determined from netstat -i (excluding the loopback)

More specific captures can be set up using expressions such as host, port, tcp, udp, ip. These expressions can be combined with primitives such as and, or, and not.

Here are some examples
# snoop host sarah and host connor and tcp port 25
# snoop -d bge0 port 9048

To filter out traffic from your telnet session:

# snoop not host sarah

Linux and FreeBSD platform includes the packet sniffer: tcpdump

To setup, you need to know on which interface (device) you want to run the tcpdump command. Use ifconfig -a to find out.

# tcpdump -i interface -s snaplen -w file

Example:
# tcpdump -i wm0 -s 0 -w /data/SMTP.cap

-i wm0                specifies that interface wm0 should be traced
-s 0                  store the complete packet regardless of length
-w /data/SMTP.cap     store the output in file SMTP.cap in directory /data

Like the snoop command, similar expressions such as host, port, tcp, udp, ip can be combined with primitives such as and, or, and not.

Here are some examples
# tcpdump host john and host connor and tcp port 25
# tcpdump -i wm0 -s 0 -w /data/radius.cap port 1812

To filter out traffic from your telnet session:

# tcpdump not host john

When you have stored the .cap file(s), use Wireshark to view the file contents.

Sometimes we need to know if there are some connectivity problems between the connected host and the switch interface.

The show logging command for Cisco IOS can be used to check if an interface was unavailable for a certain duration

Switch#show logging
Oct 10 01:53:43: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down
Oct 10 01:56:14: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up

In addition you will need to be familiar with the following show interfaces command. The following information is provided when you enter the command:

• Interface type
• Status
• Speed and duplex
• Encapsulation
• Errors on the interface
• The last time the interface was bounced
• The last time the error counters were reset
• Port utilization
• IP address, subnet mask, and MAC address
  

Switch#show interface GigabitEthernet 1/0/1
GigabitEthernet1/0/1 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 001c.5723.e901
Description: Connection to BP_CS-FW-1
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 187000 bits/sec, 81 packets/sec
5 minute output rate 207000 bits/sec, 124 packets/sec
3290283950 packets input, 2160027042 bytes, 0 no buffer
Received 10 broadcasts (0 multicast)
24 runts, 0 giants, 0 throttles
24 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
4053517837 packets output, 3285226057 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

The main uses for the show interface command are to:

• Determine if the interface is up and if the protocol is up
• Ascertain if the interface has errors on it, especially CRC errors
• Find out the speed and duplex of the interface (for Ethernet interfaces)
  
• Learn the current utilization and utilization over the last 5 minutes
• Determine the last time an interface was bounced
  

To find out the transmit/receive rate of an interface, the packets in the hold queue, or the packets dropped from the queue, use the show interface summary command.

Switch#show interface summary

 *: interface is up
 IHQ: pkts in input hold queue     IQD: pkts dropped from input queue
 OHQ: pkts in output hold queue    OQD: pkts dropped from output queue
 RXBS: rx rate (bits/sec)          RXPS: rx rate (pkts/sec)
 TXBS: tx rate (bits/sec)          TXPS: tx rate (pkts/sec)
 TRTL: throttle count

  Interface              IHQ   IQD  OHQ   OQD  RXBS RXPS  TXBS TXPS TRTL
------------------------------------------------------------------------
  Vlan1                    0     0    0     0     0    0     0    0    0
* Vlan27                   0     0    0     0     0    1     0    0    0
* Vlan45                   0     0    0     0     0    0     0    0    0
* GigabitEthernet1/0/1     0     0    0     0 23000   13 44000   18    0
* GigabitEthernet1/0/2     0     0    0     0 74000   14 32000   21    0

For a quick idea on whether there are any CRC errrors on any of the interfaces, filter the show interfaces command using the pipe [|] and include option.

Switch#show interfaces | inc CRC
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

Here's a guide on how to setup a Wireshark capture.

In this scenario, we want to leave it running for a certain duration, and coming back to retrieve the snoop traces when an special data traffic event happens.


A. Increase the memory buffer size, this is to avoid packet drops during capture.

B. Choose the directory and file name for the snoop traces.

C. Enable 'use multiple files". You want the capture files to be in manageable file sizes. The file name chosen in B. will be appended with an incremental counter and the timestamp of the start time of the capture for each respective file.

D. Here is where you can limit the file size of each capture file. Alternatively, you can choose to start a new capture file using a specific time duration, example: every 15 minutes.

E. Unless you have unlimited storage space to store all the collected snoop traces, I suggest that you enable the "Ring buffer with" option. In this example, we limit it to 100 files. For the 101st and subsequent file, it will override the capture file with the oldest timestamp.

F. This is optional. If you really want to watch the captured packets scrolling by on your display, then leave the options enabled. Otherwise, you can disable "Update list of packets in real-time". To avoid packet drops during capture, disable it.

G. With all of the above done, you are now ready to click the "Start" button. Go on and click it.

After the capture is started, you will notice a status bar near the bottom of the Wireshark screen. To know if packets are being captured, the "Packets" counter will be incrementing.

In addition, you can go to the directory where you have chosen to store the capture files, and check if capture files are being created. Refresh the directory to see if the file size of the current capture file is increasing.

SCTP's multihoming failure detection time depends on three tunable parameters:

RTO.min (minimum retransmission timeout)
RTO.max (maximum retransmission timeout), and
Path.Max.Retrans (threshold number of consecutive timeouts that must be exceeded to detect failure).

RFC2960 recommends these values:

RTO.min - 1 second
RTO.max - 60 seconds
Path.Max.Retrans - 5 attempts per destination address

If the timer expires for the destination address, set RTO = RTO * 2 ("back off the timer").
The maximum value discussed (RTO.max) may be used to provide an upper bound to this doubling operation.

Since Path.Max.Retrans = 5 attempts, this translates to a failure detection time of at least 63 seconds (1 + 2 + 4 + 8 + 16 + 32).
In the worse case scenario, taking the maximum of 60 seconds, the failure detection time is 360 seconds (6 * 60).

In another example, where the following parameters are used,

RTO.min - 100ms
RTO.max - 400ms
Path.Max.Retrans - 4 attempts

Then,
Max. failure detection time = (1 + PMR)* RTO.max = 5*400 = 2000ms
Min. failure detection time = 100 + 200 + 400 + 400 + 400 = 1500ms