Application Android de messagerie instantanée sur réseaux maillés

De Ensiwiki
Aller à : navigation, rechercher
Application Android de messagerie instantanée sur réseaux maillés
Project Project of speciality 2A
Sub-project Networking
Students Rafaelle Botter (ISSC)

Jean-Marc Celesti (ISSC)

Yohann Hako Moukam (ISSC)

Mathilde Igier (ISSC)

Promo 2016
Tutor Olivier Alphand Olivier.Alphand@imag.fr





Introduction

For years, communication is one of the most important issue of our society. In a climate of social network and mass communication, people wants an access to their contacts everywhere even in distant area in which the Internet is nearly absent. For all these reasons, it will be really interesting to build a network only with Wi-Fi Direct. Clearly, Wi-Fi Direct don’t need an Internet access to connect devices together (phones, tablet, computers….). Wi-Fi Direct enables high debit connection between devices, in that way this technologie is more efficient that other P2P technologies like Bluetooth (have a look to the document in appendix section 2). In this project, we will have to make a theorical study on Wi-Fi Direct (protocols, specifications….). In the same time we will have to do an Android application (named ChatOn) : a chat which enables a communication between devices without Internet.

This paper is not a scientific report, we made a Latex Document in Appendix to expose all details of our project in which we explain precisely our process and our results. The goal of this Ensiwiki page is to resume our work without long explanations, if you are keen enough to learn more about a specific point please look at the Latex document.

Network

Connection protocols

Wi-Fi Direct Group Formation, source:[1]

In this paragraph we are going to summarize the different parts of Wi-Fi Direct and the protocoles used. For more detail see the appendix section 3. The first step of the creation of such a network is to create a P2P group between two devices. This connection is made in three steps :

- SCAN : first each device scans its area to find an existing group. If there is one, they just ask for a connection. Else they do the second and third step. (Appendix section 3.1.1)

- FIND : each device listens on one channel choosen among 1, 6, 11, and searches on each one consecutively. They altern listening and searching phases with differents periodes then they finish by find each other on a channel. (Appendix section 3.1.2)

- FORMATION : One of the two devices becomes the P2P Group Owner (P2P GO) and takes the role of an AP (gives the other device an IP adress, upkeeps the network between devices), the other device becomes P2P Client. The GO negotiation determinate which device are going to be the GO and which one will become Client. In GO negotiation frame, an intent is draw by the devices, the device which have the higher intent (1 to 15) become the GO. In case of equality, we use the breaker bit, the device which have the breaker bit equal to 1 become the GO. The negotiationcan fail if the two device draw a number equal higher of 15. The P2P GO chooses a channel for the connection, gives key to the P2P Client (WPS services) and IP (DHCP protocol). (Appendix section 3.1.3)

At this time we have a little network with only two devices, other devices can join this network (invitation request/response), this device become Legacy Client and have not the specification of a P2P device, for this case, the P2P GO is an AP.

Wireshark Frame Study

What can be interesting to see is, beyond the App, how a Wi-Fi Direct connection really works, what are the protocols and if it really possible to capture traffic such as group formation or the GO Negotiation. For that, we used Wireshark but the use of TcpDump or any capture software is possible.

The difference to a capture from a local network is, the computer is not connected to the device. Thus, the user needs to set his adapter in a monitor mode, a mode which the wireless device to capture all the WLAN traffic, without being connected to any Access Point.

Make sure your adapter handles monitor mode by the iw list command :

chris@chris-HP-Pavilion-15-Notebook-PC:~\$ iw list
Supported interface modes:
* IBSS
17
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO

To put your card in monitor mode, type in root mode the commands as below :

ifconfig wlanX down
iwconfig wlanX mode monitor
ifconfig wlanX up
ifconfig wlanX channel Y (If you want especially listen on Y channel)

And check if everything is all right with iwconfig. To Monitor on channel 6 you should have :

chris@chris-HP-Pavilion-15-Notebook-PC:~ iwconfig

wlan1 IEEE 802.11bgn Mode:Monitor Frequency:2.437 GHz Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off

If you don't specify a channel, Wireshark will alternate beetween several channel. Problem is, some steps of a connection, happens very fast. even though the frequency-hopping has a short delay, if the adapter is not set on the good channel, it won't be able to capture it.

That is the case with the GO Negotiation. It happens on a channel which is determined by some configuration file in the device. In Fact, in the Android kernel there is a linux portage software, wpa_supplicant which which controls the roaming, authentication and association of the wireless driver. Because Android is built on a linux Kernel (Debian), It can be possible to run it on mobile. By default, it’s already included.

Go Negotiation Frame

In other words when the WLAN menu is selected, wpa_supplicant loads configuration file, wpa_supplicant.conf and p2p_supplicant.conf, one for Wi-Fi and the other for Wi-Fi Direct. In order to understand some processes, it was very convenient to see, and edit p2p_supplicant.conf. The syntax of the configuration file is as below :

root@redwood:/ # cat data/misc/wifi/p2p_supplicant.conf
ctrl_interface=/data/misc/wifi/sockets
disable_scan_offload=1
driver_param=use_p2p_group_interface=1
update_config=1
16
device_name=Android_43e6
device_type=10-0050F204-5
config_methods=virtual_push_button physical_display keypad
p2p_ssid_postfix=-Android_43e6
p2p_go_intent=15
p2p_listen_reg_class=81
p2p_listen_channel=1
p2p_oper_reg_class=81
p2p_oper_channel=1
persistent_reconnect=1

As you can see, there are some parameters you can edit (p2p_xxxx_channel, p2p_go_intent) you can edit to force the device to become Group Owner, or to create a group on a specific channel. That's how we did to capture Negotiation Frame. For more details, see the Appendix annexe section 7.3.1

However, a simple user cannot go to the configuration file, and he cannot view them. In order to perform this, a device has been rooted. Rooting is a software operation which allows to be a superuser, so be careful about what you are doing.

Example of Conversation frame

Once the group has been formed, you can recover the passphrase from the configuration file and connect to the SSID with your computer as a classic Access Point. The passphrase is given in the "psk" field as following :

root@redwood:/ # cat data/misc/wifi/p2p_supplicant.conf
network={
ssid="DIRECT-zo-Android_43e6"
bssid=9a:3b:16:2f:07:d1
psk="c5mMRRBl"
proto=RSN
key_mgmt=WPA-PSK
20
pairwise=CCMP
auth_alg=OPEN
mode=3
disabled=2
p2p_client_list=12:30:47:49:1f:8d
}

Use the "psk" to connect to the P2P Group in order to capture frames with wireshark. Keep you in managed mode (disable/enable your wireless adapter), and you should be able to see conversations.

Application ChatOn

Generality

It seems to be simple to build up an android chat application, the difficulties here is to establish the Wi-Fi Dircet P2P connection between the devices. Clearly, it’s a new technology and the existing documents are not yet very complete on the subject. Therefore one of our objectif is to make the life easier for other studient who may want to build their own app in the future, so we put a complete explanation on the paper (on appendix section 5 and 6).

Connection

This part is a summarize of the following part we wrote on the appendix section 5 and 6. Two class are required to implement a connection between two devices: an activity class, and a class P2Pconnection which extends BroadcastReceiver.

- In the Activity class, we put classic objects : button, text…. to do the graphic interface. Then in onCreate() Method we initialize a manager, a channel, a P2Pconnection and a filter (it goal is to detect changing connection parameters). In Activityclass we also call the methods DicoversPeers to scan and find peers. The list of finding peers are set in with requestPeers (Broadcast Receiver). Then we can connect them with the method connect(). Then we can connect them with the method connect(). The customer native face android devices are better to connect peers, we choose to connect peers manually. The above is for those who would implement an automatic method. subsection Discover and Connecting peers.

- In the method onReceive() of P2Pconnection, we analyze the state of the connection and react consequently.

- If you wanted to use Wi-Fi hardware you need the permissions, these permissions are list in Manifest.xml

Send messages

To send messages, use UDP socket in broadcast was the better choice found. The aim was to create a chat without using internet but with Wi-Fi P2P, it means that every people connected to a group Wi-Fi can send message to everyone in the group and receive messages from them. The final purpose was to communicate between differents groups. UDP is easier than TCP. Clearly, to send message by TCP socket, every devices has to be connected with the Group Owner and to give the message to everyone in the chat, the Group Owner have to send it to every device one by one. Whereas UDP sockets can send message to every people in broadcast without being connect to anyone, the only thing to know is the broadcast address.This address flows from our range of addresses: 192.168.49/24, therefore the broadcast address is 192.68.49.255. At the beginning we tried to use multicast address (224.0.0.0 to 239.255.255.255 excepted some addresses which are reserved) but in our local network, no one matches. If you want to try with multicast addresses, you have to write the lines below.


For the receiver

           WifiManager wifi = (WifiManager) getSystemService(Context.WIFI_SERVICE);
           if (wifi != null) {
               WifiManager.MulticastLock lock = wifi.createMulticastLock("Log_Tag"); 
             }

Allows an application to receive Wifi Multicast packets.


    DatagramPacket packet;  // creates a packet to receive incomingmessage ( or data, as you wish )
    byte[] buf = new byte[256];  // new buffer, for the packet, 256 bytes seems OK
    while (true) {
    packet = new DatagramPacket(buf, buf.length); // initialise the packet
    multisocket = new MulticastSocket(8888);     // create a multicastsocket on the port 8888 for catch packet
    multisocket.receive(packet);                // 
    String s = new String(packet.getData(), packet.getOffset(), packet.getLength());
    }


For the sender:

    byte[] buf = new byte[256];
    buf = message.getBytes();
    DatagramPacket packet =new DatagramPacket(buf, buf.length), InetAddress.getByName("192.168.49.98"), 8888);
    InetAddress address = InetAddress.getByName("192.168.49.255");
    packet = new DatagramPacket(buf, buf.length, address, 8888);
    socket.send(packet);


This both Methods implement runnable, we do that because, we have to do these methods in background. For a little more explanation, look at our report available on the top of the page. For the messages display, is a TextView which is displayed, but if someone take our code he can modify.

Appendix

This pdf document developed our work and give more details about the theory and the way we did our Application: Fichier:RapportChatOn.pdf

Source

For connection protocols: [2][3][4]

For Bluetooth and Wi-Fi Direct specifications: [5] [6]

Whireshark:[7][8]

Other students code source about Wi-Fi Direct multihop: [9]

Android developer tutorial:[10][11]

Other tutorials:[12]