Given one or more embedded devices of the same type with some unknown IPv4 addresses or maybe no IPv4 addresses set at all: is there any Ethernet based network protocol to ”find“ those devices in the local net (LAN) from remote (PC) and get their IPv4 settings?
What not works for me:
ARP: IP address must be known or only finds device I communicated with before (or ugly ARP floods …)
LLDP: point to point only (?), so I would only see the switch between device and me. Also, just announces, no response on request (because there are no requests). Further: asking the switch (which supports LLDP) through SNMP is no option when using dumb switches
IP based protocols: I played with UDP and broadcasts (both as request and response), but that does not work reliably if device and me are on different subnets, and it does not work at all if device has no IPv4 set.
DHCP: does not work in networks without DHCP server, maybe no DHCP client on the embedded device
I assume others had the same problem before, take manufactures of network equipment like access points which should be configured remotely, powerline adapters, switches … all those where the vendor gives you some proprietary tool, the device shows up like magic in a list and you can assign some IPv4 then.
Of course the device must have some daemon listening and responding to certain requests, but what would be a standard protocol for such a task? Or do I have to make up some new protocol for that? May some of the above mentioned is possible, but I overlooked something?
Ethernet only provides a layer 2 connection, so anything Ethernet-based can't ever work across a router (ARP, LLDP - LLDP doesn't even cross a decent switch as it's link layer only).
Depending on the network, routed multicasts or directed broadcasts could work - normally they don't. All vendor tools I've seen just use (Ethernet) broadcasts and don't work across routers.
Most often, simple DNS is used for this purpose - the device registers with the DNS server or is preregistered and you just resolve the name.
Edit: without the router problem, the simplest way is to use a UDP broadcast to some unused port. With DHCP unavailable, the device could fall back to zeroconf (169.254.0.0/16) and broadcast from there.
Without IP, you'd need a "raw" Ethernet socket and use an Ethertype that doesn't interfere with normal network operations.
Related
Is there a way to use socket connection between raspberry pi 3 and android app using cellular network,NOT a localor wifi network ?
Theoretically, yes absolutely - so long as each device has an IP network connection you can open a socket between them.
In practice, however, you may find you have two issues:
getting 'external' IP addresses
ensuring that your stream is allowed on your target networks
By external IP addresses, I mean ones that are globally recognised and not just on a local or private network. Most local networks and operator mobile networks use private addressing internally and some sort of NAT (Network Address Translation) function to map these internal addresses to external addresses.
Unless you have a fixed IP address, which is not the norm, you will have to discover what IP address your deice appears on externally and then share that with the other device to allow the socket to be set up. This may change every time you connect to the network, or even more frequently, depending own how the network is set up. Techniques and protocols do exist to do this, such as STUN: https://en.wikipedia.org/wiki/STUN
Assuming you can get the end point addresses in a form that allows them communicate with each other, you will also need to check that your operator, and any local network policies or firewalls you have, allow the type of traffic you want to use. Cellular network operators sometimes block certain traffic types, either for security or to try to stop services which they see as competing with their own services.
Imagine there's relatively complex network infrastructure, from PC, then intelligent hub, then router, then area network switches, then internet, and then same chain of devices towards the server.
Imagine I make HTTP request from some local PC's IP address and some its local port, to the remote server's port 80 (HTTP). Under normal circumstances communication goes from connection request packet, through acknowledgments and requests, and then finally till the finalization and channel close. All intelligent network devices can see this communication, and act accordingly.
Now imagine the following situation: PC makes request from its IP address and some fixed source port, receives half of data, and then reboots. After reboot it again makes request from same IP address and same source port.
Question - which possible behavior it will cause at network devices involved? How are they going to handle previous session before PC reboots?
This is very open ended question, and I need your view onto the situation. It is caused by me having strange problems with embedded network device, which reuses port numbers after power-cycle. I plan to see what is going on on the network using Wireshark, but need direction where to look at. Thank you.
Edit: I am adding proxy server(s) into the chain (which can work higher level than layer-3).
I'm on the client side. There're multiple network interfaces. How can I let different processes use different network interfaces to communicate? Since I want to connect to the same server, routing seems not working here. Also, connect() doesn't have arguments to specify local address or interface as bind() does.
If your goal is to increase bandwidth to the server by using multiple network interfaces in parallel, then that's probably not something you can (or should) do at the application level. Instead, you should study up on Link Aggregation and then configure your computer and networking stack to use that. Once that is working properly, you will get the parallelization-speedup you want automatically, without the client application having to do anything special to enable it.
"The bind() system call is frequently misunderstood. It is used to
bind to a particular IP address. Only packets destined to that IP
address will be received, and any transmitted packets will carry that
IP address as their source. bind() does not control anything about the
routing of transmitted packets. So for example, if you bound to the IP
address of eth0 but you send a packet to a destination where the
kernel's best route goes out eth1, it will happily send the packet out
eth1 with the source IP address of eth0. This is perfectly valid for
TCP/IP, where packets can traverse unrelated networks on their way to
the destination."
More info e.g. here.
That's why you probably misunderstand bind() call.
The appropriate way to bind to physical topology (to some specific interface) is to use SO_BINDTODEVICE socket option. This is done by setsockopt() call.
Source Policy Routing might be helpful.
Try the following steps:
Use iptables to give packets from different process with different marks.
Use iproute2 to route packets with different marks to different table.
In different table, set the default route to different uplink.
The whole process require certain amount of understanding about linux networking.
Here is an example shows how to route all traffic for a user through one specific uplink: http://www.niftiestsoftware.com/2011/08/28/making-all-network-traffic-for-a-linux-user-use-a-specific-network-interface/
You could try follow similar approach by running different process with different user and route traffic from one user to one uplink.
Also you could let processes communicate with the server with different port and mark the traffic by port.
I have been working on a local LAN service which uses a multicast port to coordinate several machines. Each machine listens on the multicast port for instructions, and when a certain instruction is received, will send messages directly to other machines.
In other words the multicast port is used to coordinate peer-to-peer UDP messaging.
In practice this works quite well but there is a lingering issue related to correctly setting up these peer-to-peer transmissions. Basically, each machine needs to announce on the multicast port its own IP address, so that other machines know where to send messages when they wish to start a P2P transmission.
I realize that in general the idea of identifying the local IP is not necessarily sensible, but I don't see any other way-- the local receiving IP must be announced one way or another. At least I am not working on the internet, so in general I won't need to worry about NATs, just need to identify the local LAN IP. (No more than 1 hop for the multicast packets is allowed.)
I wanted to, if possible, determine the IP passively, i.e., without sending any messages.
I have been using code that calls getifaddrs(), which returns a linked list of NICs on the machine, and I scan this list for non-zero IP addresses and choose the first one.
In general this has worked okay, but we have had issues where for example a machine with both a wired and wifi connection are active, it will identify the wrong one, and the only work-around we found was to turn off the wifi.
Now, I imagine that a more reliable solution would be to send a message to the multicast telling other machines to report back with the source address of the message; that might allow to identify which IP is actually visible to the other machines on the net. Alternatively maybe even just looking at the multicast loopback message would work.
What do you think, are there any passive solutions to identify which address to use? If not, what's the best active solution?
I'm using POSIX socket API from C. Must work on Linux, OS X, Windows. (For Windows I have been using GetAdapterAddresses().)
Your question about how to get the address so you can advertise it right is looking at it from the wrong side. It's a losing proposition to try to guess what your address is. Better for the other side to detect it itself.
When a listening machine receives a message, it is probably doing do using recvfrom(2). The fifth argument is a buffer into which the kernel will store the address of the peer, if the underlying protocol offers it. Since you are using IP/UDP, the buffer should get filled in with a sockaddr_in showing the IP address of the sender.
I'd use the address on the interface I use to send the announcement multicast message -- on the wired interface announce the wired address and on the wireless interface announce the wireless address.
When all the receivers live on the wired side, they will never see the message on the wireless network.
When there is a bridge between the wired and the wireless network, add a second step in discovery for round-trip time estimation, and include a unique host ID in the announcement packet, so multiple routes to the same host can be detected and the best one chosen.
Also, it may be a good idea to add a configuration option to limit the service to certain interfaces.
I'm looking for some networking gurus to help me with a problem. I have many computers running my software which uses UDP multicasting. This works fine if the computers are connected ONLY to one network (network A). My computer (which is also running said software) will listen on port XXXX for the multicasts. This computer has two network cards and when I connect it to another network, network B, my software goes haywire. The problem is that I do not know what network a given multicast came from. And if I send out a multicast, I cannot tell it to use network A instead of network B or vice versa.
My questions:
Is there a way to distinguish packets coming in from different networks??
Is there a way to send a multicast to network A and NOT network B?
I'm using C++ and Win32 sockets. Thanks to anyone that replies.
You should listen for multicast packets on one interface where you joined the group. You should explicitly set the interface used for sending the multicast packets (otherwise they are routed as everything else, default route, etc.). Both are accomplished via setsockopt calls. Here are some links for you:
Multicast programming - talks about setting "send" interface,
IP Multicast Extensions - talks about both "send" and "receive" interfaces.
Disclaimer: the links are admittedly Unix-centric, so your Windows mileage may vary :)
Working on a project with MC UDP on redundant NICs over the last year, we saw a similar problem. After battling it a bit with winsock, our ultimate solution was to prioritize traffic using the DOS command route
route add 224.x.x.x ... [desired gateway] METRIC 1
This ensured that the traffic only went out on the Interface we wanted.
I realize this might not be exactly what you want, but it could at least be a stopgap solution while you implement another fix.
On multihomed hosts you need to join the multicast group via all interfaces sequentially, or via all the ones you care about. If you are interested in network of origin you could use multiple M/C sockets, each bound to a different interface, same port, and each of them joined to the group; then the receiving socket itself tells you which network any incoming traffic comes from.