Note: tumpdump(1) may require a privileged user to access certain ports
Created Thursday 2/8/2007
This document is a unix-flavour independent look at networking. Platform-specfic differences are highlighted where appropriate. In general, most of the foonix documentation has a lean to RHEL/FC Linux.
This is pretty trivial and can be done with ifconfig(1). However, this is not always guaranteed and it may be possible that the host being communicated with (e.g., a dhcp server) may determine that the specified mac address is not as advertised.
bash # ifconfig eth0 down bash # ifconfig eth0 hw ether 00:00:00:00:00 bash # ifconfig eth0 up
Networking configuration differs from unix platform to unix platform. However, all unix implementations perform network config via simple text files, which are typically located, for Linux variants, in:
Some Linux platforms provide configuration ui's, which make the network configuration pretty straight forward. For example, RHEL/Fedora Core provide:
bash # system-config-network
The simplest way to release active interfaces (and any ip assigned via dhcp) is to use the init.d script network. For RHEL/Fedora Core (and infact most unix implementations), this can be done with:
bash # /etc/init.d/network restart
The dns configuration for most Linux variants is specified in /etc/resolv.conf. Some Linux implementations will copy this configuration from the active network profile directory. E.g., if a profile called default is active, then resolv.conf is copied from /etc/sysconfig/networking/profiles/default/resolv.conf to /etc/resolv.conf when a network interface is brought up. For Commerical Union, the DNS entries are:
search cu.com.pl nameserver 89.1.1.15 nameserver 89.1.1.25 nameserver 89.1.1.48
If the network transfer is reporting a slow transfer rate (e.g., 10Mbs on 100Mbs or 1GB link), then the issue is likely to be related to the receive buffer auto-tuning changes introduced in kernels > 2.6.7. This problem can be resolved by turning off receive buffer auto-tuning, also called tcp window scaling. The base install of Fedora reports:
Kernel 2.6.8
bash # sysctl net.ipv4.tcp_default_win_scale bash # net.ipv4.tcp_default_win_scale = 7
Kernel 2.6.9
bash # sysctl net.ipv4.tcp_window_scaling bash # net.ipv4.tcp_default_win_scale = 1
and:
bash # sysctl net.ipv4.tcp_moderate_rcvbuf bash # net.ipv4.tcp_moderate_rcvbuf = 1
For kernel 2.6.8 and less, turn these kernel parameters off with:
bash # sysctl -w net.ipv4.tcp_moderate_rcvbuf=0 bash # sysctl -w net.ipv4.tcp_default_win_scale=0
For kernel 2.6.9 and more, turn these kernel parameters off with:
bash # sysctl -w net.ipv4.tcp_moderate_rcvbuf=0 bash # sysctl -w net.ipv4.tcp_window_scaling=0
So, with the receive buffer auto-tuning on, the link speed reports a transfer rate as follows, using scp(1):
bash $ scp foo@bumerang:/tmp/c /tmp c 9% 48KB 11.9KB/s 00:38 ETA
And with the receive buffer auto-tuning off:
bash $ scp foo@bumerang:/tmp/c /tmp c 100% 513KB 10.3MB/s 00:00
References: linux-net (www.linuxarkivet.se) Notes:
The sysctl commands above can also be done with man?cat and [[echo(1)|man?echo[[ to /proc/sys/net/ipv4, e.g.,:
bash # echo 0 > /proc/sys/net/ipv4/tcp_moderate_rcvbuf bash # echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
The ether-wake tool can be used to send a WOL packet. It needs to run as a privileged user and the MAC address of the machine to wake must be known. Also appending the IP address as the password packet, is required. E.g., waking the host at IP 192.168.1.100, whose network card has the MAC address 00:09:6B:BD:37:16 can be done with:
bash# ether-wake 00:09:6B:BD:37:16 -D -p 192.168.1.100
Use the man?route(8) to print, add or delete static network routes. Executing the route(8) command with no args, e.g.,:
bash$ route
will print the current routing table. To create a static route that sends all outbound traffic for any host attached the loopback interface off to the localhost:
bash# route add -net 127.0.0.0 netmask 255.0.0.0 dev lo gw 127.0.0.1
To remove the above:
bash# route del -net 127.0.0.0 netmask 255.0.0.0 dev lo gw 127.0.0.1
Note: tumpdump(1) may require a privileged user to access certain ports
it is possible to use tcpdump(1) can be used to listen to traffic and can be configured in a variety of ways. E.g., to listen to all traffic going over eth0 on port 123:
bash# tcpdump -ni eth0 port 123
Often portforwarded traffic is sent over a port on the localhost which is then tunnelled via ssh to some remote destination. For example, a tunnel might be configured to access a remote perforce server. To listen to perforce traffic tunelled over the localhost's 1666 port (which might be forwarded to 1666 remote.host.com):
bash# tcpdump -ni lo host localhost and port 1666
Any number of conditions can be specified with tcpdump. These can be combined using the and and or operators. Parenthesis are used to group operators. For example, to monitor traffic comming from or going to ports 22 or 23 on foo.com over interface ppp0 (note, the parenthesis may need to be escaped from the shell):
bash# tcpdump -ni ppp0 host foo.com and \(port 22 or port 23\)
The following shows an outbound request (the first line) and a response (second line). The from the output we see that the first request is initiated from port 57570 on "localhost" and is sent to port 1666 on localhost. The sent packet is an IP packet. The response packet is sent from port 1666 on localhost to port 57570 on localhost. The response packet is also an IP packet.
bash# 23:03:51.857487 IP localhost.localdomain.57570 > localhost.localdomain.1666: S 1084976661:1084976661(0) win 32767 <mss 16396,sackOK,timestamp 169992198 0,nop,wscale 2> bash# 23:03:51.857849 IP localhost.localdomain.1666 > localhost.localdomain.57570: S 1085342427:1085342427(0) ack 1084976662 win 32767 <mss 16396,sackOK,timestamp 169992198 169992198,nop,wscale 2>
The network traffic packets printed by tcpdump(1) can be quite lengthy, as shown in 7.B above. By default, each printed packet includes a timestamp value and extended packet information which shows tcp sequence numbers. Much of this information is typically not required for simple diagnostics such as "is the host receiving my packets and responding?". The -t option, for surpessesing timestamps and the -q, for print less protocol info can, be quite useful. The same tcpdump(1) query as in 7.B but with brief output can be specified with:
bash# tcpdump -tq -i lo host localhost and \(port 1666\) listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes IP localhost.localdomain.48823 > localhost.localdomain.1666: tcp 0 IP localhost.localdomain.1666 > localhost.localdomain.48823: tcp 0
As in the output of 7.B, the first 2 lines show an outbound request and it's associated response. The outbound packet is sent from localhost over port 48823 to localhost's port 1666. The response is from localhost's 1666 to localhost's port 48823.
A unidirectional traffic analysis can be performed using the dst keyword in the tcpdump(1) expression. Using the same example as from 7.B and 7.C, we can specify that just packets being sent to port 1666 are captured. This in effect will ignore the response traffic as, clearly, the destination port for response will be sent back to the initiating port. The dst keyword can be applied to both port and host. The converse to dst is src.
The following example captures traffic over the loopback, sent to port 1666. For convienience, the results are limited to brief output. The first 4 sent packets are shown:
bash# tcpdump -tq -i lo host localhost and dst port 1666 listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes IP localhost.localdomain.38968 > localhost.localdomain.1666: tcp 0 IP localhost.localdomain.38968 > localhost.localdomain.1666: tcp 0 IP localhost.localdomain.38968 > localhost.localdomain.1666: tcp 64 IP localhost.localdomain.38968 > localhost.localdomain.1666: tcp 208
There are several ways to try and detect the type and version of a remote OS. A simple solution is to use nmap(1). Another possibility is to man?grep for the server content from an http request:
bash $ echo 'GET / HTTP/1.0\n\n' | nc bund.com.au 80 | egrep '^Server:'
Stuart Moorfoot © 2 August 2007 foo@bund.com.au