zeroconf implementation on an embedded linux system - linux

I have an embeeded system that I like to add zeroconf to it. The aim is:
Auto assign an IP to itself if there is no dhcp available.
It respond to mdns request and identify itself correctly.
It responds to dns-ds and broadcast its capability correctly.
Is there any library that can help me on this?
I found Avahi (http://avahi.org/) but it seems there is no development on it for some years. Is it still a good solution?
My device has Linux 2.x on it.

Avahi seems to be the de-facto standard implementation of Zeroconf for Linux and it is used pretty much everywhere. The last release is from 2012 but this does not mean it is dead -- it may just mean that it is mature and stable enough and there has been no need for additional releases yet.

Related

Using (DR)STRACE to compare Windows program execution

I'm posing a question here directly in relation to this issue on github for node-serialport. In a nutshell something that used to work fine in v4.x of the library no longer works in v6.x of the library. I think it must have something to do with how the library is opening the COM port (options or something), and I suspect its artificially limiting the power delivered over USB in the current version of the library.
I wrote the simplest scripts that I could to reproduce the problem (scripts posted in the issue) using:
NodeJS and v4.x of the library [works]
NodeJS and v6.x of the library [fails]
Python and PySerial equivalent [works]
Following through on a recommendation by the repository maintainer, I researched and found a utility for windows called drstrace that allowed me to capture logs of the execution of each of these scripts executing for a period of time (these logs are posted as attachments in the referenced issue).
Now I'm stuck, as I don't know how to make heads or tails of the drstrace logs, though I feel confident that the difference is probably evident in comparing the three files. I just don't know enough about how to read the drstrace logs and windows drivers and system calls to break through.
I realized posting this question here is something of an act of desperation, but I figure it's worth a shot. Hopefully it is clear that I've not lacked in effort pursuing this on my own, I'm just over my head at this point, and could use help getting further. Any guidance would be appreciated. Most awesome would be someone who is versed in this level of diagnostics giving it a look and reading the tea leaves. It would be great to contribute back to such an important open source library.
Update 2017 Nov 10
I reached out to FTDI support asking:
I use the FT231X in many of my products. I need some help with
understanding how the Windows FTDI driver manages power. More to the
point, I'm hoping you can help me understand how to direct the driver
to allow the full 500mA allowed by USB to be delivered to my product
by a Windows computer.
The reply was:
Just use our FT_Prog utility to set the max VBUS current to 500
mA:
This drive current becomes available after the FT231X enumerates.
I haven't tried this advice yet, but I wanted to share it with anyone reading this. The fact remains that node-serialport 6.0.4 behavior differs from both node-serialport 4.0.7 behavior and pyserial behavior.
Here is an alternative theory you could look into:
Windows interacting with V6.x might be interacting with the flow control settings differently, which might be causing your device to respond with an unexpected state causing your test to fail.
I Read a bit more about windows drivers and how they manage that i only found out that its related to the hardware manufacturer i think its not a fail from serialport it self since its really using the drivers it self it adds no extras on that level.
i am Contributor of SerialPort and can tell you that it offers only bindings for the Operating System to node that means it don't does any actions it offers you only a API read the following from microsoft they say you should ask your hardware vendor
Power Management in Serial Port Drivers (Windows CE 5.0)
Windows CE 5.0
Send Feedback
The minimum power management that a serial port driver can provide is to put the serial port hardware into its lowest power consumption state with the HWPowerOff function, and to turn the serial port hardware fully back on with the HWPowerOn function. Both of these functions are implemented in the lower layer. Beyond this minimal processing, a serial port driver can conserve power more effectively by keeping the port powered down unless an application has opened the serial port. If there is no need for the driver to detect docking events for removable serial port devices, the driver can go one step further and remove power from the serial port's universal asynchronous receiver-transmitter (UART) chip, if no applications are using the port.
Most serial port hardware can support reading the port's input lines even without supplying power to the serial line driver. Consult the documentation for your serial port hardware to determine what parts of the serial port circuitry can be selectively powered on and off, and what parts must be powered for various conditions of use.
Source:
https://msdn.microsoft.com/en-us/library/aa447559.aspx
about changes from serialport v4 => 6
new Stream Interface
but nothing changed with the core opening method of the port.
also nothing changed in the bindings which open the port
node serialport is a collection of bindings written in c++

ipsec open source for linux

What are the open source available for ipsec in linux today.
I came across 1 (strongswan), but I am very new to this. Please suggest me which is the best available one and scalable.
if you look into kernel, you may find it.
For example, there is a ipsec.h under
/include/uapi/linux/
I am not an expert of kernel. Just a clue
I think the document of strongswan is a good start point to understand IPSec. but the source code of strongswan is not friendly enough for learning IPsec implementation.
I would recommend you start from the source code of ip, part of iproute2 utility of GNU tools.

Packet injection, filtering and mangling WITHOUT GPL?

I'll have to do packet inspection, mangling, dropping and injection of packets on a Linux system. Ideally, this would be in user space and on IP packets and Ethernet frames, too.
Unfortunately, I cannot go OpenSource for this which basically rules out any approach based on NFQUEUE and libnetfilter_queue, since all of netfilter (and their dog) is GPL only.
I thought about using TAP/TUN devices in parallel to controlling netfilter by simply calling iptables, but this seems to be messy at best...
So, are there any alternatives to netfilter?
I believe your issue is that libnetfilter is subject to the GPLv2 licence (not LGPL) and any project building on these would thus be subject to the GPLv2 licence too; this is what you want to avoid (I think).
An alternative would be to use a language binding which is not subject to the GPLv2 licence. One candidate would appear to be the Go bindings - see here for example, which appears to be under the Apache licence. I have obviously not checked the provenance of every file therein. Another way would be to divide your application into two - a small layer that communicates with Netfilter, communicating via (e.g.) an RPC interface with the rest of your application.
However, the last time I faced this, I used libpcap instead, which is BSD licensed. It's a little known fact that libpcap can send raw packets as well as receive them. However, it is much lower level than netfilter - you get raw packets and that's about it.
The license does not apply to your userspace application.

Linux SCTP implementation status

Some time ago I had used SCTP on Linux and now I want to use it again in new project. The problem is that, lksctp seems to be dead, there were no updated since 2009 (according to git). In this time few important things changed in SCTP draft, so lksctp is now out of date (API for example)
I tried to find other implementation of this protocol, but it looks, that lksctp is the only one. Doy you have any information about SCTP future on Linux?
The lksctp project first developed the Linux implementation but it is now part of the core linux Kernel and maintained there. This explains why there is little activity on the lksctp project and it does not indicate that the implementation is dead at all. Indeed I am responsible for a product line for which the Linux SCTP implementation is a central, and very reliable, component.
lksctp is enough good for you to use. If you have some question or want new features(must be reasonable), linux will implement them.
The API of sctp is still in draft. But, almost functions in draft are all implemented in linux. sctp maintainer Vlad Yasevich maybe be more busy doing other things for over half of year, even one year. But other folks still can help you.
According to this SO answer, Does SCTP works as advertised using Linux? LKSTCP is the way to go.
Note that the document that you linked to is an Internet draft, which means that the API has NOT changed. It only means that it might change if the draft becomes an RFC without being changed. If you want to track the work being done in Internet drafts then you are in experimental territory. I suggest that your best bet is to contact the authors of the draft and ask them if they know of anyone working on adding their changes to LKSTCP. Then you can work together with them on this.

Support for 802.1x Authentication in a device not supporting it earlier

I am working on an embedded system with linux kernel 2.6.10 which is not supporting 802.1x authentication mode in wired network. It will be helpful if there are any specific pointers on how to proceed to have this authentication. And wanted to know whether it is sufficient to change kernel level driver (upgrade it) or will it need changes from the Application layer also? (Atleast from the protocol specifications about IEEE 802.1x my understanding is this authentication happens at lower layer itself)
Thanks in Advance.
I have got the answer for this. I needed to have wpa_supplicant with its dependancies to be built. I was able to build and cross compile them successfully.

Resources