Created by [ Rowan Dempster], last modified by [ Henry Wang] on Feb 04, 2020
If you have any more questions that are FAQ, add a comment to the Confluence, or message me (Henry Wang{.confluence-userlink .user-mention}).
There are several ways in which an interface (sensor or host) can be configured an IP:
The various ROS launch files that we use to configure our sensor drivers rely on the device IP address as input. DHCP and LLC do not guarantee the same IP address for the sensor's interface for every boot up, which would require the launch arguments to be changed as well. The same logic generally applies for why the Rugged's interfaces need to be static.
In the context of networking, bandwidth has been unfortunately overloaded to mean the data rate capacity or what data rate is still available. Throughput is the realized data rate. Bandwidth is the cross sectional area of the water pipe, throughput is the actual cross sectional area of water flow.
In the Network Connections tab, there is a list of configurable network connections, each of which is applied to a particular interface. By clicking on it, one can edit and view the configurations for a particular connection. The LIDAR-Network connection has several tabs, we're mostly interested in IPv4 settings. There are 3 IPv4 addresses in the list, which means that this particular interface has 3 IP addresses. Yes, an interface can have multiple IP addresses. Notice there's an address with the network address 192.168.1.0/24 and another with network address 169.254.0.0/24. This means that this interface can simultaneously reach hosts with 192.168.1.0/24 network addresses and 169.254.0.0/24, on the same physical network.
PC1: 192.168.1.1/24 --------- Rugged: 192.168.1.77/24
169.254.0.18/24 --------- PC2: 169.254.0.1/24
However, if we had only configured one of those IPs, both hosts would not be reachable.
PC1: 192.168.1.1/24 --------- Rugged: 192.168.1.77/24 ----//---- PC2: 169.254.0.1/24
There are use cases where this might be helpful, but this is quite a hacky solution for our purposes and I do not condone this kind of configuration.
In IPv4, the network address or subnet address is the most significant X bits of the 32 bit IP address, followed by (32 - X) 0 bits, where X is the prefix length, or the number of bits in the subnet mask. The remaining 32 - X bits are host identifier. For example, if there is an interface configured as 1.2.3.4/24, the subnet mask is 255.255.255.0 (in decimal form), the network address is 1.2.3.0/24 (specify prefix length to avoid ambiguity), and the host address is 4.
Let's say we have a setup like this:
PC1: 10.0.0.2/24 --------------------- PC2: 192.168.1.2/24
PC1 cannot ping PC2 and vice versa. When PC1 sends a packet with a different destination network address, PC1 looks up its routing table for the gateway router because PC1 presumes that PC2 is on a different network. Since there's no router in this network, there will be no transmissions. PC1 tries to send a packet to the gateway router (which has some default IP like 192.169.0.1), but the protocol stop here because an ARP request for 192.169.0.1 will not succeed. Why is it liked this? Because that's what the Internet Protocol specifies.
Document generated by Confluence on Nov 28, 2021 22:40