Anyone have idea how can find available IP addresses in a network using any protocol?
UDP broadcasting is one way. But in this case every one should have a listener app?
Please suggest if have any other way?
You could send ICMP pings to the broadcast network address. For example, if your interface IP is in the 192.168.0.0/24 network, you would send pings to 192.168.0.255 -
[22:45:54 jmac:~]$ ping 192.168.0.255
PING 192.168.0.255 (192.168.0.255): 56 data bytes
64 bytes from 192.168.0.12: icmp_seq=0 ttl=64 time=0.159 ms
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=99.708 ms
64 bytes from 192.168.0.12: icmp_seq=1 ttl=64 time=0.147 ms
However to send ICMP ping from an application, you'll need to open raw sockets & thus you'll need root permissions. The ping program on most OSes are setuid root programs, so they can be invoked by any user.
Related
My goal is to send a UDP message (smaller than 100 bytes) from a SmartWatch (running wear os 2) to an Arduino on the same network. As long as the SmartWatch stays connected to the wifi (ip address of the watch: 145.167.189.23) this works great.
But when I turn on bluetooth, the SmartWatch disables wifi and switches to an internet connection via the bluetooth connected phone.
The SmartWatch gets an ip address in a subnet of the internet connection from the mobile (if the mobile has the ip address 145.167.189.105, it gets 145.167.177.4). TCP requests, like 'stackoverflow.com' work fine.
If I now try to send a UDP message nothing arrives at the Arduino.
I already tried to send a UDP message to 255.255.255.255, 145.255.255.255, 145.167.255.255, 145.167.189.255, but nothing ever arrived at the Arduino ( verified by Wireshark).
Over six years ago there was the same problem (Simple UDP Broadcast not working on Android Wear), at that time wear os 2 was not available. The only proposed solution was the 'Wear Data Layer'. I already tried this as well, but observed very large latencies (about 3 seconds). Therefore, these do not represent a solution for me at all.
The documentation for network access on wear os only says
You can use protocols such as HTTP, TCP, and UDP
Maybe someone could give me a hint why the UDP messages are not forwarded from the phone.
Only DNS udp packages can be forwarded to the phone.
It setup some iptable rules to forward udp packages to the TPROXY. Look at the following rules (iptables -t mangle -L). It does't forward udp packges to Reserved IP addresses.
Chain oem_CW_PROXY_UDP (22 references)
target prot opt source destination
RETURN all -- anywhere 0.0.0.0/8
RETURN all -- anywhere loaclhost/8
RETURN all -- anywhere 100.64.0.0/10
RETURN all -- anywhere 127.0.0.0/8
RETURN all -- anywhere 169.254.0.0/16
RETURN all -- anywhere 172.16.0.0/12
RETURN all -- anywhere 192.0.0.0/29
RETURN all -- anywhere 192.0.2.0/24
RETURN all -- anywhere 192.168.0.0/16
RETURN all -- anywhere 198.18.0.0/15
RETURN all -- anywhere 198.51.100.0/24
RETURN all -- anywhere 203.0.113.0/24
RETURN all -- anywhere 224.0.0.0/4
RETURN all -- anywhere 240.0.0.0/4
RETURN all -- anywhere 255.255.255.255
TPROXY udp -- anywhere anywhere TPROXY redirect 0.0.0.0:35070 mark 0x1/0x1
The TPROXY will forward the reveived udp packcages to the phone throught bluetooth socket. But it will only forwoard DNS packages, which can be seen from the watch's logcat.
It seems that Wear OS decided to only forwoard DNS packages at some time.
05-20 12:20:31.269806 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 47 bytes, from: /192.168.167.239:36215 original dst: /8.8.8.8:53
05-20 12:21:05.264492 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 47 bytes, from: /192.168.167.239:63348 original dst: /8.8.8.8:53
05-20 12:21:05.272685 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 32 bytes, from: /192.168.167.239:34219 original dst: /8.8.8.8:53
05-20 12:21:38.282089 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 47 bytes, from: /192.168.167.239:54529 original dst: /8.8.8.8:53
05-20 12:21:38.287255 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 32 bytes, from: /192.168.167.239:58688 original dst: /8.8.8.8:53
I am new to tcpdump tool and I am working in the analysis of network packets, I have analysed the IPv4 Ip packtes generated in case of wifi. But Now I am running my android phone in sim's 3g network which is generated the IPv6 packets ,completely different form IPv4 format. I am confused about the IPv6 packets structure,
Again, I have gone through the IPv6 header format, and my phone's packets given below, These two format does not match. I am totally confused about IPv6 header.
My mobiles's local ip is 100.87.163.16 ,my question is how to detect the received packets and sending packets. Also I want to find out the header length , payload length, source and destination ip address in IPv4 format. I am looking for your valuable suggestions.
Thanks.
10:59:06.365651 00:00:32:06:af:56 (oui Unknown) > 45:00:00:a8:35:49 (oui Unknown), ethertype Unknown (0xd83a), length 168:
0x0000: c40e 6457 a310 01bb e6c0 f6b1 b5ed ec6b �.dW�..������k
0x0010: 23f8 8018 015e dfc7 0000 0101 080a 17c2 #�...^��.......�
0x0020: 6af1 0014 f0c3 1703 0300 6f00 0000 0000 j�..��....o.....
0x0030: 0000 0208 7db4 d0c1 846d ca75 323c e6cb ....}���.m�u2<��
0x0040: 1636 be16 942f 51ea 1caf 1c09 c085 3dbc .6�../Q�.�..�.=�
0x0050: 7642 vB
OK, let's reconstruct the full raw packet contents.
The driver supplied an ARPHRD_ value that got mapped to DLT_EN10MB (probably an inappropriate ARPHRD_ value; this is a known botch in some Android mobile phone interfaces, probably done to cope with inadequacies in the DHCP implementation, and later versions of libpcap work around it), so the packet was interpreted as if it were an Ethernet packet, when it probably was, in fact, not an Ethernet packet.
So tcpdump printed the packet as if the first 6 bytes were a destination MAC address, the next 6 bytes were a source MAC address, and the next 2 bytes were the type/length field.
Thus, the packet began with:
45 00 00 a8 35 49 00 00 32 06 af 56 d8 3a
and that really looks like an IPv4 packet with no link-layer header - which is exactly what the mobile phone interfaces in question provide as packets.
libpcap 1.6.2 and later have the libpcap workaround; if you use a version of tcpdump that uses a later libpcap, that will probably show the packets correctly. (If they don't, perhaps the hack libpcap uses to detect the bad ARPHRD_ values need to check for more interface names; please report this to tcpdump-workers#lists.tcpdump.org or on the GitHub issues list for libpcap. (Report this as a libpcap issue, not a tcpdump issue, as that's what it is.))
I want to discover all Android devices IP and Port in same wifi network using ZeroMQ?
My app basically connect all device in same wifi network (no internet needed) and message to each other. Once ip and port I know I am send message successfully but how to know all device internet Protocol (ip) Using ZeroMQ?
Principle
Part A)
Every IEEE 802.x CSMA/CD network "collision domain" ( wifi AP/SSID is such one ) has to be managed so as to work well. Thus the Address Resolution Protocol [ARP] will help you in the task to find all ISO-OSI-Layer-3 IP Addresses. Wifi Access Point [AP] host, to which all live devices register and handshake with, is the choice to start with.
HG520i> ip arp status
received 54205 badtype 0 bogus addr 0 reqst in 12105 replies 196 reqst out 14301
cache hit 63152696 (24%), cache miss 19455672 (23%)
IP-addr Type Time Addr stat iface
192.168.0.230 10 Mb Ethernet 290 00:15:af:e6:b1:79 41 enif0
192.168.0.62 10 Mb Ethernet 300 00:0c:29:98:d4:3b 41 enif0
192.168.0.55 10 Mb Ethernet 300 00:27:0e:07:c5:9e 41 enif0
192.168.0.255 10 Mb Ethernet 0 ff:ff:ff:ff:ff:ff 43 NULL
num of arp entries= 4
Part B)
Scanning all the ports on all the known IP hosts is a dumb brute force approach to the second issue.
Scanning just a subset of "reasonable" ones would save you both the time and efforts on peer-recognitions.
Using some smarter, active "visibility self-advertisement policy" will save you even more.
Solution
Decide on multi-party system architecture, whether an individual passive scan, a central/distributed proxy-assisted scan or an active self-advertisement policy will be used to build and maintain live records in a neighbouring hosts register.
ZeroMQ per-se brings you a lot of power for the smart solutions, while the dumb-force solutions would have to wait till fully fledged ZeroMQ services will be ready. Low level L2/L3-inspections will have to bring their fruit before ZeroMQ can first .bind()/.connect()
Needless to say, that uncoordinated CSMA/CD networks do not guarantee that all the L2-visible hosts will have "compatible" L3-ip-adddress ( will belong to / have the same L3-ip-network address ).
Thus you never know about all IP addresses without a truly low-level sniffer.
i have a big problem and i doubt about my intellect... I connected my android tablet (intenso tab814) to a RS232 converter (USR-TCP232-E) via a router (TL-WR740-N) and i send 7 hexadezimal bytes in a block, kinda 03 20 05... with further numbers. My problem is, if i let my tablet send, the converter receives the data, but does not submit it to a listening program on an pc behind the converter complete. There are often complete blocks missing (bnot single Bytes, but the whole command line i send), but if i send my data via tablet to another PC, and let HIM do the sending work to the converter every single byte arrives. It may be a bit dazzling, but i dont know, where this problem could belong to. My App sends every block correctly (the pc is able to receive)
The converters yellow RJ45 port-LED blinks, but i does not give the data to the listening pc.
For better understand:
Tablet(selfpogrammed app) sends data -> router -> converter (everytime blinks) seldom gives the command -> PC(selfwritten listening programm(not written by me, but by the one, i am the follower of, not familiar with language.)
But if i:
Tablet(same app) -> router -> PC (receives all the data) -> router -> converter always give the data to the listening progamm ->pc
What is the matter here? Why does the converter gives the data from app -> pc to listening pc, but not from app to listenign pc?
Tablet is connected via W-Lan to router, the pc's via RJ45-cable, the converter either. Using TCP/IP converter as server.
PLS HELP Q_Q
EDIT:
configuration:
Baud Rate: 115200bits/second
Data Size: 8 bits/characterParity: None NoneOddEvenMarkSpace
Stop Bits: 1bit(s)
Flow Control: None
Local Telnet Port Number: 2001
Remote Telnet Port Number: N/A
Telnet Mode: TCP Server
Telnet Server IP: N/A . . .
Telnet Timeout: 0seconds seconds (< 256, 0 for no timeout)
UART packet Time: 10ms ms (< 256)
UART packet length: 200
EDIT:
forgot sth to mention. the converter is via RS232 to an USB converter from RS232 to USB connected. Its receiving lamp does not blink, when the listening programm does not show my commands, but if the programm spits my lines out, the USB-part blinks too. So the converter receives, but does not give it to the USB. But only if i use my tablet. Same interval all the time.
Was my own fault, forgot to use a bufferedoutputstream, now it works.
I need to get my app to play a video file located on my network. I know the url of the file is:
http://something.local/abc.mp4
Now, when I manually substitute "something.local" with its true ip address, the MediaPlayer has no problem playing it. Nonetheless, when I have the above address, the MediaPlayer errors out with error (1, -1007).
So I'm assuming this is because Android doesn't understand "something.local" as being correct.
My question is: How can I "translate" something.local into an ip myself, so that I can then pass it into MediaPlayer?
A small caveat: I believe that MediaPlayer does not work with IPv6 addresses, so please keep that in mind...
Just a side note, in case it makes my situation clearer: When I run ping something.local -4 in the Windows command prompt, it returns:
Pinging something.local [192.168.1.126] with 32 bytes of data:
Reply from 192.168.1.126: bytes=32 time=145ms TTL=64
Reply from 192.168.1.126: bytes=32 time=112ms TTL=64
Reply from 192.168.1.126: bytes=32 time=32ms TTL=64
Reply from 192.168.1.126: bytes=32 time=169ms TTL=64
That translation where windows went from something.local -> 192.168.1.126 is what I want to do in my Android app.
Firstly, you need read document about Bonjour (iOS term) or Zero Config (Linux term).
To understand what's something.local:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/NetServices/Articles/about.html#//apple_ref/doc/uid/TP40002458-SW1
For example, if a user types steve.local. into a Web browser, this
tells the system to multicast the request for steve on the local
network instead of sending it to the conventional DNS server. If a
Bonjour-enabled computer named steve is on the local network, the
user’s browser is sent the correct IP address for it. This allows
users to access local hosts and services without a conventional DNS
server.
For how to resolve it:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/NetServices/Articles/NetServicesArchitecture.html#//apple_ref/doc/uid/20001074-SW1
For java library, previous answers provided good enough example.
You should try this snippet with jmDNS library api.. may need some changes.
JmDNS jmdns = JmDNS.create();
DNSEntry addressEntry = jmdns.getCache().getDNSEntry(name, DNSRecordType.TYPE_A, DNSRecordClass.CLASS_ANY);
if (addressEntry instanceof DNSRecord) {
ServiceInfo cachedAddressInfo = ((DNSRecord) addressEntry).getServiceInfo(true);
if (cachedAddressInfo != null) {
for (Inet4Address address : cachedAddressInfo.getInet4Addresses()) {
// use the `address`
}
}
You have access to java,net APIS on android and can use them to resolve adresses.
http://docs.oracle.com/javase/1.4.2/docs/api/java/net/InetAddress.html
However, success will depend on network proper configuration. Your device receives DNS server setup via DHCP - so you are at mercy of network provider