I am a student learning computer network.
Here's how my network look like:
Router(NAT)
/ \
My PC My iPad
I have looked up my computer's routing table, and it shows the following:
$ netstat -r
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 172.22.128.1 UGScg en0
127.0.0.1 127.0.0.1 UH lo0
172.22.128.1 0:74:9c:96:72:55 UHLWIir en0 1200
172.22.161.13 ba:2e:b1:6f:69:39 UHLWI en0 740
I confirmed that the ip 172.22.161.13's gateway ba:2e:b1:6f:69:39 is the MAC address of my iPad.
I have a few doubts:
Shouldn't the routing table records ip address of next hop? how can it store a MAC address?
If the command netstat -r also lookups the arp table, how should it send packets to my iPad without going through the router?
The issue here is understanding the functionality of layer 2 and layer 3 in a network.
There is a difference between forwarding packets to the device located on the same subnet and on the device located on the different subnet.
I don't think there is a better definition of subnet, than devices that can communicate via a layer 2 protocol with each other. Routers are used to forward packets between devices in different subnets, that is, two devices in the same subnet do not communicate over the router, at least not over the "router" part of the router.
Devices that are located in the same subnet should be assigned the same IP prefix (i.e., the bits covered by network mask are the same). "Should" means that if it is not the case, then your network is configured wrong and may not work properly. This way your PC and your IPad can determine that they are on the same subnet and do not need to go over their default gateway.
Since your PC and your IPad are on the same subnet, they will talk to each other using layer 2. I am not sure from your configuration how many interfaces are actually wireless. If both interfaces are wireless, they may actually be capable of talking directly (i am not sure if wifi protocol in AP mode allows it, i think it does). If your PC is connected over Ethernet, then your Router also acts as a switch/bridge (which is layer 2 device) and forwards packets according to ethernet specification. You can learn about it by googling MAC learning.
This should answer the second question, now to the first one.
Actually, I wonder why the table is storing IP addresses. IP address of the next hop is not used in forwarding. First, note, that communication between devices which are two hops from layer 3 (i.e., routers) standpoint happens using layer 2. When a device makes routing decision, in takes the destination address from the IP header and looks up next hop, where what the device needs is a) outgoing interface b) how to reach next hop using layer 2 protocol of the interface. Then the device constructs an appropriate layer 2 header and sends the packet to the next hop device, which more or less does the same. So, actually your PC needs mac address of your router's interface to which it is connected to send the packet somewhere outside of the subnet.
Related
If I connect a device via ethernet onto a switch, and do not receive an IP address via DHCP, how do I determine what the correct settings for that network should be, i.e. how do I choose a static IP address, subnet mask and gateway?
The specifics in my case are that I have an NVR with an 8 port POE switch that has 3 cameras plugged into it. I plugged my Windows 10 PC into the switch, expecting to be issued an IP address from the NVR via DHCP, but my PC was not given an IP. Perhaps the NVR assigns IPs via BOOTP? I want to get onto the network, probably by assigning a static IP that's not already used, then determine the IPs of the cameras so I can stream video from them directly using VLC.
Can I use tcpdump? There should be plenty of traffic from the cameras to the NVR.
how do I choose a static IP address, subnet mask and gateway?
The short answer - this should be done by your network administrator. If you are the network administrator - you should. But seems that you are connecting to the network you know nothing about.. Anyway here are some points that perhaps can help you.
There is a special thing called ARP Duplicate Address Detection (DAD). In Linux you can check if the particular IP is occupied in your broadcast segment with help of arping utility. From MAN page:
-D
Duplicate address detection mode (DAD). See RFC2131, 4.4.1.
Returns 0, if DAD succeeded i.e. no replies are received.
So if IP address is occupied you will see something like:
-bash-4.4# arping -D 10.0.99.99 -I eth0
ARPING 10.0.99.99 from 0.0.0.0 eth0
Unicast reply from 10.0.99.99 [DE:AD:BE:EF:00:8D] 1.274ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
If this IP address is vacant, you'll see no responses. Read about ARP ping in Windows.
Also you can inspect the network through the tcpdump (to see some IP addressing info at least in broadcast packets), nmap and some other scanning utilities, but this topic is too broad (and at the same time it's well disclosed on the Internet). Btw you have to consider network architecture difficulties: vlan and so on.
I am just preparing for a test in college about networking.
I'm currently trying around with sub netting and I found out that two devices attached to a layer 2 switch can talk to each other although they have different subnets!
Device A: 192.168.0.1 subnet mask : 255.255.255.0
Device B: 192.168.1.1 subnet mask : 255.255.255.0
The question is why I can ping from device A to B and vice versa?
There's no router, just the two devices and a switch.
From my understanding they should not see each other.
The OS should not even send the ARP request when the unknown IP is in a different subnet.
Could this be a caching issue?
Many Cisco Layer 2 switches are capable to ping the connected systems.
It is possible that your computer might have a route entry that sends a packet which matches no other specific route entry to your router. This is also called as the default gateway. Conventionally the computers in the same subnet are connected directly and most of the times, do not go through the gateway.
To explain it more clearly, If you're on a Linux machine, run route -n.
Destination Gateway Genmask
14.0.1.0 0.0.0.0 255.255.255.0
0.0.0.0 172.16.80.1 0.0.0.0
The first entry has a destination ranging from 14.0.1.0 to 14.0.1.255. The gateway for this match is 0.0.0.0. The table implies that these systems are connected directly. On the other hand, the entry 0.0.0.0 in the destination field will get matched when the packet matches none of the other entries. The gateway for this is the router address (which in my case in 172.16.80.1). All the packets that do not have IPs in the range that I specified above go to the router for further routing. Once the router gets the packet, it takes the further decision based on its routing information that it posses.
In your case the router happens to know that the other subnet is attached to it and hence passed your packet onto that subnet.
Have a closer look at the ARP. The ARP would be addressed to the router in your case of pinging to the other subnet. On the other hand, if pinging within the network, the ARP would be to the destination directly. This is the conventional case. Of course, it all depends on the routing tables in your system. You can always make all packets go through the gateway or no packets to go through the gateway.
I am trying to achieve double NAT working with UPNP. My PC connection is as follows:
Internet -> Router 1 -> Router 2-> PC
I have successfully done port forwarding on the Router 2, but not able to do on router 1. Due to which packets from the server(which is on Internet) are not able to reach PC.
Gone through few document how to tackle but mostly found manual way like bridge the network or put the lan wire.
I am rather looking for the some recursive solution using UPNP protocol to do the port forward on both routers. I guess torrent, skype does the same.
How to get the network interface related to router 1 and then port forward on that Network ?
Any help would be highly appreciated.
Thanks,
Pawan
There is an IGD-PCP IWF specification that tries to solve similar problem, although it assumes PCP support on your "Router 1", not UPnP. So let's try to approach this issue from a pure theoretical point of view with two plain UPnP routers/NAT devices.
There are several distinct steps of UPnP communication as per UPnP Device Architecture version 2.0:
addressing
discovery
description
control
eventing
presentation
Addressing is of little interest for us, let's assume proper DHCP everywhere and be done with it. Eventing and presentation are also almost useless in our case. So the main things to be concerned about are discovery, description and control.
Discovery works via SSDP message exchange. SSDP uses UDP for its transport with port number 1900 (by default) and well-known multicast address.
Description starts with URL provided by the device at discovery phase, the control point (that is PC in our case) needs to issue an HTTP GET request on this URL and that means it uses TCP as a transport protocol with devices IP address (unicast).
Control starts with URL provided by the device in its description, and it uses SOAP on top of HTTP on top of TCP which in turn also means unicast IP for us.
So, what all of that means for double NAT is that in description and control steps of UPnP interaction we have zero problems communicating from PC to Router 1 as all of that is just standard TCP with unicast IP addresses. But to get to the description step we need to have a URL of Router 1, so let's take a closer look at how this URL is acquired the normal way.
There are two main mechanisms for discovery — advertising (when the device periodically multicasts some information about it) and search (when the control point sends multicast search message and the device answers to that with unicast response). Obviously, by default our PC behind the Router 2 can't get multicast advertisements from Router 1 and the Router 1 can't get multicast search messages from PC, so we have a problem here and the question now is whether there is a possibility for communication without multicast.
Luckily, the same architecture document says:
In addition, a control point is allowed to unicast a discovery message to a specific IP address on port 1900 or on the port specified by the optional SEARCHPORT.UPNP.ORG header field (which supersedes port 1900 for this use), searching for a UPnP device or service at that specific IP address.
...
All devices shall listen to incoming unicast search messages on port 1900 or, if provided, the port number specified in the SEARCHPORT.UPNP.ORG header field and shall respond if any of their root devices, embedded devices or services matches the search criteria in the discovery message.
And this means that if you know the Router 1 IP address (from Router 2 side, of course), you can (and most importantly, allowed by specification to) communicate with it with unicast UDP messages and that is also NAT-friendly, so not an issue to be done from PC behind the Router 2.
The only thing left is getting Router 1 IP address. Unfortunately, there is no easy standard way to do that, but you have at least two options: tracerouting (in whatever fashion you want) and brute force IP scanning (most probably, the potential set of IPs for Router 1 is limited).
Now you can communicate with the Router 1, but there is still one minor thing you should always remember while communicating with it — in any internal UPnP messages you should use Router 2 IP address (as seen from Router 1 side) and its ports. Like in NewInternalClient parameter of AddPortMapping action on Router 1 you should use Router 2 IP. This, BTW, raises a question of Router 2 IP, but you can get that via Router 2 UPnP ExternalIPAddress variable of WANIPConnection service (this service is required for IGDs to implement).
So, to summarize:
this technically can be done, although I doubt that any standard library would do that for you
two things you need are:
Router 2 "external" IP and you get that via ExternalIPAddress variable of WANIPConnection UPnP service
Router 1 "internal" IP (from Router 2 side), that requires tracerouting or scanning
given Router 1 IP you just need to use unicast messaging at discovery step instead of multicast
everything else should just work, with only caveat of using Router 2 "external" IP instead of PCs IP in the UPnP messages
With the upnpc cli tool I've been able to get Double NAT port forwarding working.
For my example, let's say I want port 6667 to be forwarded to my machine, 192.168.50.123, behind a double NAT. The first layer of NAT has the IP range 192.168.1.1-255, and then 2nd layer has IP range 192.168.50.1-255.
On a machine inside the 2nd layer of NAT, just setup port forwarding with upnpc like normal.
$ upnpc -a 192.168.50.123 6667 6667 tcp
...
$ upnpc -l # this will confirm the rule is in place
...
Now for the slightly tricky part. I now issue UPNP requests to the outer layer NAT. Since the usual SSDP discovery won't work, I have to specify the XML root description URL manually. It's often something standard like http://192.168.1.1:5000/rootDesc.xml, though on some hardware the port number is randomized. I find just port scanning the gateway address will eventually reveal it.
Now that I have the rootDesc url, http://192.168.1.1:5000/rootDesc.xml, I then issue UPNP command to the outer layer NAT:
$ upnpc -u "http://192.168.1.1:5000/rootDesc.xml" -a 192.168.1.XX 6667 6667 tcp
...
$ upnpc -u "http://192.168.1.1:5000/rootDesc.xml" -l # this will confirm the rule is in place
...
With the -u option instead of discoverying the rootDesc, it just uses the URL provided.
The address 192.168.1.XX should be the 2nd layer network's IP address on as seen by the 1st network. When running the first set of UPNP commands this will be shown since it's the "external" address from that NAT's perspective.
With that now setup, traffic will go like this:
<INTERNET> --> MY_PUBLIC_IP -> 192.168.1.XX -> 192.168.50.123
Im not too sure why this wont work. My application works fine if the client and server are ran on the same PC hence the 127.0.0.1 but it wont connect to my other laptop using IP 82.41.108.125 which is the IP of that device.
Any reason why this is happening?
Your firewall could quite possibly be blocking the port assuming all of your coding is working fine - try opening up the port number you're running the application on (in the client/server comptuers' firewall options).
Some additional information that should shed some light on things
Networked devices use ARP (Address Resolution Protocol) and RARP (Reverse Address Resolution Protocol) to map IPs to link layer (MAC) addresses and back. Your network interface card (the thing that plugs into your ethernet cable) will have a unique MAC address on both computers. Each PC has an IP configured for it which is used by higher level protocols (those in the Network Layer).
Computer A will know computer B's IP address (and it will be different from computer A's) if your program works correctly. When computer A goes to send to comptuer B, assuming they're directly connected and not going through a router or something in between, computer A's link layer will need to translate that IP for comptuer B into a MAC address it can use. It does this by sending out a broadcast to all network PCs on the same sub network asking "Hey, is this your IP!?" essentially. The one that has an IP matching the broadcasted one yes, "Yes, it's mine - and here's my MAC address so you can talk directly to me."
So, if two computers have the same IP this all goes to hell :) don't do it - give them unique IPs and make sure that comptuer A transmits to the same UDP port and IP that computer B is listening on as well. communications work in {IP, Port} pairs - its like a telephone number and area code.
Also...
As said by EJP - UDP is a connectionless protocol - computer A just sends to computer B and hopes that computer B is listening correctly. If computer B wasn't listening or was but wasn't in the right state to process the data, the data will simply be dropped and lost. Computer A will not know that this happened. If you want reliable communications where it will keep trying and you will have assurance that compuer B received computer A's data then use TCP instead - it does a 3 way handshake to establish a connection and uses acknowledgements to ensure data is retransmitted when it doesn't reach the other end.
It could be that you're listening on localhost (127.0.0.1) and don't accept other traffic. Use a wildcard address.
Check on the server with netstat -npu.
If that's not the case then it's probably firewall issue, verify with tcpdump or wireshark.
Check firewall on your laptop... Most of the time that acts as spoilsport.
we have little network devices which are shipped with IP address 0.0.0.1 to ensure that they never collide with any other device in their new environment (thus none of the 10.x.x.x, 172.16.x.x or 192.168.x.x ranges) until configuration. DHCP is no solution since there might be no DHCP server in the field.
The devices would listen to UDP broadcasts and answer with broadcasts until they are given their new IP address this way.
This worked fine with Windows XP - but sucks with Windows 7: the config program does not receive the answer packets from the devices which still have 0.0.0.1. Wireshark sees the packets, then they are dumped by the system.
Question: Is there any reason (RFC?) that actually prohibits using this address in a local environment? Or is it just MS that was overcautious? Where can I read why they treat this address "invalid"? Which ranges are really "invalid" now, too?
Any idea of a workaround on the PC side (Win 7)?
I know that it is not recommended to use 0.xxx addresses for work places, but for this very reason - having a not-used address - it works perfectly.
Edit: there is a device out there called "Netburner" which might have faced the similar issue, according to their forum. See: http://forum.embeddedethernet.com/viewtopic.php?f=5&t=612&p=2198 Does - by coincidence - anybody know some background information?
It sounds as if your configuration application is listening for broadcast packets on all network interfaces and expecting to receive packets from foreign subnets.
That should not work - the OS should only pass-on broadcast packets from the subnets each network interface is on, not from all subnets on the same physical (e.g. Ethernet) segment. I am reasonably certain that doing otherwise is broken behaviour WRT the IP protocol.
The are two ways to deal with this:
Make sure that your network interface has an IP address in the target subnet. You can have more than one IP addresses for each network card, so that should not interfere with normal network operations.
Configure or modify you application to use raw sockets, like Wireshark. Keep in mind, however, that this overrides all normal checks and balances and should be avoided, since it can cause behaviour that is almost impossible to diagnose - which is why it is frowned upon by meny network administrators.
Can you you add new routing table entries to Windows machines easily? Windows has to know which interface to use when routing a broadcast packet to the 0.0.0.x network.
The Unix machines I'm familiar with have a routing table that maps network/netmask entries to either gateways or interfaces (if the network is a local network). The local network (192.168.0.0/16 for my home network) gets sent to interface eth0. Everything else 0.0.0.0/0 gets sent to a specific gateway machine 192.168.0.1.
If my machine sent a UDP broadcast message to network 0.0.0.0/24 (in other words, UDP broadcast sent to 0.0.0.255, then my machine would forward the packet to the gateway machine (which it can look up via arp). The switches in the middle wouldn't propagate the packet to other network devices, because the MAC address is set.
If my machine had another routing entry for 0.0.0.0/24 to the local interface, then my machine would send the packet on the wire using an ethernet broadcast group, and the switches would forward the packet to all connections. (Yay! Just like hubs in the 90s! :)
So I figure you need to add a routing entry for 0.0.0.0/24 to your client machines, so that they can properly address the broadcast packet.