PinePhone VBUS_CTRL fix

I found out about another hardware fix that should be done to my rev 1.2 and 1.2a PinePhones: 2020-10-12: Backlight changes when switching between USB-C power modes

The backlight level changes depending on whether you connect a USB-C device or not. This is a very minor thing, though I previously noticed it as well. The fix is said to be easy (removing a connection on the PCB), so we’ll see. I’ve already fixed the VCONN switches on my rev 1.1 and 1.2 PinePhones, so this shouldn’t be a problem.

Luckily the next batch of PinePhones will not be affected by this problem. Nice!

PinePhone is an amazing project and I love that it keeps on improving, thanks to the work of the community and PINE64 as well. Even though every iteration (batch sold) of the device is slightly better in terms of the hardware, the previous revisions are still supported, they work fine and often times they are even DYI fixable. I hope this continues to be a great success!

SecuShare Runs

Last activity on the SecuShare Git Repository was almost exactly a year ago. Over the year the guys over at the core GNUnet did some API-breaking changes. Due to this, SecuShare does not compile.

Luckily the changes needed are mostly minor. I did some digging in the history of the GNUnet git repo and found out what were the API changes. The patch can be found in my gnunet-secushare git repository.

After this SecuShare could finally compile. The next problem was that it wouldn’t run. More precisely, gnunet-arm didn’t recognize the service.

I’m not sure if my installation is somehow misconfigured, but everything related to SecuShare was moved to a directory gnunet-secushare and not gnunet. That is why the service could not be picked up. I decided to symlink the config files and binaries into the right place:

cd /usr/share/gnunet/config.d
for i in multicast.conf psyc.conf psycstore.conf social.conf; do \
 sudo ln -s /usr/share/gnunet-secushare/config.d/$i $i; \
done

cd /usr/lib/gnunet/libexec
for i in gnunet-service-multicast gnunet-service-psyc gnunet-service-psycstore gnunet-service-social; do \
 sudo ln -s /usr/lib/gnunet-secushare/libexec/$i $i; \
done

I guess you could e.g. re-configure the build of SecuShare to move the files to the correct directory. Or update the gnunet-secushare-git AUR package. But maybe I’m just doing this wrong and gnunet-arm could be configured to look in multiple directories?

Anyway, with this I was able to start all the SecuShare services and run the gnunet-social app successfully. Not that it did anything useful. Then again I still haven’t looked at the code and what it is capable of. Let’s not forget this is an experimental prototype and not the final product. Next time!

First GNUnet phone call!

I was able to successfully make a phone call from my PinePhone to my laptop over GNUnet! Establishing a connection from the phone to the laptop worked, while trying it the other way around resulted in one of the clients crashing (and I wasn’t yet able to find out why exactly). Anyway, this is great!

So far my testing setup is this:

• both the laptop and the phone have an identity of their own, called ‘local’ on both devices: gnunet-identity -C local
• both have a reference to the other device through a PKEY GNS record: gnunet-namestore -z local -a -n XNAMEX -t PKEY -V XKEYX -e "1 d" -p, XNAMEX is e.g. phone and laptop, XKEYX is the other device’s public key obtained by gnunet-identity -d
• running the gnunet-conversation-gtk generated a ‘phone’ GNS record entry with the phone address, again on both devices

Then it is just about starting the gnunet-conversation-gtk app on both machines. On the phone I called the address phone.laptop.local. local is my local identity on the phone, laptop is the PKEY entry (GNS sub-zone) referencing the local entry on the laptop. And finally phone is actually taken from the laptop’s phone entry under local, created by the conversation app. This entry is not really available on the device yet. It needs to be obtained. And that is where GNS comes into play and fetches the needed data from the P2P network.

The call itself was established surprisingly quickly. Though this is likely due to both devices being on the same LAN and they probably know about each other by now.

I’m playing around with gnunet-conversation (and the GTK app). I managed to make a connection between my laptop and a phone, but every time the devices connect, one of the apps crash and core dump. It’s time to bring out the debugger!

As always, Arch Linux is your friend. And Arch Linux Wiki is your best friend! It has a guide on everything (GNUnet included!): Core dump

I spent some time going through the GNUnet handbook and tried out some of the commands. Naturally I compiled the most cutting edge version from git via AUR. Now I’m trying this on my LAN, building a connection between my laptop and my smartphone.

…

Now two of my smartphones have a running and working GNUnet service on them. One from git built locally, one installed from a package. Next up: creating a real network!

…

I was successful in connecting my laptop and my smartphone through GNUnet! I made a GNS query from the laptop to a record created on the phone and it came back. Not immediately of course, I had to first “pair” them as “friends” by adding the phone’s peer ID to the laptop. But then everything started magically working. Even on a second phone which also wasn’t previously able to propagate its GNS records.

I watched an HBO production video Government Surveillance: Last Week Tonight with John Oliver featuring Edward Snowden.
Entertaining presentation of a very complicated and serious topic.

I looked at secushareBox (AKA boxen): A CLI devices management utility built on P2P and GNUnet. Looks to be deserted now. And the binding from this Go code to GNUnet is done via system() calls, not a library? The motivation for this utility sounds reasonable, I might revisit it for inspiration later on.

Time to look into running GNUnet on my own. Whatever that means…

GNUnet at FOSDEM20: FOSDEM20 featured several Pine64 products, e.g. PinePhone. Now I found out GNUnet was covered as well. I’ll have to dig into this!

I watched the introduction to GNUnet from FOSDEM20. Sounds like a great project, ticking all the right boxes for me. Though the dark shadow with this one is that it is a giant undertaking with years and years of work (both behind and ahead of it) on multiple fronts. Then again, what do you expect when you want to replace the whole ISO/OSI stack?

Watched 34c4: SecuShare looks cool!

Secure Scuttlebutt is not anonymous and this is what put me off when initially looking into it. That as well as that it is reinventing the wheel and not using a standard protocol / library.

Reading about SecuShare makes me excited. Even more so when I compare it to reading about e.g. Secure Scuttlebutt or other non-cloud social networks.

I read about PSYC: I have my doubts about a 1995 protocol, but hey, SecuShare uses this, so it has to be cool, right?

Discovered youbroketheinternet.org and secushare.org with some interesting points on how and why the current Internet is broken. Can’t really argue with them…

Federation doesn’t work, here is why: I thought federation was a way to go, an improvement on the current centralized corporation-owned services. Though still somewhat true, I can’t argue that federation isn’t as awesome and wildly spread as it should’ve been by now.

GNUnet looks to be “better” than I2P or Tor according to SecuShare’s site.

Is SecuShare project still alive? Looks interesting, lots of good ideas and observations (e.g. on federation and P2P technology in social setting).

Well, there are 2020 updates on the page. Sounds like it lives to some extent.

SecuShare Prototype: “Mobile is further down the road, re-using the code for desktop. The problem is getting our daemons onto mobile operating systems.” — looks like a job for PinePhone, i.e. native GNU/Linux smartphone?