Tag Archives: pain

oh udev. oh yes

Posted by KarlP on 25 May, 2016 None comments

I try and do the “right thing” when it comes to the future and how linux distros see their roles and the way things should be.  I think systemd has some generally good ideas, though I think upstart has far far better documentation.  Anyway, given that linux distros still “protect” users from plugging in usb devices, except for all those ones that they _don’t_ protect you from, if you’re working with embedded electronics, sooner or later you need to “fix” permissions for some device you have.  No matter, the canonical advice for a “long time” has been something like adding a file in /etc/udev/rules.d/doesnt_really_matter.rules with some content like…


ATTRS{idVendor}=="aaaa", ATTRS{idProduct}=="bbbb", GROUP="plugdev"

And you added yourself to the plugdev group, and everything was pretty much ok. Now, it’s the “future” and we can’t use anything so silly and outdated as groups to assign permissions. Heaven help us, what would become of us all if people just used groups?! Now we need to use “tags” and a magical “uaccess” incantation. Except for all those devices that we do use groups for, like usb modems, usb serial ports, usb printers, wireshark capture permissions, virtualization, colour correction devices, basically everything except “unknown” devices.

But ok, good and well, we’ll learn the new magic incantation for udev….

ATTRS{idVendor}=="aaaa", ATTRS{idProduct}=="bbbb", TAGS+="uaccess"

And…. it doesn’t work. Why? Good fucking luck finding out. If you’re lucky, someone might suggest that the name of your file isn’t right. Why should that matter? Welllll. because it does. See https://lists.freedesktop.org/archives/systemd-devel/2015-August/033946.html and https://bugzilla.redhat.com/show_bug.cgi?id=1074122#c0 for some hints and clues.

TL;DR: pretty much must be named 70-doesnt-matter.rules. At least until system decides that it should be a different number without documenting it anywhere.

SELinux is teh suck – I’ve given up.

Posted by KarlP on 30 December, 2014 2 comments

I tried, I really did. I let the selinuxtroubleshooter run, I added exceptions, I tried to do it’s bidding and be a joyful comrade marching forwards to a secure perfect future. I’ve given up. Fuck this shit. The last straw was installing nginx, to serve up a few virtual hosts in the form of /home/domain/subdomain/{site,logs}
Errors in the journal like SELinux is preventing /usr/sbin/nginx from getattr access on the file . and then how to run grep on a log and feed it an audit tool that generates exceptions. Oh yes, that’s actually how you’re meant to do things. From past experience I knew it would only allow the first layer of the onion to unpeel and I’d have to keep adding exceptions, so I looked into what it was really complaining about.

Missing labels on THE ENTIRE WEBROOT labelling them as “httpd_sys_content_t” Right. Go fuck yourself SELinux. chcon -Rt httpd_sys_content_t /home/blah/wop No. No. No. I get it, you were only trying to stop me from inadvertently starting a webserver and…. serving web content… Actually, no, that’s not it. I was very fucking explicitly trying to start a webserver. I’d installed nginx, I’d added configs for the virtual hosts, and restarted nginx. That’s pretty damn explicit.

So, I gave up, I set SElinux to “permissive” so I could maybe see logs, and maybe feel inclined to work with it again in the future. But to avoid rebooting, I then did the old “echo 0 > /sys/fs/selinux/enforce” and then restarted nginx again. Now nginx works, but… now the journal is full of “detected unhandled Python exception in ‘/usr/sbin/setroubleshootd'” and stack traces following. So it’s over SELinux. You’re beyond dead to me, and I really, really tried to make it work.

Further adventures with Contiki OS

Posted by KarlP on 26 June, 2013 None comments

I got the (very) basic things working with my port of Contiki OS to my stm32l discovery and stm32vl discovery boards. It was more painful than I expected, there were some unexpected things, but generally, nothing too complicated. Now, I’m at the point where I was hoping to be, starting to try and use the networking stacks in Contiki OS. I want to use the 6LoWPAN implementation, the RPL implementation, the TCP (v4 and v6) implementations.

And here things unravel very quickly. The docs had lead me to believe that I just needed to implement “rtimers” and it would all start working. Turned out the docs referred to an API 5 years out of date. rtimers only actually support a single timer, so you can’t really actually use them in your own apps, you’re really just providing them for the exclusive use of the radio duty cycling (RDC) code. Of which there are multiple styles.

So, yeah, you don’t need to implement them at all. Think of them as rdc_timer and it all makes a lot more sense. They were presumably only introduced at all as the existing timer code (etimer/ctimer) are based on co-operative multi tasking, and RDC algorithms need relatively hard timing to do the radio strobing.

So, what’s the status of Contiki then? The mailing list gives an interesting picture. You’ve got some very advanced topics being discussed about packet loss modelling and distance calculation methods and tweaking the latest draft of CoAP implementation. Then you’ve got posts about simple things that still aren’t fixed like examples simply not even compiling.

Oh yeah, that’s right, did I mention that? There’s examples that don’t compile. You can apply some “fixes” to make them compile, but they’re clearly not the way the makefiles and the project were intended to be, and no-one who might know is
answering.

Stepping out again, it starts to feel like Contiki OS isn’t really an OS project that you can use as is. It’s an OS that’s an incubator for other projects. TCP and UDP for both ipv4 and v6, with all of it configurable via an undocumented mix of makefile variables and C preprocessor defines. A windowing toolkit, because why wouldn’t I want to VNC to my battery powered wireless sensor node and click on things. (I’m serious, the current tree includes a graphical calculator app and a vnc server) Three different RDC algorithms. Two different CoAP implementations. A rather large and complex java modelling framework. Two different file systems. Two different webservers and a webbrowser. This is all in the same tree, along with support for ~20 platforms with ~6-7 different architectures.

It starts to make a bit more sense when you realise that it all started out as an operating system for a commodore 64, but that doesn’t really excuse it per se. Shit’s broken. Shit aint improving real fast. Back to the two different sorts of threads on the mailing list and it starts making more sense again. There’s the CS research types, using hardware the previous grad student used, with the magic incantations from the previous researcher, working on really interesting science, and Contiki OS is the base. Then there’s people who are looking around for some modern networking stacks to use on a device of their own. These other people currently have a pretty raw deal. It’s like the Contiki itself really, some really neat cutting edge science, with sharks and hot burning sun and no water nor a soul in sight to ask for help.

Fortunately, there does appear to be a few birds in the sky, hinting at land. Contiki OS’s now a github project, and getting actual pulls, rather than just being hidden inside a Swedish University. There’s a bunch of people who seem keen to try and clean up some of the accumulated cruft of ten years of grad projects being dumped into a repository somewhere. Now if only there was a little bit of direction and documentation from central leaders and we could really sail!