By analyzing the captured packets, there is a big amount of them, so we'll have to use filters for the packets.
-The filters used to see the association packets are:
-wlan.fc.type_subtype==0 || wlan.fc.type_subtype==1 → used to watch assosciation request and responses, respectively.
-wlan.addr == mac_pc → used to filter the MAC address of PC2, coupled with an AND (&&).
-After each connection, there is an exchange of Authentication packets between PC2 and the Router.
-The filters used to see the association packets are:
-wlan.fc.type_subtype==11 || wlan.fc.type_subtype==12 → used to watch authentication and deauthentication, respectively.
-wlan.addr == mac_pc → used to filter the MAC address of PC2, coupled with an AND (&&).
-Since we're connecting to a network with no password, the Authentication process uses an Open System algorithm.
-On the other hand, on the Deauthentication process, it disconnects with a reason behind it.
-These packets are constantly transmitted so that the router may know how many clients are currently connected, and where they are connected.
-As mentioned before, association packets are exchanged on a new connection, and responsible for informing the router about the information of the connecting device.
-After pinging the Router and applying the filter icmp, on PC1 while keeping the MAC address filter, we can see that they exchange ARP packets. During pinging process, after each request, we get Request to Send (RTS) and Clear to Send (CTS) packets.
Since now we are sending larger packets, the connection elapsed time will be higher and it's also more unstable.
-Since the limit of the RTS and CTS packets is 1000 bytes and we are trying to send packets larger than that, it ends up resulting on that unstability.
-Those packets are used to limit the bandwidth used by each user, otherwise it could overwhelm the router and cause connection issues for other users.
-During the authentication process, since now we are using a private network, instead of having just the association packets, we will also have authentication packets with keys to validate the connection.
-We also won't be able to capture ICMP packets from this connection.
- - diff --git a/2ano/1semestre/rc1/pratica06/pratica06.html b/2ano/1semestre/rc1/pratica06/pratica06.html deleted file mode 100644 index 11f174c..0000000 --- a/2ano/1semestre/rc1/pratica06/pratica06.html +++ /dev/null @@ -1,115 +0,0 @@ - - - - - - -On the server's source code, the server is always wating for a message from a user, on the IPv4 address 0.0.0.0, on the UDP port 5005.
On the client's source code, there are two functions for user interaction, and its IPv4 address is 127.0.0.1, using the same UDP port as the server. Then, it waits for a message to then send to the server using that IP address and port, so that the server receives the message (which is constantly listening).
On Wireshark, per message, we can capture a UDP packet, which contains the information of the message (length, content), and it also has the port information.
-The client uses the UDP port defined by the server to send the message. The client's UDP port is defined automatically on the socket creation.
-After analyzing the server's source code, we define the IP and port of the server (same as before). After that, the socket is created, and starts listening for incoming clients (maximum is 5). Then, after a client connects, it stores the address and socket of the connected client. It now creates a thread to listen for messages, while still being able to accept more clients. When receiving a message from a client, echoes the message back to it.
-On the client, it defines its IP and port (same as before), and creates a socket, which then connects to the server. Then, it waits for a message to then send to the server using that IP address and port, so that the server receives the message (which is constantly listening). Finally before allowing the user to send another message, awaits for the server to echo the sent message.
-On both ends, there is a exception handler, in case of one of them disconnects, it clears the used socket, and allows the server to listen to a new client.
-On Wireshark, we first capture 3 TCP packets when the client connects to the server:
-We then capture 4 more TCP packets per message exchange in the following order:
-The difference between this and the previous server, is that now all clients are handled by a single thread, using the selectors module.
After registering a client, it will look for activity/events (which will be in this case messages), so it can then trigger the handle_data function.
The handle_data function works similarly as the function handle_client_connection in the previous file. It waits for a message and sends it back, and if the connection closes or loses connection, it closes the socket.
Every single client has a key, provided by the selector, which is printed everytime it establishes a connection, it receives data, or disconnects.
-On both the server the client, there are a few changes. Now, instead of sending a simple message, the client sends a structured message using the struct python module. This is still a normal message, but we define how it should later be decoded.
If we take the example of this code, the struct '!BLL20s' represents a struct that contains the following:
This way we are able to send not only the message, but we are also sending the version of the message, the order number of the client and the message size, this one being important for the server to unpack the struct since the message is a character (byte) array of variable size and the server needs to know how many characters to unpack.
-On the TCP packet, we still see all the data compacted into its Data field.
-To adapt the code, we first edit the server. When receiving a message, it then sends back the struct to the connected client.
-On the client, after we send the packet, we then await the response from the server and once the replies comes, we unpack it and print it.
-In this case, the packet is still similar to the previous one.
-The difference now is, instead of sending the struct at once, we first send the struct header. This header contains the version, order and size (the first elements of the structs used before). The server then requests the number of bytes passed as the size. This way, we can now send a message with whatever size we want.
-For this, we adapt the code the same way we did in 4.3.
- - diff --git a/2ano/1semestre/rc1/pratica06/pratica06.pdf b/2ano/1semestre/rc1/pratica06/pratica06.pdf index b1e6a74..be200a1 100644 Binary files a/2ano/1semestre/rc1/pratica06/pratica06.pdf and b/2ano/1semestre/rc1/pratica06/pratica06.pdf differ