i am making 802.15.4 protocol.
I'm confused about device's information such as short address.
When multiple device try to associate coordinator, coordinator have to allocate
short address to each device.
Therefore, Coordinator should have device's information which are associated.
After then, allocated short address is not duplicated.
I read document, but there was no info what i mentioned.
How coordinator keep associated device's info ?
Can i make it own my way ?
I believe that the address allocation (and duplicate address resolution) is defined above the MAC layer, which in ZigBee is the ZigBee Pro specification (http://www.zigbee.org/zigbee-for-developers/network-specifications/zigbeepro/). The 802.15.4 specification defines the MAC layer.
"Therefore, Coordinator should have device's information which are associated.
After then, allocated short address is not duplicated."
This is not correct. The parent (an FFD - i.e. Coord or Router) will allocate the address, which is not always the coordinator. An address conflict resolution mechanism is implemented in the ZigBee protocol stack in case 2 FFD's in the network allocate the same address.
"Can i make it own my way ?"
If you are developing your own protocol on top of 802.15.4, and not using ZigBee (as the tag suggests).
Regards, TC.
Related
I am writing some code that scans for BLE devices. Because of the address type random the same device may send out multiple address if its GAP address type is Random. Is there a way to determine if different addresses came from the same device?
It is possible after bonding the devices. While bonding, devices using a random address share a resolvable key with wich one can determine wether a received random address matches a known device or not. See also this question.
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.
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).
Using SNMP queries to the MIB-II objects, how to identify devices acting as routers, ie, forwarding packets?
The only way to identify them is through the identifier, type or description, or can I identify it through the packet traffic?
If you're only looking to tell whether or not they forward traffic, then there is actually a MIB object to tell you just that:
IP-MIB::ipForwarding
ipForwarding OBJECT-TYPE
-- FROM IP-MIB
SYNTAX INTEGER {forwarding(1), notForwarding(2)}
MAX-ACCESS read-write
STATUS current
DESCRIPTION "The indication of whether this entity is acting as an IPv4
router in respect to the forwarding of datagrams received
by, but not addressed to, this entity. IPv4 routers forward
datagrams. IPv4 hosts do not (except those source-routed
via the host).
When this object is written, the entity should save the
change to non-volatile storage and restore the object from
non-volatile storage upon re-initialization of the system.
Note: a stronger requirement is not used because this object
was previously defined."
::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) ip(4) 1 }
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.