The INET WirelessHost inherits from the StandardHost which has store-and-forward as its default forwarding behaviour. Is there a way to change that behaviour to cut-through? I did not find any fitting parameters in both the StandardHost and WirelessHost modules.
TL;DR: No, that is not possible and makes no sense.
cut-through is a layer 2 (link layer) device feature i.e. switches can support it. It is impossible to do this on layer 3 (network layer) as IP packets can be fragmented, defragmented and the IP header itself can change during routing. So at most, the question should be: can a wireless access point support cut-through? BUT:
cut-through implies that the interface can receive and send simultaneously. That's an almost impossible feat for a wireless transciever over a radio medium. (unless the transmission is highly directional (like. StarLink laser links, but in that case they could be considered as wired channels)
Related
I want to know in RPL networks, after a node sends one packet to another node (for example RPL-Collect/udp-sender), how to know that intended node will forward this packet or not? I think overhearing neighbors transmission is needed, but is the another simple way to implemented this scenario in Contiki/Cooja?
To overhear packets in addition to normal operation you need to do several things:
Ensure that the radio is turned on and in the right channel. If you're using always-on CSMA or ContikiMAC you don't need to do anything special. Same for TSCH minimal schedule. Otherwise for TSCH you need to schedule a Rx cell with the right channel offset and in the right timeslot.
Somehow hack into the MAC layer to print or account packets not addressed to you - normally the MAC layer silently drops such packets.
Ensure hardware frame filtering is turned off (the radio is in promiscious mode).
Example:
radio_value_t radio_rx_mode;
/* Entering promiscuous mode so that the radio accepts all frames */
NETSTACK_RADIO.get_value(RADIO_PARAM_RX_MODE, &radio_rx_mode);
NETSTACK_RADIO.set_value(RADIO_PARAM_RX_MODE, radio_rx_mode & (~RADIO_RX_MODE_ADDRESS_FILTER));
If you just need to overhear packets and don't need the normal operation things and simpler. You can use SenSniff then.
I know that SPI plays an important role in IPsec. But I want to know that:
Is it possible to remove SPI from IPSec header and still get it work?
I don´t think that could be possible. But It´s always depends of the kernel´s implementations.
According to the RFC 4301, a SA is identify by three parameters: IP destination, Security Protocol (AH, ESP) and a SPI.
The SPI is unique, if we had a SA with the same IP destination and same Security Protocol (for example, diferent encryption algorithm) the only parameter that could differentiate the SA is the SPI, needed to map the traffic.
https://www.rfc-editor.org/rfc/rfc4301
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.
I've looked over the info on BSCANE2 in http://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf (pg 169 7 Series FPGA Configuration Guide) and I can't quite figure out how to use it based on that descriptions.
I want to be able to use the JTAG port on the KC705 board to shift in some configuration data for our design. I think (based on the description there in the user guide linked above) that the BSCANE2 is what I need to do that... but I really don't understand why all of the pins of the BSCANE2 component seem to have the wrong direction (TDO is an input while all of the other JTAG control sigs like TCK, RESET, TDI are outputs). Initially I had thought that there was an implicit connection from the signals of the JTAG port of the FPGA to the instantiated BSCANE2 component, but that doesn't appear to be the case based on the port directions. I suspect I'm missing some information somewhere and while I have read the docs it's still not clear to me how to actually use the BSCANE2 to do what I'm trying to do.
Any example usage of a BSCANE2 component would be appreciated.
NOTE: the description of the BSCANE2 in the user guide linked above says:
The BSCANE2 primitive allows access between the internal FPGA logic and the JTAG Boundary Scan logic controller. This allows for communication between the internal running design and the dedicated JTAG pins of the FPGA
This sounds exactly like what I need.
Xilinx offers a 8 bit CPU called PicoBlaze that uses a JTAGLoader module to reconfigure the PicoBlaze's instruction ROM at runtime. The JTAGLoader is provided in VHDL for Spartans and Series-7 devices.
But I think JTAG is not a good protocol for data transfer. Especially the JTAG software API is a mess.
What about UART? Most boards have a USB-UART bridge like CP2103 that supports up to 1 MBoud.
Here is the topology under discussion:
NIC0 NIC0 NIC0
| | |
+-----+-----+ +------+-----+ +------+------+
---NIC1 NIC2---------NIC1 NIC2-----NIC1 NIC2---- . .
+----PC1----+ +----PC2-----+ +-----PC3-----+
I have stack of PC Boxes each having multiple (3) Nic Cards, one to interface with outside world, and others to be used to daisy chain for communication among themselves.
Q(1) Can someone suggest if I can somehow control "multicast traffic" on daisy chained systems without letting that mixed with traffic coming from NIC0(diagram below) Cards?
I am running Linux kernel on each boxes. I can give multicast address in the interface name, but my guess is that it would not guarantee the mixing of traffic if the NIC0 traffic also has same multicast IP, so, is ACL a answer?
Q(2) My application needs subscribe-notify setup, and that's why I need multicast. There are options such as using 0MQ that also use TCP based multicast(PGM). Will that protect me here somehow?
I don't know why you would daisy chain these computers. Before going any further, you should connect these machines with a switch.
Really, though, I don't understand what your questions is...