RayHunter and Access Denied

If you have a spare Orbic RC400L laying around, EFF’s RayHunter might give it a new lease to life. It always warms my heart to see old (and cheap) equipment get some even as it gets gray in hair. So, of course, I tried to get RayHunter running.

Fortunately, instructions are reasonably clear. Just download the latest release and run install-linux.sh. However, on my computer that resulted in an error:

thread 'main' panicked at serial/src/main.rs:151:27:
device found but failed to open: Access denied (insufficient permissions)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Error is clear - insufficient permissions. And you can get around it by running stuff as root. But that should be only the last resort. Proper way to handle this is to add USB device rule that will put it into plugdev group and thus allow current user to access it (at least on Ubuntu).

To do this, first add a file to /etc/udev/rules.d/ directory for 05c6:f601 device (double-check numbers using lsusb, if needed).

sudo tee /etc/udev/rules.d/42-orbic-rc400l.rules << EOF
ACTION=="add", \
SUBSYSTEM=="usb", \
ATTRS{idVendor}=="05c6", \
ATTRS{idProduct}=="f601", \
GROUP="plugdev", \
TAG+="uaccess", \
ATTR{power/control}:="auto"
EOF

Once file is in place, just reload the rules (or restart the computer).

sudo udevadm control --reload-rules && sudo udevadm trigger

With this, script should now update device without any further problems.


PS: It’s really hard for me to tell if IMSI catcher update even works since I never had it trigger.

PPS: Rather than messing with wireless, I like to just access server via USB (adb can be found in platform-tools directory):

./adb forward tcp:8080 tcp:8080
firefox http://localhost:8080/

New Solution File Format

Illustration

Not all heroes wear capes. I mean, bunch of them cannot be bothered to wear pants. But all heroes should at least get a beer. And none more than those that finally took the darn .sln format behind the barn.

Yep, without much fanfare, a new solution file format was introduced. Instead of big ugly sln file everybody was used to but nobody ever loved, we got much simpler slnx file. In just a few lines new format pretty much does the only thing you need it to - list darn projects.

Gone are GUIDs, gone are Debug and Release profiles, and finally, gone is darn BOM with an empty starting line. Essentially everything is gone except for what you actually need. And yes, you can still have debug and release profiles - you just don’t need to explicitly define them in the solution file.

Migration is as easy as it gets:

dotnet sln <solution.sln> migrate
rm <solution.sln>

Looking at the whole .NET ecosystem, this feature is small. In general, I think this syntactic sugar category often gets overlooked. If it’s good, you will actually probably forgot all about how things were before. I hope that, in a few years time, sln will be just a distant memory and a way to scare children into eating their broccoli.

Slashing the Slash

Switching website to 11ty brought minimal changes when it comes to the URL setup. I actually haven’t touched URLs for years now. And there is a benefit to a stability. But then again, not all change is bad. Since 11ty did give me way more flexibility, I decided to switch things a bit.

The first change will probably not be noticed by any human. I finally removed www. prefix. And yes, both www.medo64.com and medo64.com were always supported with non-www version being redirected. However, for ages now all browsers would simply remove www prefix when displaying the address. So, one could argue that this blog’s address has been medo64.com as far as people are concerned. In .htaccess this was just a simple change to a redirect:

RewriteCond %{HTTP_HOST} ^www\.medo64\.com$ [NC]
RewriteRule ^(.*)$ https://medo64.com%{REQUEST_URI} [R=301,L]

The second change I did was getting rid of /YYYY/MM/ structure. This was actually trivial as it’s default 11ty behavior when it comes to slugs. Migrating from Wordpress, I actually had to add special slug code to retain it. Therefore, one could say I’m actually simplyhing the things now for both me and the reader.

Why did I have dates in URL in the first place? Well, I started blogging on Blogger platform that had this as default. As I moved my blog over various platforms, I just simply kept the URL format in order to make migration easier. Suffice to say, I still support old format just by a simple redirect in .htaccess:

RewriteRule ^[0-9][0-9][0-9][0-9]/[0-9][0-9]/(.*) /posts/$1 [R=301,L]

The last change is probably one I will be dealing with the longest and that will cause the most mistakes. I decided to remove the final URL slash (/). Fortunately, 11ty does support removing the slash with a simple config code:

eleventyConfig.addUrlTransform((page) => {
  if (page.url !== "/" && page.url.endsWith("/")) {
    return page.url.slice(0, -1);
  }
});

This will indeed change all 11ty generated URLs but mission is not accomplished yet. In my case, this broke page retrieval (e.g. used for literal pages). For example, in order to match both slash-anding and non-slash-ending pages, I now use:

return arr.filter(item => urls.includes(item.url) || urls.includes(item.url + '/'));

But that alone is not sufficient on Apache (and I suspect many different web servers). You also need to tell it to read index.html when user asks for a directory. I personally solve this in .htaccess:

RewriteCond %{REQUEST_URI} !/$
RewriteCond %{REQUEST_URI} !\.html$
RewriteCond %{REQUEST_FILENAME} -d
RewriteCond %{REQUEST_FILENAME}/index.html -f
RewriteRule ^(.*)$ $1/index.html

And yes, we’re still not done as there is yet another change to make. What you need it also a Directory directive in your apache configuration file:

<Directory "/srv/apache/">
  AllowOverride FileInfo
  DirectorySlash Off
</Directory>

And with all this in place I finally got rid of the pesky slash. So much work for a single character.

And there is also some minor work intentionally remaining. For example, I don’t redirect slash-URL to its non-slashed version. Not because it’s hard but because browser might have cached the old redirect thus making it a potential loop. I will probably come back and clean that up only after a month or two.

Moreover, as with all changes, I am sure I missed something. But, with 11ty in the backend, I am sure fixing stuff won’t be too difficult, once issue is discovered.

Forwarding Makefile Targets to a Script

I love make files. There is something special when you just run make and all gets built automatically. Even better, you can use multiple targets to chain a few operations together, e.g., make clean test debug All this is available to you under Linux. Under Windows, all this magic is gone.

For Windows, most of the time I see either a separate script handling build tasks, or nothing at all. A separate script is not a bad solution but it does introduce a potential difference between builds. Assuming you have Git installed, the easiest way out is to simply forward Makefile entries to the bash script. Something like this:

.PHONY: clean test debug release

clean:
	@./Make.sh clean

test:
	@./Make.sh test

debug:
	@./Make.sh debug

release:
	@./Make.sh release

And honestly, this is probably good enough. If you are on linux, you use make debug and on Windows you use Make.sh debug. For years now I used this approach whenever I needed things to work on both Linux and Windows. But there were issues - mainly with target “chaining”.

For example, if you want to run clean as a prerequisite to release, you can do that in Makefile.

…

clean:
	@./Make.sh clean

release: clean
	@./Make.sh release

This will, under Linux, do what you expect it. But, under Windows, this is not enough. So, alternatively, you might leave Makefile as-is and do the chaining in Make.sh. And that works on Windows but, under Linux, it will double call to clean, i.e.,

make clean release

will translate into

./Make.sh clean    # first call doing only clean
./Move.sh release  # second call internally does clean again

It’s not the worst issue out there and god knows I lived with it for a long time. What I need was to just forward whatever arguments I receive in make command to my Make.sh script. Reading GNU make documentation did point toward MAKECMDGOALS special variable that was exactly what I needed. It even pointed to last resort %:: syntax. So, the following Makefile looked to be all I needed.

%::
	@./Make.sh $(MAKECMDGOALS)

Only if life was that easy. This last-resort rule will unfortunately call script once for each target given to make. I.e., the final call in our example would be:

./Make.sh clean release
./Move.sh clean release

And there is no fool-proof way I found to prevent the second run. You cannot set a variable, you cannot really detect which argument you’re forwarding, you cannot exit. You could write in file that you are already running but that gets messy when task is cancelled.

I spent quite a lot of time messing with this but I never found a generic way. But, I finally managed to find something incredibly close.

all clean run test debug release &:
	@./Make.sh $(MAKECMDGOALS)

As long as you list all targets, listing only one or all of them will lead to the same command. And, because they are all grouped together, it will run it only one. It’s not ideal because I do need to keep target list in two places, but that list is not likely to change.

If you want to check my whole build script, you can check my GitHub.

Calculate This

Illustration

As I moved to Linux, I slowly started moving all my apps along. But, as I played with electronics, I often had to boot up Windows just to get to a simple calculator. I made this calculator ages ago in order to calculate various values. But I made it for Windows Store which meant it was time to make it again, this time a bit more portable.

With the help of Avalonia and a bit of C# code it was a long overdue weekend project. Most of the time I just need LDO power and voltage divider calculations, but it seemed a shame not to reimplement the others.

Since, I wanted application to work on Linux (both KDE and Gnome), choice fell between two frameworks: Avalonia and ETO Forms. I was tempted to go the ETO Forms route because I actually like(d) Windows Forms. They’re easy, event drive, and without 50 shades of indirection. But, after playing with both for a while, Avalonia just seemed more suitable.

As previously, I created the following calculators:

  • E-Series
  • LDO Power
  • LED
  • LM117
  • LM317
  • Microchip PIC PWM
  • Microchip PIC TMR0
  • Ohm’s Law
  • Parallel and Series Resistors
  • Voltage Divider

I will implement more as I need them.

While development environment does contain unit tests, currently it’s a bit low on their count. I was too lazy to implement them all. Probably I’ll write them only as I fix bug since I’m lazy that way.

If this app seems interesting, You can download it here. It should work pretty much on any glibc-based Linux out there. I will eventually make Windows setup version too, but you can you Windows Store one in meantime.