I am working on an embedded software product that runs on an Ubuntu edge computer with multiple network ports.
The software allows the user to change the IP address of the ports via a locally hosted web interface.
In the scenario that a customer changed an IP on one of our devices, but then forgets their setting I am looking for an easy strategy to walk them through detecting the IP.
Ideally this tool would be usable by non-sophisticated customers (we don’t want to walk them through using Wireshark or command line tools).
Is there a service we can setup on our machine that will broadcast its identity across subnets using another protocol like UDP or EtherNet/IP? Then a simple tool the client could install on their computer to ‘scan’ for our devices?
The edge computers also have USB ports if it is easier to broadcast an identify there.
Changing a local IP address to something invalid (=not compatible with its local subnet) generally disables all L3 communication. Limited broadcasts (to 255.255.255.255) still work, but answering to them by unicast most likely won't. The same goes for multicasting - but you could use that for discovery both ways.
Also, the common link-level discovery protocols (like LLDP or CDP) still work since they don't rely on IP.
However, all that is limited to the connected L2 segment at most. Discovery across subnets isn't possible without some kind of infrastructure (discovery sensors, central server, multicast routing, ...). A reasonable way would be dynamic DNS but then again, that requires IP to work.
I think you'd need to take a step back and reevaluate your design. One way would be to verify a user's reconfiguration before it becomes permanent. For instance, you could have a user change the IP setup and then forward the session to the new IP address. If the session isn't continued within five minutes or so on the new address, it reverses to the previous config.
Additionally, some kind of out-of-band management could be useful.
Related
I'm working on a simple Swift app where one user can find other machines on a local network which are running an instance of my app and then send data to that machine using TCP sockets.
My question is how to find IP addresses of devices on same network which are running an instance of my app (cross-platform)?
I was thinking about listing all devices on local network and then
checking whether they have opened specific port (the port my app is
using)?
I also found that Apple provides service called Bonjour which could make my process discoverable. I'm not sure if this solution is good for cross-platform communication.
Apart of Mac-related stuff and high-level solutions (I believe keywords "network service discovery" will bring you to them), there are a couple of things that will work for a local network:
I Have a server that clients should report to. Some short hello-like UDP message and a timeout mechanism will be sufficient to keep a list of available clients in the network.
II Use IP or UDP multicast groups to notify others that a client has just connected to the network. Send a message to a multicast group and listen to this group to build a list of clients.
However, broadcasts and multicasts won't be transmitted through a router. So if your network is large enough only neighbouring clients will hear your notification. In order to overcome it,
III DHCP servers can be configured to provide custom data to clients via unassigned DHCP options. Large networks have usually such server. You probably can use it to send out a list of clients, but I'm not sure about this.
For example, when you make an ssh connection, you are connected to port 22. What happens then? On a very high level brief overview, I know that if port 22 is open on the other end and if you can authenticate to it as a certain user, then you get a shell on that machine.
But I don't understand how ports tie into this model of services and connections to different services from remote machines? Why is there a need for so many specific ports running specific services? And what exactly happens when you try to connect to a port?
I hope this question isn't too confusing due to my naive understanding. Thanks.
Imagine your server as a house with 65536 doors. If you want to visit family "HTTP", you go to door 80. If you were to visit family "SMTP", you would visit door no. 25.
Technically, a port is just one of multiple possible endpoints for outgoing/incomming connections. Many of the port numbers are assigned to certain services by convention.
Opening/establishing a connection means (when the transport protocol is TCP, which are most of the “classical” services like HTTP, SMTP, etc.) that you are performing a TCP handshake. With UDP (used for things like streaming and VoIP), there's no handshake.
Unless you want to understand the deeper voodoo of IP networks, you could just say, that's about it. Nothing overly special.
TCP-IP ports on your machine are essentially a mechanism to get messages to the right endpoints.
Each of the possible 65536 ports (16 total bits) fall under certain categories as designated by the Internet Assigned Numbers Authority (IANA).
But I don't understand how ports tie into this model of services and
connections to different services from remote machines? Why is there a
need for so many specific ports running specific services?
...
And what exactly happens when you try to connect to a port?
Think of it this way: How many applications on your computer communicate with other machines? Web browser, e-mail client, SSH client, online games, etc. Not to mention all of the stuff running under the hood.
Now think: how many physical ports do you have on your machine? Most desktop machines have one. Occasionally two or three. If a single application had to take complete control over your network interface nothing else would be able to use it! So TCP ports are a way of turning 1 connection into 65536 connections.
For example, when you make an ssh connection, you are connected to
port 22. What happens then?
Think of it like sending a package. Your SSH client in front of you needs to send information to a process running on the other machine. So you supply the destination address in the form of "user#[ip or hostname]" (so that it knows which machine on the network to send it to), and "port 22" (so it gets to the right application running on the machine). Your application then packs up a TCP parcel and stamps a destination and a return address and sends it to the network.
The network finds the destination computer and delivers the package. So now it's at the right machine, but it still needs to get to the right application. What do you think would happen if your SSH packet got delivered to an e-mail client? That's what the port number is for. It effectively tells your computer's local TCP mailman where to make the final delivery. Then the application does whatever it needs to with the data (such as verify authentication) and sends a response packet using your machine's return address. The back and forth continues as long as the connection is active.
Hope that helps. :)
The port is meant to allow applications on TCP/IP to exchange data. Each machine on the internet has one single address which is its IP. The port allows different applications on one machine to send and receive data with multiple servers on the network/internet. Common application like ftp and http servers communicate on default ports like 21 and 80 unless network administrators change those default ports for security reasons
I'm building a system that relies on a central server to send the IP address and port of the first user (on mobile or desktop app) to a second user (on mobile or desktop app). The second user establishes a P2P encrypted connection with the first user, using the IP address and port sent by the central server, to send a large file directly (ideally, the actual file doesn't pass through the central server).
This system needs to work even if the users are behind different firewalls / NATs and on mobile or desktop devices, without requiring users to manually open ports.
I've been looking into NAT Traversal Protocol (Teredo IPv6), libjingle (Google's open source suite), STUN, direct socket connections, and direct VPNs between the users.
I'm confused if I'm approaching this correctly. Would all of these options solve this problem independently? Or am I approaching this wrong? Would direct IPv6 connections would straight out, even behind IPv4 routers?
P2P connection is not guaranteed to succeed always. It can fail for the following reasons:
1) Two peers are behind symmetric NAT. (Although Teredo works if one peer is behind symmetric nat.) 2) UDP is blocked
3) If the peer is behind proxy.
4) Double NAT scenarios.
There are three types of ipv6 address - link local, private address & global. Two peers can connect directly over the internet if they have global address. Global address prefix is (200:....). If your building P2P system, you should have fallback mechanism in which case the central server should relay the data between the peers. This way you can make your application reliable at the time make connection faster for most peers using p2p.
I am not expert on this subject, need your suggestions. I have a few devices on ethernet/LAN. I wanted to have these devices communicate over LAN without going into their network configurations. Below is my plan, please let me know if this can be achievable:
1) I install TCP/IP stack on these devices
2) I give them their hostnames like device1, device 2 etc....
3) I configure these devices for local-link networking, so that they can configure themselves and get their IPs.
4) I use socket programming and access each device by using hostnames.
Please let me know if this can be done without much hassle, and let me know if I have missed out something in above mentioned points.
Thanks in advance.
This is basically a good approach.
If your embedded devices have a good IPv6 stack, I recommend using it instead of IPv4. link local addresses work better with IPv6. Most IPv4 stacks are configured to try to obtain an address from a DHCP server first, and only fall back to link local addresses if they can't get one. The link local address and DHCP address might be mutually exclusive, so the link local address doesn't become operational until after DHCP has been tried and timed out. The link local address might even be disrupted if DHCP periodically retries. Although the devices will normally be connected to each other and there won't be a DHCP server, you don't want to disable DHCP, because the devices probably should obtain a DHCP address if they are ever connected to a wider network. With IPv6 on the other hand, the link local addresses come up immediately when the interface comes up, and stay up continuously while other IP addresses (from autoconf or from DHCPv6) may come and go.
Link local addresses alone won't let the devices contact each other by hostname, but dns-sd (mDNS, zeroconf) will. If you are using Linux then you can use avahi as a dns-sd stack.
Better than using hostnames, consider having the devices probe for each other by dns-sd service type. If you are using a custom protocol between your devices, make up a unique service tpe name and have the devices advertise themselves it and probe for it with dns-sd.
I want to develop an iPhone app with a simple IM feature. I am thinking about setting up an HTTP server on an iPhone. If the iPhone is using wifi and is behind a firewall, how can I make sure that other iPhone clients can connect to it?
It's not the firewall that will disturb the connection as much it is the NAT.
When you are connected through wireless router to connect the internet you are surfing via NAT. it means you dont really have an extenral IP but once you initiate connection the router will map your intenral IP to one of his externatl ports and for certain time window he will pass connections to you if he will get it to the right port.
That being said, there is no actual way of setting a server behind a NAT unless you can configure port forwarding in the router and internal static IP.
Hope i was clear enough, good luck
I do not really think that you need to get an HTPP server up and running on iPhone to make an application that can send and receive messages (IM). The idea of making one iPhone user to directly connect to one another does not seem right to me since the users will need to know IP addresses of one another to do that.
Interconnectivity between different users of the chat can be solved by making your application communicate via a dedicated TCP port. It is generally advisable to choose ports with a number higher than 1024 since those below are generally found on the list of so-called well-known ports and are used for Web (like port 80), FTP (port 21), SSH (22), DNS (53), etc., it will be the responsibility of the user to make sure the port used by your application is open on the firewall. In order to solve this problem you can actually use port 80 for communication if you find that the port you have selected is blocked. You can do this because you know that this port will not be blocked in most cases. Indeed Yahoo Messenger is reported to use this technique when the firewall blocks the port it uses for communication.
The port should be used by your application to connect to the Web-server that will actually store user credentials, perform authentication, message transmission, etc., and the server should reside on capable hardware to be able to support large number of simultaneous connections. I can suggest using either a VPS (like the one provided by Linode) or a cloud (like Amazon EC2, Google Application Engine, Rackspace).