I am using NetSim by Tetcos to simulate Wormhole attacks in IoT networks that rely on RPL as routing protocol.
To do so I need two IoT devices to communicate with each other even if they are not linked directly in the DODAG structure. Therefore my theoretical solution would be to set up a wired link between the two malicious nodes and to do so I would need to set up a second interface in the IoT device which is not available by default.
Is there anyone of you who know how to implement this or that can help me in any way?
Thank you in advance.
I solved the problem with the help of NetSim support. I was able to implement a function that modifies the routing table of the malicious node in order for it to forward all the packets (except for DIO, DAO and DIS packets) to another malicious node of my choice creating a tunnel between this two nodes.
Related
I am starting ROS on Ubuntu 20 on Raspberry PI with setting ROS_HOSTNAME to $(hostname).local and ROS_MASTER_URI to http://$(hostname):11311.
The problem is that if I am connected to WiFi and then that connection fails (for example if WiFi goes out of range), then the robot stops working correctly.
I was thinking that a possible solution could be to create a new network interface or a VLAN and start ROS on that network and then bridge that new network to wlan interface. This would make the network that the ROS is connected to independent from wlan interface, but it would still have access to network if wlan would be online. I would also like to keep the possibility to connect to robot's ROS through another device on the wlan network.
I am asking here for help because I don't have enough networking knowledge to make this work. So any guidelines would be appreciated. If there is another better approach to solving this problem, please let me know.
I suggest using ros_bridge for communication with the robot. It is often used if you have a web interface for your robot and you need to visualize some data from the robot's backend on the web. Or even send a command to the robot.
The counterpart to this node is the roslibjs library. You can find it here
For more info, you can check Robot Web Tools, a collection of tools for web-based robot apps.
However, maybe you are not interested in web apps; you can still use ros_bridge with roslibpy which is python implementation of rosbridge protocol. It is the same as roslibjs, but this uses python instead of javascript.
You can easily create a python app which will use roslibpy to subscribe or publish to topics or call services.
This approach is better because you will encapsulate your robotic backend, and you can control what is visible to the outside world with params for the ros_bridge node. You can also handle better reconnects if your robot lost wifi connection.
Still, you can use exposed ROS_MASTER_URI for rviz and debug proposes, but I wouldn't try to use it for controlling the robot because the connection between nodes won't be recreated if you lose wifi connection.
In my work, we used ros_bridge for some time in production AMR, and I have to say that it wasn't as robust as I thought initially. For example, there were issues when the robot changed the wifi access points, and caching messages didn't behave according to the documentation. For the web, we still use it but to control a fleet of mobile robots, we had to abandon it, and we developed our solution based on rabbitmq.
But I guess that if you are using Raspberry Pi, then it is not a production robot, and therefore I think you should be OK with ros_bridge.
Chromecast v2 devices announce their presence using mDNS, and they are discoverable when performing mDNS queries for _googlecast._tcp.
DNS-SD / Bonjour also support the concept of "wide-area discovery", which makes use of standard unicast DNS queries to find devices. This can be useful for more complex networking scenarios - i.e your Chromecast devices may be in one VLAN but your sender devices are in another.
However, when trawling Chromium source I found this code in mdns_api.cc which seems to indicate that the Chrome extension will only search for _googlecast._tcp.local - completely preventing wide-area DNS discovery of other Chromecast devices. Based on anecdotal testing, it seems the Chromecast iOS app and SDK also have this behaviour.
Why does the official discovery mechanism for the Chromecast Chrome extension explicitly only discover link-local Chromecast devices?
They probably didn't do "wide-area discovery" because there are a lot of gotchas in implementing it and there isn't much gain to be had.
Let's suppose that they did implement it (from looking at the spec, it doesn't seem to be technically difficult; seems like it is mostly an edge-case problem).
You'd need:
A domain under your control. Could be a local-only domain.
Not many people do this.
Multiple VLANs that you want to use.
Most homes only have a single VLAN.
A DNS-SD server that supports Wide-Area Discovery.
This is probably the easiest thing to have. Even then, most people wouldn't do it.
A UX flow to input the various WAD servers that you want to ping for devices.
This is the hard part for Google since it needs to be consistent across all SDKs and using a WAD-discovered Chromecast would cause all local-media-server Apps to not work (e.g. Plex).
(1) - (3) are why Google wouldn't make this a priority. Chromecast is, after all, a consumer device and consumers tend to have simple networking situations. (4) is why it isn't low-hanging fruit.
You'd also need to solve a few problems:
What happens when you are connected to a Chromecast on a separate VLAN and then remove it's WAD server?
What if the WAD server goes offline?
What happens when you have multiple Chromecasts with the same name?
What if they also have the same IP address (possible since VLANs can have overlapping IP spaces)?
What happens when a Chromecast is discoverable using WAD but not reachable?
Should they attempt a connection to every single Chromecast you discover to test that it is reachable?
How would you scale this out to work with 100s of Chromecasts in VLANs that could be "far" away?
It is these problems that I think would prevent Google from implementing WAD even if they wanted to.
I am working on fpga firmware, in which i want to have very fast data transfer using ethernet . I got help from FPGA forum they say that suggest designs for data transfer using light weight internet protocol (LWIP).
How this is different from transfering the data using NDIS. I will be grateful if you can suggest me some guide to interface my visual c++ application to the network guide and tranfer the data.
many greeting in advance.
LWIP is a library for talking IP on a network.
NDIS is a specification for how an OS talks to network cards.
Neither is necessarily what you appear to want.
If you want to transfer data very simply and quickly point-to-point using Ethernet, you need to understand how Ethernet works at the packet level, and form your data into some Ethernet packets. You can make up your own protocol for this if you have control over both ends of the link.
If you want to transfer the data over an existing network topology, you would be better doing it using an existing protocol. UDP/IP might be one such protocol, depending on your requirements for data-rate, latency, software complexity, reliability etc. LWIP is one library which implements UDP, so might be of use.
I am currently working on some design concepts that would see me have the requirements for the following type of system.
In short I am looking at ways to Tunnel a connection through NAT similar to VPN but without the complexity.
I have a small embedded linux device that sits behind a home LAN that I would like to be able to interface with through an API that I have created.
Currently the setup I have is as follows:
Device A (Embedded Linux) - Public IP
Device B (Amazon Server)
I am using a REST/Json api to control Device A from Device B.
I am looking for a protocol or solution that would allow me to send two way communication from Device A and B possibly by adding a third proxy server to handle this "Tunnelled" connection.
Notes:
Would preferably like to avoid complex VPN's and the need for the NAT device to support VPN Passthough.
Traffic between Device A and B is small and not highly sensitive but some security like SSL would be nice.
This is a multinode system, Hence, There are many Device A's.
Any advice as to where I should be looking would be greatly appreciated.
Regards
pjf
I am Developing a Java ME Application. Here I am using WiFi Connection. Now My Question is how to get a particular WiFi Connections name using Java ME Code ?
My Requirement is for Nokia E5 Device only.
After doing much research work I found that this is not possible in Java ME Technology to fetch the WiFi Connection's Name.
However Similar Library would be com.nokia.multisim.networkid which returns Network ID and Network Short Name.
I Dont Think so it is 100% possible in J2ME and even though if it has worked and there is no guarantee that it will work on all J2ME devices which has Wifi connectivity.
most appropriate answer i have found , please go through it once.
" Much as I hate to put you through all that grief and then not have a simple answer, I don't have a simple answer.
The reason for that is because Java's networking model is based on TCP/IP, and the TCP/IP architecture is based on the idea that applications will neither know nor care about the hardware details of networking. A typical mobile device may contain several different network interfaces (WiFi, Bluetooth, Infrared, USB cable, and so forth), but when an app wants to contact another network node, the app doesn't know which of these interfaces is actually being used. And in fact, if the OS wants to do so, it can use more than one (in parallel) and/or switch interfaces in and out, based on routing criteria such as best measured data rates. Rather like how cell phones route phone calls.
So basic Java/JME won't know anything about WiFi.
However, there is an extension, specified as JSR 309 (http://jsp.org) that looks like it may help. It supports learning about and controlling the network interfaces themselves. The problem is that not all devices will implement this extension, so it will depend on what device(s) you are supporting. "