Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I notice that my Android phone has the https port (443) opened.
This is the nmap report:
PORT STATE SERVICE VERSION
443/tcp open http Mongoose httpd
|_http-methods: No Allow or Public header in OPTIONS response (status code 400)
|_http-title: Index of /
The port is not accessible, if I try to access from browser to this page: https://PHONE_IP I get this error: ERR_SSL_PROTOCOL_ERROR
I tried to connect using adb shell and the port is actually opened, this is the netstat report:
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:7777 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:7203 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN
But I can't understand which process bind the 433 port.
Any suggestions?
UPDATE:
Android netstat has no options, not even the -h option.
I don't recall if Android's netstat has the -p option but if it does, that would be the easiest way to learn the process id that has the port open.
Failing that, you can either walk through /proc/ directories looking at the file descriptors open by each process until you find the offending one.
Related
"Default interface" refers to ppp0:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 wlp3s0
172.30.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 wlp3s0
Which one is used by default when I access WAN instead of LAN.
I need to run it on Android,so I can't use getifaddrs,because ifaddrs.h is NOT in the Android NDK.
Uhh, I don't know if an interface can be marked as "default", but there are plenty way to retrieve interface list without getifaddrs.
You can execute "ip link show" command and parse the result (or "ifconfig").
you can go to "/sys/class/net" where each directory reprensent an interface (and there is file under those directory that can help you).
I don't know if Android work like Debian, and I recommand you to find a way through Android NDK or system command (like "ip" or "ifconfig") because directory like /net or /proc are subject to change between different OS version (even if it's not really common, I can't recall to have see that).
I have an Android device that communicates wirelessly with a PC, using a java.net.Socket. Everything hums along fine, but if I do nothing (i.e., no network use) for exactly 1 minute then when the Android sends a packet of data to the PC the PC receives it and sends an ACK, but the Android responds with an RST.
From Wireshark ( 10.1.2.1 is the Android, 10.1.2.11 is the PC)...
356 0.112470 10.1.2.1 10.1.2.11 TCP 97 34360→181 [PSH, ACK] Seq=1
Ack=1 Win=4935 Len=31 TSval=156103571 TSecr=320673352
359 0.000011 10.1.2.11 10.1.2.1 TCP 66 181→34360 [ACK] Seq=1 Ack=32
Win=260 Len=0 TSval=320738236 TSecr=156103571
360 0.000304 10.1.2.1 10.1.2.11 TCP 60 34360→181 [RST] Seq=32 Win=0
Len=0
At this point if I interrogate the socket's member variables it says . . .
isConnected = true
isCreated = true
isInputShutdown = false
isOutputShutdown = false
isClosed = false
isBound = true
... which looks like I should still be receiving packets just fine. So how do I figure out why I'm sending RST?
N.B. - there are no settings to "sleep" or turn off the wifi or display or any other battery-saving features set enabled on this device.
The 1 minute delay looks like a timeout. It may be the SO_TIMEOUT but this does not generate network activity on itself. Also the fact that the last packet sent contains 31 bytes of data seems to indicate that the application is involved. A possible scenario would be :
The android application times out (on its own or triggered by a socket's SO_TIMEOUT)
It sends a last chunk of data, e.g. by flushing an output stream.
It closes abruptly the socket, for example by using the setSoLinger(true, 0) socket option.
None of those Socket methods returns the state of the connection. They are all about the internal state of the java.net.Socket object, as determined by which constructors and methods you have called on it. They don't magically start returning false if the peer drops the connection.
You will find when you go to use the socket for I/O that you will get an IOException: 'connection reset'.
Why the connection has been reset is another matter. The usual reason is that you had sent to a connection that had already been closed by the peer, or that the peer closed the connection without reading all the data that had already arrived. In other words, an application protocol error. There are other reasons, but these are the most common.
This could be caused by your NAT router that tries to close sockets after a timeout to free up resources. Turning on keep_alive may help. You can also try to create your own network with static IP addresses bypassing the router to rule out this hypothesis.
When the connection is closed the isClosed() method should return TRUE.
It's OK for the isConnected() method to return TRUE even if the connection has been closed because what that method tells you is "if ever you managed to get connected", the variable state is not changed/refreshed when you get disconnected.
However in your case the connection has definitely not been closed as per documentation.
For more info see:
https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html#isConnected--
https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html#isClosed--
Note: It might help you to set to TRUE setKeepAlive(boolean)
See also:
https://docs.oracle.com/javase/8/docs/api/java/net/SocketOptions.html#SO_KEEPALIVE
https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html#setKeepAlive-boolean-
Back to the problem, check for one of the following:
Can you make sure for some reason there isn't another device with
the same IP as the Android? Also turn off you 3G/4G and stay
connected only in the wireless network.
Is there a router doing NAT ? In this case the router can send the
RESET flag.
If everything seems fine (it's your Android phone replying with RST) and the SO_KEEPALIVE does not work then it might be some application level error that is killing the connection.
Is there an easy way, to see which ports are open on my Android device and a way to close the open ports?
Create a wifi hotspot on your phone
Connect your computer to the hotspot
use ipconfig or ifconfig to know the gateway IP adresse ( ie: your phone's IP adress )
Download nmap : http://nmap.org/
Use the nmap command : nmap -sS -Pn -p- your_phone_ip_adress
the open TCP ports will be shown as follow :
65531 closed ports PORT
STATE SERVICE
53/tcp open domain
8187/tcp open unknown
38647/tcp open unknown
42761/tcp open
unknown MAC Address: A4:9A:58:::** (Samsung Electronics Co.)
PS : For UDP ports use: nmap -sU -Pn -p- your_phone_ip_adress
You can determine the currently open ports by reading the textual /proc pseudo-files such as
/proc/net/tcp
/proc/net/udp
This is basically what a netstat command (where implemented) does - you may wish to find and examine the source of a simple netstat implementation (it should be possible to port such to java)
However, when running as an unprivileged app userid, you will only be able to close sockets belonging to your own process (or by roundabout means involving ptrace or process killing, other processes belonging to your userid). Also note that closing a socket does not necessarily make that port available for immediate re-use.
You can try different network commands through runtime and check the results
// netstat -lptu
// netstat -vat
Process su = Runtime.getRuntime().exec("netstat -vat ");
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.
Any command to know the MTU size of Android?
You should use the NetworkInterface class to query and obtain the network interfaces, then call getMTU().
Today, looking into the code of netcfg I saw that the configuration of the interfaces is located into /sys/class/net.. and then I thought of you! (I read your question yesterday)
If you have root access, open a terminal and run
cat /sys/class/net/<interface>/mtu
Methods to know the MTU size of Android:
from terminal: ifconfig $DEVICE | egrep addr\|MTU
through Android Debug Bridge (adb):
adb shell netcfg | grep UP to find the desired address and
adb shell ip addr show rmnet0 in case of rmnet0 or
adb shell cat /sys/class/net/rmnet0/mtu in case of rmnet0 (as described by #patedit)
Without ROOTING your phone, you may use a ping command from a Windows/Mac/Unix system. Though, the syntax of ping-options is very different for different OS.
For Windows
try this:
ping /l 1473 /f 10.68.34.75
/l <Size> — Specifies the length, in bytes, of the Data field in the echo Request messages sent. The default is 32.
/f — Specifies that echo Request messages are sent with the Do not Fragment flag in the IP header set to 1 (available on IPv4 only).
Adjust the payload using the -l command-line option. When you reach the higher limit, you will see this message and you will find the MTU size :
> The packet needs to be fragmented but DF set.
More details: https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router
1480, I believe, but you can check by using ifconfig $DEVICE with a rooted device, and checking the MTU there.
For most network access, MTU could be resolved by MTU Discovery. You can use Ping command with different payload size and don't fragment to find aChrysler value. Good luck
Without ROOTING your phone, you may use a ping command from a Windows/Mac/Unix system. Though, the syntax of ping-options is very different for different OS.
From most Unix/Linux/Mac systems (Without ROOTING the phone)
You might share the internet connection from your phone, and then from any PC connected to your android-phone run ping commands:
ping www.yahoo.com -s 1413 -M do
man ping says:
-s <packetsize> — Specifies the number of data bytes to be sent. The default is 56, which translates into 64 ICMP data bytes when combined with the 8 bytes of ICMP header data.
-M <pmtudisc_opt> — Select Path MTU Discovery strategy. <pmtudisc_option> may be either do (prohibit fragmentation, even local one), want (do PMTU discovery, fragment locally when packet size is large), or dont (do not set DF flag).
Adjust the payload using the -s command-line option (for example: 1200, 1300, 1400, 1500, 1450, 1425, 1440, ...). When you reach the higher limit, you will see a message like this and you will find the MTU size :
> From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1500)
ping: local error: Message too long, mtu=1500
My answer is based on this one for windows: answer #25165641