I want to implement an opportunistic routing protocol in UnetStack to transmit a packet to more than one neighbor node. How can I proceed with that?
You can transmit to PHY frame to the BROADCAST address (0). The default address is 0, so not specifying a to address is equivalent.
Example:
phy << new TxFrameReq(data: [1,2,3])
will transmit a frame with bytes [1,2,3] to all neighbors.
Related
How is Forward Error Correction implemented in Unet audio, and what approach should be used to work on the existing algorithm or to add a new FEC technique to the Unetstack?
The Unet audio community version implements a ½ rate convolution FEC, which can be enabled or disabled using phy[1].fec or phy[2].fec parameters. If you disable the FEC and there are any errors in the received frame, the CRC check will likely fail, and you'll get a BadFrameNtf instead of a RxFrameNtf. The BadFrameNtf message will have the erroneous bits available as data. If you want to implement your own FEC, you can use these as hard decisions from the PHY layer and do your decoding.
So, to implement your own FEC:
Disable the default FEC on transmit and receive modems (phy[2].fec = 0).
Create your own uncoded frame by including source address, destination address, and protocol number along with your data bits. Compute a CRC and include it in the frame.
FEC encode your uncoded frame and send the encoded bits using a TxRawFrameReq from the transmitter. The "raw" frame request tells UnetStack not to add its default headers.
Receive the corresponding BadFrameNtf on the receiver and extract the received bits from data field.
FEC decode the received bits to yield the uncoded received frame.
Check CRC on the uncoded receive frame. If that passes, then extract the source address, destination address, protocol number and your data from the uncoded received frame.
If you want the rest of the stack to process this as if it came from PHY, you can send a RxFrameNtf with relevant fields filled in and send it on the topic(phy).
I listen to tcp socket in linux with recv or recvfrom.
Who taking care that I will get the tcp packets on the right order?
Is that the kernel taking care so if packet 1 came after packet 2 the kernel will drop out both/save packet 2 until packet 1 will come?
Or maybe I need to take care on user-space to the order of tcp packet?
On Linux based systems in any normal scenario, this is handled by the kernel.
You can find the source code here, and here's an abridged version:
/* Queue data for delivery to the user.
* Packets in sequence go to the receive queue.
* Out of sequence packets to the out_of_order_queue.
*/
if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt) {
/* packet is in order */
}
if (!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt)) {
/* already received */
}
if (!before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt + tcp_receive_window(tp)))
goto out_of_window;
if (before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt)) {
/* Partial packet, seq < rcv_next < end_seq */
}
/* append to out-of-order queue */
tcp_data_queue_ofo(sk, skb);
along with the actual implementation that does the reordering using RB trees:
To quote Wikipedia,
At the lower levels of the protocol stack, due to network congestion, traffic load balancing, or unpredictable network behaviour, IP packets may be lost, duplicated, or delivered out of order. TCP detects these problems, requests re-transmission of lost data, rearranges out-of-order data, [...]
It's an inherent property of the protocol that you will receive the data in the correct order (or not at all).
Note that TCP is a stream protocol, so you can't even detect packet boundaries. A call to recv/recvfrom may return a portion of a packet, and it may return bytes that came from more than one packet.
I have a NDIS 6 filter driver working on Windows Vista and later systems.
I have bound it below NativeWiFi Filter so I can see 802.11 packets instead of fake Ethernet packets.
And I have set the NDIS_PACKET_TYPE_802_11_RAW_DATA and NDIS_PACKET_TYPE_802_11_RAW_MGMT in the packet filter based on: https://msdn.microsoft.com/en-us/library/windows/hardware/ff554833(v=vs.85).aspx, so I can receive the Raw 802.11 Packets indications from the miniport.
Then I switched my wireless adapter to Monitor Mode.
By now my filter driver can receive all the 802.11 control and management packets.
My question is how to determine whether a 802.11 raw packet has FCS (frame check sequence, 4bytes) in my driver?
I'm asking this because i'm adding Radiotap header (http://radiotap.org/) to the packets and radiotap has a field called Flags that specified whether the 802.11 packet has a FCS or not.
My experiment with my laptop with a wireless adapter Qualcomm Atheros AR9485WB-EG Wireless Network Adapter shows that Beacon and Reassociation Response packets have FCS and all other 802.11 packets don't have one. And the wrong Flags in the radiotap header will cause Wireshark to show Malformed Packet for those packets. This is why I need to determine the availability of FCS in my driver.
My code is like below, and I want to know how to write the if condition.
// [Radiotap] "Flags" field.
if (TRUE) // The packet doesn't have FCS. We always have no FCS for all packets currently.
{
pRadiotapHeader->it_present |= BIT(IEEE80211_RADIOTAP_FLAGS);
*((UCHAR*)Dot11RadiotapHeader + cur) = 0x0; // 0x0: none
cur += sizeof(UCHAR) / sizeof(UCHAR);
}
else // The packet has FCS.
{
pRadiotapHeader->it_present |= BIT(IEEE80211_RADIOTAP_FLAGS);
*((UCHAR*)Dot11RadiotapHeader + cur) = IEEE80211_RADIOTAP_F_FCS; // 0x10: frame includes FCS
// FCS check fails.
if ((pwInfo->uReceiveFlags & DOT11_RECV_FLAG_RAW_PACKET_FCS_FAILURE) == DOT11_RECV_FLAG_RAW_PACKET_FCS_FAILURE)
{
*((UCHAR*)Dot11RadiotapHeader + cur) |= IEEE80211_RADIOTAP_F_BADFCS; // 0x40: frame failed FCS check
}
cur += sizeof(UCHAR) / sizeof(UCHAR);
}
Any methods? Thanks!
My experiment with my laptop with a wireless adapter Qualcomm Atheros AR9485WB-EG Wireless Network Adapter shows that Beacon and Reassociation Response packets have FCS and all other 802.11 packets don't have one.
No, it doesn't. When I looked at the same capture, and forced the "FCS at end" flag on, I found that a LOT of frames other than those frames had an FCS that Wireshark reported as valid. Do NOT assume that, just because a frame didn't show a "Malformed frame" error, it didn't have an FCS; the "Malformed frame" errors are due to Wireshark thinking the FCS is frame data, and trying to dissect items larger than the 4 bytes of the FCS. For data frames, the 802.11 dissector doesn't dissect the payload, and if the payload has a length field of its own, as IPv4 and IPv6 frames do, that length will be used, and the FCS will be treated as extra data after the payload and not cause a "Malformed frame" error.
What you should try is to check whether uReceiveFlags has DOT11_RECV_FLAG_RAW_PACKET set and, if so, assume the frame has an FCS, otherwise assume it doesn't.
And remember that, in monitor mode, frames that couldn't be completely received may still be provided to the host, so some "Malformed frame" errors in monitor mode may be due to, for example, the frame being cut short by the radio, so don't assume that a "Malformed frame" error means that the frame shouldn't have had the "FCS at end" flag set.
Environment
As per my understanding Network layer is responsible for reassembly of fragmented datagrams and then it supplies the reassembled data to upper Transport layer.
I have collected packet traces using libpcap and i want to reassemble fragmented packets at layer 3 on my own.
This link says that i need fragment flag, fragment offset, identification number and buffer value for reassembly of segments.
Question
At the arrival of first segment how to know what should be size of buffer to be initialized for complete reassembly of datagram.
Thanks.
The IP header only gives you the size of the fragment. So you need to reserve a buffer the size of the largest possible IP packet, i.e. 65535 bytes. Only once you get the last fragment can you determine the length of the complete packet.
I am trying to interface with a module using the i2c protocol.
the modules(slave) address is 0x48.
What I am trying:
send 0x48(it's adress) to the module. After which I should receive an ACK.
But it seems as if i don't receive an ack or am I wrong?
If I do effectively don't get a proper ACK, how does it come?
All i do is reset the module, so it is in a known state and afterwards I just send 0x48 (and 0x00 as data).
for info: i am using a 32-bit ARM controller and 1k5 pullup resistors
an image of what I see on an oscilloscope: