I'm a novice in this area looking for clarification. I believe that CDMA would be classified as part of the physical layer, so what is used for the data link layer (according to the OSI model) in cellular networks? Is TCP/UDP used in cellular networks? If so, in what capacity?
On a CDMA network (and some others, such as GPRS and HSPA), PPP is used at the Data Link Layer (layer 2).
TCP/UDP (or more generally, IP) is indeed used in CDMA networks to mostly for connection to the CMDA providers ISP network for Internet access by phones and "data sticks".
These data sticks usually provide an emulated modem on a serial port over USB, which is used in a very similar manner to dial-up modems of days gone by. You'd use the same "AT commands" to establish a connection, the only difference being the relatively high speed of the emulated serial port.
Related
I'll start with stating that I know very little about networking and the whole OSI model.
My goal is to create a tiny network(for now my laptop and a raspberry Pi) using an unmanaged network switch. On higher layer transmissions(level 3+) I would simply set the destination IP address for a packet. From what I've read on Wikipedia a network switch operates at the data link layer which means it uses MAC addresses.
How does one send data to a device on a local area network when it's connecting with something that only supports MAC addresses. More importantly, how does one do it from a high level language like Java or C#?
TL;DR The the OSI model is about abstraction and programing languages use operating system calls to implement this abstraction. The Rasberry Pi is running a full OS and will send and receive network data addressed to its assigned IP address. You do not need to specify MAC address.
You want to communicate with a Raspberry Pi from your Laptop. To do this you first connect them to the dumb switch and assign both devices an IP address in the same subnet, on physical interfaces connected to the dumb switch. Let say that your laptop's physical ethernet connection is assigned 10.0.0.1/24 and Rasberry Pi's physical ethernet connection is assigned 10.0.0.2/24 (If you do not understand my notation look at CIDR). IP addresses are Layer 3 constructs. Now your application will use an Operating System socket to create a TCP or UDP connection(see UDP java example here) with a layer 4 address (application port). Everything higher than Layer 4 is handled by your application.
Layer 2 and lower is handled by the OS. When your application tries to send data through the socket, the Operating System determines which physical interface to send data from by looking at the destination IP address. This lookup uses the OS Routing Table. Assuming you have a normal routing table, the OS will pick the interface that has ab IP with the same subnet as the destination IP. So if you send data to 10.0.0.2, your OS will send data from 10.0.0.1 because it has the same subnet of 10.0.0. Now the OS has selected an interface, it still does not know what Layer 2 MAC address to send the Layer 3 IP packet to. The main reason the OS does not know this is because IP addresses can change, but Layer 2 MAC addresses should not. Anyhow the OS sends out an ARP request which tries to get the MAC address for an IP address. If the devices are connected properly, the OS gets a MAC address for the desired IP address and begins to send data to that MAC address. The switch (smart or dumb) makes sure the message gets to the desired MAC address. At the receiving end, the OS receives the packet and send the data in the packet to sockets bound to the Layer 4 address (application port).
Side note: it is technically possible to send data to just a MAC address using RAW sockets but it is extremely technical.
Liam Kelly's answer provides great insight on abstraction of data sending. I will try to provide complementary information.
Network switch operation
While most switches operate at data level, there are some that can perform some operation at higher levels:
layer 3: Within the confines of the Ethernet physical layer, a layer-3 switch can perform some or all of the functions normally
performed by a router.
layer 4: [...] capability for network address translation, but then adds some type of load distribution based on TCP sessions.
layer 7: [...] distribute the load based on uniform resource locators (URLs), or by using some installation-specific technique to
recognize application-level transactions.
RAW sockets usage
As already specified, these require fairly advanced programming skills. They are also severely restricted in non-server versions of modern Windows Operating Systems (source) due to security concerns:
TCP data cannot be sent over raw sockets.
UDP datagrams with an invalid source address cannot be sent over raw sockets. The IP source address for any outgoing UDP datagram must
exist on a network interface or the datagram is dropped. This change
was made to limit the ability of malicious code to create
distributed denial-of-service attacks and limits the ability to send
spoofed packets (TCP/IP packets with a forged source IP address).
A call to the bind function with a raw socket for the IPPROTO_TCP protocol is not allowed.
Suggestion
If .NET is a viable option for you, I would take Pcap.Net for a spin, as it allows various operations at packet level using high level programming (including LINQ).
I'm currently for a side project trying to setup a VPN with 2 linux box doing the encryption/decryption.
At the moment, I work on layer 3 with the linux framework xfrm (IP packets from host 1 are transformed into ESP when passing through the first box before being sent to host 2, decryption being done on the second box).
I'd like to act directly on layer 2 so I can remove the IP address of my boxes. I think I can do that by setting up ethernet bridges on each box, using netfilters hooks to redirect frames to a socket where a userspace program would do the encryption of the ethernet frames payload (transform the IP packets into ESP).
|Host 1|==|Ethernet Bridge|==Router --- (network not secure) --- Router==|Ethernet Bridge|==|Host 2|
Problem I have with this implementation lies in throughput as I think all these actions would greatly reduce it. Are there other ways I could implement what I'm looking for ?
Layer-2 only works from host-to-host (your router is just a host to layer-2) on a LAN. layer-2, including layer-2 encryption, does not cross a layer-3 device, e.g. router. MACsec (IEEE 802.1AE) is used for layer-2 encryption.
Layer-3 is used to connect LANs, and if you want end-to-end encryption from one LAN to another LAN, you need to encrypt on a layer higher than layer-2. Routers strip layer-2 frames from the packets, switch the packets, then create a new frame for the next hop. The next hop may not use MAC addresses; PPP is common for ISP connections, it doesn't use MAC addresses, and the frames are very different than ethernet. Unless you control all the links between the LANs, you need to encrypt at a high layer.
You're right, deploying a layer 2 VPN is costly (in the sense that you have to pay for internet bandwidth) and most of the time useless, since there are few applications that won't work without being on the same LAN.
What you will get with a layer 2 VPN is mostly broadcasts, things like SMB out-of-the-box name resolution (does not apply if you have to connect to an AD server or have a WINS server), DLNA, SPX/IPX or LAN-only games will work seamlessly, on the other hand your perception on having to relay lots of possibly useless information will also be correct.
Maybe the solution you're looking for is to use ebtables , which is a layer 2 firewall akin to iptables relating to layer 3 in such way that you can drop some packets while accepting others before relaying it over VPN/internet/etc.
PPP just one layer 2 protocol, there's nothing special about it, some VPN gateway use it (namely PPtP VPNs), others don't.
I'm capturing 3G data on my iOS device using RVI interface on my mac.
Looks like I'm succeed making capture and I can analyse RX/TX traffic.
Currently I'm streaming a UDP stream out to 3G network. So, what I want is to measure traffic and get some statistics on that stream.
What's strange for me is all required headers are presented in the captured packets besides Ethernet header. So I'm curious whether packets sent over 3G interface should have Ethernet header?
P.S. Packets contain "Raw packed data" header which actually tells "No Link information available".
If you mean packets between the handset (the UE in UMTS terms) and the network (Node B), then no is the answer.
The IP protocol is a layer 3 protocol (usually expressed as being 'comparable to layer 3 in the OSI model') and it can be carried by different layer 2 protocols. Probably the most common one is ethernet in regular wired networks, but between a handset and the network in a UMTS network the IP protocol is carried over a layer 2 protocol called PDCP (Packet Data Convergence Protocol).
The following Wiki article on the OSI stack gives some good example of the different protocols at the different layers:
http://en.wikipedia.org/wiki/OSI_model (see the Examples section and look at IP which is layer 3 and Ethernet and PDCP which are layer 2 and hence can 'carry' the layer 3 protocol)
This link contains a nice diagram showing the protocol stack for the UMTS traffic between your handset and the network, and lots of other good background also (see fig 17 for your 3G scenario):
http://www.lteandbeyond.com/2012/01/interfaces-and-their-protocol-stacks.html
Note that if your IP traffic exits the 3G carriers network and travels towards a host on the internet (for example) then it will almost certainly be carried over different layer 2 protocols at this stage of its journey and this will probably be Ethernet in many cases.
I have a dumb question, first of all sorry for that. i am learning now 7 OSI Layer models and i stumble across one thing. The Ethernet which is in the second Data Link Layer provides the end-to-end connection via LANs, right? Does it mean that even if i connect to Internet thru WiFi, somewhere my connection is running thru LANs?
Thanks
I am going to break my answer into points:
1.Lan is not necessary to connect to internet. You can have cable internet or internet through DSL connection etc. in which though the wire that comes and connect to your pc is the same cat5(for example) cable, there is no lan involved.
2.Internet through wireless router an be accessed in two ways:
(a)The ethernet cable from (say) a cable modem connects to your wireless router WAN port and then wireless router sends out radio waves which your laptop catches.
(b)There are many wireless routers and one cable internet connection. So the WAN port of one of the routers will connect to the cable modem(same as (a)) and from that router's ethernet ports(usually there are 4 ethernet ports on a wireless router ), ethernet cables will connect to other routers' ethernet ports and now these routers will send out radio waves which your pc catches.
3.Ethernet is one of the IEEE protocols(IEEE 802.3) for the data link layer. The wifi uses IEEE 802.11 standards to communicate through wireless media.
Short answer is: most likely
In your case, you only know your direct connectivity is made possible thru WiFi. From your perspective, it's just a WiFi network. But behind WiFi network, it could be Ethernet, DSL, Cable, etc. And behind those, it could be T1, frame relay, ATM, 10G or maybe 100G Ethernet, etc.
For example, I can have a small LAN at my home while my company office building can have a much bigger enterprise LAN. And both can provide me with the same kind of WiFi access.
Your connection to the nearest router is using a wifi data link protocol (in the IEEE 802.11 family). But the connections to other routers and (eventually) hosts will use other data link protocols, likely including ethernet at least at the far end.
Why is it must that all interfaces (routers and bridges) involved support LRO/TSO technique ?
Routers don't. Bridges do.
External routers, hubs, switches or anything else that is externally connected to the network will not see the effects of TSO, only interfaces inside the device with TSO will experience any effects - it's a software thing.
A router is an external device which is connected to the network by ethernet cables, fibre optic cables, wireless comms etc. These communication mediums adhere to internation standards such as 803.2 for ethernet or 803.11 for wireless - they're hardware devices, and hardware devices have very strict rules on how they communicate.
A bridge is an internal software construct and is specific to your OS.
Let's use 803.2 (ethernet) and a linux host for an example.
An application calls for a socket to be created and then pushes a large data chunk into the socket. The linux kernel determines which interface this data should be transitted on. The kernel will next interrogate the driver for this interface to determine its capabilities, if the interface is TSO capable the kernel will pass an sk_buff with a single "template" header and a huge chunk of data (more than 1 packets worth) to the interface driver.
Let's consider a standard interface straight to a hardware NIC first:
Some interfaces have fake TSO (they segment the packet in the driver) and some have true TSO (the template header and data are passed to the hardware with minimal alterations). At this point ether the driver or the NIC hardware will convert this large segment of data into multiple, standard compliant, 803.2 ethernet frames, it is these compliant frames that an external device, such as a router, hub, switch, modem or other host will see on the wire.
Now let's consider several NICs behind a software bridge:
Although the kernel is aware of each NIC at a low level, the network stack is only aware of the bride, thus only capabilities that ALL of the underlying NICs have should be passed up to the bridge. If an sk_buff is passed to a bridge, then ALL the interfaces in the bridge will receive the same sk_buff. We'll assume that the kernal has once again passed our large TSO sk_buff to a bridge, if any of the underlying interfaces does not support TSO then the packet will most likely be dropped by the hardware NIC in question.
In summary:
Worst case scenario is the bridge will repeatedly retry to send the same data chunk on the broken interface and the whole bridge will lock up until the application decides to give up. Best case scenario, the non TSO NIC will simply appear to be dead.
That said, if the NIC has unsafe code in its driver then this could cause a segmentation fault that could bring the whole system down.