I would like to get packet level data traffic captures (.pcap) in Android during a week (in several files if possible).
I thought that I could use tcpdump via Shark, however I find that the capture stops after some time. The biggest packet capture I got is around 40MB. I found out that tcpdump stops/crashes when changing the network interface. For example, when the phone is connected to 3G, when I run tcpdump from Shark I can see the process of tcpdump running until I switch on WiFi.
In the Galaxy S2, when connected via WiFi I have the following interfaces (got by using netcfg in adb shell): lo, svnet0, usb0, sit0, eth0. When I connect via 3G, I get pdp0 instead of eth0.
Is there any way that I can run tcpdump 24/7? Or any way to check when it is running and if it stops make it run again from a Java app? Checking the process of tcpdump or something like this maybe? Or monitoring the status of the network and running tcpdump every time the network is changed?
I had a look to: ReadLine on TCPDump-Buffer sometimes blocks until kill tcpdump , but it does not completely solve my problem.
I am using rooted devices.
How about trying tPacketCapture application ( works with non-rooted devices)
Android OS 4.0
Free
https://play.google.com/store/apps/details?id=jp.co.taosoftware.android.packetcapture
If you have rooted device then use SimplePacketCapture instead of tPacketCapture.
tPacketCapture creates a vpn that can break your voip application.
I'v tried as follow to see what's going on about tcpdump after alternating network interface.
1.open wifi run tcpdump-arm
2.run ps|grep tcpdump-arm
3.close wifi and open mobile interface
4.run ps|grep tcpdump-arm
I've found that when alternating the network interface on the mobile phone, the tcpdump-arm process is still working, but it captures no packets.
I think you need tcpdump to keep capturing even when the network interface changed.
You can catch the connectivity change broadcast as the tutorial of google says at first.
Then, you should run "killall" to kill the tcpdump processl
At last, restart the tcpdump process, if you don not specify an interface, it will listen on the newly opened interface.If you would like the tcpdump to return quickly, you can add "-l" option as the answer in TCPDump-Buffer sometimes blocks until kill tcpdump implies.
Related
I made a program to backup files in android devices. To put it simply, it works in background of Windows like a server and when a defined android device (with its LAN IP) connects to home's WiFi network it looks for specific files in specific folders in device and backups them.
My problem is, for some devices (e.g Samsung Note 4), after a few successful WiFi connections (or a few days later) the device starts to appear offline. To fix this, I need to reset the authorities in device or do the reconnection procedure of my program with USB cable again. I researched the web in-depth but couldn't find a way to make offline devices online automatically.
Most of 'ADB offline' solutions on the web works well, but i need to do this automatically over WiFi within my program.
-ADB kill-server & start-server, not working,
-ADB disconnect & connect, not working too.
Disable your antivirus and then try again or add adb.exe as exception in your antivirus.
I want to connect two devices using Wifi-Direct.
One is a pc with Linux (during my test I'm using Linux Mint 17.2), the other is an Android smartphone (Samsung Galaxy S3 with Android 4.3. Not rooted and don't want to root).
Reading a number of guides on the internet, I decided to use wpa_supplicant in Linux and to create an app for Android.
This is one of the best guides I found for wpa_supplicant:
https://web.archive.org/web/20210114180304/https://processors.wiki.ti.com/index.php/OMAP_Wireless_Connectivity_NLCP_WiFi_Direct_Configuration_Scripts
When I run iw list I see that the "Supported interface modes:" allows P2P_client and P2P_GO.
My wpa_supplicant.conf contains:
ctrl_interface=/var/run/wpa_supplicant
update_config=1
ap_scan=1
device_name=My-pc
device_type=1-0050F204-1
driver_param=use_p2p_group_interface=1
p2p_go_intent=15
p2p_go_ht40=1
The app is very similar to this example (it's from a book) https://github.com/retomeier/Wrox-ProfessionalAndroid-4E/blob/9741a8b62005d49519b1decfea21e7213fdd94a3/Snippets_ch18/app/src/main/java/com/professionalandroid/apps/myapplication/WiFiDirectActivity.java
It works as expected. When I try it with two Android devices, they can see each other and connect (it appear the Wifi-Direct icon).
Now I am trying to connect Android and Linux, but I guess I don't really understand how wpa_supplicant works.
I also saw this question that is very similar to what I asked, but it doesn't really answer my doubts...
Direct Wifi Communication between android smartphone and other devices
My problem is that I can't understand how to do the handshake between the two devices and how to set up the network.
Wpa_supplicant is my problem. I run:
sudo wpa_supplicant -wlan0 -Dnl80211 -c/etc/wpa_supplicant.conf
sudo wpa_cli
But I had a lot of problems:
The device_name (and other parameters) weren't set as I specifiend in the .conf file
wpa_supplicant continues to try to connect to all the networks
p2p_find was really slow...
so I went into /usr/share/dbus-1/system-services and moved away the two files
fi.epitest.hostap.WPASupplicant.service
fi.w1.wpa_supplicant1.service
Now I can
sudo killall wpa_supplicant
and it really dies, disconnecting me from Wifi without reconnecting the following second.
Now I can launch wpa_supplicant and the three problems are resolved.
I go into wpa_cli, launch "p2p_find" and at the same time, I enable the search from within the app.
Android and Linux can now see each other.
P2P-DEVICE-FOUND 00:11:22:44:88:ff p2p_dev_addr=00:11:22:44:88:ff
pri_dev_type=10-0050F204-5 name='GT-I9300' config_methods=0x188
dev_capab=0x24 group_capab=0x0 vendor_elems=1 new=0
With "p2p_peers" I can see the cellphone MAC.
> aa:bb:cc:dd:ee:ff
Here I can't go ahead. I tried various possibilities, but none of them worked. My objective is to have Linux as Group Owner.
Question 1.1: Which is the correct way to handshake the two devices?
Question 1.2: When I try p2p_connect I often get "Michael MIC failure detected" between the results, what does it means in this contest?
Question 1.3: Android currently tries to connect with PBC. There is a way to connect with PIN?
Seeing that I couldn't connect Android/Linux, I tried to do some practice with Linux/Linux (Linux Mint as GO, Ubuntu as Client), following examples from internet like the ones in the first link.
I have a number of problems even here.
In Mint I try
p2p_connect MAC_UBUNTU pin auth
in Ubuntu I try
p2p_connect MAC_MINT PIN_GENERATED_BY_MINT
When I write the psp_connect in Mint, it creates a new interface p2p_wlan0 _0, and it returns
P2P-DEVICE-LOST p2p_dev_addr=MAC_UBUNTU
then the p2p_connect launched from Ubuntu fails.
Question 2.1 Why it switches interface when creating the group?
Question 2.2 What is the correct way to handle this change? After the change I can't p2p_find Ubuntu anymore (I have to wait some time or restart everything)
Question 2.3 Should Ubuntu change it's interface?
Question 2.3 In the new interface I should set the IP for both Ubuntu and Mint... how should I do this with static IPs?
Question 2.4 If I want to set up for example a DHCP server and client?
Question 1.4 And with Android(client) / Linux(GO)?
I worked a lot on this problem and here is the answers that I found:
Answer 1.1 There are a lot of possibilities and the correct one depends on what you are trying to achieve.
You can find the various possibilities here: http://processors.wiki.ti.com/index.php/OMAP_Wireless_Connectivity_NLCP_WiFi_Direct_Configuration_Scripts
I wanted Linux as a GO and Android as a client, so what worked for me in Linux is:
// Kill current supplicant and avoid its automatic recreation
system("mv /usr/share/dbus-1/system-services/fi.* .");
system("killall udhcpd");
system("wpa_cli -i wlan0 terminate -B");
usleep(300000);
// Start new supplicant
system("wpa_supplicant -Dnl80211 -iwlan0 -c /etc/p2p_supplicant.conf -B");
system("wpa_cli -iwlan0 p2p_group_add");
system("ifconfig p2p-wlan0-0 192.168.1.2");
// Connect with a peer
for (;;) {
system("wpa_cli -ip2p-wlan0-0 wps_pbc");
system("udhcpd /etc/udhcpd.conf");
// Here start your TCP server on a port
Server server([port]);
server.startServer();
}
N.B. To destroy P2P connection and restart the normal one I use this script:
#!/bin/bash
wpa_cli -i wlan0 terminate -B
wpa_cli -i p2p-wlan0-0 terminate -B
cp ./fi.* /usr/share/dbus-1/system-services/
service network-manager restart
Here the server listens for a connection and the android client connects to it. I used a very easy TCP server found on the first website and it worked like a charm.
It's important to start the udhcpd or you won't get the "connected" icon in Android.
For the Android side, I followed what I saw on http://developer.android.com/training/connect-devices-wirelessly/wifi-direct.html and it worked perfectly.
Answer 1.2 From wpa_cli you can get a lot of different warnings and errors. I saw that simply calling the function (like I did in the previous snippet) made everything work despite the warnings. I ignored them.
Answer 1.3 The connection using PIN works, when I tried it I wasn't starting the udhcpd and that crashed my connection every time. It was not due to PIN or PBC.
Answer 2.1 Both the server and the client are switching interface.
It is a very similar behaviour to what you usually do with sockets. You create a listening socket, somebody connects, you create a new socket to handle that client in a separate thread while the listening socket is still there, waiting for other users.
You do the same with interfaces. Starting a wpa_cli that monitors the wlan0 interface and one that monitors the p2p-wlan0-0 interface gives a good idea of what is happening during the change.
Answer 2.2 The client "went" to the other interface and is now ready to receive an IP. Start the DHCP and TCP servers!
Answer 2.3 Don't use static IP. Only only for the server is ok, the client should use a DHCP IP. Maybe there is a way to handle static IPs, but it was not useful for my objectives.
Answer 2.4 Done. That was the problem all along
Answer 1.4 This works perfectly even with Android/linux.
Sorry if I made some mistake in my answer, I still don't get the whole picture of WiFi-Direct connections, I simply hope that this can help someone else.
(May not be a complete answer, but right direction)
The issue is on the Linux side. I'm encountering similar issues between a Cyanogenmod (Android 5) and Fedora 22, attempting to use Wifi Direct (Wifi P2P) for Intel's Wireless Display Software for Linux OS (WDS).
Specifically, Intel's connman diverged (written from scratch) back in 2009 from what had been standard in Linux, NetworkManager. Connman appears to be the only implementation of Wifi Direct (Wifi P2P) for Linux, and had been written for the embedded (mobile) market.
Due to an RPM issue, connman remains untested on my system, but the software should provide the dbus communications Linux needs.
Website: https://01.org/connman
Did you simply tried to activated your hotspot option on Android? Then connect with the Ubuntu device, check the connected IP on the Android hotspot options and give it to your app.
It work for me for remote controling my Ubuntu system.
Could anyone tell me is it possible to test an android application that connects two phones using wifi(or any network connection) with the help of two Emulator instances.
We would like to make an social networking app that uses location services in android.But since I don't have an android phone I would like to know whether we could test the application using two Emulator instances.
Of cause you can connect to devices as many as you have. First you can connect to your phones via USB and run "adb tcpip" to set all the device to restart ADBD on network interface. The you can do "adb connect IpAddressOfEveryDevice". To direct command to specific device, use adb -s IP:PORT command
Is there a way to fake calls for android devices that I have plugged in via usb? Some way to trigger a call using ADB? If so, how do I do it?
I feel like this might be a duplicate question but I can't find a SO question for it. This is the closest question, but it only relates to the emulator.
Here's some things I've tried. I would like to do the reverse of the following command:
adb shell am start -a android.intent.action.CALL tel:1112223333
Just like the other guy said in the question I linked to above. Except I would like to do this on a device, instead of in the emulator. For the work that I am doing the emulator is not sufficient for testing phone calls, I can only run my tests on actual devices. Our "solution" doesn't have emulator support.
So normally I would telnet into the local host using the emulator's port but I can't do that, so can I telnet into a plugged in device? Is there a way for me to fake an incoming call on a plugged in device?
To explain why I would want to do this, I am making modifications to AOSP at this time. At the moment we have not modified the emulator to work with our changes, but we are making modifications to telephony. Eventually getting the emulator to work will be important but at this time it would be ideal if we could test telephony with fake calls using the devices we have access to.
It is entirely possible that this is not even possible but if someone has experience with this I would love to know. I feel like there should be some tests somewhere for faking phone calls on devices before they release a device to the public.
Telnet to your Android device
Alternatively to adb you can also use telnet to connect to the device. This allows you to simulate certain things, e.g. incoming call, change the network connectivity, set your current geocodes, etc. Use "telnet localhost 5554" to connect to your simulated device. To exit the console session, use the quit or exit command.
For example
# connects to device
telnet localhost 5554
# set the power level
power status full
power status charging
# make a call to the device
gsm call 012041293123
# send a sms to the device
sms send 12345 Will be home soon
# set the geo location
geo fix 48 51
So, let me start off by saying that I am 'relatively' familiar and comfortable with making Android apps and using both LogCat and DDMS to debug.
That being said, I'm encountering more of a logistical issue than anything else right now - I am making a locative app, where the GPS is fuelling and controlling other methods in my Activity, and after a while, it is crashing.
Now, because it is locative, I am walking around to test it, in order to receive different GPS locations. Because of this, I am not connected to my computer at the time that it crashes, so have no way (that I know of) to read the stack trace, etc.
In my particular instance, I am navigating through a series of activities, and finally reach the penultimate screen in my app, and while I am running the application in my studio, it runs indefinitely without issue. It is only when I take the device outside that it crashes...
I am wondering if anyone has any tips or tricks with this issue - I'm sure give the prevalence of locative apps, it must have come up, but I cant seem to find the right search terms. It could be as simple as saving the LogCat to file, and/or the stackTrace, but I'm not sure that's the answer...
Thanks in advance.
If I got you right, this is what you are looking for:
https://play.google.com/store/apps/details?id=org.jtb.alogcat&hl=de
Edit: Also there are many more apps like this. You can just browse around in Google Play Store
You can debug the app without rooting your android, unlike the other responses. start off by plugging the android into your computer, then run adb devices to make sure the device is there. Then, run tcpip 5555 to change the android to tcp mode, which will allow debugging over wifi. Disconnect the android from the computer, and connect to it by typing adb 192.168.x.xxx, replacing the x's with your android's IP address. It should connect with no issues, as long as port 5555 is open, and both the android and your computer is on the same wifi.
Simple: Wireless ADB
One of the reason that I choose to run CyanogenMod on my testing devices is that it is a stripped down version of Android that has some additional developer tools, one of those being the ability to access the wireless portion of the ADB system.
As you are probably unaware, you are able to establish an ADB connection to your device over WiFi, however, if running a stock ROM, this requires root access, as it can be potentially harmful to your device, as Wireless ADB will work even over your cellular network, meaning that you could potentially receive apps from other insert carrier here's devices.
If you wish to run WirelessADB, here is a Play Store app that will help you to enable the feature on your device. Requires ROOT
It is as simple as connecting your device to your local WiFi network, (same one the development computer is connected to), enable Wireless ADB, and then running the following command on your computer:
adb connect 192.168.1.101
Replacing 192.168.1.101 with the IP address of your android device.
By establishing this connection, you can run everything just as you would if the device was plugged in via USB Cable.
I recommend ACRA (Application Crash Reports for Android ). It allows you to send crash reports to a number of different destinations. See https://github.com/ACRA/acra/wiki/BasicSetup