I am using TCPDUMP-arm because I'd like to capture TCP packets arriving on my tablet. The problem is that I want to get rid of the results about the outgoing packets.
When I execute:
./tcpdump-arm tcp -qt -l > /sdcard/res.txt
I get results like:
IP 172.17.***.***.49890 > 74.125.***.***.5228: tcp 139
IP 172.17.***.***.56869 > 173.194.***.***.80: tcp 0
IP 173.194.***.***.80 > 172.17.***.***.56869: tcp 0
Where the IP starting with 172.17. is mine.
So, is there a way to adjust TCPDUMP to show me only the last result (the one where my IP is destination)
Not sure about tcpdump-arm (never used it), but assuming that the pcap-filter expression is the same as tcpdump's (which is quite likely, I'd think), then to see tcp traffic and leave out packets where your IP address is the source, your expression should be:
tcp and src host not 172.17.x.x
Can't try it out now to be 100% sure, but I'll leave that to you.
I've managed to deal with the problem :)
Also , I created one ToggleButton in my app , in order to Start/Stop TCPDUMP. Now I want to be able to read the text file which is generated, while the program is still executing , and make decisions based on the data from the file.
The problem is that I want to read only the latest results , and so far I can just read the whole file from begging to the end. My other option is somehow to read the output from TCPDUMP directly/live in my app , without making a text file , but I have no idea how to achieve that.
I am looking forward for your replies.
Related
I am logging GPS data on a Raspberry Pi (Raspbian OS) by forwarding text from an Android phone connected by USB. The app ShareGPS correctly dumps several lines of text every second to port 50000. On the Pi I run adb to forward the port to the Pi.
From there I redirect the socket using a pseudo path to a file descriptor and then redirect the descriptor to a text file.
adb forward tcp:50000 tcp:50000
exec 3<>/dev/tcp/localhost/50000
cat &3 >> dump-file.txt
To me this seems a very convoluted route. Is there a more efficient way record from a port on the phone to a text file on the Pi?
Phone setup and adb reference http://ubuntuforums.org/showthread.php?t=2145434
Socket redirection http://hacktux.com/bash/socket
If you don't need back-and-forth communications, you don't have to open a separate FD:
cat < /dev/tcp/localhost/50000 > dump-file.txt
One way or another, there will need to be a process that listens to the port and writes to the file as there is no built-in O/S function to do so.
So, really, there isn't going to be a more efficient way to run that. You might be able to save some startup cost by turning the script into a program, but I wouldn't bother - the savings will be tiny.
I tried at making a socket with an Android NDK wrapper, passing the file descriptor to Java to be used with a recv wrapper. The target user should not require Single User. The recv call does not receive any data. Why?
TCP sockets can not be read without a connection, because they require sequentiality. UDP packets were not being received either. RAW sockets were, of course, not being successfully made. My code had more bugs than a restaurant's dumpster, I was calling shutdown instead of close... not sure why. It's April fools, and usually I delete questions once I realize I'm being an idiot and wasting people's time; but today I have a bounty on this question, so I think I'll revisit this idea for a bit and post better code. Check back later if you're still interested.
Android doesn't support reading from unconnected sockets.
TCP doesn't support reading from unconnected sockets, or writing to them either. Your socket is of type SOCK_STREAM, and you are calling shutdown() on it, so it must be a TCP socket.
NB:
shutdown() doesn't close the FD. You must also call close().
recv() returning -1 doesn't necessarily mean 'socket closed'. You need to look at the value of errno to decide what it does mean.
Your title 'Java Native Socket Not Persistent' has nothing to do with your question.
I have been doing some low-level hacking on Android.
I'm trying to enable wifi i.e. establish Internet Connectivity through terminal (adb shell). I have written a C program to achieve this by hacking into android's bionic library and libnetutils library to get things working.
Everything works fine. I'm able to acquire an IP address via dhcp request. The problem is that whenever I try to open any site for ex. google.com via browser, it does not opens. But when I enter the IP address of the site "74.125.228.66" (google.com), the page gets loaded.
I have tried several options, like modifying the dns entries in file "resolv.conf" (present in /system/etc) and in file "20-dns.conf" (in /system/etc/dhcpcd/dhcpcd-hooks).
I also tried using "setprop" call to set dns values manually for "dhcp.eth0.dns*" and "dhcp.wlan0.dns*".
But nothing seems to work. There's also an interesting behavior I noticed. If I turn on wifi manually from "settings" menu and then turn it off and then run my program, I don't face this issue anymore. Looks like it uses some settings that I could not figure out.
My guess is that this is DNS issue, but it may be something else. Let me know if anyone has faced this issue before.
Here's is what I do to enable wifi:
Enable wpa_supplicant daemon using set_prop().
Send a dhcp request to acquire IP (code from dhcpclient.c in libnetutils).
Enable dhcpcd daemon using set_prop(). (Even without this, everything works. I ran this so that IP lease gets renewed automatically. ( Although I'm not sure about this, if dhcpcd daemon would take care of lease renewal or not) ).
In order to enable WIFI on Android via command line through a C program, you'll need to do the following:
1) Enable wpa_supplicant daemon. (Make sure you have the wpa_supplicant.conf file at /data/misc/wifi with AP (access point) information in it.). wpa_supplicant internally takes care of loading the driver and then establishes connectivity to the specified networks in its configuration file based on availability and strength.
2) Issue a dhcp request. ( To fetch IP, lease, dns1, dns2 etc.)
3) Start dhcpcd daemon. (For Lease renewal)
4) Set net.dns* properties. (Without this, DNS service would not work for any application)
In order to enable daemons (wpa_supplicant and dhcpcd) and set net.dns* properties , you'll need to use Android property system (property_set() and property_get() functions). To learn more about Android Property System, follow this link:
http://rxwen.blogspot.com/2010/01/android-property-system.html
In order to use above 2 functions, you'll need to hack into bionic and core libcutils library.
Location:
/bionic/libc/bionic/system_properties.c
/system/core/libcutils/properties.c
For issuing dhcp request, you need to hack some of the implementation of libnetutils
Location:
/system/core/libnetutils/*
Disabling Wifi:
1) Unload the driver manually.
2) Stop wpa_supplicant daemon.
3) Stop dhcpcd daemon.
4) Unset net.dns* properties.
In this case, driver needs to be unloaded manually unlike loading. If this step is not done, then any of the existing connections will not be torn apart even after 2, 3, and 4. To manually unload the driver, you need to issue "DRIVER STOP" request to wpa_supplicant which will take care of interacting with kernel to unload the driver.
In order to communicate with wpa_supplicant, you'll need to hack into wpa_cli implementation to see how it works. It basically uses UNIX Domain Sockets to interact with the supplicant. You basically need to have a look at wpa_ctrl.c and wpa_cli.c
To learn more about wpa_supplicant, wpa_cli, follow below link:
http://hostap.epitest.fi/wpa_supplicant/devel/
All above that I explained to you is done in Android at HAL layer.
Location:
/hardware/libhardware_legacy/wifi/wifi.c
So, basically whenever you toggle wifi switch from settings menu, control passes from wifi_app code to wifi_frameworks layer (WifiManager and WifiServices) which passes control to wifi.c (HAL layer) through JNI implementation (WifiNative).
A good starting point would be to look at wifi.c if you want to know things that are done at low level to enable wifi.
PS - All above is what I learned after several attempts trying to figure out stuff on my own. There are no documents or blogs (atleast I didn't find any!) that would specify what needs to be done and order of events that should be followed to enable/disable WIFI. So, it may be possible you might find a better way of doing things. This worked for me, something else might work for you!
I have written an executable file, and push it into /system/bin.
After run the file, it will give a result in float.
Now on PC side, I want to get this result.
At first I write this float number into a file and use 'adb pull' to pull this file, then read file.
Because I need to do this operation frequently, may 2 times per sec. This cause bad performance of the phone.
Wheather it will be little influence when I use adb socket?
Where my executable file should output?
How adb socket get the result?
Thanks.
James.
If you're leaving the phone connected, you could probably just do
adb shell /system/bin/myexecutable
and just have your binary print its output to stdout. As long as your program runs quickly, twice per second shouldn't be too fast. Otherwise, you could do
adb shell cat /somewhere/myoutfile
to see what's in a file currently.
You could potentially use logcat as a medium for getting data from your Android app to your desktop machine provided there is an ADB connection available.
My thinking is that there are two pieces:
Log your app output with logcat to a unique TAG on the Android side. For example,
Log.d("MyAppOutput", "This is the output I am looking for");
On the desktop side, you could run a command line that looks specifically for that TAG, something like:
adb logcat -s MyAppOutput
I believe this would allow you to read the results from the Android app in near realtime. If you need to know the timestamp of the log message, you could add the -v time parameter to prefix each message with a timestamp.
I had the same question before, you don't need output result to file, just output your result to a socket port, and use adb forward to get the result on your pc by adb socket. this is what you need solution.
adb forward tcp:18000 tcp:19000
this command means，pc's tcp port 18000 bind to device's tcp port 19000, if you send data to 18000 port on pc, you can get data from 19000 on device.vice versa.
I am trying to send some data (in the form of raw bytes ) from my device to host(connected through USB). What can be the different ways to do it ??
One idea is to write the raw bytes in one of the ring buffers (in /dev/log/) and let the logcat read it. But logcat expects the formatted strings in ring buffers, Is there a way to modify the behavior of logcat ??
or is there a way to create a tcp connection between host and device to transfer the data???
Any other suggestions ??
Thanks.
adb forward is your friend. You can do port forwarding and then run TCP servers on either the host or the device.
EDIT: see http://developer.android.com/guide/developing/tools/adb.html#forwardports for more detail.