The netstat utility Netstat utility displays a list of open sockets if none parameter is set, it shows the active

sockets of all configured address families. Some useful parameters are, for example -r which prints the routing tables; or -n which shows the numerical addresses instead of trying to resolve symbolic host or user name. We can also check the packet statistics with -s parameter. We find out that we have lost some of them. //no recuerdo si apuntamos cuantos, sino podemos inventar algun num Netstat offers the possibility to know about TCP configuration on sockets. We use -a -tcp to see that our machine is listening through some sockets to receive ftp connections. //en cuanto a la seguridad de la mquina no se que comentamos, quizas la maquina no es muy segura por tener muchos puertos abiertos en listen. Escribo algo de este estilo, cambialo si crees que no es cierto! We think that this is not a very secure machine, it have many sockets opened on listen. We don't know if there is some type of firewall control though, so maybe the security is present through other methods. In order to observe how TCP socket works we run the command netstat -c 1 -tcp while we browse some Internet web page. The first thing that surprises us is how many connections the machine does (more than one, as we could expect). It's nice to see how the socket changes through the different TCP states like ESTABLISHED or FIN_WAIT when it waits until finally the connection is closed. The route utility Route utility allows us to manipulate IP routing tables. Its primary use is to set up static routes to specific hosts or networks via an interface configure through ifconfig. The routing table for serv2, for example, has router2 as destination for addresses on the subnet 192.168.0/24 and 172.16.0.1 as destination by default. Another interesting utilities from route are: M to change MTU; W to set the TCP window size on a specific route; or I to change the initial RTT. The ARP utility ARP utility lets us configure the mentioned protocol which is used to convert Link layer hardware addresses (MAC) to Ipv4. Some relevant options are -a to display all the entries on the ARP table; -s to manually create an ARP entry; or -d to delete any of them if we are taking down some device for example. If we make a ping to a local machine that is not on our ARP table, we will see that the MAC address of this machine is added to the table. Although, if we do the same procedure to an exterior machine, we will observe no change on our ARP table, that is because any host only keeps record of the next hop MAC addresses (in this case our default route, because is an exterior machine). //Creo que era asi como funcionaba, que solo guarda las direcciones adyacentes no? No se si apuntamos la MAC de serv3, pero la pregunta.

Forcing client1 to send packets to serv3 on the default route will result on serv3 sending these packets to router2. Serv3 realizes it and automatically sends an ICMP message to client1 (ICMP-Redirect) telling it that he can send them directly to router2. If IP forwarding is available, next packets from client1 to default route will be sent straight to router2. IP forwarding is not always available because it will be easy to redirect traffic to an external host with bad intentions. //lo de bad intentions no me suena muy bien pero no se como ponerlo mejor xD ARP Protocol We capture only the ARP traffic setting a filter on wireshark. When we ping a machine that is not on our ARP table we can see our machine sending a broadcast ARP packet asking who is IP_direction. Being IP_direction the next hop that our packet has to do, if it is a local machine his direction; if not, the IP of the default router. After the transmission ends, we can see another ARP packet asking again for the destination IP, this seems a little awkward because we already finalized our transmission, but it is done as a safe mechanism to ensure that we send the packets to the correct device. ARP entries on the table are temporary, we can see that after a transmission the entry will be deleted after a few minutes, this is done because of the mobility and changing environment of the networks that could lead to an incorrect MAC address attached to a certain IP. But if we are sure that our network is going to be stable and without lots of hardware changes (different MAC addresses) we can define static ARP entries. We define a static one for our router, we make sure that the transmission is done correctly. When we define an incorrect ARP entry the system can't find the machine which it has to send and the packets can't leave the transmitter. IP and ICMP Protocols After putting a wireshark filter to show only ICMP packets we proceed to analyse one of them from our pings. We can see the the 'echo (ping) request' and the reply, both of them keep pretty much the same structure, only differs on the type field from ICMP header (8 for request and 0 for reply), and of course destination and source addresses. Other interesting fields from the packet are the Protocol from IP header which is set 1 (ICMP); the TTL (Time to Live) shows the number of hops left before the packet is discarded; Fragment Offset, in this case no fragmentation is required; two checksums, one from IP and another from ICMP; sequence number; and last the data field. We try to send a packet to a non-existent IP, it will be sent through different routers until eventually it gets discarded because his TTL reaches 0. The ICMP protocol will send us a message telling that the destination is unreachable. //Creo que era esto lo que pasaba pero no estoy seguro Another feature interesting to observe is the packet fragmentation, if we send a packet larger than 1500 bytes it will have to be separated into smaller ones because Ethernet maximum MTU is set to 1500 bytes. We send a 1600 bytes packet and check that now, the Fragment Offset field from IP header on the second packet is not set to 0. Also, the

identification number from the IP header is the same, this indicates that indeed they are fragments from the same larger packet. //pregunta por el n de identificacion de los paquetes cuando estan fragmentados, no se bien bien que deberia pasar, puede ser que al ser fragmentos del mismo paquete tengan el mismo numero? //faltan preguntas 41-42 It exists certain packets that cannot be fragmented, we can do this through a flag from the IP header (bit 1 from Flags field which correspond to DF Don't Fragment flag). This becomes useful, for example when we want to discover the MTU from a certain route, we send a 1500 bytes packet with the DF flag set to 1, then we will receive an ICMP message with the MTU required to fulfil that request