I want to detect all devices in a LAN which have IP: 10.x.x.x Mask: 255.0.0.0.
I first wrote a synchronous ping program to ping IPs one by one, but it's tooooo slow.
Therefore I improved it by using asynchronous ping, then it's much faster.
Now I can use it to detect 10.x.0~255.0~255 in an acceptable time.
But it still use tooooooooooooo long time to detect all the IPs 10.0~255.0~255.0~255.
Is there any method/protocol that can just broadcast one message and let all devices in a LAN to respond, so I can detect all the devices?
(either Ethernet broadcast or UDP/IP broadcast or any other broadcast.)
(I've researched ARP & ICMP but haven't find suitable methods.)
Or any other method even don't need broadcast?
I just need to detect all the devices, any method is OK.
Not sure if it's what you are looking for but you can go in command prompt and run the command:
arp -a
I recommend "Angry IP Scanner" http://angryip.org/
It is fast, detects all devices in a given ip/netmask.
Angry IP scanner is a very fast IP address and port scanner.
From site:
It can scan IP addresses in any range as well as any their ports. It
is cross-platform and lightweight. Not requiring any installations, it
can be freely copied and used anywhere.
Angry IP scanner simply pings each IP address to check if it’s alive,
then optionally it is resolving its hostname, determines the MAC
address, scans ports, etc. The amount of gathered data about each host
can be extended with plugins.
It also has additional features, like NetBIOS information (computer
name, workgroup name, and currently logged in Windows user), favorite
IP address ranges, web server detection, customizable openers, etc.
Related
What is the proper way to connect an app to a device? At the moment, I have a raspberry pi 3 that controls something about electricity and an iPhone app I created. Every time the app goes to foreground, it sends a UDP broadcast message, when the app receives a response from the raspberry pi, it uses that IP address (in the IP header) to consume the web services I created in the hub. This UDP process is done all the time you run the app. Is this what IOT devices usually do? I assume the raspberry pi IP will change sooner or later.
A colleague of mine told me another way: After the first time I get the IP address, instead of using UDP broadcast messages every time the app runs, use ICMP to ping the previously saved IP address to see if it is responding. In that case, I use the web services with that IP address, otherwise, use the UPD broadcast message again.
I don't see the point of that. Basically because the system is not faster using ICMP. (a UDP request is more or less as fast as an ICMP request). Moreover, maybe, another device started using that IP address now (like a smart TV or a smart plug) and for that reason, it is not going to reply to the network requests sent by the app. In that case, the app cannot recover, because it thinks it is already connected to the proper device. As far as I understand, ICMP is a protocol use for diagnosis, not for devices discovery.
What do you think? What's the process used by devices like Alexa, Philips Hue, Smart plugs... to solve the problem of discovering the devices by their apps?
It seems Philips HUE is using SSDP, which under the hood uses a UDP broadcast message. Is it used every time you run the app to discover the IP address? (I am going to check this later with wireshark)
Thanks for suggestions.
You can enable the hostname of your Raspberry Pi to be accessible on your local network through:
http://raspberrypi.local
To enable it, you need to install Bonjour support on your Raspberry Pi by installing the Avahi mDNS daemon (implements Apple's Zeroconf architecture):
$ sudo apt-get install avahi-daemon
Update boot startup:
$ sudo insserv avahi-daemon
Restart to apply the new configuration:
$ sudo /etc/init.d/avahi-daemon restart
I am a newbie in networking and learned about bridging concepts .I have a device which functions as bridge which works in transparent mode and filter mode.In the latter mode , whenever the packet is received to Ethernet port (which is bind to bridge ports of bridge) it floods to other Ethernet ports except the received one through bridging, If the mac address is not learned .How can i ensure this ? can anyone suggest a method to test this.
Every Ethernet switch you can find is a bridge. It learns MAC addresses from ingress frames and uses this MAC table for efficient forwarding. In the unlikely event of an unknown destination address is mimicks a repeater and outputs the frame to all ports but the one it was received from.
If you connect several computers with a bridge/switch and run a packet capture on all of them you'll see that you won't see traffic between two computers on a third computer. Some - broadcast - traffic - will show up on all of them, e.g. when you start a connection and ARP is requesting the destination MAC address for the destination IP address.
I have a server running on a Raspberry Pi and a client running on my Mac and iPhone (soon Apple Watch). I would like to connect to my server automatically without finding the Raspberry pi's Ip-address.
Is there a way to lookup all the devices on the network, and select by Mac-address, name or something else? I know that the first 3 bytes of the mac-address is the same for all Pies. (B8:27:EB) Maby i can use that information.
I have been looking for a solution for this issue a while but i can't seem to find one.
Zeroconf (aka Bonjour)
IMO, the best way to do this is to have your Raspberry Pi advertise itself on the network using Zeroconf (aka. Bonjour).
On the Raspberry Pi, install avahi-daemon and configure it to advertise whichever service you'd like to connect to connect to, for example, if you're connecting via SSH, you'll need to do something like this.
In Cocoa, you can use NSNetServiceBrowser to find the advertised service.
Possible MAC Address solution
Alternatively, if Avahi-daemon is not an option, you may be able to use the MAC address. I will not go into the specifics in Objective-C, just a high-level overview using the command-line.
In terminal, type ping 255.255.255.255. You will get back ping packets from every device on the local network. For each IP address, send an individual ping e.g. ping -c 1 192.168.x.x. Then, type arp -a. You will see the MAC address for each IP on the local network. From here, you can perhaps use your MAC address filter to find Raspberry Pis.
Why does this work? Well, the first command ping 255.255.255.255 sends a ping in an IP packet to the 'broadcast' address, which means all machines on the local network respond. When you ping the individual IP addresses, the low-level networking stack uses ARP to find the MAC address of the IP to directly send a ping to it. In doing so, the ARP tables on the local machine are updated with the cached values.
Maybe you can use this method in your app to discover local Raspberry Pis.
Well..I have found some third party application regarding sending data from com port to IP. but I have not found any basic tutorial regarding them. so can anyone help me with this? I have a GPS device which I will connect to my laptop through usb to serial adapter.Now I need to send that data from a laptop to another laptop on same network. Can I use putty to view that data in another laptop(receiver)? Is virtual serial port driver meant for this kind of application?
If you do not want to write your own tool for it, you can simply use ncat and set up a daemon that reads piped data from one process and broadcasts it to all connected clients.
If you want something that reads the data from the serial port and then transmits it to clients, you'll need to write a server application that accepts connections and sends data around, but there's entire books on this. It should be easy to do for your purposes as written here, but it depends on the amount of control you need.
Alternatively you can use a virtual serial port application as you had mentioned, which might be the easiest route. The two devices will need to be on the same network unless the application supports TCP based virtualization instead of the common Ethernet based implementation.
This Python script works very well as a free "device server". Just enter the serial port configuration and the IP address and port information.
https://github.com/jaredly/pydbgp/blob/master/symbian/serial_tcp_redirect.py
This can work on both Windows and Linux.
You need pyserial.
You can always try using stand alone hardware such as the SENA LS100 device server.
we are currently considering whether ns3 satisfying our requirements, we're looking for a convenient tool to run in distributed devices in the real network (every kind of possible connections) and capture the network performance data (like a sniffer). I realize that the primary purpose of ns3 is to simulate network topology in a single machine, but its emu module sounds promising and the flow monitor can save our effort on data capture.
In the following link
http://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world
it is declared that NS-3 EMU can be applied to inject simulated nodes interacting with real live network, and 3 kinds of testbed are given. However the first solution, virtual machine vmware testbed is still woking within LAN -- in promiscuous mode the virtual machines network card are listening to all LAN broadcasts so that the emu-udp-echo server and client can find each other.
My question is, is it possible that the emu-udp-echo server/client running in different, physical systems from different positions in wide network?
e.g. in different cities or from different network providers, given ip address of the hardware where the other ns-3 node is running? if it is possible, how can i specify the "real" ip address and port for the node, instead of assign a virtual ipv4 address?
Thanks a lot.
Yes, while the documentation describes how to perform this using virtual machines, this can be done in general on real hardware. Since that HOWTO was written, there has been additional work on providing helpers for running this type of experiment, including running on PlanetLab testbed machines. This documentation describes the generalized file descriptor NetDevice, added to the ns-3.17 release: http://www.nsnam.org/docs/release/3.19/models/html/fd-net-device.html. A similar example to the one described in that HOWTO is found in the file fd-emu-udp-echo.cc.
When using emulation mode on real networks, configuration of the MAC addresses and IP addresses must be done carefully. First, the device must be able to be put into promiscuous mode. Second, the MAC address needs to be different than the hardware address of the NIC. If you intend to be riding on top of an active NIC with existing IP address (in use for other Internet traffic), you'll need to have another IP address for ns-3 that is within the right link subnet. If instead you want to dedicate the NIC to ns-3 use, then do not assign the IP address to the host NIC and just assign it to the ns-3 configuration.
The PlanetLab example also shows another configuration that uses Tap devices to send data to/from PlanetLab testbed nodes. Some of this configuration is specific to how PlanetLab works, but the use of Tap device bridged to an ns-3 device may also facilitate emulation.