I was looking for workable options available in NS-3 to use and modify light-weight implementation of the TCP/IP (LWIP) protocol suite. So far I have found network simulations cradle (https://www.nsnam.org/docs/models/html/tcp.html#network-simulation-cradle) installation as the only option but I can only see executable stacks for linux2.6.18 and linux2.6.26. There is no executable stack for lwip. I am also having a hard time finding any tutorial online on the usage of lwip in NS-3.
Is there any way to execute lwip stack in NS-3? If not, does anyone know of any other light-weight tcp variant (with limited functionality and small footprint) that can be simulated in NS-3?
Related
due to the discontinuation of the SL-Thread stack by Silicon Labs, we are considering migrating to OT for a new device in a system that is already based on EFR32s.
The device would be a relatively simple, mains powered FTD (think "range extender").
I am trying to estimate what the effort would be and in particular I am a bit worried about OTA firmware updates.
Looking at the EFR directory in the GitHub repo, I see:
no trace of the Gecko bootloader. Does this imply that we should use a regular Gecko bootloader build from the SL SDK? Or is there a OT-specific bootloader that I'm missing?
no trace of an OTA protocol (in SL'Thread there used to be a TFTP implementation and an dotdot implementation)
Is there any plan to have a OpenThread specific OTA method? Or is the official advice to use the GeckoBootloader and implement your own transfer protocol?
Thanks in advance,
Matteo
Jonathan Hui, tech lead for OpenThread, replied in the Google Group.
Quoting him: "The primary goal of the OpenThread project is to implement the Thread protocol. Given that Thread is a network-layer technology, it does not specify a protocol for OTA. Similarly, the OpenThread project does not include bootloaders and OTA in its scope."
I have lots of experience with the efr32 line of microcontrollers and, incidentally, I'm also attempting to port our Silicon Labs Thread implementations to OpenThread. So I think I can help you here...
If you only need a powered (assuming non-sleepy) full thread device this may not be too much of a problem. You can build the demo projects from the command line (either in Linux or Windows Subsystem for Linux) and just change one of the demo projects to meet your needs.
If you need an IDE build for advanced debugging functionality or just general usability this is much more of a challenge.
The bootloader may be a bit of an issue though. OpenThread is only designed to implement the Thread protocol and is generic so it can be used in a myriad of applications. You won't see any of the Gecko Bootloader stuff there, or any bootloader stuff for that matter.
The Gecko bootloader is essentially an application that runs after a microcontroller reset which looks for a Gecko bootloader image (.gbl) either in external flash or internal flash. If it finds an image it will overwrite the existing application and boot into it. If it doesn't find an image it will just jump to the application. So you're bootloader challenge is 2-fold.
1) The application has to put the .gbl image into the memory location the Gecko bootloader expects. There isn't a standard way to to this as far as I know, it's up to the application. My application, for instance, repeatedly polls a CoAP endpoint to grab chunks of the .gbl image to put in external flash (which is where my bootloader expects the image). Then when it gets the whole image it reboots.
The demo project for the efr32 boards in openthread use a linker script that doesn't include space for the Gecko Bootloader. You'll have to reverse engineer the linking process used in the Simplicity Studio build. It uses 2 linker files as well as some #defines to put the application in the correct location. Depending on your comfort level with the build process this may or may not be difficult.
A note of caution: If you need an migrate an existing Silicon Labs Thread stack based project to an OpenThread project you're in for a beast of a project. The Silicon Labs Thread stack integrates a simple non-rtos based scheduler and sleep functionality. OpenThread, even the efr32 demo projects, contain none of this. Because the Silicon Labs Thread stack is closed source, it makes this much much more difficult. I'm attempting to do this right now an it is very unpleasant. I wouldn't wish it on my worse enemy.
I would like to work on Weave but I noticed that Nest has open sourced Openthread instead. I would like to get my hands dirty with Openthread but if someone can answer these questions for me I would really appreciate that.
Is one preferred over the other for certain applications. If so, what are they?
Will devices running Openthread be directly compatible with ones running Weave?
Will these devices be able to communicate with Android devices as is or is future support in Android being planned?
What soc's or emulators can I test Openthread on?
Thanks in advance!
First Question
Succinctly, in terms of the OSI model:
Thread is a network technology that defines layer 2 (link-layer) and layer 3 (network-layer). Thread gives your embedded device IPv6 interface with some nifty capabilities, such as fault-tolerance, mesh networking, and low power consumption.
Weave is (for the most part) a layer 6 protocol, like CoAP or HTTP. It is a protocol that applications running on embedded devices can use to communicate with each other. It requires an IPv6 network interface, which could be provided by ethernet, Wi-Fi, or Thread.
It is important to differentiate OpenThread and Thread. OpenThread is an open-source implementation of the Thread standard.
Both technologies are designed to be used (albeit in different ways) in residential settings on the following loose categories of embedded devices:
Embedded devices that need to be able to reliably communicate with each other under adverse conditions, like a power outage or a fire.
Battery-operated embedded devices that need to be able to last for many years without changing or recharging the battery.
Sensor networks for monitoring things like temperature, motion, humidity, etc.
Second Question
The implication of your question is that the two technologies are mutually exclusive, or that they somehow solve similar problems. As the cute naming implies, Thread and Weave are complementary technologies. Weave needs a network interface to communicate with other devices, and Thread provides one.
Thread is like Wi-Fi in this way. Wi-Fi doesn't define the protocols that run over it. For example, just because a smart thermostat and a smart light switch have Wi-Fi radios doesn't mean that they can communicate with each other. It will be a similar situation with devices that have Thread-compatible radios.
Third Question
While there is no particular reason why you would not be able to use Thread or Weave (or both!) to communicate with devices running Android (or any other operating system), the the devil is in the details: there is no one-size-fits-all solution.
That being said, one way is to use IPv6 routing: Thread is based on IPv6, so if you have a Thread border router, you can allow devices on a Wi-Fi network to directly communicate (via IPv6) with devices on the Thread network.
Fourth Question
In addition to the POSIX simulator, the CC2538 is now an officially supported hardware platform. Support for Dialog's SmartBond™ SoC family of chips is currently provided directly by Dialog.
it might help to first better understand Thread and what it is trying to solve. Designed for the home, Thread is an IPv6 networking protocol built on open standards for low-power 802.15.4 mesh networks that can easily and securely connect hundreds of devices to each other and the cloud. This is different than Weave, which is an application protocol. Multiple application protocols can be developed on top of Thread, including Nest Weave. The Thread Group has a nice technical overview of Thread on their site.
Now to your specific questions:
You should use OpenThread if you're looking for an open source low-power, ipv6-based mesh networking protocol to build upon for your home connectivity application protocol
That really depends on what you mean. Any application protocol built on Thread should be compatible at the network layer with OpenThread, assuming they are targeting compatible versions of Thread.
One of the key design goals of Thread is being able to allow the Home Area Network to reliably communicate to the cloud through Border Routers. We demonstrated an Android app controlling a Thread end device from a Android. Here is a video.
You can find a CLI simulator in the /examples folder. At the time of this writing, OpenThread is still rather new - however we expect to see various SoCs officially supported from our silicon launch partners. Watch the repo for more updates.
Fuzz testing tools generate malformed packets of protocols. Do they use their own TCP/IP stack to generate these malformed packets? Does the operating system's TCP/IP stack play any role in Fuzz testing?
I am working on a MPLS Fuzz testing tool running on Windows 7 OS. The tool is testing a MPLS stack on a Linux machine. Does my test tool use the windows stack? I was told that windows does not support MPLS but the test tool works just fine.
Any tool that doesn't rely on kernel modifications will have to go through the OS's networking stack. This doesn't mean that they necessarily have to use the networking stack's TCP/IP support: many OSes support APIs like SOCK_RAW+IP_HDRINCL (Windows, BSD, OS X)/PF_PACKET (Linux) which lets you build your own packets (which do not have to be TCP, or even IP).
This means that userspace tools are free to bypass the TCP/IP handling in the OS and roll their own packets so long as the OS provides the necessary support (and most major ones do).
I have a system I want to test, the system handles a proprietary network protocol (this need to be checked). The tested protocols are over TCP and UDP.
I'm looking for a software I could install on my OS-X/Linux/Windows computer connect it to the system I want to test and inject protocol messages and analyse feedback (software should have the ability to compare for each received message if it is the expected one etc.).
Prefer a software with a nice looking GUI and open-source so I could add features if needed (could be a paid software).
Where should I begin?
There is a probably a library/framework which implements the protocol. My approach would be to use it (or write it when it's missing) to write simply unit tests.
There are many unit testing frameworks with nice GUIs, headless modes and automated tools, so unless you can be more specific, it's hard to suggest something.
With the Argos protocol analyzer (http://xpro.co/index.php/products/argos), you can:
define your proprietary protocol in XML
monitor IP traffic, offload to TCP/UDP endpoints, load proprietary
format text/binary logfiles
visualize the analysis
send commands/messages from command forms, where you can include also
a COM/ActiveX control, which can generate and receive traffic and
implement the logic behind it
Argos runs on Windows and it is a paid software.
Using Load Multiplier (loadmultiplier.com), you can test proprietary protocols. Any text / binary call flows (with / without media) over any transport protocol like (udp / tcp / tls / dtls / sctp / websocket / secured websocket) can be simulated using multiplier.
Disclaimer: I work for load multiplier tool.
Does anyone have already implemented zeroMQ as reliable message solution on cortexM3 nodes? I'm trying to understand if it is possible and to have a memory footprint idea of this. I will have freeRTOS OS maybe.
Thanks for ideas and suggestions.
Nicola
See this thread on the zeromq-dev list. It seems the 0MQ source makes extensive use of POSIX API, so would take some porting to be supported on a non POSIX OS. Moreover it requires a TCP/IP stack which may have a larger footprint that 0MQ itself.
For a port FreeRTOS may not be a good starting point - you'd either have to implement a porting layer to map the POSIX API calls to your RTOS and network stack, or modify the 0MQ source directly (which would make accepting updates problematic).
There are a number of RTOS with POSIX or POSIX-like APIs. Amongst free/open-source RTOS NuttX may be a better bet. It has a POSIX like API and a BSD sockets API stack.