Question image
Can anyone tell me how to solve the question iv) ? I don't really understand what the question is looking for. What does it mean by device interface's ip address?
Your device may have several network interfaces. Those can correspond to real devices (NICs) or be virtual.
In order to be usable (i.e. initiate or listen for connections), each interface should have an IP address. Usually there will be one IP per interface, but it's possible to have several via IP aliasing.
Individual connections on each IP address are identified by port number. There is a limit of 65536 ports per IP address imposed by the IP protocol. One reason behind IP aliasing is to overcome this limitation.
Related
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.
Recently I was working with the Berkeley socket API for IPv6, and noticed that IPv6 addresses (sockaddr_in6) have a field called sin6_scope_id, which was not part of IPv4 addresses.
After searching around a bit, I’ve learned that scope_id is meant to identify the network interface, because multiple network interfaces can have the same link-local IPv6 address. This made sense, but then what I didn’t understand is how IPv4 handles this issue, if there’s no equivalent of scope ID there?
Is there a mechanism in the kernel that prevents multiple IPv4 interfaces from being assigned the same link-local address?
If that’s the case, then why was it necessary to invent scope ID for IPv6 instead of going with the same solution as IPv4?
Also, is the scope_id only used to distinguish between interfaces with identical link-local addresses, or are there other use cases too?
In short, no, there is no well-defined mechanism for handling link-local IPv4 addresses on hosts with multiple interfaces. There is nothing stopping the same link-local address being selected for two different interfaces (however if the two interfaces are on the same network link, then ARP-based conflict detection will cause at least one of them to be reassigned).
RFC 3927 section 3.2 covers the issues of "address ambiguity":
Given that the IP stack must have the outbound interface associated
with a packet that needs to be sent to a Link-Local destination
address, interface selection must occur. The outbound interface
cannot be derived from the packet's header parameters such as source
or destination address (e.g., by using the forwarding table lookup).
Therefore, outbound interface association must be done explicitly
through other means. The specification does not stipulate those
means.
And also in section 6.3:
Application software run on a multi-homed host that supports IPv4
Link-Local address configuration on more than one interface may fail.
This is because application software assumes that an IPv4 address is
unambiguous, that it can refer to only one host. IPv4 Link-Local
addresses are unique only on a single link. A host attached to
multiple links can easily encounter a situation where the same
address is present on more than one interface, or first on one
interface, later on another; in any case associated with more than
one host. Most existing software is not prepared for this ambiguity.
In the future, application programming interfaces could be developed
to prevent this problem.
This problem was solved in IPv6 by the introduction of a scope ID.
At present scope id is only used for link-local addressing.
As a packet travels from a source IP to a destination IP, assuming that it makes hops across many different routers, how does each router know the next MAC address in the sequence. It is my understanding that for communication in a local network, a computer gets the destination MAC address using the Address Resolution Protocol. But for the intermediary router hops, how does a frame get the next set of L2 Mac headers without storing (at least briefly) the IP address of the next router? Is this a separate protocol or something? How does it even know which router (and thus IP in order to get next MAC address?) it should jump to next
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.
What could cause IP-addresses to be different in one computer?
My Perl variable $ENV{'REMOTE_ADDR'} differs all the time. What could cause this to happen?
Most people do not have fixed IP addresses. They may change daily, or when their connection to their ISP is reset, or all the time if they are behind some kind of proxying layer that may route requests through more than one system.
REMOTE_ADDR refers to the client address, so would be different if you have multiple clients.
If you are testing with one client, perhaps your network interface has multiple IP addresses or you're observing this behavior over time when your IP has changed due to DHCP?