I am currently working on an implementation of AODV protocol, One thing am not clear about is the use of HELLO packets.
Are HELLO packets exchanged even before a route is established or HELLO packets are used to keep an existing route alive ?
Note: Also according to my understanding of AODV RFC 3561, HELLO packets are optional. Is that correct ?
Hello packets used to construct neighbor table for all the nodes. IN AODV you can use Hello packets or Link layer detection to create a neighbor list. in default AODV works with link layer detection. If you want to use hello packets you have to command the below lines in aodv.cc
//#ifndef AODV_LINK_LAYER_DETECTION
//#endif // LINK LAYER DETECTION
now you can verify hello packets operation using your trace files.
Related
I wanted to peek Ipv4Header from a packet, but the system thrown a runtime error as following:
<!> Returning an incomplete chunk is not allowed according to the flags: 0 -- in module (inet::ieee80211::Dcf)
The line of code causing error is:
const auto& ipv4header = packet->peekAtFront<Ipv4Header>();
Thank you in advance!
As far as I see, you are trying to get an Ipv4Header at the link layer (802.11 Dcf). That is not possible. Nobody have ever guarantied that a link layer data packet starts with an IP header. IP packets can (and will) be fragmented if the MTU is smaller than the actual packet size. The first fragment indeed will start with an IP header, but subsequent fragments definitely will NOT.
As a general rule of thumb, if you are trying to access an upper OSI level data structure in a lower OSI level, you are definitely doing it wrong.
I've found what code parses IP (v4) packets in the kernel source tree. This function, ip_rcv, can to a high degree of certainty detect whether a packet is correct or not, as is outlined in one of the comments:
Length at least the size of an ip header
Version of 4
Checksums correctly. [Speed optimisation for later, skip loopback checksums]
Doesn't have a bogus length
Malformed packets are simply dropped. This function seems to get a bunch of bytes that should resemble an IP packet, but what if some malicious actor would sneak an extra byte on the line? If not handled correctly, all the chunks of bytes that ip_rcv receives from now on will start 1 byte off and no correct IP packet can be reconstructed anymore. I assume the kernel does something smarter than to try all different byte offsets at which to start parsing an IP packet. What exactly, I'm unable to find. Could anyone shed some light on this?
I haven't taken the time to look at the kernel code but most protocol stacks are going to work by parsing data immediately following the previous stack location and not by searching for data.
In the case of Ethernet, an Ethernet frame header is typically 14 bytes in size. It can vary but the header itself indicates the different length in the etherType field when necessary. In this example, the NIC (Network Interface Card) will receive an Ethernet frame. If the frame is destined for this NIC then the data passed from the NIC driver to the IP stack will be an Ethernet frame containing this 14-byte header followed immediately by the IP header (first nibble will be 4 if it is a version 4 IP header for instance).
Again, I didn't look at the network stack code but there are two common cases here:
1) The IP stack is told this is an Ethernet frame and only needs to parse the Ethernet frame header for its length and the very next byte must be an IP header or the data is deemed not an IP frame.
2) The IP stack is given a pointer to the beginning of the data immediately following the Ethernet frame header and the IP stack then starts parsing at that location.
I'm trying to implement S-MAC protocol on waspmote xbee sensors and i know it has its own CSMA/CA. So first of all I need to understand the basic of xBee collision avoidance.
Two senders set up in api mode in libraries and both periodically sending single bytes to a common receiver. I reduce the delay and many changing in libabries to make collision and to see how algorithm works. But when i monitor data at the receiver all looks as expected at the receiver .. byte1, byte 2 .. byte1, byte2.
Do u have any idea how can i make collision?
Are you sniffing the 802.15.4 traffic? That's the only way you'd see a collision.
The XBee module buffers the data you want to send, using the host communication parameters (baud rate, API mode, etc.) and then sends it out over 802.15.4 at 250kbps. The module has all of the collision avoidance built in, and will retransmit as necessary to deliver your message. If it's unable to deliver after some number of transmission attempts, you'll get a Transmit Status frame indicating failure.
On the receiving end, it buffers the data and delivers it to the local host using local serial settings (baud rate and API mode).
If you're trying to implement S-MAC, you need a different radio processor where you have low-level control over the radio. The XBee module provides an application layer and handles the MAC layer itself.
This is 2 example:
How to append data on a packet from kernel space?
How to route the splitted packets using netfilter hooks in kernel space
I just want change data coming server at hook LOCAL_IN, this is similar spllitted example.
At append data example, that is ok. But splitted example, that is not work.
I think problem is update length, checksum udp,ip packet(example: the value offset in calculating checksum at hook LOCAL_IN and LOCAL_OUT is different( int offset = skb_transport_offset(skb)) because when a packet goes in, packet is processed before go to udp layer).I try to alter htons -> ntohs but that is not work.
Anyone have idea to solve? Thanks
the problem is different function checksum.
In side sender, when you update udp checksum at hook(POST_ROUTING or LOCAL_OUT), checksum just for pseudo header, not include udp datagrams.
In side receiver, when you updata udp checksum at hook(PRE_ROUTING or LOCAL_IN), checksum must include pseudo header+udp datagrams.
in the current linux kernel,
when ICMP module receives ECHO REQUEST message, does it check or limit the data size?
or does it just puts the data in a new ICMP message and send back to the source?
I been reading the source code, and I am pretty sure the kernel doesn't check the data size but I want to make it sure :)
You are correct ICMP is not handling the size of the packet.
ICMP packet are contained in standard IP datagram. Since max size of IP is 65K. So the size check is done at IP level itself. ICMP layer need not worry about that in code.