Difference between revisions of "Ethereal"
| (14 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
We captured the network data with the following machines: | We captured the network data with the following machines: | ||
| − | + | * <tt>192.168.1.101 </tt>- Asterisk #1 | |
| − | + | * <tt>192.168.1.106 </tt>- Asterisk #2 | |
| − | + | * <tt>192.168.1.3 </tt>- Windows machine 1 (running VMware with Tribox, Asterisk #1) | |
| − | + | * <tt>192.168.1.200 </tt>- Windows machine 2 (running VMware with Tribox, Asterisk #2) | |
| + | * <tt>192.168.1.189 </tt>- Laptop #1 running only X-lite | ||
| + | * <tt>192.168.1.100 </tt>- Laptop #2 running only X-lite | ||
| − | After capturing we filtered out | + | = Analysis on VoIP-calls = |
| + | We did also do some [[Ethereal Analysis]] on the traffic during several conversations. | ||
| + | |||
| + | = Using Ethereal = | ||
| + | Ethereal can capture all network data. | ||
| + | This captured data must be filtered in order to do some analysis. | ||
| + | |||
| + | e.g. After capturing we filtered out all data to machines not on the local network (IP-adress other than 192.168.1.x), using this filter: | ||
ip.src >= 192.168.1.1 && ip.src <= 192.168.1.255 && ip.dst >= 192.168.1.1 && ip.dst <= 192.168.1.255 | ip.src >= 192.168.1.1 && ip.src <= 192.168.1.255 && ip.dst >= 192.168.1.1 && ip.dst <= 192.168.1.255 | ||
| + | A shorter notation is: | ||
| + | ip.src == 192.168.1.0/24 && ip.dst == 192.168.1.0/24 | ||
| + | Doing this ensures other data like a webpage refreshing, or a mail-client fetching new mail does not contaminate the meassurements. | ||
| + | |||
| + | When doing further analysis, sometimes the filters should only look at the protocol under investigation, because Windows PC's will also communicate to each other about shared files, etc. | ||
| + | Also HTTP- and DHCP-traffic is not uncommon between the VMware- and other local machines. | ||
| + | |||
| + | For more information on Packet Capturing, we have included a simple how-to [[Ethereal capture filter]] ([http://www.openxtra.co.uk/support/howto/ethereal-filter.php source]) | ||
| + | == Promiscuous mode == | ||
| + | For detailed analysis, also traffic not adressed to the machine running Ethereal must be captured. | ||
| + | If both VMware machines run on the same computer, it is impossible to capture the traffic between them. Therefore we setup an extra Windows machine running VMware. | ||
| − | + | [[image:schematic_of_PC-config.png|Schematic overview of all PC's running which software.]] | |
| − | + | This way we could capture all network traffic. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | When measuring (listening to) all data on the local network, the network adapter has to be set in '''promiscuous mode'''. This is only possible with administrator rights (e.g. root in Linux) and not all network devices can operate in such mode. | |
| + | For example most WiFi cards cannot operate in this mode and therefore cannot listen to all traffic it receives. | ||
| − | + | Another problem when listening to all other traffic (= all traffic not adressed to the computer running Ethereal) is in a switched network. When using switches instead of hubs, you cannot "hear" what other computers are sending to each other. Possible work-arounds are setting the switch in broadcast-mode (not all switches can do this) or forcing the switch to operate like a hub (System-administrators will not like this) by overloading the MAC-table (see [http://en.wikipedia.org/wiki/MAC_flooding Wikipedia:MAC flooding]). | |
| − | - the | + | Some (manageble) switches can create one or more <tt>Vlan</tt>s in which sniffing the traffic is possible. |
| − | |||
Latest revision as of 12:11, 1 February 2007
Ethereal is used to analyse the network traffic.
We captured the network data with the following machines:
- 192.168.1.101 - Asterisk #1
- 192.168.1.106 - Asterisk #2
- 192.168.1.3 - Windows machine 1 (running VMware with Tribox, Asterisk #1)
- 192.168.1.200 - Windows machine 2 (running VMware with Tribox, Asterisk #2)
- 192.168.1.189 - Laptop #1 running only X-lite
- 192.168.1.100 - Laptop #2 running only X-lite
Analysis on VoIP-calls
We did also do some Ethereal Analysis on the traffic during several conversations.
Using Ethereal
Ethereal can capture all network data. This captured data must be filtered in order to do some analysis.
e.g. After capturing we filtered out all data to machines not on the local network (IP-adress other than 192.168.1.x), using this filter:
ip.src >= 192.168.1.1 && ip.src <= 192.168.1.255 && ip.dst >= 192.168.1.1 && ip.dst <= 192.168.1.255
A shorter notation is:
ip.src == 192.168.1.0/24 && ip.dst == 192.168.1.0/24
Doing this ensures other data like a webpage refreshing, or a mail-client fetching new mail does not contaminate the meassurements.
When doing further analysis, sometimes the filters should only look at the protocol under investigation, because Windows PC's will also communicate to each other about shared files, etc. Also HTTP- and DHCP-traffic is not uncommon between the VMware- and other local machines.
For more information on Packet Capturing, we have included a simple how-to Ethereal capture filter (source)
Promiscuous mode
For detailed analysis, also traffic not adressed to the machine running Ethereal must be captured. If both VMware machines run on the same computer, it is impossible to capture the traffic between them. Therefore we setup an extra Windows machine running VMware.
This way we could capture all network traffic.
When measuring (listening to) all data on the local network, the network adapter has to be set in promiscuous mode. This is only possible with administrator rights (e.g. root in Linux) and not all network devices can operate in such mode. For example most WiFi cards cannot operate in this mode and therefore cannot listen to all traffic it receives.
Another problem when listening to all other traffic (= all traffic not adressed to the computer running Ethereal) is in a switched network. When using switches instead of hubs, you cannot "hear" what other computers are sending to each other. Possible work-arounds are setting the switch in broadcast-mode (not all switches can do this) or forcing the switch to operate like a hub (System-administrators will not like this) by overloading the MAC-table (see Wikipedia:MAC flooding). Some (manageble) switches can create one or more Vlans in which sniffing the traffic is possible.
