So lets say I have a laptop which connects through a Wireless Access Point which is then connected to a router.
I'm trying to figure out if this happens as a result of an ARP response using the MAC address or, if the laptop uses the IP address to find the router. I know most models have switches built into them so lets negate that for this.
Does that mean that the laptop explicitly uses the IP address to find the router and will only use the MAC address if it needs to traverse through a switch somewhere else in the topology?
Thanks in advance. This is quite a difficult topic to find information on.
First lets rewrite your question to:
Question 1: How does a wireless lan (WiFi) connection differ from a wired connection?
Question 2: Does a WiFi connection transmit data directly to the router's IP, or does it uses the MAC address?
Question 3: Does a Laptop forward PDU's into the router through the wireless access point? does it than use the IP or MAC?
Assumption, PDU refers to Protocol Data Unit
Awnser question 1:
To understand how WIFI works, we first need to understand how a Wired network works. For this we use the OSI model.
The PDU for each of the 7 layers in the model is different and dependent on what that layer represent.
Layer 1 (Physical) is all about electrical signals, Frequencies, voltages, amplitudes and the likes. it defines how we transmit the data down a wire (or through the ether), in this layer there is no network. All communication is from node to node
(so like
"switch <=> switch"
"switch <=> Accesspoint"
"Accesspoint <=> Laptop"
Etcetera
)
This layer does not (normally) have any security or encryption.
Layer 2 (Data Link) is the layer were we start to get a network.
In this layer we start to see structures in the data (the PDU's are called frames) and we get addresses (MAC) Data can now only travel within this physical network (also known as subnet). Encryption is possible but not often implemented outside of the Enterprise networks.
Layer 3 (Network) is where we start to really get interesting. We have all the parts now to build networks and networks of networks (internet).
This layer's PDU is called a packet and its address is an IP address.
From this point on we can make connections that span over multiple hops though different networks with the so called routing scheme's.
Now to WiFi has the following changes to this standard model:
Layer 1: this is wireless (through the ether) so we get channels, bands, frequency and interference. It means that besides how to encode the bits we also have to dial a transceiver. to facilitate this there is a mechanism that uses names for humans to identify networks (SSID).
also because normally we do not have encryption anyone could just see all your data , WiFi adds an encryption scheme to this layer to ensure only authorized devices can communicate on it. (WPA for example)
Answer question 2:
WiFI is on layer 1, so it does not connected to anything but what is directly connected to itself (ergo WiFi is only on the ether), the router is on a different connection. We need at least layer 2 to communicate with it (using MAC addresses) or if we want to send data to other networks we need at least layer 3 and an IP address.
Answer question 3:
Well, for data to be transmitted to other networks (a router connects at least 2 networks) we need layer 3 and an IP address. so the only way your laptop can transmit data like this we use IP addresses.
Footnote:
To learn more about all this you could capture the data transmitted in your own network (DO not capture data on other people there network this is often illegal consult your local law proffesional!). To capture this data Wireshark is a great tool. you can see all this in action in it.
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.
Is there a way to use socket connection between raspberry pi 3 and android app using cellular network,NOT a localor wifi network ?
Theoretically, yes absolutely - so long as each device has an IP network connection you can open a socket between them.
In practice, however, you may find you have two issues:
getting 'external' IP addresses
ensuring that your stream is allowed on your target networks
By external IP addresses, I mean ones that are globally recognised and not just on a local or private network. Most local networks and operator mobile networks use private addressing internally and some sort of NAT (Network Address Translation) function to map these internal addresses to external addresses.
Unless you have a fixed IP address, which is not the norm, you will have to discover what IP address your deice appears on externally and then share that with the other device to allow the socket to be set up. This may change every time you connect to the network, or even more frequently, depending own how the network is set up. Techniques and protocols do exist to do this, such as STUN: https://en.wikipedia.org/wiki/STUN
Assuming you can get the end point addresses in a form that allows them communicate with each other, you will also need to check that your operator, and any local network policies or firewalls you have, allow the type of traffic you want to use. Cellular network operators sometimes block certain traffic types, either for security or to try to stop services which they see as competing with their own services.
When doing a network scan using for example NMAP with its "-A" option, what layer of the OSI model does it work on?
For reference, this is the description of the "-A" option:
-A : "Enable OS detection, version detection, script scanning, and traceroute"
The OSI model is a theoretical model with 7 layers; there are lots of resources out there describing which layers map to actual protocol layers in various network stacks, so I won't get into that. Instead, I'll give you the breakdown of what happens at each layer of the TCP/IP stack, which has 5 layers.
Physical layer. Nmap unavoidably uses this layer, though it is not usually concerned with it. It doesn't matter if you are using Cat 5 cable, 2.4 GHz radio, or coaxial cable—you can't use a network without having a physical layer. Nmap has no idea what it is, either; the firmware in your network card handles that.
Data link layer. Here again, Nmap has to use this layer or nothing gets sent to the destination. But there are some cases where Nmap is aware of what layer-2 protocols are in use. These all require root privileges to work:
On Windows, Nmap can't send raw IP packets (more on this in the next layer), so it falls back to sending raw Ethernet (layer 2) frames instead. This means that it can only work on Ethernet-like data links—WiFi is fine, but PPTP doesn't work.
There are some NSE scripts that probe layer-2 protocols: lltd-discovery, broadcast-ospf2-discovery, sniffer-detect, etc.
If the target is on the same data link, Nmap will use ARP to determine if the IP address is responsive. It will then report the MAC address of the target. For IPv6 targets, Neighbor Discovery packets are used instead.
Network layer. Nmap supports both IPv4 and IPv6 network layer protocols. For port scans (except -sT TCP Connect scan), Nmap builds the network packet itself and sends it out directly, bypassing the OS's network stack. This is also where --traceroute happens, by sending packets with varying small Time To Live (TTL) values to determine the address where each one expires. Finally, part of the input into OS detection comes from the network layer: initial TTL values, IP ID analysis, ICMP handling, etc.
Transport layer. This is where the "port scanner" core of Nmap works. A port is a transport layer address; some of them may be used by services on the target ("open" ports), and others may be unused ("closed" ports). Nmap can scan 3 different transport layers protocols: TCP, UDP, and SCTP. The majority of inputs to OS detection come from here: TCP options, sequence number analysis, window size, etc.
Application layer. This is where version detection (-sV) takes over, sending various strings of data (probes) to open services to get them to respond in unique ways. SSL/TLS is handled specially, since other services may be layered over it (in which case it provides something like an OSI Session Layer). This is also where the vast majority of NSE scripts do their work, probing services like HTTP, FTP, SSH, RDP, and SMB.
All of them? If you're asking for some sort of course, I'll leave it to you to turn this into something that answers your questions and instead focus on thinking about what's going on.
Obviously layer 1 packets are sent, but nmap isn't really aware of them
When on the same local network, nmap pays attention to MAC addresses and ARP. This helps with vendor detection, as well as giving you network distance information
layer 3 (network layer) is used for sending packets, for detecting whether the host is up.
the transport layer (layer 4) is used for things like SYN scans, and to detect which ports are open. Sequence number detection, which happens at layer 4 is important to OS detection.
Mapping OSI layers 5 and 6 session and the one I can never remember to the TCP/IP protocol stack is complex. I leave that to a long paper I'm not going to write.
layer 7(application) is involved in the scripts and in doing things like collecting info about websites. If you think HTTP is layer 6 rather than 7 (a valid world model), then some of that happens at layer 6.
As you can see, this really isn't very clear.
The -A option seems to do a few things. Since it seems to be doing TCP/UDP port detection as well as traceroute (which is ICMP) (see man nmap for more info), I would say that includes the Transport Layer as well as the Network Layer. As it seems to be checking versions of server software running, there's a good chance it's also on the Application Layer.
I need to send int and double values from one computer to another. The two pc's are connected to the same wireless network and the values I get are generated by a Matlab code. Can this be done in Matlab or do I need to use a medium between the two?
Sending data over WiFi is basically the same as sending it over any network. You'll need the other computer's local IP address (various ways to find this on different operating systems, ask google). You don't want to use an external IP address like this, since this would usually require you to change some settings on your router (e.g. port forwarding).
Once you have a local IP address, you could use something like Sockets - Loren has a good blog post.
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.