We are planning to use Ethernet bus topology (wiki). The reason using this very old topology is hardware limitations and software requirements. Collisions should be OK, as bandwitdh requirement is very low.
My problem is, how can we test this topology with modern Ethernet controllers and software like Ubuntu etc. I could not find a good implementation example.
I have tried connecting three Intel Ethernet controllers (with Static IPs) together and only two of them had link at a time (they worked in point-to-point connection as usual)
"Modern" hardware is rather limited when trying to build a bus topology - it's much easier to build a more usual star/tree network. However, with the right key components you can even connect both topologies.
From the software point of view, the network just "works", i.e. as long as the network is configured correctly the software applications can (and should) be oblivious to the network layout.
With an assumed Ethernet network, the logical structure of each segment is a bus anyway: each device can just talk to any other device, regardless of where and how they are connected.
Related
I would like to communicate over USB using COAP protocol.
I am currently planning to use libcoap, it has examples but it is based on UDP server-client.
If I want to use USB, what must be done?
Thanks
Depends a bit on the deployment scenario, but in general I'd recommend using USB Ethernet inbetween (CDC-ECM). Then you can use CoAP over USB like you use it over any other network connection. (If you use RIOT for your embedded device and build the gcoap example on a board with native USB and enable the usbus_cdc_ecm module, you get that almost out of the box).
The large downside of this approach is that you are subject to the whims of the host OS's network setup. Probably it'll take up at least the IPv6 link-local interface so you can go ahead with requests to fe80::addr:ess (or even use link-local multicast to find your device), but there may be pitfalls.
There is the slipmux proposal which would do CoAP over serial, but a) I don't know implementations thereof, and b) it leaves you with similar issues of how to make sure your application can really find the right serial port.
It wouldn't be impossible to specify CoAP over custom USB commands (which would then be taken up by an application), but there'd need to be really good reasons not to just go through USB networking to justify them, and I'm not sure that the complexity of ensuring that your NetworkManager is set up correctly counts.
I'm confused about what parts of a linux system do what when it comes to networking. I'm looking for a good reference about more than just the network layers. Starting with network layers though, using the OSI 7 Layer model:
7-Application
6-Presentation
5-Session
4-Transport
3-Network
2-Data Link
1-Physical
At what point do networking go from hardware to kernel to application software? I suspect at (1) it's all hardware and just signals on wires or over wifi At (2) it reaches some network interface, but do they make frames, or do the interface drivers? (3) network, IP, I'm guessing handled by the OS? (4) still kernel or at least sockets provided by low-level libraries in C/C++? (5) Not entirely sure, but thinking this is still low level, where SYN, SYN/ACK, ACK take place. And then finally (6) user-space, or application space of actual data, but in raw form. And then (7) all application, and the application can determine the intents and behavior of network communication.
I’m creating an IOT device with some unusual needs when compared with typical home automation. I wanted to ask if anyone knew of a mesh protocol (Zigbee, Thread, BLE Mesh), that might be able to achieve this user experience:
When someone turns on their device, it looks to connect to a mesh network, comprised of other devices they have previously “friended”.
If no network is found, it creates its own mesh network, available for other “friended” devices to connect to, when those devices turn on.
If the device creates its own mesh network (as in behaviour above), but no one connects to it – and then the device finds a different network with more than one friend on it, the device should kill its own network in favour of connecting to the other.
I’m expecting that there will not be a “master” node who has “friended” every possible device that wants to join the network – I’d like the possibility for “friends” to bring their “friends”, to also join the network.
If a partition in the network occurs (this is very likely to occur in my use case), the network should automatically re-form when the devices are close to each other again.
All devices are expected to be identical in function, size, software – so BLE Mesh is probably not suitable given it needs a “Provisioner”?
Messages transferred will be bespoke to this application – ruling out Zigbee’s Application Layer?
Messages will be small in size, so data transfer speed is not a big concern.
I believe from what I’ve read that Thread is probably the most suitable for this use case – but wanted some other opinions to see what the best choice might be?
Seems to be a bit of a mine field to fully understand the ins and outs of all of these mesh protocols!
I believe Thread/OpenThread addresses all of the use case items you listed above.
I'm new to DDD and I'm trying to decide how to access infrastructure hardware (network devices, specialized hardware, etc) information. Most of the devices I want to communicate with and control have a state. I'm representing the devices in the domain as objects but to replicate the state should it be through a repository or a service or some other component.
An example would be: If a customer buys a firewall the command AddFireWall would be executed and the vlan on a network device would be switch to a firewall and an IP and private IP would be placed on that firewall device. I'm representing the network devices and firewall devices as entity objects in my domain. The state of those objects/devices would be saved in the repository.
Generally speaking you domain models should be kept free from external dependencies like hardware and networks etc. There is a concept known as an Anti Corruption Layer that may be worth looking up. The idea is to build a bridge between systems like hardware and the domain. It's responsibility is to translate between the two systems. If hardware or network changes then all you need to adjust is the code in the ACL.
Other approaches could include generating event messages from the hardware. These messages can then be subscribed to be various parts of your system.
I'm currently developing a wireless connectivity between two embedded devices over 802.15.4 RF protocol. One of the devices is the coordinator(server), and the other is a node(client)
I want to make sure that only specific vendor devices will be able to communicate with the coordinator.
What's the best approach to authenticate a device to the coordinator, so other devices couldn't try to cheat. the messages are over RF so anyone can listen to them with a sniffer.
You could filter by MAC address, since all devices from a single manufacturer will start with the same three-byte OUI.
It would be better to look into the security options of ZigBee though. You could configure all of the devices with a secret, pre-shared key, and only devices with that key will be able to join your network.
Or, look at the Smart Energy model, where each device has a unique pre-shared key. The coordinator is given a MAC address and an install code out of band (some method other than over the ZigBee network) and will then allow that single device to join the network.
What level of security are you looking for? Something to prevent accidental interference by non-participating devices, or something to protect sensitive information from prying eyes? If the latter it's best not to try rolling your own solution as it's very hard to get absolute security right. As mentioned in the last answer: a ZigBee stack would provide a comprehensive solution to the problem, but the cost is added complexity and higher spec hardware (you'd need at least 128kB flash, and 4-8kB RAM to run all classes of ZigBee device comfortably).