I want to send data within a WLAN as fast as possible to another device within this WLAN? And I am completely confused at the moment.
If I want to send something from one device in this WLAN to another device in this WLAN. Do I necessarily need an IP Address then?
So I could write a program that produces IP Packets and sends them to the destination. Then I would program at Network layer.
Can I go to the data linklayer and send something to the Router in this WLAN and he figures out where to send it without any ip address? Would it be faster than programming at Network layer?
You could indeed sent to the MAC address. Bit I doubt if it's worth the effort. Using IP is the standard way of doing things. Speed would only improve minimally.
Yes, you need IP address in both devices if you are using TCP/IP stack.
You can directly send with the MAC address without IP if you are under the same lan switch. Use raw sockets. This is not recommended.
Related
I am sorry if its basics, but I did not find the appealing answer for it over the Internet.
Why only MAC is used to transfer the packet to a device ? MAC address is only obtained by ARP for a specific IP address. So, why not just let the routers maintain IP addresses of the neighbouring routers and route packets using IP addresses of routers instead of MAC addresses ?
Why not redesign the architecture, to only use IP address for routing as well as moving the packet in the data link layer too ?
Why do we need MAC addresses?" Why can't network devices such as the routers just send the packet to the next router using the router's IP address?
Note : I know that MAC address is used to identify the system in a network. But you see the source never knew the MAC address of receiver. All it knew was its IP address and MAC address of next hop.
I'm reading Data Comm and Networking by Forouzan ( Ed 5) and it says that even routers have an IP address. So why use the mac address at all. The router can store the IP address of the source and route it to the next router .
EDIT : The question that I was getting as suggestion to this one does not answer my query. There are multiple counter points and proof that I have presented here which could have been done which is not answered by the one which is suggested. So please read my question before making any assumptions.
What do you think makes more sense: Having one protocol like Ethernet handle all the layer 2 details so that its layer 3 payload doesn't have to care, or force IP, ARP, WoL, IPX, MPLS, SLPP, and dozens more implement it on their own? The whole purpose of OSI layers is that upper layers need not know all the lower layer's details and lower layers need need not support the upper layer's features.
MAC addresses are used for the layer 2 protocol which encapsulates a layer 3 protocol. If all the necessary features were embedded into IP, then you'd be leaving other protocols to re-implement layer 2 routing on their own. This would be wildly inefficient.
For example, is it possible to send this "11110000 00001111" sequence alone, without any protocol encapsulating it, or even Ethernet or IP in order to implement a different protocol for my local network?
You can send the sequence without IP headers through an 802.3 frame. But I think MAC protocol already comes in the NIC with some logic also in the device driver.
I would like to write a software running in a networked device, i.e. PC. It can automatically detect the other network devices' types. For example, it can detect there is a PS3, a Wii, an IPad running in the same network. Any ideas? Thanks,
You have two problems: first, detecting that a device is connected to your network and at 192.168.1.x. Second, somehow detecting what that device is.
The first is easy-ish to accomplish: there's discovery protocols like UPnP and Bonjour. However, in a home networking scenario, the easiest and most reliable way to get a list of connected devices is probably to pull the DHCP reservations from your router. You might have to scrape data from the router's HTML-based management interface—hacky as that may be—but it would work. (If you're using .NET, consider the HTML Agility Pack to accomplish this.)
Once you have a list of IP addresses of connected devices, your next problem is to figure out what each device actually is. This will be more challenging. Some possibilities:
You may be able to use the MAC address to help detect the device's vendor. (Here's a list.)
If you're using UPnP, you can ask the device what it is.
Use IP fingerprinting to determine what the device is.
Couple thoughts. The broadcast IP address - 255.255.255.255 is where devices talk and say "here I am". Should be able to listen to this and find ip addresses and more. Second, if devices are assigned an IP address by a DHCP client (obviously) you can usually find a list on the dhcp device. Devices often have names, this is a higher level protocol, like windows SMB, that you may have to interface with in order to get that information.
i was learning socket programming in unix using c/c++.
I am confused with one function call bind(params..).
Actually it takes the adreess structure "sockaddr_in" and we can create the structure in the following way
sockaddr_in.*** = somthing..
sockaddr_in..s_addr htonl(INADDR_ANY)
**Passing INADDR_ANY will alow to bind all local addresses**
My question is , why do we need to use "INADDR_ANY" ?
In my knowledge every machine can has only one unique IP Address. In this way there is only one address associated with the machien. Thye bind call should directly bind the socket to the single available address.
Please explain what are the different scenarios and why is it so?
A machine usually has an IP address for each connected network interface plus 127.0.0.1 for localhost (loopback). For example, a laptop might be connected to a wireless network as 10.0.1.25 and also to a wired network as 10.0.2.4. Servers often have an interface to an internal network as well as a public network.
It's possible for a machine to have more than one IP address, either because it has multiple network cards or through software. INADDR_ANY lets you bind a socket to all of the machine's IP addresses.
Not true. Most machines are Multi-Homed, that means, they have more than one IP address.
For example, the network address and 127.0.0.1.
I'm trying to confirm a user a unplugged my embedded device from a network before performing some maintenance. I'm considering "ping"ing all IP address on my sub-net, but that sounds crude. Is there a broadcast/ARP method that might work better?
You can try a broadcast ping (this is from linux):
ping -b 255.255.255.255
Another option is to download Nmap and do a ping-scan.
You could use nmap. It's still crude, but at least it's using a tool designed to do it so you don't have to spend time on it.
If you can't get reliable link state information from your Ethernet device (which most chipsets should support these days, BTW...), sending an ARP request for each IP on your local subnet is a decent substitute. The overhead is minimal, and as soon as you get a single response, you can be sure you're still connected to a network.
The only possible problem I see here, is that if your device is on a /8 subnet, it can take quite a while to loop through all 4294967296 possible IPs. So, you may want to consider some optimization, such as only sending ARP requests for your default gateway, as well as all IPs currently in your ARP table.
If there's a peer you know you were connected to recently you could try pinging or arping that first. That could cut down on the traffic you're generating.
you could also run tcpdump -n to see what's active on the network too.
Not receiving any responses to ICMP pings or ARP requests is not a 100% guarantee that there's no network connection. For instances, there might be devices on the network that are firewalled off.
EDIT: May be you could access some lower-level information on your embedded device to check whether the network interface has its link up without actually sending any data.
Is there any chance that your device supports UPnP or Bonjour? Beside of the low-level protocols your should also have a look at these protocols which support some kind of plug-&-Play functionality. A UPnP device for example sends a message on the LAN before it is switched off (though, this doesn't help if it is just removed by unplugging it...).