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).
Related
I have doubt while making my router as DHCP server that is:
suppose I made my router a DHCP server and I have connected one computer to the router which will listen to all the user requests now I have added more devices like mobile phones etc. But till now as we know we have only one device (server) which listens to user requests my question is, Is there any possibility that because of all other devices my server won't able to get user requests? I know question can be silly for you I want to know the answer.
Thanks.
DHCP protocol has an explicit mechanism for packet loss. Clients are supposed to do a retry on renew or fall back to start over with discover messages. If there is one more computer on the network is probably less important than the number of clients trying to renew their IP address at the same time. I have seen networks with 70,000 devices managed by a single DHCP server with no problem. Of course the DHCP server needs to be fast in all aspects: network latency, storage speed (for the lease data base) and processing speed. If the question is whether the DHCP protocol traffic can hinder other protocols? Then the answer is potentially yes, but probably only at times when many device go online (and need an IP address) at the same time. The overall traffic on the network generally is most likely not influenced by the very small amount of data single DHCP messages create.
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.
I have a machine, with no external IP address, it will need to send UDP packets to the outside world. Only NAT access.
Will this work?
It is really hard to prototype this in our environment.
It is still really under construction.
Any thoughts on how I can prototype this?
Most of the home network configurations in the world are made of a PC with an internal IP and a router with a public IP that NAT the internal one. (Independently of UDP/TCP or whatever protocol that needs to go out)
I see no troubles with it
It should work.
Ensure that for the socket created, set the TTL (time-to-live) to a value that is sufficiently large to cover the possible number of router hops to reach the destination. Running traceroute to the destination IP will give you a rough idea on the number of hops. Note that this value can change depending on network conditions. So it's best to set this to a larger value. Refer to sockets IOCtl API documentation for the syntax for setting TTL.
Finally, remember that UDP is not a reliable protocol. So even after taking the necessary steps above, the packet may not reach its destination. However, if the entire network, including the intermediary routers, is within a controlled environment, such as a corporate intranet, chances of packet drop are minimal.
If you want to add reliability on top of UDP, you can adopt a NAK based algorithm where packets are stamped with a sequence number. Various resources might advise you that if you need to add reliability over UDP you should consider TCP, but my experience has been that if your app runs in a controlled environment with very minimal chance of packet drops and you need fast connection setup and tear down, adding a lightweight reliability over UDP has its merits. Also TCP connections take up valuable space in the OS kernel whereas UDP don't. This could also be a consideration if you want to support very large number of 'connections' in a constrained environment.
At the end of the day you need to experiment a little to figure out what works best for you.
To prototype, I would set up a NAT server using something like Linux and then start working from there. Real world traffic scenarios that you want to simulate will determine where the client and server are to be located on either side of the NAT. That is, if the traffic should go through an ISP or all within a controlled environment.
HTH
I am creating a class which communicates with remote server. Currently my device (iPhone 4) is having connectivity via wifi and local network cellular. By default it uses wifi. It works fine in both the cases.
However when I switch from wifi to cell service, it hits error delegate. I want keep communication on going even when connectivity is changed.
Is it possible? How?
Thanks,
I don't expect it is possible. Having switched networks, you've probably also switched IP addresses. Connections are defined by the IP addresses of the end points (as well as protocol and protocol-specific data such as port numbers). So, you can't maintain a connection when the IP address changes. You must cleanup and dispose of the broken connection and open a new one.
If the high-level protocol you're using, such as FTP or HTTP, allows it, you can try resuming the data transfer at the point it was interrupted. For example, if downloading a file, you may be able to resume the download at the file position of the last data you received.
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.