This recipe shows how to determine which process or application uses a TCP connection which you saw listed in your netstat output. The exampe below is for Linux. Windows is further down in the post:
In this example, I have a small ARM Linux device being remotely managed via the “Dataplicity” service. To use the service you install a script which runs on startup. It seems that the script sets up an SSH connection from the managed ARM device to the dataplicity server, so that when you login to their Admin portal and choose the “terminal” option, you access the Linux terminal which is already setup.
The netstat output shows a session outbound from the ARM machine (10.10.0.126) to the dataplicity server (96.126.99.204) on TCP/443 (SSL):
root@raspberrypi:/# netstat -an | grep ‘:443’
tcp 0 48 10.10.0.126:46098 96.126.99.204:443 ESTABLISHED
the next step is to find which process(es) use the (source) TCP port 46098:
Read more…
Any non-tmsh command you use in the HMS bash shell (like free) will generally only relate to the HMS. This is why there is an apparent discrepancy between the tmsh “show system memory” command and the Linux “free” command: Read more…
This describes a problem whereby a client connects to a server then waits for a report to complete before retrieving it. The report took longer than 5 minutes to complete and the TCP session remained idle whilst the client waited. After a while the TCP connection dropped.
Packet traces were taken at the client, server and intermediate points, which included an F5 load balancer which simply acted as a router. The analysis of the packet traces revealed some interesting things..
What was happening was that the TCP 3-way handshake completed to setup the TCP session. Then the client sends an HTTP GET requestor method (of TCP segment length 734 bytes) to submit the data, which is then received by a client-side firewall. The firewall then forwards it onwards towards the server in the direction of an F5 load balancer …
BUT: The HTTP GET doesn’t seem to arrive at the F5. The server-side firewall however, DID receive the GET and forwards it onto the application server, which then sends back an ACK to the client – which DOES go via the F5. Huh?
It was initially thought that the The F5 therefore saw an ACK packet for a TCP segment that it hasn’t seen, so it sends a RST packet in both directions to tear down the TCP session. This is a little confusing because the TCP session goes through the F5 but the HTTP GET request seemingly bypasses the F5 but does arrive at the server. After a bit of head-scratching and furrowed brows because it made no sense. The delay. The fact that there clearly wasn’t any asymmetry anyway because the ACK came back via the same path. So why the reset? Read more…
nMap uses a list of “default” applications in the nmap services file, used to list services running on scanned open ports. To see the “real” application execute nMap using the “-sV” option. Read more…
There is a field in each TCP segment called the “receive window”. The receiver is essentially signalling the amount of data that it can accept, or is willing to accept. This post describes the metrics and overhead.
The overhead is: window/2^tcp_adv_win_scale (tcp_adv_win_scale default is 2) So for linux default parameters for the recieve window (tcp_rmem):
87380 – (87380 / 2^2) = 65536. Read more…
This script is a simple, interactive way to backup and date-stamp your juniper Netscreen ISG/SSG (ScreenOS) firewall configurations. The script copies the configurations from the firewall using scp. Configurations older than one day ( -mtime +1) are archived off to a bz2 compressed file. Archives older than 60 days ( -mtime +60 ) are removed from the disk.
The usage is: nsb.sh [ip address / hostname of Netscreen]. (VIEW SCRIPT)
Read more…
An aide-memoir:
ScreenOS-> undebug all
ScreenOS-> clear db Read more…
The entries in the /proc/meminfo can help explain what’s going on with your memory usage, if you know how to read it.
Example of “cat /proc/meminfo”:
root: total: used: free: shared: buffers: cached:
Mem: 1055760384 1041887232 13873152 0 100417536 711233536
Swap: 1077501952 8540160 1068961792
Read more…
Another aide-memoir:
daren@Shimla:~$ sudo apt-get install wireshark
[sudo] password for daren:
Reading package lists… Done Read more…
An aide-memoir from practicing iproute2, the utilities used to control TCP/IP networking and Linux Traffic Control
“ip link list” – shows us our links
[Daren@home Daren]$ ip link list
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc pfifo_fast qlen 100
link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
link/ppp
Read more…
