Showing posts with label Network. Show all posts
Showing posts with label Network. Show all posts

Wednesday, September 20, 2017

My Top Internet / Network Tools

There are lots of useful sites which helps the troubleshooting procedures. I listed some common tools or websites used by myself. Please let me know what you are using and I would like to try them and add them into this list.
1. Internet/Network Tools Portal
2. Internet/Network Speed Test
3. IP Subnet Calculator
4. Network Monitoring Related
5. DNS and Domain Name Related
6. BGP Toolkit
7. Your Public IP Address
8. Online Diagram Drawing Sites
9. Snmp tools
10. HTTP and HTTPS Check Tools
11. Email Diagnostic Tools
12. Proxy Sites
13. Remote Support / Online Meeting
14. Remote (SSH / Telnet) Access Tools
15. NTP Server
16. Portable Software
17. Online PDF Tools

Friday, August 11, 2017

Gartner Magic Quadrant for Cloud Infrastructure as a Service (Worldwide) (2017, 2016, 2015, 2014, 2013, 2012...)

In the context of this Magic Quadrant, cloud compute IaaS (hereafter referred to simply as "cloud IaaS" or "IaaS") is defined as a standardized, highly automated offering, where compute resources, complemented by storage and networking capabilities, are owned by a service provider and offered to the customer on demand. The resources are scalable and elastic in near real time, and metered by use. Self-service interfaces are exposed directly to the customer, including a web-based UI and an API. The resources may be single-tenant or multitenant, and hosted by the service provider or on-premises in the customer's data center. Thus, this Magic Quadrant covers both public and private cloud IaaS offerings.

2017
On Jun 15 2017, Gartner has published  Magic Quadrant for Cloud Infrastructure as a Service that – no surprising  – has Amazon Web Services and Microsoft alone in the leader's quadrant, same as last few years.

Reference: Magic Quadrant for Cloud Infrastructure as a Service, Worldwide

Thursday, July 27, 2017

Gartner Magic Quadrant for Network Performance Monitoring and Diagnostics (2017, 2016, 2015, 2014 )

According to Gartner, Network performance monitoring and diagnostics (NPMD) enable network professionals to understand the impact of network behavior on application and infrastructure performance, and conversely, via network instrumentation. Other users and use cases exist, especially because these tools provide insight into the quality of the end-user experience.

The fast-growing network performance monitoring and diagnostics market is helping businesses support more complex environments and services through network visibility, performance issue detection and root cause analysis.

Leaders in this industry are innovating around cloud-based monitoring, better support for software-defined environments and more flexible deployment models, according to research firm Gartner. The research firm estimates that the network performance monitoring and diagnostics tool market, which is a segment of the lager network management space, sits at $1.6 billion and is growing at a compound annual growth rate of 20.7 percent.

2017
NetScout (Formerly is Fluke) , Viavi (formerly is JDSU) and Riverbed are leaders in the Gartner NPMD Magic Quadrant for the fourth consecutive year. 

Gartner Magic Quadrant for Data Center Infrastructure Management (DCIM) (2016, 2015,2014)

Data center infrastructure management (DCIM) tools monitor, measure, manage and/or control data center resources and energy consumption of both IT-related equipment (such as servers, storage and network switches) and facilities infrastructure components (such as power distribution units [PDUs] and computer room air conditioners).

2016
Based on Gartner report on Oct 2016, Nlyte Software, Emerson Network Power, and Schneider Electric continue to lead in the DCIM software market.

Gartner Magic Quadrant for DCIM, Oct 2016




Friday, April 7, 2017

Avocent® ACS 8000 Advanced Console System Configuration

My company has used Avocent ACS (Advanced Console Server) to do network devices' console management for many years already. I were using 4000, 5000 and 6000 serie, and now 8000 series is coming to refresh some old ones.

Emerson (EMR) acquired infrastructure management specialist Avocent Corporation (AVCT) for $1.2 billion on Oct 2009. Since then Emerson combined its Aperture and new Avocent businesses as a new division focused on helping data center customers better manage their infrastructure. Now it is part of Vertiv which launched as standalone business. The Vertiv's Trellis DCIM platform was the first to use real-time data to enhance data center management and has been recognized as a leader in every DCIM Magic Quadrant published by Gartner.

Interesting thing is I even could not find Avocent product from Vertiv's product page. Totally there are 13 products under IT management category, but ACS product line is not there. I managed to google and find one link which shows more this product at this link: https://www.vertivco.com/en-us/products-catalog/monitoring-control-and-management/it-management/avocent-acs-8000-serial-consoles/


Emerson Avocent ACS8000 Front


Thursday, March 30, 2017

Brocade Switch Access Through SSH and Web Tools




1. Through SSH
It is pretty straightforward, launch ssh client, enter your switch ip and credential, you will be in the command line.

Saturday, February 25, 2017

Gartner Magic Quadrant for WAN Optimization (2016, 2015, 2014, 2013, 2012, 2011)


WAN optimization provides a range of features to: (1) improve the performance of applications running across the WAN; and (2) reduce the cost of the WAN. The range and scope of features supported by
WAN optimization solutions continue to evolve, typically in support of three high-level needs:
  • Improve the response times as experienced by users of business-critical applications over WAN links or mobile connections, often addressing application performance problems caused by bandwidth constraints, latency or protocol limitations.
  • Assist in maximizing the ROI for WAN bandwidth, and delay costly bandwidth upgrades.
  • Optimize data-center-to-data-center (DC-to-DC) traffic for faster replication and synchronization.

Gartner Magic Quadrant for Application Delivery Controllers (2016, 2015,2014,2013,2012,2010)

Application delivery controllers (ADCs) are generally deployed in the data center and provide functions that optimize delivery of enterprise applications across the network. ADCs provide functionality for both user-to-application and application-to-application traffic. The ADC effectively bridges the gap between the application and underlying protocols and the traditional packet-based networks. The market evolved from load-balancing systems that were developed in the latter half of the 1990s to ensure the availability and scalability of websites. Enterprises use ADCs today to improve the following aspects of their applications:
  • Availability
  • Scalability
  • End-user performance
  • Data center resource utilization
  • Security
2016
F5 Networks Named a Leader in Gartner Magic Quadrant for Application Delivery Controllers for 10th Consecutive Year
Citrix: Recognized as a Gartner ADC Magic Quadrant Leader for 10 years

Friday, November 4, 2016

Infoblox NetMRI 1400 Appliance with Network Automation OS Configuration Steps

The Infoblox NT 1400 network automation appliance is designed to automate network change, see the impact of changes on network health, manage network configurations and meet a variety of compliance requirements.

KEY FEATURES:
  • Network Discovery
Automatically and continually track multi-vendor infrastructure, end hosts, network constructs (routes, VLANs, virtual forwarding and routing, etc.), and topologies with current and historical information.
  • Configuration Management
Automatically detect and audit network changes and receive detailed analysis. Take advantage of configuration back up, powerful search, and correlation of network problems with time and location.
  • Change Automation
Manage network-wide change tasks with simple yet robust methods for encoding change logic with minimal scripting.
  • Policy and Compliance Enforcement
Automatically and continuously assess network changes in real time against security policies with an easy-to-use rule studio.
  • Network Analysis
Get analysis and alerts on network configuration problems, including ticking time bombs that show no fault or performance symptoms.
  • Anytime, Anywhere Mobile Access
Manage your network from your mobile device. View network inventory, find device locations, and control port and VLAN connections.
  • Hardened Appliance
Get a solution that ships on a purpose-built hardware device and includes the operating system and database, reducing your costs and maintenance requirements.

 Infoblox NT 1400 network automation appliance


Monday, October 24, 2016

Gartner Magic Quadrant for Cloud-Enabled Managed Hosting, North America (2015, 2014)

Cloud-Enabled Managed Hosting Market Definition/Description

The cloud-enabled managed hosting (CEMH) market deals in standardized, productized hosting offerings that combine a cloud-enabled system infrastructure (CESI) platform — comprising compute, network and storage hardware owned and operated by a service provider — with cloud management platform software to facilitate self-service and rapid provisioning with managed services (see "Technology Overview for Cloud-Enabled System Infrastructure" note that this document has been archived; some of its content may not reflect current conditions ). The infrastructure platform may be located in a service provider's data center, or optionally at the customer's data center, but, either way, it requires standardized deployment across all customers and uses a single code base that has been pre-engineered and/or predeployed by the provider prior to customer sign-up. At minimum, a service provider must supply server OS management services, including guest OS instances when virtualization is used. The provider may optionally supply other managed and professional services relating to the infrastructure's deployment and operation.
Cloud-enabled managed hosting allows only limited customization. It is sold on a stand-alone basis, with no requirement to bundle it with — for example — application development, application maintenance or data center outsourcing (DCO) services.
Customers must be able to access a self-service interface, which may be different from the platform interfaces used internally by the provider. A service provider can potentially intervene in the self-service workflow to manually approve, deny or alter a customer's requests, as long as the provisioning requested is fulfilled in a fully automated manner thereafter. Managed services (such as OS backups, patching and monitoring) must be available to customers on commitments of less than one year.

Thursday, March 24, 2016

Mobile Iron Sentry VM Installation

What is Mobile Iron Sentry?

Mobile Iron Centry provides access control for email. Sentry connects to Microsoft ActiveSync-enabled email systems such as Microsoft Exchange, IBM Lotus Notes, Google Gmail, and Microsoft Office 365. MobileIron Sentry  is an in-line gateway that manages, encrypts, and secures traffic between the mobile device and back-end enterprise systems. Like the VSP, it may be deployed as a physical hardware appliance or a virtual appliance using VMware ESX. Mobile Iron Sentry is included in the Mobile Iron Advanced Management package, though the hardware appliance is sold separately.

MobileIron's Mobile@Work App connects your Android device to your company network so that you can easily and securely access email and other work resources. Mobile@Work App works in conjunction with a MobileIron Core server deployed by your company’s IT organization. .


In this post, I am using sentry-mobileiron-7.0.1-29.iso to do installation into Vmware Workstation 10.


 

Saturday, November 28, 2015

Updating InfoBlox Network Automation Product NetMRI

Infoblox NetMRI product  has been really helpful to manage network environment. The post Use Network Automation Tool Infoblox NetMRI Push Configuration to Multiple Network Devices explains how to do a batch job with some clicks. This post will explain how to update NetMRI product with some learned experience.

There are two methods to update NetMRI software:

1. Automatic Update


Friday, October 16, 2015

Use Network Automation Tool Infoblox NetMRI Push Configuration to Multiple Network Devices

Infoblox NetMRI Appliance
For those still do not know what is Infoblox NetMRI product, here is some simple introduction. Actually it can do more than what normal network administrators think.

NetMRI is one of the most important products owned by Infoblox. This product came with the acquisition of Netcordia in 2010. NetMRI provides automatic network discovery, switch port management, network change automation and continuous configuration compliance management for multi-vendor routers, switches and other layer 2 and 3 network devices. NetMRI helps customers move from out-of-date spreadsheets, error-prone manual processes like scripts and CLI access and ad hoc audit teams.

Sunday, August 16, 2015

Layer 2 / Layer 3 IP Packets Switching Procedures

Layer 2 Packets Switching Procedures

The packet will be sent in the same vlan.

1. A sends ARP -who is 10.1.1.3?
Destination MAC address : ALL FF's
Source MAC address: A1

2. ARP is broadcast so switch forwards out all ports

3. B replies to ARP
Destination MAC:A1
Source MAC: B1

4. A sends to B
Destination MAC: B1
Source MAC: A1
Destination IP address: 10.1.1.3
Souce IP: 10.1.1.2

5. Switch performs CAM lookup using destination mac address and forwards packet to B1.



-----------------------------------------------------------------------------------------------------------

Layer 2 / Layer3 IP Switching Procedures

Packets will send from A to D across multiple vlans:


1. A sends ARP - who is 10.5.1.2?
Destination MAC address : ALL FF's
Source MAC address: A1

2. Switch replies to ARP - saying send it to me

3. A sends to Switch
Destination MAC: C1
Source MAC: A1
Destination IP: 10.5.1.2
Souce IP: 10.1.1.2



4.Switch does a L3 lookup 

5. Packet forwarded
Destination MAC: D1
Souce MAC: C3
Destination IP: 10.5.1.2
Source IP:10.1.1.2

6. Switch does a forwarding lookup

7: Packet forwarded
Destination MAC: F2
Source MAC: D2
Destination IP: 10.5.1.2
Souce IP: 10.1.1.2








Monday, March 16, 2015

Linux Service Configuration - NTP

As a network guy, you will work with NTP (Network Time Protocol) lots for your network devices.

From Wikipedia, the explanation regarding NTP is:
"The protocol is usually described in terms of a client-server model, but can as easily be used in peer-to-peer relationships where both peers consider the other to be a potential time source.Implementations send and receive timestamps using the User Datagram Protocol (UDP) on port number 123. They can also use broadcasting or multicasting, where clients passively listen to time updates after an initial round-trip calibrating exchange. NTP supplies a warning of any impending leap second adjustment, but no information about local time zones or daylight saving time is transmitted."
A local linux NTP server on the network can be synchronized with a trusted timing source to keep all of your internal NTP clients in sync with an accurate time. For windows ntp server, please check my previous post: Build NTP Windows Server for Network Devices (not Win32Time)

1. Install NTP Server

a. Check your linux release

[root@syslov1p ~]# cat /etc/redhat-release
CentOS release 6.6 (Final)

b. [root@syslov1p ~]# yum install ntp

Loaded plugins: fastestmirror
Setting up Install Process
Loading mirror speeds from cached hostfile
Package ntp-4.2.6p5-2.el6.centos.x86_64 already installed and latest version
Nothing to do

2. Modify /etc/ntp.conf

a. add trusted time server, in my case it is 10.9.1.1. Other configuration could be default. 


b. Restart ntpd service

[root@syslov1p ~]# service ntpd restartShutting down ntpd: [  OK  ]Starting ntpd: [  OK  ][root@syslov1p ~]# service ntpd stopShutting down ntpd: [  OK  ][root@syslov1p ~]# service ntpd startStarting ntpd: [  OK  ]

c. Also you could restrict only specific clients

restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

d. add local clock as backup

server 127.127.1.0 # local clockfudge 127.127.1.0 stratum 10

3. Verify NTP Status

a. using command ntpq -p
[root@syslov1p ~]# ntpq -p     remote           refid      st t when poll reach   delay   offset  jitter==============================================================================*10.9.1.1     193.108.184.92   3 u   25   64  377    2.173    4.430   3.906

b. Manually synchronize time

[root@syslov1p ~]# ntpdate -u 10.9.1.116 Mar 20:38:58 ntpdate[2671]: adjust time server 10.9.1.1 offset -0.005387 sec

c. on your linux NTP client, you could start your ntp client Daemon and check the ntp client status

[root@syslov1p ~]# /etc/init.d/ntpd start
Starting ntpd:  
[root@syslov1p ~]# ntpdc -c sysinfo
system peer:          r-1-hsrp.mgmt.intern
system peer mode:     client
leap indicator:       00
stratum:              4
precision:            -19
root distance:        0.18851 s
root dispersion:      1.09599 s
reference ID:         [10.9.1.1]
reference time:       d8b1b105.8e2ff185  Mon, Mar 16 2015 20:44:05.555
system flags:         auth monitor ntp kernel stats
jitter:               0.000000 s
stability:            0.000 ppm
broadcastdelay:       0.000000 s
authdelay:            0.000000 s
[root@syslov1p ~]# service ntpd status
ntpd (pid  28807) is running...
[root@syslov1p ~]# chkconfig --list
abrt-ccpp       0:off   1:off   2:off   3:on    4:off   5:on    6:off
abrt-oops       0:off   1:off   2:off   3:on    4:off   5:on    6:off
abrtd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
atd             0:off   1:off   2:off   3:off   4:off   5:off   6:off
auditd          0:off   1:off   2:on    3:on    4:on    5:on    6:off
autofs          0:off   1:off   2:off   3:off   4:off   5:off   6:off
avahi-daemon    0:off   1:off   2:off   3:on    4:on    5:on    6:off
blk-availability        0:off   1:on    2:on    3:on    4:on    5:on    6:off
certmonger      0:off   1:off   2:off   3:off   4:off   5:off   6:off
cgconfig        0:off   1:off   2:off   3:off   4:off   5:off   6:off
cgred           0:off   1:off   2:off   3:off   4:off   5:off   6:off
chronyd         0:off   1:off   2:off   3:off   4:off   5:off   6:off
cpuspeed        0:off   1:on    2:off   3:off   4:off   5:off   6:off
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off
cups            0:off   1:off   2:on    3:on    4:on    5:on    6:off
dnsmasq         0:off   1:off   2:off   3:off   4:off   5:off   6:off
dsmc            0:off   1:off   2:off   3:off   4:off   5:off   6:off
ebtables        0:off   1:off   2:off   3:off   4:off   5:off   6:off
fusioninventory-agent   0:off   1:off   2:off   3:off   4:off   5:off   6:off
haldaemon       0:off   1:off   2:off   3:on    4:on    5:on    6:off
htcacheclean    0:off   1:off   2:off   3:off   4:off   5:off   6:off
httpd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
ip6tables       0:off   1:off   2:off   3:off   4:off   5:off   6:off
iptables        0:off   1:off   2:off   3:off   4:off   5:off   6:off
irqbalance      0:off   1:off   2:off   3:on    4:on    5:on    6:off
iscsi           0:off   1:off   2:off   3:off   4:off   5:off   6:off
iscsid          0:off   1:off   2:off   3:off   4:off   5:off   6:off
kdump           0:off   1:off   2:off   3:off   4:off   5:off   6:off
ksm             0:off   1:off   2:off   3:off   4:off   5:off   6:off
ksmtuned        0:off   1:off   2:off   3:off   4:off   5:off   6:off
libvirt-guests  0:off   1:off   2:off   3:off   4:off   5:off   6:off
libvirtd        0:off   1:off   2:off   3:off   4:off   5:off   6:off
lm_sensors      0:off   1:off   2:off   3:off   4:off   5:off   6:off
lvm2-monitor    0:off   1:on    2:off   3:off   4:off   5:off   6:off
mcelogd         0:off   1:off   2:off   3:on    4:off   5:on    6:off
mdmonitor       0:off   1:off   2:off   3:off   4:off   5:off   6:off
messagebus      0:off   1:off   2:on    3:on    4:on    5:on    6:off
netcf-transaction       0:off   1:off   2:on    3:on    4:on    5:on    6:off
netconsole      0:off   1:off   2:off   3:off   4:off   5:off   6:off
netfs           0:off   1:off   2:off   3:off   4:off   5:off   6:off
network         0:off   1:off   2:on    3:on    4:on    5:on    6:off
nfs             0:off   1:off   2:off   3:off   4:off   5:off   6:off
nfslock         0:off   1:off   2:off   3:off   4:off   5:off   6:off
nmb             0:off   1:off   2:off   3:off   4:off   5:off   6:off
nrpe            0:off   1:off   2:on    3:on    4:on    5:on    6:off
nscd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
nslcd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
ntpd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
ntpdate         0:off   1:off   2:off   3:off   4:off   5:off   6:off

numad           0:off   1:off   2:off   3:off   4:off   5:off   6:off
oddjobd         0:off   1:off   2:off   3:off   4:off   5:off   6:off
portreserve     0:off   1:off   2:on    3:on    4:on    5:on    6:off
postfix         0:off   1:off   2:on    3:on    4:on    5:on    6:off
psacct          0:off   1:off   2:off   3:off   4:off   5:off   6:off
quota_nld       0:off   1:off   2:off   3:off   4:off   5:off   6:off
radvd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
rdisc           0:off   1:off   2:off   3:off   4:off   5:off   6:off
restorecond     0:off   1:off   2:off   3:off   4:off   5:off   6:off
rngd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
rpcbind         0:off   1:off   2:off   3:off   4:off   5:off   6:off
rpcgssd         0:off   1:off   2:off   3:off   4:off   5:off   6:off
rpcsvcgssd      0:off   1:off   2:off   3:off   4:off   5:off   6:off
saslauthd       0:off   1:off   2:off   3:off   4:off   5:off   6:off
smartd          0:off   1:off   2:off   3:off   4:off   5:off   6:off
smb             0:off   1:off   2:off   3:off   4:off   5:off   6:off
sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
sssd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
svnserve        0:off   1:off   2:off   3:off   4:off   5:off   6:off
syslog-ng       0:off   1:off   2:on    3:on    4:on    5:on    6:off
sysstat         0:off   1:on    2:on    3:on    4:on    5:on    6:off
udev-post       0:off   1:on    2:on    3:on    4:on    5:on    6:off
winbind         0:off   1:off   2:off   3:off   4:off   5:off   6:off
xe-linux-distribution   0:off   1:off   2:on    3:on    4:on    5:on    6:off
ypbind          0:off   1:off   2:off   3:off   4:off   5:off   6:off

[root@syslov2p ~]# service --status-all | less
auditd is stopped
crond (pid  1087) is running...
dsmc is stopped
dsmcad is stopped
fusioninventory-agent is stopped
ip6tables: Firewall is not running.
Table: filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination        
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
2    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0          
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
5    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:5666
6    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:1500
7    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:1501
8    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination        
1    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination        
ktune settings are not applied.
No sensors found!
Make sure you loaded all the kernel drivers you need.
Try sensors-detect to find out which these are.
lvmetad is stopped
messagebus (pid  863) is running...
netconsole module not loaded
Configured devices:
lo eth0
Currently active devices:
lo eth0
nrpe (pid  973) is running...
nscd is stopped
nslcd is stopped
ntpd (pid  961) is running...
master (pid  1071) is running...
Process accounting is disabled.
qpidd is stopped
rdisc is stopped
rpcbind (pid  804) is running...
rsyslogd (pid  778) is running...
sandbox is stopped
saslauthd is stopped
openssh-daemon (pid  932) is running...
syslog-ng is stopped
tuned is stopped
winbindd is stopped
os_distro="centos"
os_majorver="6"
os_minorver="6"
os_uname="2.6.32-504.8.1.el6.x86_64"
os_name="CentOS release 6.6 (Final)"

[root@syslov2p ~]# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name  
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      932/sshd          
tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      1071/master        
tcp        0      0 0.0.0.0:5666                0.0.0.0:*                   LISTEN      973/nrpe          
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      804/rpcbind        
udp        0      0 0.0.0.0:973                 0.0.0.0:*                               804/rpcbind        
udp        0      0 0.0.0.0:111                 0.0.0.0:*                               804/rpcbind        
udp        0      0 10.9.1.132:123            0.0.0.0:*                               961/ntpd          
udp        0      0 127.0.0.1:123               0.0.0.0:*                               961/ntpd          
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               961/ntpd            


Sunday, March 1, 2015

Bridge Your Home Routers to Extend Your Wireless Network

Not sure how many home users are experiencing wireless router coverage issue. Your wireless home router is set at living room, but at the certain location of your home, the wireless signal is quite weak. It will be painful especially when you found this fact on the bed with your tablet devices. Upgrade a more powerful wireless routers, or buy another router repeater?Actually the router vendors have implemented a "bridge" technology which can enable wireless connection between multi-vendor's routers. Here is Wikepedia's explanation about Bridging (networking):
"Network bridging is the action taken by network equipment to create an aggregate network from either two or more communication networks, or two or more network segments. If one or more segments of the bridged network are wireless, it is known as wireless bridging. Bridging is distinct from routing, which allows multiple different networks to communicate independently while remaining separate."
This post is my weekend task to get my living room's wireless signal to cover the corner of my bed room better. In the bedroom's far end from wireless router's location, the signal is always not enough to keep my ipad/cell phone persistently connected. To stop my family's complain, I decided to set up secondary router as a bridge Access Point at second floor, which will provide strong signal to upper floors.

Topology:



1. Main Router's Configuration

Main router is from isp, and this Adsl device model is HG-A800. This router's configuration is not any special. You just need to enable wireless security, LAN network and DHCP. 

Wireless basic configuration:


Note: Channel should not be set to Auto since it may change after a reboot or power outage. After you find out current channel number such as 6 in this example, you will need to set it as current channel. Your bridge channel will be set it to same number manually. That will prevent lost connection between two routers. (updated Jul 12 2017)


 Wireless Security:

 LAN and DHCP Setup (LAN IP is 192.168.2.1):


2. Secondary Router's Configuration:

TP-LINK WR941ND is used as secondary router for bridge Access Point purpose. 

There is no connection on WAN port since it is secondary router which is not directly connecting to Internet. LAN port can be used to connect local network devices such as media player, game console or desktop.WAN configuration type for this secondary router will be Dynamic IP. LAN IP will be 192.168.2.2. DHCP Scope is from 192.168.2.151 to 192.168.2.199. As you tell, The DHCP Scope of Primary router and Secondary router is not overlapping, which is easier for us to identify which device your system is logged in by wireless later. 

The most important part is Wireless Settings in secondary router. You had better set up same wireless SSID and password  as Primary router, especially at SSID (to be bridged) section. 

Note. As you can see the channel is manually set to 6 to match your main router. 


3. Test Result

My ISP is providing 15 mbps downloading speed and 1 mbps uploading speed. From the speedtest.net's result, it shows pretty good result from Secondary router, almost no loss from this set up.



Tuesday, January 20, 2015

Build NTP Windows Server for Network Devices (not Win32Time)

Based on Cisco Document (ID108076) Troubelshoot Network Time Protocol (NTP), Cisco devices are not able  to Sync NTP to W32 Based Time Service.

"Windows W32Time shows that it is an SNTP implementation inside (rather claiming itself NTP). Cisco IOS-NTP, which tries to sync with W32Time, gets its own root-dispersion value that it sends to the W32Time and this proves costly for Cisco IOS-NTP to synchronize. Because the root-dispersion value of Cisco IOS-NTP goes higher than 1000 ms, it unsynchronizes itself (clock-select procedure). Since the Cisco IOS based routers run the full RFC implementation of NTP they do not sync to an SNTP server. In this case the output of the show ntp associations detail command shows that the server is flagged as insane, invalid. The root dispersion value is in excess of 1000 ms, which causes the Cisco IOS NTP implementation to reject the association. Routers that run Cisco IOS can be unable to synchronize to an NTP server if it is a Windows system that runs the W32Time service. If the server is not synchronized, the routers are not able to transmit to and receive packets from the server."


Afroz Ahmad has a post in his blog show How to Setup Windows as NTP Server for Cisco Devices. Basically what you need is a 3rd party NTP software from Meinberg which helps us out.

Download from this link. (http://www.meinbergglobal.com/download/ntp/windows/ntp-4.2.6p5@spider-man-win32-setup.exe)

Installation procedure is quite straightforward.


Problem:

 Unfortunately, I got some small problems while trying to create a new account to start this service:



Solution: 

What  I did is to use a existing account within administrators group to replace NTP service account configured in the Network Time Protocol Daemon.


Another thing I want to mention is how to enable a time server to synchronize in the configuration file (C:\Program Files\NTP\etc\ntp.conf) after the installation, which is basically to remove the # sign from server 127.127.1.0, and add one internal server from your environment, just like shows in the following configuration.
# NTP Network Time Protocol
# **** ATTENTION ****: *You have to restart the NTP service when you change this file to activate the changes*
# PLEASE CHECK THIS FILE CAREFULLY AND MODIFY IT IF REQUIRED
# Configuration File created by Windows Binary Distribution Installer Rev.: 1.28  mbg
# please check http://www.ntp.org for additional documentation and background information

# The following restrict statements prevent that someone can abuse NTP as a traffic amplification tool by
# ignoring mode 6 and mode 7 packets. Especially the monlist feature has a big potential to be abused for this.
# See http://news.meinberg.de/244 for further information. 
restrict default nomodify notrap nopeer noquery
# But allow local tools like ntpq full access: 
restrict 127.0.0.1
# if you are not using IPv6 on this machine, please comment out the following line:
restrict -6 ::1

# Use drift file
driftfile "C:\Program Files\NTP\etc\ntp.drift"

# your local system clock, should be used as a backup
# (this is only useful if you need to distribute time no matter how good or bad it is)
server 127.127.1.0
# but it operates at a high stratum level to let the clients know and force them to
# use any other timesource they may have.
fudge 127.127.1.0 stratum 12

# Use a NTP server from the ntp pool project (see http://www.pool.ntp.org)
# Please note that you need at least four different servers to be at least protected against
# one falseticker. If you only rely on internet time, it is highly recommended to add
# additional servers here.
# The 'iburst' keyword speeds up initial synchronization, please check the documentation for more details!
 server 0.north-america.pool.ntp.org iburst
 server 1.north-america.pool.ntp.org iburst
 server 2.north-america.pool.ntp.org iburst
 server 0.us.pool.ntp.org iburst
 server 2.us.pool.ntp.org iburst


# Use specific NTP servers
server 192.168.2.6 iburst

# End of generated ntp.conf --- Please edit this to suite your needs

Reference:

Friday, September 26, 2014

Gartner Magic Quadrant for User Authentication (2014, 2013, 2012)

The Magic Quadrant for User Authentication depicts Gartner's independent analysis of authentication vendors in the marketplace. Positioning within the quadrant is based on an organization's ability to execute and completeness of vision.

All those six companies Safenet, EMC (RSA), Genalto, Technology Nexus, CA Technologies and Vasco Data Security are in the leaders Quadrant for the second year.

2014


2013



2012




Thursday, August 21, 2014

FTP Active mode vs Passive Mode

Traffic flow for Active mode and Passive mode:

 1. Active FTP :

     command : client >1023 -> server 21
     data    : client >1023 <- server 20

Running ftp command from client 10.94.200.28 to connect server 10.94.200.14:
C:\Users\j>ftp 10.94.200.14
Connected to 10.94.200.14.
220-FileZilla Server version 0.9.41 beta
220-written by Tim Kosse (Tim.Kosse@gmx.de)
220 Please visit http://sourceforge.net/projects/filezilla/
User (10.94.200.14:(none)): test
331 Password required for test
Password:
230 Logged on
ftp> debug
Debugging On .
ftp> mput C:\Users\john\Documents\a1.txt
mput C:\Users\john\Documents\a1.txt?
---> PORT 10,94,200,28,255,15 
200 Port command successful
---> STOR a1.txt
150 Opening data channel for file transfer.
226 Transfer OK
ftp: 30348 bytes sent in 0.00Seconds 30348000.00Kbytes/sec.
ftp> ls
---> PORT 10,94,200,28,255,121
(Port number is 255*256+121=65401)
200 Port command successful
---> NLST
150 Opening data channel for directory list.
a1.txt
Tekradius DB.bak
226 Transfer OK
ftp: 26 bytes received in 0.00Seconds 26000.00Kbytes/sec.
ftp>

On server 10.94.200.14, checked the port number 65401 with netstat -na command

 2. Passive FTP :

     command : client >1023 -> server 21
     data    : client >1024 -> server >1023


ftp> literal pasv
---> pasv
227 Entering Passive Mode (10,94,200,14,233,114)
ftp>

Notes:
FTP communications use two port number values – one for commands (port 21 by default) and one for data transfer (this is where the PORT command comes into play).

The PORT command is sent by an FTP client to establish a secondary connection (address and port) for data to travel over. In some FTP implementations port 20 is used for data, but that is the exception rather than the rules. Typically in a trace you will see data crossing over a dynamic port number (IANA states that this range should be between 49152 through 65535, but most likely you’ll see your application using something just above 1024 – the area that used to be the dynamic port number area).

Thursday, July 24, 2014

Understanding TCPDUMP Output



These examples in this post bases on Checkpoint Firewalls. In other platform, the output and

command options may have a difference.

Basic TCPDUMP Commands:


  • tcpdump port 257   , <– on the firewall, this will allow you to see if the logs are passing from the firewall to the manager, and what address they are heading to.
  • tcpdump -i WAN.15  <- data-blogger-escaped-capture="" data-blogger-escaped-everything="" data-blogger-escaped-interface="" data-blogger-escaped-li="" data-blogger-escaped-on="" data-blogger-escaped-this="" data-blogger-escaped-to="">
  • tcpdump -i eth1.16 icmp  <– to capture just PINGs on this interface
  • tcpdump -i  Mgmt -vvv -s0 -w tcpdumpfile.log   <– this captures the FULL packets to a file usefull for wireshark the -s0 stops the files being shortened
  • tcpdump -i INT port 67   <– view dhcp requests
  • tcpdump -eP -nni any host 10.9.4.30 
  • tcpdump -i any  
  • tcpdump -nn


    Flags:
  • S – SYN (Start Connection)
    . – No Flag Set
    P – PSH (Push Data)
    F – FIN (Finish Connection)
    R – RST (Reset Connection)
    “ack” means acknowledge, “win” means “sliding windows”, “mss” means “maximum segment size”, “nop” means “no operation”.
    Flags are some combination of S (SYN), F (FIN), P (PUSH), R (RST), W (ECN CWR) or E (ECN-Echo),
    or a single ’.’ (no flags)
    Selective Acknowledgment Permitted (SackOK): This option simply says that selective acknowledgments are permitted for this connection. SackOK must be included in the TCP options in both the SYN and SYN/ACK packets during the TCP three-way handshake, or it cannot be used. SackOK should not appear in any other packets.
    more explanation can be found from Steven’s post – `Masterclass – Tcpdump – Interpreting Output’

    Three-way Handshake:

    The three-way handshake is simply the source host and the destination host requesting a connection, and then confirming to each other that a connection has been made. As mentioned above, to open a session a client determines a local source port and an Initial Sequence Number (ISN). The ISN is
    a randomly determined integer between 0 and 4,294,967,295. Communicating hosts exchange ISNs during connection initialization. Each host sets two counters: sequence and acknowledgement. In the context of a single TCP packet, the sequence number is set by the sending host, and the acknowledgement number is set by the receiving host.
    Host A sends a TCP SYNchronize packet to Host B
    Host B receives A’s SYN
    Host B sends a SYNchronize-ACKnowledgement
    Host A receives B’s SYN-ACK
    Host A sends ACKnowledge
    Host B receives ACK.
    TCP socket connection is ESTABLISHED.
    tcp three-way handshake,syn,syn-ack,ack
    TCP Three Way Handshake (SYN,SYN-ACK,ACK) – See more at this URL:

    Commands and Outputs Examples:

    1. ICMP Example



    [Expert@ CP1:0]#tcpdump -i Mgmt host 172.16.1.53
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on Mgmt, link-type EN10MB (Ethernet), capture size 96 bytes
    09:37:38.370763 IP 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 3, length 40
    09:37:38.372210 IP 172.16.1.53 > 10.94.20.14: ICMP echo reply, id 1, seq 3, length 40
    09:37:39.365648 IP 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 4, length 40
    09:37:39.366558 IP 172.16.1.53 > 10.94.200.14: ICMP echo reply, id 1, seq 4, length 40
    09:37:40.363506 IP 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 5, length 40
    09:37:40.364318 IP 172.16.1.53 > 10.94.20.14: ICMP echo reply, id 1, seq 5, length 40
    09:37:41.361947 IP 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 6, length 40
    09:37:41.362771 IP 172.16.1.53 > 10.94.20.14: ICMP echo reply, id 1, seq 6, length 40

    [Expert@CP1:0]# tcpdump -v -nn -i Mgmt host 172.16.1.53
    tcpdump: listening on Mgmt, link-type EN10MB (Ethernet), capture size 96 bytes
    09:38:29.232691 IP (tos 0x0, ttl 126, id 5783, offset 0, flags [none], proto: ICMP (1), length: 60) 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 7, length 40
    09:38:29.233395 IP (tos 0x0, ttl 127, id 4146, offset 0, flags [none], proto: ICMP (1), length: 60) 172.16.1.53 > 10.94.20.14: ICMP echo reply, id 1, seq 7, length 40
    09:38:30.222653 IP (tos 0x0, ttl 126, id 5788, offset 0, flags [none], proto: ICMP (1), length: 60) 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 8, length 40
    09:38:30.223565 IP (tos 0x0, ttl 127, id 4147, offset 0, flags [none], proto: ICMP (1), length: 60) 172.16.1.53 > 10.94.20.14: ICMP echo reply, id 1, seq 8, length 40
    09:38:31.220764 IP (tos 0x0, ttl 126, id 5791, offset 0, flags [none], proto: ICMP (1), length: 60) 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 9, length 40
    09:38:31.221607 IP (tos 0x0, ttl 127, id 4149, offset 0, flags [none], proto: ICMP (1), length: 60) 172.16.1.53 > 10.94.20.14: ICMP echo reply, id 1, seq 9, length 40
    09:38:32.235355 IP (tos 0x0, ttl 126, id 5795, offset 0, flags [none], proto: ICMP (1), length: 60) 10.94.20.14 > 172.16.1.53: ICMP echo request, id 1, seq 10, length 40
    09:38:32.236151 IP (tos 0x0, ttl 127, id 4152, offset 0, flags [none], proto: ICMP (1), length: 60) 172.16.1.53 > 10.94.20.14: ICMP echo reply, id 1, seq 10, length 40



    2. HTTPS Example



    [Expert@Pub-cp2:0]# tcpdump -vvv -nn -i eth1-01 host 19.26.16.19
    tcpdump: listening on eth1-01, link-type EN10MB (Ethernet), capture size 96 bytes
    11:39:04.822700 IP (tos 0x0, ttl 126, id 7241, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.19.10747 > 19.26.16.24.443: S, cksum 0xea51 (correct), 2579834556:2579834556(0) win 8192   //SYN
    11:39:04.826136 IP (tos 0x0, ttl  63, id 0, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.24.443 > 19.26.16.19.10747: S, cksum 0x99db (correct), 487537799:487537799(0) ack 2579834557 win 5840  // SYN ACK
    11:39:04.826153 IP (tos 0x0, ttl  63, id 0, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.24.443 > 19.26.16.19.10747: S, cksum 0x99db (correct), 487537799:487537799(0) ack 2579834557 win 5840  // This packet is repeated SYN ACK
    11:39:04.826926 IP (tos 0x0, ttl 125, id 7242, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.19.10747 > 10.9.1.25.443: ., cksum 0xd4d0 (correct), 2579834557:2579834557(0) ack 487537800 win 256  //ACK
    11:39:06.883076 IP (tos 0x0, ttl 125, id 7243, offset 0, flags [DF], proto: TCP (6), length: 42) 19.26.16.19.10747 > 10.9.1.25.443: P, cksum 0xb101 (correct), 0:2(2) ack 1 win 256
    11:39:06.883285 IP (tos 0x0, ttl  63, id 16050, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: ., cksum 0xf14d (correct), 1:1(0) ack 3 win 46
    11:39:07.048713 IP (tos 0x0, ttl 125, id 7244, offset 0, flags [DF], proto: TCP (6), length: 42) 19.26.16.19.10747 > 10.9.1.25.443: P, cksum 0xb0ff (correct), 2:4(2) ack 1 win 256
    11:39:07.048905 IP (tos 0x0, ttl  63, id 16051, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: ., cksum 0xf14b (correct), 1:1(0) ack 5 win 46
    11:39:07.199352 IP (tos 0x0, ttl 125, id 7245, offset 0, flags [DF], proto: TCP (6), length: 42) 19.26.16.19.10747 > 10.9.1.25.443: P, cksum 0xb0fd (correct), 4:6(2) ack 1 win 256
    11:39:07.199883 IP (tos 0x0, ttl  63, id 16052, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: ., cksum 0xf149 (correct), 1:1(0) ack 7 win 46
    11:39:07.342045 IP (tos 0x0, ttl 125, id 7246, offset 0, flags [DF], proto: TCP (6), length: 42) 19.26.16.19.10747 > 10.9.1.25.443: P, cksum 0xb0fb (correct), 6:8(2) ack 1 win 256
    11:39:07.342228 IP (tos 0x0, ttl  63, id 16053, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: ., cksum 0xf147 (correct), 1:1(0) ack 9 win 46
    11:39:07.492210 IP (tos 0x0, ttl 125, id 7247, offset 0, flags [DF], proto: TCP (6), length: 42) 19.26.16.19.10747 > 10.9.1.25.443: P, cksum 0xb0f9 (correct), 8:10(2) ack 1 win 256
    11:39:07.492407 IP (tos 0x0, ttl  63, id 16054, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: ., cksum 0xf145 (correct), 1:1(0) ack 11 win 46
    11:39:07.634867 IP (tos 0x0, ttl 125, id 7248, offset 0, flags [DF], proto: TCP (6), length: 42) 19.26.16.19.10747 > 10.9.1.25.443: P, cksum 0xb0f7 (correct), 10:12(2) ack 1 win 256
    11:39:07.635119 IP (tos 0x0, ttl  63, id 16055, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: ., cksum 0xf143 (correct), 1:1(0) ack 13 win 46
    11:39:07.635269 IP (tos 0x0, ttl  63, id 16056, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: F, cksum 0xf142 (correct), 1:1(0) ack 13 win 46
    11:39:07.635864 IP (tos 0x0, ttl 125, id 7249, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.19.10747 > 10.9.1.25.443: ., cksum 0xbe08 (correct), 12:12(0) ack 2 win 256
    11:39:07.635927 IP (tos 0x0, ttl 125, id 7250, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.19.10747 > 10.9.1.25.443: F, cksum 0xbe07 (correct), 12:12(0) ack 2 win 256
    11:39:07.636058 IP (tos 0x0, ttl  63, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 19.26.16.24.443 > 19.26.16.19.10747: ., cksum 0xf141 (correct), 2:2(0) ack 14 win 46


    3. SSH Example





    [Expert@Pub-CP1:0]# tcpdump -v -nn -i Mgmt host 172.16.1.53
    tcpdump: listening on Mgmt, link-type EN10MB (Ethernet), capture size 96 bytes
    09:46:34.443382 IP (tos 0x0, ttl 126, id 7173, offset 0, flags [DF], proto: TCP (6), length: 52) 10.9.2.14.50831 > 172.16.1.53.22: S, cksum 0xac58 (correct), 3232602545:3232602545(0) win 8192
    09:46:34.444081 IP (tos 0x0, ttl 127, id 6889, offset 0, flags [DF], proto: TCP (6), length: 52) 172.16.1.53.22 > 10.9.2.14.50831: S, cksum 0xb937 (correct), 41283738:41283738(0) ack 3232602546 win 8192
    09:46:34.444916 IP (tos 0x0, ttl 126, id 7175, offset 0, flags [DF], proto: TCP (6), length: 40) 10.9.2.14.50831 > 172.16.1.53.22: ., cksum 0x190b (correct), ack 1 win 256
    09:46:34.452567 IP (tos 0x0, ttl 127, id 6893, offset 0, flags [DF], proto: TCP (6), length: 73) 172.16.1.53.22 > 10.9.2.14.50831: P, cksum 0x1960 (correct), 1:34(33) ack 1 win 256
    09:46:34.647359 IP (tos 0x0, ttl 126, id 7180, offset 0, flags [DF], proto: TCP (6), length: 40) 10.9.2.14.50831 > 172.16.1.53.22: ., cksum 0x18ea (correct), ack 34 win 256
    09:46:35.764373 IP (tos 0x0, ttl 126, id 7184, offset 0, flags [DF], proto: TCP (6), length: 41) 10.9.2.14.50831 > 172.16.1.53.22: P, cksum 0x15e1 (correct), 1:2(1) ack 34 win 256
    09:46:35.764610 IP (tos 0x0, ttl 128, id 9109, offset 0, flags [DF], proto: TCP (6), length: 40) 172.16.1.53.22 > 10.9.2.14.50831: R, cksum 0x19f6 (correct), 41283772:41283772(0) win 0


    4. FTP Example



    [Expert@Pub-CP1:0]# tcpdump -v -nn -i Mgmt host 172.16.1.53
    tcpdump: listening on Mgmt, link-type EN10MB (Ethernet), capture size 96 bytes
    09:47:11.477696 IP (tos 0x0, ttl 126, id 30923, offset 0, flags [none], proto: TCP (6), length: 44) 10.9.2.14.50864 > 172.16.1.53.21: S, cksum 0xebe1 (correct), 2535345973:2535345973(0) win 32120
    09:47:11.479045 IP (tos 0x0, ttl 127, id 6954, offset 0, flags [DF], proto: TCP (6), length: 44) 172.16.1.53.21 > 10.9.2.14.50864: S, cksum 0x31a2 (correct), 3764401990:3764401990(0) ack 2535345974 win 8192
    09:47:11.480173 IP (tos 0x0, ttl 126, id 30925, offset 0, flags [none], proto: TCP (6), length: 40) 10.9.2.14.50864 > 172.16.1.53.21: ., cksum 0xebe6 (correct), ack 1 win 32120
    09:47:11.480858 IP (tos 0x0, ttl 127, id 6955, offset 0, flags [DF], proto: TCP (6), length: 40) 172.16.1.53.21 > 10.9.2.14.50864: ., cksum 0x695f (correct), ack 1 win 65535
    09:47:11.690070 IP (tos 0x0, ttl 127, id 6959, offset 0, flags [DF], proto: TCP (6), length: 334) 172.16.1.53.21 > 10.9.2.14.50864: P 1:295(294) ack 1 win 65535
    09:47:11.690579 IP (tos 0x0, ttl 126, id 30926, offset 0, flags [none], proto: TCP (6), length: 40) 10.9.2.14.50864 > 172.16.1.53.21: ., cksum 0xebe6 (correct), ack 295 win 31826
    09:47:13.470582 IP (tos 0x0, ttl 126, id 30933, offset 0, flags [none], proto: TCP (6), length: 46) 10.9.2.14.50864 > 172.16.1.53.21: P, cksum 0x02bf (correct), 1:7(6) ack 295 win 32120
    09:47:13.472164 IP (tos 0x0, ttl 127, id 6963, offset 0, flags [DF], proto: TCP (6), length: 81) 172.16.1.53.21 > 10.9.2.14.50864: P, cksum 0xc94d (correct), 295:336(41) ack 7 win 65529
    09:47:13.472557 IP (tos 0x0, ttl 126, id 30934, offset 0, flags [none], proto: TCP (6), length: 40) 10.9.2.14.50864 > 172.16.1.53.21: ., cksum 0xeaba (correct), ack 336 win 32079
    09:47:13.473093 IP (tos 0x0, ttl 127, id 6965, offset 0, flags [DF], proto: TCP (6), length: 40) 172.16.1.53.21 > 10.9.2.14.50864: F, cksum 0x680f (correct), 336:336(0) ack 7 win 65529
    09:47:13.473336 IP (tos 0x0, ttl 126, id 30936, offset 0, flags [none], proto: TCP (6), length: 40) 10.9.2.14.50864 > 172.16.1.53.21: ., cksum 0xea90 (correct), ack 337 win 32120
    09:47:13.489842 IP (tos 0x0, ttl 126, id 30939, offset 0, flags [none], proto: TCP (6), length: 40) 10.9.2.14.50864 > 172.16.1.53.21: F, cksum 0xea8f (correct), 7:7(0) ack 337 win 32120
    09:47:13.490369 IP (tos 0x0, ttl 127, id 6967, offset 0, flags [DF], proto: TCP (6), length: 40) 172.16.1.53.21 > 10.9.2.14.50864: ., cksum 0x680e (correct), ack 8 win 65529
    09:47:14.836964 IP (tos 0x0, ttl 126, id 19859, offset 0, flags [DF], proto: TCP (6), length: 112) 10.94.16.48.58884 > 172.16.1.53.445: P 1912308033:1912308105(72) ack 3052976289 win 258
    09:47:14.836979 IP (tos 0x0, ttl 126, id 19860, offset 0, flags [DF], proto: TCP (6), length: 112) 10.94.16.48.58884 > 172.16.1.53.445: P 72:144(72) ack 1 win 258
    09:47:14.837677 IP (tos 0x0, ttl 127, id 6970, offset 0, flags [DF], proto: TCP (6), length: 40) 172.16.1.53.445 > 10.94.16.48.58884: ., cksum 0x9ad5 (correct), ack 144 win 258
    09:47:14.837693 IP (tos 0x0, ttl 127, id 6971, offset 0, flags [DF], proto: TCP (6), length: 112) 172.16.1.53.445 > 10.94.16.48.58884: P 1:73(72) ack 144 win 258
    09:47:14.837700 IP (tos 0x0, ttl 127, id 6972, offset 0, flags [DF], proto: TCP (6), length: 112) 172.16.1.53.445 > 10.94.16.48.58884: P 73:145(72) ack 144 win 258
    09:47:14.838389 IP (tos 0x0, ttl 126, id 19870, offset 0, flags [DF], proto: TCP (6), length: 40) 10.94.16.48.58884 > 172.16.1.53.445: ., cksum 0x9a46 (correct), ack 145 win 257
    09:47:14.838843 IP (tos 0x0, ttl 126, id 19872, offset 0, flags [DF], proto: TCP (6), length: 40) 10.94.16.48.58884 > 172.16.1.53.445: R, cksum 0x9b43 (correct), 144:144(0) ack 145 win 0



    5. FTPS example



    [Expert@Pub:0]# tcpdump -v -n -i eth1-01 host 12.25.20.4
    tcpdump: listening on eth1-01, link-type EN10MB (Ethernet), capture size 96 bytes
    10:59:02.525754 IP (tos 0x0, ttl  39, id 26220, offset 0, flags [none], proto: TCP (6), length: 60) 12.25.20.4.62712 > 19.26.16.5.ftps: S, cksum 0xd8cb (correct), 1970824717:1970824717(0) win 65535
    10:59:02.526420 IP (tos 0x0, ttl 127, id 32480, offset 0, flags [DF], proto: TCP (6), length: 60) 19.26.16.5.ftps > 12.25.20.4.62712: S, cksum 0xdbb7 (correct), 2713847003:2713847003(0) ack 1970824718 win 8192
    10:59:02.570606 IP (tos 0x0, ttl  38, id 26433, offset 0, flags [none], proto: TCP (6), length: 52) 12.25.20.4.62712 > 12.17.3.59.ftps: ., cksum 0xa43c (correct), ack 2713847004 win 4096
    10:59:02.906868 IP (tos 0x0, ttl  46, id 22227, offset 0, flags [none], proto: TCP (6), length: 98) 12.25.20.4.62712 > 12.17.3.59.ftps: P 0:58(58) ack 1 win 2047
    10:59:02.908200 IP (tos 0x0, ttl 127, id 32486, offset 0, flags [DF], proto: TCP (6), length: 1476) 19.26.16.5.ftps > 12.25.20.4.62712: . 1:1425(1424) ack 59 win 261
    10:59:02.908216 IP (tos 0x0, ttl 127, id 32487, offset 0, flags [DF], proto: TCP (6), length: 245) 19.26.16.5.ftps > 12.25.20.4.62712: P 1425:1618(193) ack 59 win 261
    10:59:02.949626 IP (tos 0x0, ttl  47, id 2661, offset 0, flags [none], proto: TCP (6), length: 40) 12.25.20.4.62712 > 12.17.3.59.ftps: ., cksum 0xfe5b (correct), ack 1 win 2047
    10:59:02.968018 IP (tos 0x0, ttl  46, id 63635, offset 0, flags [none], proto: TCP (6), length: 366) 12.25.20.4.62712 > 12.17.3.59.ftps: P 58:384(326) ack 1618 win 2047
    10:59:02.972322 IP (tos 0x0, ttl  46, id 41339, offset 0, flags [none], proto: TCP (6), length: 40) 12.25.20.4.62712 > 12.17.3.59.ftps: F, cksum 0xf6c3 (correct), 384:384(0) ack 1618 win 2047
    10:59:02.972387 IP (tos 0x0, ttl  46, id 33795, offset 0, flags [none], proto: TCP (6), length: 40) 12.25.20.4.62712 > 12.17.3.59.ftps: ., cksum 0xf6c3 (correct), ack 1618 win 2047
    10:59:02.972523 IP (tos 0x0, ttl 127, id 32489, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.5.ftps > 12.25.20.4.62712: ., cksum 0x1e55 (correct), ack 386 win 260
    10:59:02.972737 IP (tos 0x0, ttl 127, id 32490, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.5.ftps > 12.25.20.4.62712: F, cksum 0x1e54 (correct), 1618:1618(0) ack 386 win 260
    10:59:03.015360 IP (tos 0x0, ttl  46, id 24500, offset 0, flags [none], proto: TCP (6), length: 40) 12.25.20.4.62712 > 12.17.3.59.ftps: ., cksum 0xf6c2 (correct), ack 1619 win 2047



    6. SQL Example 




    [Expert@Pub-CP1:0]# tcpdump -i eth1-02.104 host 172.16.1.2
    10:39:52.671997 IP 172.16.1.2.19209 > 10.9.10.252.ms-sql-s: S 3761967874:3761967874(0) win 8192
    10:39:52.673393 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19209: S 4159880273:4159880273(0) ack 3761967875 win 8192
    10:39:52.673743 IP 172.16.1.2.19209 > 10.9.10.252.ms-sql-s: . ack 1 win 256
    10:39:52.673970 IP 172.16.1.2.19209 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    10:39:52.674791 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19209: P 1:44(43) ack 48 win 256
    10:39:52.675230 IP 172.16.1.2.19209 > 10.9.10.252.ms-sql-s: P 48:151(103) ack 44 win 256
    10:39:52.675570 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19209: P 44:661(617) ack 151 win 256
    10:39:52.676104 IP 172.16.1.2.19209 > 10.9.10.252.ms-sql-s: P 151:357(206) ack 661 win 254
    10:39:52.676980 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19209: P 661:728(67) ack 357 win 255
    10:39:52.677889 IP 172.16.1.2.19209 > 10.9.10.252.ms-sql-s: P 357:714(357) ack 728 win 253
    10:39:52.680064 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19209: P 728:1141(413) ack 714 win 254
    10:39:52.681073 IP 172.16.1.2.19209 > 10.9.10.252.ms-sql-s: P 714:866(152) ack 1141 win 252
    10:39:52.681402 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19209: P 1141:1510(369) ack 866 win 253



    A problem SQL session :




    [Expert@Pub-CP1:0]# tcpdump -i eth1-02.104 host 172.16.1.2
    11:03:28.691563 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: S 3948339855:3948339855(0) win 8192
    11:03:28.692264 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19451: S 909862134:909862134(0) ack 3948339856 win 8192
    11:03:28.692795 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: . ack 1 win 256
    11:03:28.693041 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:28.998541 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:29.606984 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:30.808145 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:31.692318 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19451: S 909862134:909862134(0) ack 3948339856 win 8192
    11:03:31.692610 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: . ack 1 win 256
    11:03:32.025035 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:33.226224 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:35.628622 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:37.690075 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19451: S 909862134:909862134(0) ack 3948339856 win 65535
    11:03:37.690422 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: . ack 1 win 256
    11:03:40.449096 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: P 1:48(47) ack 1 win 256
    11:03:43.681010 IP 172.16.1.2.19451 > 10.9.10.252.ms-sql-s: F 48:48(0) ack 1 win 256                      //Finish packets
    11:03:49.690374 IP 10.9.10.252.ms-sql-s > 172.16.1.2.19451: R 909862135:909862135(0) win 0     // Reset Packets




    7. A Problem Telnet Session




    [Expert@Pub:0]# tcpdump -v -n -i eth1-01 host 19.26.16.129
    tcpdump: listening on eth1-01, link-type EN10MB (Ethernet), capture size 96 bytes
    11:17:59.759390 IP (tos 0x0, ttl 126, id 360, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.129.10329 > 19.26.16.24.telnet: S, cksum 0x8b11 (correct), 4098502333:4098502333(0) win 8192
    11:18:02.756485 IP (tos 0x0, ttl 126, id 469, offset 0, flags [DF], proto: TCP (6), length: 52) 19.26.16.129.10329 > 19.26.16.24.telnet: S, cksum 0x8b11 (correct), 4098502333:4098502333(0) win 8192
    11:18:08.760662 IP (tos 0x0, ttl 126, id 658, offset 0, flags [DF], proto: TCP (6), length: 48) 19.26.16.129.10329 > 19.26.16.24.telnet: S, cksum 0x9f20 (correct), 4098502333:4098502333(0) win 8192


    Notes: 19.26.16.24 sent three Sync packets to 19.26.16.129, but received nothing back.

    4098502333:4098502333(0) means the sending TCP stack is setting 4098502333 as the initial synchronization number (ISN), and “0” (no) data is being passed in this packet.

    Generic TCP

    Here’s a line of output related to an SSH session. Note the -v parameter has been used, without it, the IP header information and some of the TCP information is not displayed.
    22:24:18.910372 IP (tos 0×10ttl 64id 9792offset 0flags [DF], proto TCP (6)length 88)
    78.47.105.76.ssh > 82.132.219.219.55495Flags [P.], cksum 0xcb29 (correct)seq497880562:497880610ack 1593322765win 379length 48
    So, let’s break down the components (bits and octets related to the IP header);
    • 22:24:18.910372 – the datagram’s timestamp
    • IP (tos 0×10ttl 64id 9792offset 0flags [DF], proto TCP (6)length 88) – the layer three datagram’s header fields and values;
      • tos 0×10 – the IP TOS value (more correctly in the present context, the DS and ECN fields (8bit, 2nd octet)
      • ttl 64 – the IP TTL value (8bit, 9th octet)
      • id 9792 – mostly used for identifying the parts of a fragmented datagram; incremented by one with every packet sent (16bit, 5th and 6th octets)
      • offset 0 – the fragment offset, used with fragmented packets (13bits of the 7th and 8th octets)
      • flags [DF] – any IP flags set; [DF] for Don’t Fragment and [MR] for More Fragments (3bits of the 7th octet)
      • proto TCP (6) – the higher layer (four) protocol and it’s number (8bits, 10th octet)
      • length 88 – the entire IP packet length, including headers (16bits, 3rd and 4th octets)
    • 78.47.105.76.ssh – the source IP address and port
    • 82.132.219.219.55495 – the destination IP address and port
    • Flags [P.] – any TCP flags; a period ‘.‘ indicates an ACK
    • cksum 0xcb29 (correct) – the packet’s TCP checksum value
    • seq 497880562:497880610 – the TCP packet’s sequence number
    • ack 1593322765 – the TCP packet’s acknowledgement number
    • win 379 – the source host’s TCP window
    • length 48 – the TCP packet length, including headers

    Generic UDP

    It’s odd how often people don’t think they even use UDP but we all do for Voice, Video, DNS, DHCP, NTP, VXLAN and the like.
    Here’s some output related to DNS. Request without -v;
    22:54:40.769351 IP 78.47.105.76.6891 > 213.133.100.100.domain: 28642+ AAAA? vps.allenz.eu. (31)
    Response with -v, as you can see, without it the IP header information and the UDP information is not displayed;
    22:47:08.352707 IP (tos 0×0ttl 60id 1457offset 0flags [none], proto UDP (17)length 72)
    213.133.99.99.domain > 78.47.105.76.16165: [udp sum ok] 11711 ServFail q: A? 40.1.255.158.bl.tiopan.com. 0/0/0 (44)
    So, let’s break down the components of that last one;
    • 22:47:08.352707 – the datagram’s timestamp
    • IP (tos 0×0ttl 60id 1457offset 0flags [none], proto UDP (17)length 72) – the layer three datagram’s header fields and values;
      • tos 0×0 – the IP TOS value (more correctly in the present context, the DS and ECN fields (8bit, 2nd octet)
      • ttl 60 – the IP TTL value (8bit, 9th octet)
      • id 1457 – mostly used for identifying the parts of a fragmented datagram; incremented by one with every packet sent (16bit, 5th and 6th octets)
      • offset 0 – the fragment offset, used with fragmented packets (13bits of the 7th and 8th octets)
      • flags [none] – any IP flags set; [DF] for Don’t Fragment and [MR] for More Fragments (3bits of the 7th octet)
      • proto UDP (17) – the higher layer (four) protocol and it’s number (8bits, 10th octet)
      • length 72– the entire IP packet length, including headers (16bits, 3rd and 4th octets)
    • 213.133.99.99.domain – the source IP address and port
    • 78.47.105.76.16165 – the destination IP address and port
    • [udp sum ok– the datagram’s checksum status
    • Everything else relates to the DNS application response.

    Notes on the proto(col) Field

    You can find a full list of protocol number assignments here. Here’s a few more you might know;
    • ICMP (1)
    • IGMP (2)
    • GRE (47)
    • ESP (50)
    • VINES (83) 
    • EIGRP (88)
    • ETHERIP (97)
    • OSPF (89)
    • VRRP (112)
    • L2TP (115)
    • SCTP (132) 

    Notes on Service Ports

    I’m sure you all know this but anyway, valid port numbers are 0 through to 65535. If you want to live by IANA assignments (and we all should right?);
    • 0 to 1023 are reserved for well known applications
    • 1024 to 49151 are registered (with IANA) ports
    • 49152 to 65535 are user and dynamic ports (aka ephemeral or temporary)

    Protocol Formatting

    tcpdump provides data formatting for the following protocols amongst others (see Jens comments below for more information);
    • ICMP
    • ISAKMP
    • ARP
    • NTP
    • DNS
    • STP
    • HSRP
    • SNMP
    • RADIUS
    Thanks again to Jens for this: If you see ‘[|proto]‘ at the end of the verbose output, e.g. ‘[|radius]‘ the snap length is too small for the application data to be captured;. just increase it (using the -s0 parameter) to see the complete application data information.
    Here’s a few examples;
    ARP: 22:45:47.220050 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 78.47.108.52 tell 78.47.108.49, length 46
    NTP (with -v);
    78.47.105.76.ntp > 213.239.239.166.ntp: NTPv4, length 48
    Client, Leap indicator:  (0), Stratum 3 (secondary reference), poll 10s, precision -22
    Root Delay: 0.020477, Root dispersion: 0.056991, Reference-ID: 83.137.98.96
    DNS: 213.133.99.99.domain > 78.47.105.76.16165: [udp sum ok] 11711 ServFail q: A? 40.1.255.158.bl.tiopan.com. 0/0/0 (44)

    Here are some Tcpdump Scenarios from Making a Connection with tcpdump, Part II

    Scenario 1: Established Telnet Connection

    Using tcpdump we can analyze the PDUs that establish and terminate a TCP/IP connection. TCP uses a special mechanism to open and close connections. The tcpdump output below display data from different connection scenarios between host 192.168.2.10 and 192.168.2.165. The following tcpdump command and options were used to generate output:
    #tcpdump -nn host 192.168.2.165 and port 23
    Before examining the output, let’s take a detour and get a brief overview of TCP/IP connection management. This small detour will assist those individuals who are new to protocols. To guarantee a reliable connection (startup and shutdown), TCP uses a method in which three messages are exchanged. The process is called a three-way-handshake. To startup a connection:
    • The requesting Host sends a synchronization flag (SYN) in a TCP segment to create a connection.
    • The receiving Host 192.168.2.165 receives the SYN flag and returns an acknowledgment flag (ACK).
    • The requesting Host 192.168.2.10 receives the SYN flag and returns it’s own ACK flag.
    A similar handshake process is used to close a connection using a finish flag (FIN).
    To establish a connection, the sending host creates a segment containing the IP address and port number of the host it want to connect to. The segment contains a SYN flag and the sending hosts initial sequence number. Data is segmented before it is sent. The sequence numbers allow the segments to be assembled in the correct order.
    20:06:32.845356 192.168.2.10.1249 > 192.168.2.165.23:
    S 3263977215:3263977215(0) win 16384  (DF)
    The receiving hosts responds with its own SYN flag and its initial sequence number. This segment also contains an ACK flag to acknowledge the sending host’s SYN (segment 3263977215 +1). This type of acknowledgment is called expectational acknowledgment, because the receiver acknowledges the sequence number of the next segment it expects to receive.
    20:06:32.845725 192.168.2.165.23 > 192.168.2.10.1249: S
    48495364:48495364(0) ack 3263977216 win 32120 
    (DF)
    The sending host acknowledges the SYN flag from the receiving host by sending another segment containing the . and ACK flags.
    20:06:32.845921 192.168.2.10.1249 > 192.168.2.165.23: . ack 1 win 17520
    (DF)
    So far two flags, S and ., have been seen. There are five in total.
    • S: SYN (Synchronize sequence numbers – Connection establishment)
    • F: FIN (Ending of sending by sender – Connection termination)
    • R: RST (Reset connection)
    • P: PSH (Push data)
    • .: (No flag is set)

    Scenario 2: Closed Telnet Connection

    To terminate a connection, a segment containing a FIN flag is sent from host 192.168.2.165 back to the host with the open session.
    20:07:32.916410 192.168.2.165.23 > 192.168.2.10.1249: F 147:147(0) ack
    56 win 32120 (DF)
    This may appear backwards, but trust me, it’s not. Think of where the session is open–this is the point that is asking to close the connection. Host 192.168.2.10 acknowledges the FIN segment.
    20:07:32.916680 192.168.2.10.1249 > 192.168.2.165.23: . ack 148 win
    17374 (DF)
    Then host 192.168.2.10 terminates it connection by sending a segment containing a FIN flag.
    20:07:32.928907 192.168.2.10.1249 > 192.168.2.165.23: F 56:56(0) ack 148
    win 17374 (DF)
    Host 192.168.2.165 acknowledges the segment.
    20:07:32.929121 192.168.2.165.23 > 192.168.2.10.1249: . ack 57 win 32120
    (DF)
    Scenario 3: Telnet Connection Refused (no service offered at the host)
    To establish a connection, host 192.168.2.10 sends a segment containing the IP address and port number of the host it want to connect to. The segment contains a SYN flag and the sending hosts initial sequence number.
    05:28:00.080798 192.168.2.10.1063 > 192.168.2.165.23:
    S 3034008467:3034008467(0) win 16384  (DF)
    Host 192.168.2.165 acknowledges the SYN from host 192.168.2.10 by sending another segment containing the R (connection reset) and ACK flags.
    05:28:00.080979 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0)
    ack 3034008468 win 0 
    Host doesn’t take no for answer and tries again.
    05:28:00.579420 192.168.2.10.1063 > 192.168.2.165.23: S
    3034008467:3034008467(0) win 16384  (DF)
    But it receives the same result from receiving host.
    05:28:00.579524 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 1 win
    0
    A final attempt is made to establish a connection.
    05:28:01.080114 192.168.2.10.1063 &glt; 192.168.2.165.23: S
    3034008467:3034008467(0) win 16384  (DF)
    Only three strikes in this ball game. Sending host gives up.
    05:28:01.080225 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 1 win
    0
    Compare the outputs from an Establish Telnet Connection scenario and Telnet Connection Refusal scenario. The outputs from the receiving host are different. For the Telnet Connection Refusal scenario, the Telnet service was turned off at the receiving host using the /etc/inetd.conf file. If the service is not available, no connection can be established. Note to self: simple security measures turn off services not being used.

    Scenario 3: Telnet Connection Refused (tcp wrappers security used at host)

    The same opening as before is used to establish a connection.
    05:40:39.838710 192.168.2.10.1064 > 192.168.2.165.23: S
    3223709294:3223709294(0) win 16384  (DF)
    The receiving host responds with its own SYN flag and its initial sequence number. This segment also contains an ACK flag to acknowledge the sending hosts SYN (segment 3223709294 +1).
    05:40:39.839045 192.168.2.165.23 > 192.168.2.10.1064: S
    063202536:2063202536(0) ack 3223709295 win 32120 1460,nop,nop,sackOK> (DF)
    Host 192.168.2.10 acknowledges the SYN from host 192.168.2.165 by sending another segment, which contains the . and ACK flags.
    05:40:39.839295 192.168.2.10.1064 > 192.168.2.165.23: . ack 1 win 17520
    (DF)
    Host 192.168.2.165 responds with a segment containing a FIN flag–connection terminated. Something has told the receiving host no connection is allowed.
    05:40:44.852844 192.168.2.165.23 > 192.168.2.10.1064:
    F 1:1(0) ack 1 win 32120 (DF) 
    Host 192.168.2.10 has a no-flag-set second acknowledgment.
    05:40:44.853137 192.168.2.10.1064 > 192.168.2.165.23: . ack 2 win 17520
    (DF)
    Because a FIN flag segment was received, the connection must be terminated. So host 192.168.2.10 sends a FIN flag to terminate the connection.
    05:40:44.855050 192.168.2.10.1064 > 192.168.2.165.23: F 1:1(0) ack 2 win
    17520 (DF)
    Host 192.168.2.165 responds with a segment acknowledgment.
    05:40:44.855176 192.168.2.165.23 > 192.168.2.10.1064: . ack 2 win 32120
    (DF)
    Compare the outputs from an Establish Telnet Connection scenario and Telnet Connection Refusal (tcp wrappers) scenario. The outputs from the receiving host are different. In the Telnet Connection Refusal (tcp wrappers) scenario, tcp wrappers is enabled by adding the following line to the /etc/hosts.deny file: ALL:192.168.2.10. This means “deny all services to this host with address 192.168.2.10”. A similar connection test was done using a rule in iptables firewall. The resulting output was the same.
    The reader may gain some insight into how systems are at risk from the trappings of tcpdump. Before a system hack is possible, some effort is expended to engineer the hack. An examination of the data from a system can provide the hacker with some insight into where efforts might provide the greatest chance of success.

    Scenario 4: No Telnet Connection (host removed from the network)

    Same opening, different scenario.
    05:55:21.557846 192.168.2.10.1065 > 192.168.2.165.23: S
    3443876657:3443876657(0) win 16384  (DF)
    There’s no response, so the sending host tries the same request again.
    05:55:24.560891 192.168.2.10.1065 > 192.168.2.165.23: S
    3443876657:3443876657(0) win 16384  (DF)
    With still no response on the third try, the three-strike rule comes into effect. The sending host abandons the connection attempt.
    05:55:30.569584 192.168.2.10.1065 > 192.168.2.165.23: S
    3443876657:3443876657(0) win 16384  (DF)

    Reference:

    NetSec Youtube Videos