Wednesday, August 24, 2011

iperf tool for tcp and udp traffic generations


TCP Uplink

CONSOLE:
iperf -s -i 1

STA:
iperf -c [-t 90] -i 1
-------------------------------------
TCP Downlink

CONSOLE:
iperf -c [-t 90]

STA:
iperf -s -i 1
-------------------------------------
Multicast

iperf -c 225.0.0.1 -u -b 80k 92 -i 1

iperf -s -u -b 225.0.0.1 -i 1

Tuesday, August 23, 2011

Are URLs on your servers "case sensitive"?


No, our Web servers do not treat URLs as being case sensitive. This means that your visitors won't see an error page if they follow a link that accidentally points to a file named "mypage.html" on your Web site if the file is actually named "MyPage.html": they'll see the "MyPage.html" file, just as you would expect.
However, there's a little more to it than that. The sections below have more details.

Some background information

We should first explain exactly what we mean by "case sensitive URLs". Some Web servers (usually Unix servers, such as the ones we use) consider URLs to be case-sensitive. That is, they would treat each of the following URLs as referring to a different file:
http://www.example.com/mypage.html
http://www.example.com/MyPage.html
http://www.example.com/MYPAGE.html
http://www.example.com/MYPAGE.HTML
If you visited "http://www.example.com/mypage.html" but the file was actually named "MyPage.html", these kinds of servers would display a "file not found" error.
Other Web servers (mostly Windows servers) would treat all these URLs as requests for the same file, because they use a file system that doesn't care about capitalization. Using an incorrectly capitalized link on these kinds of servers doesn't cause an error.
It's best to avoid this problem by making sure that the capitalization of any URL links matches the capitalization of your file names, ensuring that your files work on any kind of server. However, if you have an existing site, these errors can be difficult to find.

So do these kinds of links work on Tiger Technologies servers?

Yes. Our servers use special software that makes links work even if they contain capitalization errors. In other words, although we use Unix servers for reliability, our servers treat URLs in the same forgiving fashion as Windows servers.
That means that if you're transferring your Web site from a Windows server to Tiger Technologies, you don't need to worry about fixing the capitalization of links to avoid "file not found" errors. If your file is named "MyPage.html" and you have a link referring to "mypage.html", it will work, just as it did on a Windows server.
That's not to say that you shouldn't try to make your links match your file names. For technical reasons, pages that are accessed through miscapitalized links take a little more time to load. The delay is only a few milliseconds, but every little bit helps.

Some technical details

Advanced users may be interested in knowing how URLs can be case insensitive even though Unix servers use a case-sensitive file system. The answer is that we use an Apache Web server module called "mod_speling" (sic), which "fixes" URL requests that don't exactly match an existing file. We have mod_speling configured to look for matches that differ only in terms of case, which almost always "does the right thing".
We should mention that there is a (quite rare) potential issue when relying on mod_speling to fix miscapitalized links, which is that mod_speling does not change the fact that the actual file system can still allow files with different capitalization to exist simultaneously. This can cause subtle problems if you mistakenly upload two files with names that differ only in capitalization.
For example, if you upload a file named "mypage.html", then later upload a file named "MyPage.html", both files will exist on the disk, just as they would on any Unix server. The second upload will not replace the first file as it would on a Windows server. If you then use a link named "mypage.html", you're always going to see "mypage.html", even though you might be expecting to see the new "MyPage.html" file you more recently uploaded. Stranger still, if you use a link that doesn't match either file — say, "MYPAGE.HTML" — you'll appear to get one of the files at random. Again, just make sure that your link capitalization matches the file names you upload to avoid any potential problems.

Thanks to :
http://support.tigertech.net/case-sensitive

How ARP Works

How ARP Works

This article is based off of a series of usenet posts (one in particular) on the alt.certification.network-plus news group. I've done some revision in order to make the whole thing flow as a stand-alone document and I've also made some revisions to the example.

What is ARP?

ARP stands for Address Resolution Protocol. It is used to associate a layer 3 (Network layer) address (such as an IP address) with a layer 2 (Data Link layer) address (MAC address).

Layer 2 vs. Layer 3 addressing

I think where a lot of confusion with ARP comes from is in regards to how the IP address and the MAC address work together. The IP address is a layer 3 (network layer) address. The MAC address is a layer 2 (data link) address. The layer 3 address is a logical address. It will pertain to a single protocol (such as IP, IPX, or Appletalk). The layer 2 address is a physical address. It pertains to the actual hardware interface (NIC) in the computer. A computer can have any number of layer 3 addresses but it will only have 1 layer 2 address per LAN interface. At layer 3, the data is addressed to the host that the data is destined for. At layer 2 though, the data is addressed to the next hop. This is handy because you only need to know a host's layer 3 address (which can be found out by using DNS for instance) but you won't need to know the hardware address (and you won't have to bog down the network by sending an ARP request across the internet to find it out). The layer 3 packet (addressed to the destination host) will be encapsulated within a layer 2 frame (addressed to the next hop).

ARP operation for a local host

Your computer will have data that it needs to send (I'm assuming that we're using TCP/IP from here on). When the data gets to the Network layer it will put on the destination IP address. All of this info (the network layer datagram, aka packet) is passed down to the data link layer where it is taken and placed within a data link frame. Based on the IP address (and the subnet mask), your computer should be able to figure out if the destination IP is a local IP or not. If the IP is local, your computer will look in it's ARP table (a table where the responses to previous ARP requests are cached) to find the MAC address. If it's not there, then your computer will broadcast an ARP request to find out the MAC address for the destination IP. Since this request is broadcast, all machines on the LAN will receive it and examine the contents. If the IP address in the request is their own, they'll reply. On receiving this information, your computer will update it's ARP table to include the new information and will then send out the frame (addressed with the destination host's MAC address).

ARP operation for a remote host

If the IP is not local then the gateway (router) will see this (remember, the ARP request is broadcast so all hosts on the LAN will see the request). The router will look in it's routing table and if it has a route to the destination network, then it will reply with it's own MAC address.
This is only the case if your own computer doesn't know anything about the network topology. In most cases, your computer knows the subnet mask and has a default gateway set. Because of this, your own computer can figure out for itself that the packet is not destined for the local network. Instead, your computer will use the MAC address of the default gateway (which it will either have in it's ARP table or have to send out an ARP request for as outlined above). When the default gateway (router) receives the frame it will see that the MAC address matches it's own, so the frame must be for it. The router will un-encapsulate the data link frame and pass the data part up to the network layer. At the network layer, the router will see that the destination IP address (contained in the header of the IP packet) does not match it's own (remember, the IP address has not been touched at all in this process since your computer created the IP packet). The router will realise that this is a packet that is supposed to be routed. The router will look in it's routing table for the closest match to the destination IP in order to figure out which interface to send the packet out on. When a match is found, the router will create a new data link frame addressed to the next hop (and if the router doesn't know the hardware address for the next hop it will request it using the appropriate means for the technology in question). The data portion of this frame will contain the complete IP packet (where the destination IP address remains unchanged) and is sent out the appropriate interface. This process will continue at each router along the way until the information reaches a router connected to the destination network. It will see that the packet is addressed to a host that's on a directly connected network (the closest match you can get for an address, short of the packet being addressed to you). It will send out an ARP request for MAC address of the destination IP (assuming it doesn't already have it in it's table) and then address it to the destination's MAC address.
Now then, I did slightly gloss over 1 part in the above explanation and that's the part about the router finding out the hardware address for the next hop. I just didn't want to disturb the flow with entering into that there. How the router does this will depend on what type of connection (and in some cases, what protocol and/or encapsulation is used on the connection). In some cases, this will be a hard set value (like a frame relay pvc) within the configuration of the router. In some cases, you don't even need a hardware address (like any point to point connection, there's only 1 possible host you could send it to), in those cases the router will just create a data link frame appropriate for the connection and it won't even need to be addressed. This is why the OSI model is good. It's layered so that any layer can change and as long as it takes in information in a standard way (the way the layer above wants to send it) and spits out information in a standard way (the way the layer below wants to receive it), then it's all good. When Frame Relay came along nothing changed with the way you had to address IP packets, all of the changes took place at the data link and physical layers. If some new type of connection comes along in the future, only the data link and physical layers will likely change. When we go to IPv6, only the network layer should change (it probably won't but that's more to do with how the layers tend to blur, but if it were truly layered that would be the case).

Putting it all together

Anyways, since I feel like doing an example here's one showing the whole process. In the original post, I had used IP addresses from the 10.x.x.x range (which is a reserved range for private networks) with a subnet mask of 255.255.255.0. This seemed to cause some confusion (both because of the misconception that the 10.x.x.x range is non-routable and because I was using a class C subnet mask for a class A network) both of these are valid and would work but I've decided to change this so that I'm using non-reserved (ie, real) IPs from class C networks. I figure that this will help reduce the confusion in this example, and I can clear up the rest in another article or 2. Needless to say then, if you want to try this on your own network, don't connect it to the internet! IP conflicts are just plain evil and can screw up lots of stuff. If you want to try this in a home lab that is connected to the internet then put the whole network behind some kind of a firewall and use the reserved IPs. Or, if you're lucky enough to have a block of real IPs, use them. The bottom line is don't use IPs that haven't been assigned to you on the internet.
Your computer has an address of 200.0.1.2, it's connected to the 200.0.1.0 network (I'm assuming a subnet mask of 255.255.255.0, we'll call this network 1) which is an ethernet network. Your default gateway is a router (router a) which has an address of 200.0.1.1. That router is connected to the 200.0.1.0 network and the 200.0.2.0 (network 2) network (the interface connected to the 200.0.2.0 network will have an address of 200.0.2.1). The network 2 is also an ethernet network. Also connected to network 2 is another router (router b) which has the address (for the interface connected to network 2 at least) of 200.0.2.2. Router b is also connected to network 3 (200.0.3.0). Router b's interface on network 3 has the address of 200.0.3.1. Here's a (probably bad) ASCII diagram to illustrate:
Router        Router
           a             b
-----------O-------------O------------
Network 1    Network 2       Network 3
(200.0.1.0)   (200.0.2.0)      (200.0.3.0)
Now then, your computer (on network 1 with an address of 200.0.1.2) wants to send some data to a computer on network 3 (with an address of 200.0.3.2). We'll assume that none of the info in already cached in an ARP table on any of the machines or routers (a big assumption but it's mine to make!). Your computer will create an IP packet addressed to 200.0.3.2. That packet will be sent to the data link layer where it needs a MAC address. Based on the subnet mask, your computer will know that the destination computer isn't on the same local network. So, your computer will send out an ARP request for the default gateway's MAC address (ie, what's the MAC for 200.0.1.1?). On receiving the MAC address, your computer will send out the IP packet (still addressed to 200.0.3.2) encapsulated within a data link frame that is addressed to the MAC address of router a's interface on network 1 (because routers have more than 1 interface they can have more than 1 MAC address, in this case each router has 2 ethernet interface each with it's own unique MAC address). Router a will receive this frame and send the data portion up to the network layer (layer 3). At the network layer, router a will see that the packet (which is addressed to 200.0.3.2) is not addressed to router a. Router a will look in it's routing table to find out where to send the packet. The routing table will show that network 3 (the closest match to 200.0.3.2) is reachable via network 2. The routing table will also show the IP address for the next hop is 200.0.2.2. Router a will send out an ARP request onto network 2 asking for router b's MAC address (well at least for the interface connected to network 2). On receiving this, router a will send the IP packet (still addressed to 200.0.3.2, nothing's changed here) encapsulated in a data link frame addressed to router b's MAC address. When router b receives this frame it will do the same thing that router a did, it will send the IP packet up to the network layer and see that the packet is not addressed to router b (the packet is still addressed to 200.0.3.2). Router b will then look up in it's routing table for the closest match and see that it is directly connected to network 3, so there isn't a next hop router to send it to. Router b will send out an ARP request to learn the MAC address for 200.0.3.2. When this is received, router b will send out the IP packet (again, this is still addressed to 200.0.3.2) encapsulated within a data link frame that is addressed to the MAC address of the destination computer. The destination computer will see that the data link frame is addressed to it and will pass the IP packet to the network layer. At the network layer, the IP address will also match that of the computer and the data from the IP packet will be passed up to the transport layer. Each layer will examine the header and determine where to pass it up to until eventually, the data reaches the application running on the destination computer that has been waiting for the data.
What you'll notice through this whole process is that the IP address never changes. The IP packet is always addressed to 200.0.3.2. However, at the data link layer, the address used changes at each hop (it's always addressed to the next hop). As you go up through the layers, you get more and more specific about where the data is supposed to be going. At the data link layer this is very vague, it's basically just, "here's who to pass it on to, they should know what to do with it". At the network layer you get more specific (this is the exact computer I want to send this to). Above that you get more specific (is it TCP or UDP?, what port?, etc)

Thanks to :
http://www.tildefrugal.net/tech/arp.php

TCP/IP: The Three-way handshake

TCP/IP: The Three-way handshake
myline
Each and every communication through TCP starts with a procedure called three-way-handshake. Here I'm going to illustrate the process for future reference --- for myself.



three-way-handshake

Here client is shown as active participant and server is shown as passive participant because client initiates (active) a connection to a server which waits (passive) for connetions on a particular port.
The three-way handshae is done in the following process:

  1. The client sends a SYN packet to the server indicating that it wants to set a TCP connection. It also sends ISN (Initial Sequenc Number). Here ISN is x.
  2. If the server is 'alive' and listening on the requested port and can accept an incoming connection, it replies with its own SYN + ACK packet. It sends its own ISN (Initial Sequence Number) (for this connection, y ) and acknowledges the clients request by sending back client's ISN + 1 sequence number (x + 1) .
  3. Finally, after receiving the server's SYN + ACK response, the client sends back an ACK packet with a sequence number of server's ISN + 1 (y + 1) .
Now this is all theory! Let's see whether we can observer a real TCP connection and whether we can identify the three-way-handshake process. We'll be using tcpdump to observe the process. Commands used to capture the TCP communication is:

tcpdump -n -S -t
Here, -n don't convert addresses (i.e., host addresses, port numbers,
	    etc.) to names.
	 -S print absolute, rather than relative, TCP sequence numbers.
	 -t don't print timestamp.
    
192.168.1.12.1051 > 192.168.1.11.23: S 4255483971:4255483971(0) 
                              win 65535  (DF)
    192.168.1.11.23 > 192.168.1.12.1051: S 4279842714:4279842714(0) 
	                           ack 4255483972 win 32120  (DF)
    192.168.1.12.1051 > 192.168.1.11.23: . ack 4279842715 win 65535 (DF)
	 
  1. First line: someone on client (192.168.1.12) is connecting to port 23 (telnet) of server (192.168.1.11). We can see that SYN flag is set (S), followed by:
    4255483971:4255483971(0)

    Here, 4255483971(=x) is the ISN (Initial Sequence Number) and it apears twice separated by ':' because there's no payload (0 in parentheses indicates this).

    win 65535 indicates that the client has a buffer that can hold 65535 bytes.

    mss 1460 indicates that the network on which the client exists can accept a maximum of 1460 bytes payload in a single packet. mss stands for maximum segment size .

    requests that the packet shouldn't be fragmented.

    Interesting fact: though the client has a buffer that can accept 65535 bytes of data, the network cannot accept more than 1460 bytes of payload.
  2. Second line: server replies with a SYN and ACK flagged packet. It also sends its ISN (4279842714=y) and acknowledge number (clinet's ISN + 1 = 4255483972).

    Server's window size is 32120 and maximum segment size is 1460.
  3. Third line: client sends back acknowledgement packet with a sequence number of 4279842715 (server's ISN + 1 = 4279842715).

    Note that this packet has no flag set (`.' indicates that no flags were set).
 Thanks to:
http://www.reocities.com/jchakma/TCPIP/ThreeWayHandshake.html

Wednesday, August 17, 2011

7zip File: How to Uncompress 7z files on Ubuntu, Debian, Fedora


Question: How do I uncompress a *.7z file ( 7zip file ) in UNIX / Linux ? Can you explain with a simple example? Answer: Use 7za command to unzip a 7z file ( 7zip file ) on Unix platform as shown below.

Verify whether you have 7za command on your system.
# whereis 7za
7za: /usr/bin/7za /usr/share/man/man1/7za.1.gz
If you don’t have 7za command, install p7zip package as shown below.

Install p7zip to unzip *.7z files on Fedora

# yum install p7zip

Install p7zip to unzip *.7z files on Debian and Ubuntu

$ sudo apt-get install p7zip

Uncompressing a *.7z 7zip files in Linux using 7za

$ 7za e myfiles.7z 

7-Zip (A) 9.04 beta  Copyright (c) 1999-2009 Igor Pavlov  2009-05-30
p7zip Version 9.04 (locale=C,Utf16=off,HugeFiles=on,1 CPU)

Processing archive: ../../myfiles.7z

Extracting  myfiles/test1
Extracting  myfiles/test2
Extracting  myfiles/test
Extracting  myfiles

Everything is Ok

Folders: 1
Files: 3
Size:       7880
Compressed: 404
  • 7za – command name
  • e – specifies the 7z to be extracted
  • myfiles.7z – is the file that is to be extracted

Creating a 7zip compression file in Linux

$ 7za a myfiles.7z myfiles/

7-Zip (A) 9.04 beta  Copyright (c) 1999-2009 Igor Pavlov  2009-05-30
p7zip Version 9.04 (locale=C,Utf16=off,HugeFiles=on,1 CPU)
Scanning

Creating archive myfiles.7z

Compressing  myfiles/test1
Compressing  myfiles/test2      

Everything is Ok
Files and sub directories of myfiles/ will be added to the myfiles.7z.
  • a – add to archive
  • file.7z – archive file to which these files and dir from dir1 will be added to.

Extracting 7z Files in Linux

Download

The first thing you will need to do is download the p7zip program.
Ubuntu users can do this by typing the following command:
sudo apt-get install p7zip

Extracting

To extract the file just type:
p7zip -d filename.7z
If you are using gnome you should also be able to right click on the file and select extract here.
right-click-7zip
7zip files have great compression ratios and often times offer higher compression than RAR, ZIP and other formats. Enjoy!

Tuesday, August 16, 2011

Install Application of Ubuntu Restricted Extras

Application: Ubuntu Restricted Extras

What it is:

While not strictly an application in the true sense, Ubuntu Restricted
Extras takes care of a number of software and codecs that other Ubuntu
applications may require and that cannot be shipped with Ubuntu for
legal reasons.

To install in Ubuntu:

sudo apt-get install ubuntu-restricted-extras

This will install Java, Flash, some proprietary fonts and a bunch of
codecs, enabling you to view most video files and play your favorite
audio formats and a lot more essential software that you may not use
directly but is important all the same.

To know more about:

https://help.ubuntu.com/community/RestrictedFormats