bigbigvpn is an ephemeral VPN self-hosting managing system. You give it API keys from your favorite VPS providers, and it allows you to get VPNs on all countries they support.

You pick a country, hit connect, and in a minute or so it finishes setting everything up and automatically connects you to the VPN. You disconnect (or be offline for a configurable amount of time), and it automatically deletes the server.

You get the best of both worlds, with very low prices, dynamic IPs, large amount of locations AND the comfort of self-hosting.

It mostly started as a “would be nice” and then quickly turned into a quick 6 hour PoC. I stopped working on it for a while, but picked it back up to add more features as I ended up using it more and more, and I finally feel like I'm comfortable sharing what I accomplished so far alongside some thoughts about the whole concept.

I was supposed to post this 2 weeks ago (even said so on twitter), but life happened, and I decided to delay the PoC until it got to a state where it represented the whole potential, and that's the state now.

Demos

Please note that this is just a PoC at the moment, and while it works fairly well, it's not as polished as I'd like:

As a note, bigbigvpn can currently have providers configured with a weight value. While both DigitalOcean and Hetzner provide servers in Germany (and I have them both configured), in the video it automatically picked Hetzner there as I had a higher weight set on it.

Post release edit: My very cool friends Mary and Linuxgemini had some ideas and helped implement them, and now server spin up takes significantly less, down to ~30-40s on hetzner.

(Also available as some asciinema recordings: Connecting to a server on Hetzner, Connecting to a server on scaleway, Getting region list)

Conclusions from the “experiment”

(Please do note that I have a conflict of interest as the developer of the project.)

I do think that the idea of ephemeral VPN servers is fairly viable as long as you're willing to wait 60-90s for a server to spin up, are okay with the fact that there's little to no tooling or clients right now, and most importantly, need the benefits it provides.

Many VPS providers offer hourly pricing, and most of them (that I've used) just charge for one hour when you initially spin them up, though there's some exceptions (like Scaleway). This makes them quite viable for short term use.

There are some stuff that can be improved from a technical perspective that I intend to address (see the next section), but even with those covered, several shortcomings remain:

• Your IP is still not shared with others, though you're not on the same one all the time. This is a step up from traditional self-hosting.
• Some VPS providers (Hetzner etc) don't give you a random IP on every server creation, but seem to effectively reserve an IP to hand out back to your next server creation for a while after you delete it. This is good if you accidentally fat fingered the prod server away, and bad if you're looking for a VPN service with dynamic IPs.
• Many commercial VPN services have tons of locations, and the 3 VPS providers bigbigvpn currently supports add up to “just” 11 countries. Even if more providers were added, it might not be possible to get to a similar number of countries.
• Compared to both commercial VPN services and self-hosting, payments can get very segmented depending on how many providers you enable.
• Compared to commercial VPN services, registering is a slower process, and in many cases can involve a KYC process (Hetzner required me to send over my passport several years ago, and Scaleway is slowly rolling out ID verification too). This may not be desirable to all, but it's a compromise I'm okay with, the saying does go “Be gay, be law abiding” after all.

Going forward

Overall, bigbigvpn was intended to be quick experiment that I'd stop thinking about after a few hours, but after I talked about it with friends, quite a few of them expressed that it may be actually useful, and as such I do intend to continue working on it. It's quite fun anyways :)

Right now, bigbigvpn code is not something I'm ready to publish. While most of the server related bits are fairly clean (and as such will be carried over), web bits were fairly rushed, and I still make breaking changes to the API on a regular basis.

I have significant changes in mind and will do a complete redesign of many parts of it, and intend to open source the proper implementation early on in the development cycle.

Some of the changes I want to make include:

• Multiple device support per server/location, so you can connect from both your phone and PC at the same time, or even add your friend to your current VPN box.
• Multiple user support, so you don't have to also pay a server to manage the server-side code if you don't want to. We'll probably host an instance on lavatech too.
• Better accounting for pricing schemes (for example, Scaleway charges for first 3 hours on DEV1-S spinup, so it doesn't make sense to delete server until that time)
• More clients, most notably mobile clients.
• Support for more providers, or perhaps even just terraform.
• Preparing images and just creating VPSes from those to have faster start times. I also intend to experiment with optimizing other parts of the process to minimize the spinup time.

I'll likely be publishing the repositories under https://gitlab.com/bigbiglarge and if there's enough interest I may post more updates here in my blog.

Thanks for reading this post! I've also posted some parts I cut out from this blog post (like how we got the idea, why I want this etc) over in my side blog in case you want to read more.

(tag: #bigbigvpn)

The Turkish ID Card, aka TCKK, is a smartcard, quite an interesting one actually. It has two separate chips for contact and contactless. Both run a locally developed smartcard OS (AKİS/“Akıllı Kart İşletim Sistemi”, lit “Smart Card Operating System”). It can theoretically use a locally developed IC (UKTÜM), but none of my IDs so far had it.

The contactless interface

On the contactless (NFC) interface, it's an ISO/IEC 14443A based ICAO 9303-compliant eMRTD (Electronic Machine Readable Travel Document). I've done quite a bit of work recently to add eMRTD support to Proxmark3 and it can read my ID perfectly, but that's a blog post for another day.

The contact interface

On the contact interface, however, it's a completely different beast: It's based on a number of Turkish Standards [1], and it's seemingly quite secure.

It has various applets like ID verification, e-signature (both by your identity, and your dedicated e-imza cert, though latter wasn't deployed yet I believe) and emergency health information. Sadly, however, it's not well documented publicly (other than some exceptions [4], and all these cool features are simply... unused.

Dumping the cert

I've dumped my first TCKK cert on my first ever TCKK back in 2018 by sniffing USB communications[7], and wrote a tool to automate it back in 2019 when I renewed my ID to get my image updated, and finally got to use it again when I got a new ID in 2020 after I lost my wallet in Leipzig after 36c3 [2].

Anyhow, today I open sourced that script and another one. I'll probably be publishing more over there in the future, especially as I understand ISO/IEC 7816-4 and ASN.1 better after implementing ICAO 9303, so I will simply go over using that.

This isn't intended to be a “TCKK verification for the masses” post, so I'll skip through the simple details.

Clone TCKKTools, install python3.6+, install dependencies, plug in your favorite contact smart card reader (I use an ACS ACR39U), put in your ID with the chip facing up. You'll likely also want to install openssl as we'll be using that for converting the certificate and verifying it.

Run python3 dumpcert.py, and it should dump your certificate as a file called cert.der:

You can convert the cert from der to pem with openssl x509 -in cert.der -inform der -out cert.pem.

You can view certificate details with openssl x509 -in cert.pem -text.

Verifying the cert [3]

First off, ensure that you converted the certificate to pem format and that you have openssl installed.

Secondly, let's grab the required files. Download the following URLs (do be aware that the .crl url is fairly big, around 350MB):

http://depo.tckk.gov.tr/kok/kokshs.v1.crt
http://depo.tckk.gov.tr/kyshs/kyshs.v1.crt
http://depo.tckk.gov.tr/kyshs/kyshs.v1.crl

So... there's an odd thing where kokshs is a der and kyshs is a pem file (where kyshs lacks a newline on the file ending), so the procedure is a little odd. In any case...

# Convert CRL to a PEM
openssl crl -inform DER -in kyshs.v1.crl -outform PEM -out crl.pem
# Add a newline to kyshs.v1.crt
echo "" >> kyshs.v1.crt
# Convert the kokshs.v1.crt file to a PEM
openssl x509 -in kokshs.v1.crt -inform der -out kok.pem
# Join intermediary cert with root cert to create a cert chain
cat kyshs.v1.crt kok.pem > chain.pem
# Join chain and CRL into a single CRL chain
cat chain.pem crl.pem > crl_chain.pem

Additionally, you may have issues verifying the certificate as the CRL at the time of writing has expired (roughly 2 weeks ago), so we'll be skipping CRL expiry checks. If this is no longer the case in the future (see [5] for more info on how you can check), drop the -no_check_time. See [6] for more info on what happens if you run without that.

To verify the certificate, run this command:

openssl verify -no_check_time -crl_check -CAfile crl_chain.pem cert.pem

It should take a while, but it will go through the whole CRL and verify your TCKK cert's validity.

If you see a message like this, then your TCKK certificate is valid:

cert.pem: OK

However, if you see one like this, then it isn't:

C = TR, serialNumber = 1234568902, CN = ACAR HASAN
error 23 at 0 depth lookup: certificate revoked
error cert2017.pem: verification failed

Conclusion

I've been curious if my old ID certificates that I was keeping around were in the long, long CRL that govt publishes, but only got around to checking today. It was nice to see that they were indeed in there.

I've also been meaning to publish some of the TCKK research I made, and publishing this and the two scripts over at TCKKTools feels good. I look forward to publishing more stuff.

Disclosure

This is just one of the many ways to verify the identity of someone using the TCKK. This may not be a legally acceptable way of verifying someone's ID for actual commercial purposes (I simply haven't checked them).

Notes

1: TS 13582, TS 13583, TS 13584, TS 13585, TS 13678, TS 13679, TS 13680, TS 13681.

2: Funny story actually. I got through the whole event without losing anything, then dropped my wallet in Leipzig Hbf at an Aldi. Almost missed my flight searching it. Called my banks on Sbahn to cancel my cards. When I got to the airport there was a “Final Call” for me, Turkish Airlines staff warned me that I was late but that they'd let me through, and airport staff practically pushed me to the front of the passport line. Border control dude still took his sweet time counting the amount of days I spent in Germany before finally letting me through. I was the last to board. I ended up getting my NVI date while taxiing to gate on Istanbul Airport. But in the end everything ended up working out and I ended up getting everything reissued, which is okay I guess.

3: Huge shoutouts to this article on raymii.org as I based the CRL verification on that.

4: There's apparently a person called Furkan Duman who's working on a company developing ID verification technologies who's posted some tidbits in Turkish on his blog, I didn't get a chance to read stuff very much so far, but they look quite interesting: https://furkanduman.com/blog/category/tckk

5: Run openssl crl -in crl.pem -text -noout | grep "Next Update". You can safely Ctrl-c after the first output, otherwise it'll go through the whole file for no good reason. If the shown date is past current date, then the CRL has expired.

6: Running without -no_check_time leads to a rather confusing output from openssl. You still get the same output when feeding it invalid certificates, but you also get error 12 at 0 depth lookup: CRL has expired. However, on valid certificates, while you don't get error 23 at 0 depth lookup: certificate revoked like you do on invalids, you still get the CRL has expired line, and that leads to a verification failure, which ends up being a little confusing.

7: Huge shoutouts to linuxgemini for informing me this was possible (and overall sparking my interest in smartcards and RFID tech) and showing me how to do it on a cold election day in Ankara when I flew back to vote.

I was looking at random cheap networking stuff on the Turkish ebay clone the other day when I stumbled upon the good old 3G modems.

I always wanted one, and at some point one entered the house, but I never got a chance to use it, and I no longer am on good terms with the person who owns it now. I also ended up being given one by my grandparents several years ago, but I managed to break the sim slot before I could test it by storing a sim converter in it without the actual sim, which got stuck on the pins, and the attempts to pull it out led to the pins being destroyed. Ouch.

So, after all this time, I wanted to finally give it a shot, and they were being sold for as cheap as $3.5 + shipment, so I ordered the first one I saw, which was an “Avea Jet” model. It arrived this morning in a bootleg nutella box, and I had to pay like $2 to shipment. Yup. Can't make that shit up.

But yeah, the modem was inside that, wrapped in bubble wrap. I quickly opened it up, grabbed a SIM that has an actual data plan, found an appropriate SIM converter, stuffed it in:

So... I plugged it into my computer... and it didn't show up as a modem on neither modemmanager when I ran mmcli --list-modems, nor on dmesg:

Uh oh.

Back when my grandparents gave me their old one years ago, I didn't need to install drivers or do any special config for it to be detected, but I was running Ubuntu 16.04 back then.

This suddenly got me worried. What if the relevant kernel module was dropped since then? What if arch doesn't build it in? What if this device never got supported? What if the modem itself was broken? What if the modem is carrier locked (I was using a Turkcell SIM)?

I plugged it into the only Windows computer to try and figure out stuff, but that left me with more concerns, especially about the modem itself being broken, as the CD drive just decided to not load after some time, and as I couldn't see the modem in device manager.

So I started searching, and stumbled upon this arch wiki page, and it's pretty much the basis of this blog post.

I already had many of the software needed such as modemmanager, usbutils and mobile-broadband-provider-info, but turns out I also needed usb_modeswitch and also optionally nm-connection-editor for easy configuration of the settings (nmtui doesn't support it), and modem-manager-gui if you want a GUI for SMS.

The whole thing boiled down to:

# pacman -S mobile-broadband-provider-info modemmanager usbutils usb_modeswitch --needed
# pacman -S nm-connection-editor modem-manager-gui --needed  # these are optional
# systemctl enable --now ModemManager

But even after that, I was a little scared. usb_modeswitch --help talked about modes for huawei, cisco and many other manufacturers, but ZTE was missing from that list:

I sighed. I took a deep breath, and I re-plugged the modem and... what do you know, it showed up as a modem on dmesg and mmcli:

First off I opened modem-manager-gui, and sent a text to my girlfriend, who was able to confirm that she got it:

Being relieved that there's no apparent SIM lock or any other modem issues, I booted up nm-connection-editor, hit +, picked Mobile Broadband, and followed the wizard:

After saving, I finally booted up nmtui, disconnected from wifi and connected to the mobile broadband network:

And voila. I'm now writing this blog post while on a mobile network.

It's not fast by any means, but at least I can fall back to this in an emergency:

We're also planning having a similar setup on a colo with an IoT SIM so that we can still access the network if anything goes wrong.

That's all! Hope you enjoyed this blog post.

Optional reading after this post: A retrospective of 3G routers in Turkey

I've been using their 100/5Mbps unlimited fiber service (their highest-end plan, other than the 1000Mbps one that has its own listing and costs 1000TRY/mo) for over a year now.

Let me tell you: I suffered a lot. Anything from random internet cuts to constant network-wide slowdowns whenever we watched anything on Netflix. I was constantly spammed with calls trying to sell me Turkcell TV+ (even when I told them that I don't watch TV countless times), and roughly 5 months before my contract expired, trying to sell me expensive and lengthy contract renewals*.

And even when it worked, it wasn't as fast as promised, at least over WiFi (5GHz):

Meet the routers

Huawei HG253

When I first got my Home Internet, I was given a Huawei HG253, a rather bad router: No 5GHz WiFi, horrible DHCP (can't even set static assignments), etc.

This is a rather hated router according to bad internet forums apparently (yes, I called donanimhaber bad, bite me).

Back then I set up a pihole instance at home just to deal with the DHCP issues (and ofc, also to block some ads).

All in all, this is how it looked like (before I did cable management haha I never did):

Thankfully though, the HG253 had a security vulnerability that ended up in my favor: It sent the PPPoE password to the client on the UI, and just marked the field as a password. You can literally just check the page source and get the PPPoE password. Back then I realized this and noted down the credentials (more on this later).

The HG253 had at least one public firmware (link of my HG253 files archive, including a user guide and firmware), and had SSH enabled.

I extracted this firmware and pretty much just explored it Back Then™, but found nothing too interesting. I think I found some hashed credentials but never bothered with hashcat-ing them. SSH was also out of question, it was ancient and even when I forced ciphers it liked to error out, I couldn't get very far with it.

I don't remember exactly what happened to this router, but IIRC it just died one day, and upon calling the support line, they replaced it with a...

Huawei HG255S

The HG255S, my current ISP Router, is a fairly decent router compared to HG253 and overall to other ISP routers I've used so far: It has 5 GHz WiFi (but it sucks, you saw the speedtests earlier), decent DHCP (after the HG253 it felt nice to have), 3G modem support, built-in SIP and DECT, USB port with Samba and FTP support, etc.

However, as you may expect, most of these features are either locked down or behind a paywall. I'd honestly love to be able to modify the SIP settings so that I can have a DECT network at home that connects to my SIP network, but SOL only allows buying phone service from them. The SIP settings menu is removed from UI. More on all this later, this is what finally brought me to the point of replacing the router.

I still kept my Pihole install with this setup in order to not lose my DHCP and DNS data if my ISP ever swapped my routers again, and at that point, I was already doing a bunch of other odd stuff on that Pi anyways (like running openhab2).

“So just replace the router”

Well... Superonline doesn't allow you to replace their router if you're a fiber customer. The PPPoE credentials are not given to you even if you ask for them unless you're an enterprise customer (Relevant page for enterprise customers).

They hate the idea of you replacing the router. Whenever I call the support line with a technical problem they ask if my router is the one they gave or not.

There's literally no technical reason for this I can see, it's all red tape: The fiber cable doesn't even plug into the router, they give you a free GPON:

The fiber cable goes into that and terminates as a female RJ45 port, which then gets plugged into the WAN port on their router. After that, it's just PPPoE.

I've previously looked into getting an inexpensive router that can run DD-WRT or OpenWRT to plug into the ISP router (and to limit the use of the ISP router to just serving the DD-WRT/OpenWRT router instead), but the things I found were either incredibly high end or simply unavailable. I ordered a router that can run OpenWRT couple months ago, and the order got canceled saying that they don't actually have any left. I gave up.

The straw that broke the camel's back

Couple weeks back, I was looking into messing with the HG255S again, mostly to figure out how I can get my own SIP stuff running on it so that I wouldn't have to worry about the horrible SIP implementation on my Cisco phone, and so that I could free an Ethernet port.

While doing my usual scouring to find any new information, I stumbled upon this specific post on a bad Turkish forum mentioning them running OpenWRT on the Xiaomi Mini router, and asking if moving to that would get them better performance. I quickly checked N11 (Turkish amazon, basically) and saw that there's some other Xiaomi Mi Routers, specifically the Mi Router 4 and 4A (Gigabit Edition). I checked their OpenWRT compatibility, and after seeing that they're supported, I ordered a 4A for merely 230TRY.

I considered getting something better that costs more, but due to COVID-19, I am trying to lower my expenses.

I also went ahead and dropped ~120TRY for a bunch of different programmers to have around, lol.

More on the Mi Router 4A

It's a Xiaomi Mi Router (to be called MiR) 3Gv2, in which 3Gv2 is just 3G, but worse. If you can get one of those, go ahead. Sadly though, they're not available in Turkey. It has 3 gigabit Ethernet ports, one for WAN. It has 2.4GHz and 5GHz WiFi.

It has support for OpenWRT snapshots, though it was broken as part of the move to Kernel 5.4 for over a week now. I talk more about this later.

It runs their own OpenWRT fork called MiWiFi:

MiWiFi is fairly decent and honestly, is pretty usable by default. However, as you might expect, it's not very extensible. I wanted to use Wireguard with this router, and MiWiFi simply didn't offer that (though it did have built-in PPTP and L2TP). There are also some privacy concerns I have with Xiaomi due to the amount of telemetry my Xiaomi Mi phone sends.

It has two ways of getting proper OpenWRT on it:

The physical way

You can go the physical way by opening up the device, dumping the SPI, changing the uboot parameters, then flashing it back.

This is safer as you have a point to recover to if you somehow manage to softbrick, but in the end, there are people who posted their own images on the Internet (which will change your MAC address btw, you'll need to edit your MAC back if you flash those images).

While noting down that I was unable to successfully dump the SPI as I couldn't get the programmer to see it, I was unable to find enough information on several parts of this process before I could even attempt it, so here are some tips:

• For the most part, follow this guide
• There are two Phillips screws on these spots, after you unscrew them you need to pry open the back, I recommend using a card to do this.
• Different versions of spiflash have different names for the GD25Q128C chip, for me, it was GD25Q127C/GD25Q128C. Check yours with flashrom -L | grep -B1 -A1 GD25Q128C. If it's on a newline (like this), then you have to include the string from the last line too.

Software (OpenWRTInvasion)

The other approach is to take the lazy approach and use the software exploit, OpenWRTInvasion. This is what I ended up doing in the end.

FWIW, to get stok (session token), open the panel (http://192.168.31.1) and log in. It will be on the URL:

OpenWRT on MiR 4A time

Shortly after it arrived, I ended up installing a build from the OpenWRT forum, as the latest builds reportedly soft-bricked the device. I spent the day setting it up and learning how to use Luci (the Web UI) and OpenWRT.

Sadly though, I realized shortly after that I wouldn't be able to run Wireguard on it for some time as:

• MiR 4A doesn't have stable releases, just snapshots.
• The build I installed was an unofficial build (I later tried another build and it was one too).
• Snapshots do not have packages for older versions (except kmods, but obviously only for official builds— I tried force installing one with a matching kernel version, but it obviously didn't work as it couldn't match the symbols).
• The OpenWRT image builder uses the latest packages from the repo.
• Official snapshots do not get archived, which means that I couldn't switch to an official version.

So a couple days later, I decided to make my own build. Being scared of bricking my router (even if I could recover from it, I didn't want the hassle), I ended up hours trying to find which commit was the last safe one and then realized that the version I'm running included a git hash in the version code. Oops. I ended up going with that one.

So I set up an OpenWRT build environment and built it for the first time, and while praying to tech gods to not lead to a brick, I flashed it.

And it worked... though it was missing Luci and a bunch of other packages as I compiled them as modules, not as mandatory. Apparently, module means that you just get the ipks, while mandatory means that you get the ipks AND it gets built into the image.

I SSH'd in and installed the Luci modules I compiled (it was painful, it's like 10 packages), then did another build with everything set as mandatory.

And sure enough, it worked! I quickly posted my build and talked about my success in the OpenWRT forum.

All basic functionality worked as expected AND it had the wireguard kmod, so I could call it a success, right? Well, no.

I just couldn't get wireguard to work, it did show as connected on the router, but when I checked on the peers, it didn't show up. I never used OpenWRT before so I had no idea if I was doing something wrong or not, so I simply noted that down on the forum post and moved on.

The next day though, someone who's an OpenWRT dev posted about a patch they proposed to fix the issue on master. I quickly applied the patch, improved the set of packages I include, compiled, flashed, confirmed that it worked and posted a build to the forum.

I had to reset the settings to get it to work due to these DTS changes, and after a reconfiguration, I was happy to see that wireguard actually worked... mostly.

While it did work for IPv4, IPv6 just kept not working. This happened when I tried 6in4 too, which is rather annoying as I've been wanting IPv6 at home or some time. I think IPv6 is just broken somehow. I'll dig into it more later.

Edit, a couple days later: IPv6 on router was okay, however there were two issues:

• The server I was Wireguarding to ended up having constant issues due to upstream, leading to IPv6 downtime for some time (without me realizing it, oops).
• I had no idea how to properly distribute an IPv6 block to LAN with Wireguard, and I still don't. Yell at me with instructions here.

Anyhow, I got it working. See the conclusion for more details.

This is mostly where the state of affairs is right now. A modified version of the proposed patch was merged into master, and I also posted a build including that, but there's not much noteworthy there, nothing in the build was changed.

Extracting SOL's PPPoE creds

And as promised, what you came for: PPPoE magic.

Well, first of all, I tried using the PPPoE credentials I extracted from the HG253, but they didn't work. It'd probably work if I still had the HG253, but it probably changed when my router was being changed to an HG255S. That's all there is to the “I'll get to this later”. Yep.

There are guides out there that talk about how you can extract the credentials, but these are all aimed at people who don't use Linux, basically writing guides that are helpful to people who aren't familiar with Linux, but wasting the time of those who are familiar. Some are better tho, but IMO could be improved.

Here's my take at it:

• Log into your router, find the PPPoE username. It should look like this: 123456789123@fiber. Note it down.
• Install rp-pppoe

On Debian-based distros: # apt install pppoe

On Arch-based distros: # pacman -S rp-pppoe

• Edit /etc/ppp/pppoe-server-options

Change the contents to:

# PPP options for the PPPoE server
# LIC: GPL
require-pap
login
lcp-echo-interval 10
lcp-echo-failure 2
show-password
debug
logfile /var/log/pppoe-server-log

• Edit /etc/ppp/pap-secrets

Change the contents to (replace REPLACETHISWITHYOURUSERNAME with your username):

# Secrets for authentication using PAP
# client        server  secret                  IP addresses
"REPLACETHISWITHYOURUSERNAME" * ""

• Create the log file for rp-pppoe: # touch /var/log/pppoe-server-log; chmod 0774 /var/log/pppoe-server-log
• Find your ethernet interface with ip a. Mine looks like enp3s0, it's what I'll use in the future commands, replace that with your own.
• Shut down your router, plug in a cable to the WAN port, plug the other end to your computer.
• Run # pppoe-server -F -I enp3s0 -O /etc/ppp/pppoe-server-options on a terminal, replace enp3s0 with your own interface.
• Run # tail -f /var/log/pppoe-server-log on another terminal
• Turn on your router, wait for a little until you see lines like this:

rcvd [PAP AuthReq id=0x7 user="no@fiber" password="no"]
sent [PAP AuthNak id=0x7 "Session started successfully"]
PAP peer authentication failed for no@fiber
sent [LCP TermReq id=0x2 "Authentication failed"]

and

  script /usr/bin/pppoe -n -I enp3s0 -e 7:no:no:no:no:no:no -S '', pid 4767
Script /usr/bin/pppoe -n -I enp3s0 -e 7:no:no:no:no:no:no -S '' finished (pid 4767), status = 0x1

Take the password from the first block, and the MAC address from the second one (ignore the 7: or whatever number from the start).

Now you have everything you need to replace your SOL router.

Finally: Replacing the ISP router with a MiR 4A

This is the simple part.

Plug the cable from GPON to your router.

Log onto Luci, edit WAN (and disable WAN6), change type to PPPoE, put in the username and password we got earlier into the PAP/CHAP username and password fields like this:

Then save and apply.

ssh into your router, edit /etc/config/network, find config interface 'wan'. Add a line to it (with proper indents) with something like option macaddr 'no:no:no:no:no:no'— replace no:no:no:no:no:no with the MAC address we found earlier.

Then finally run service network restart, and you'll be free from the curse that is Superonline's ISP routers.

In conclusion

My wifi speeds are MUCH better now :)

And I can connect to our internal network without needing to VPN on the device itself :D

Soon I'll even be able to have IPv6 at home :P

I even have IPv6 at home, thanks to linuxgemini :3

Also: Capitalism is a failure, and free market ideologies are a joke. You don't get companies competing for cheaper prices, better service and less restrictions, you get companies all limiting their customers and all of them fucking them over in different ways. I am forced to use SOL because VodafoneNet and TT both have a contract minimum of 2 years, TT is unreliable AF, and TurkNet Fiber is unavailable in 99% of Turkey, including where I live, and everyone else are just resellers.

Bonus vent

*: I constantly turned down their offers as they were all worse than what I was already getting, or were slower than 100Mbps. I was also lied to, saying that fees would go up after the new year due to BTK, which was simply wrong, they still sell the same plan for the same price I started out my contract with. I ended up calling them 2 weeks before my contract expiry date, telling them exactly what I want (100Mbps, with contracts no longer than a year), they came up with a 15 month 100Mbps plan for 135TRY for the first 6 months, then 160TRY for the next 9. I kinda hesitated for the 15 months thing, but I said meh and agreed to it.

And ever since I got my Pinebook Pro, I felt the distinct lack of a delete key.

What's worse was the fact that in place of a delete key was a power key, one that, once tapped, depending on the DE either showed a power menu, or shut off the PBP:

One of the first things after I installed Manjaro ARM was disabling the power button's system shutdown effects in /etc/systemd/logind.conf, by setting HandlePowerKey=ignore (and restarting systemd-logind, which fyi kills X session)

Later on, to actually get it to work as a delete key I used something I did long ago, and just got the keycode from xev and set it with xmodmap to delete.

This wasn't perfect by any means, it had some delay, and some software like gimp just ignored it (which made image editing a lot more painful).

Then the project working on improving the keyboard and touchpad ended up releasing an update, one that allowed people to make their own keymappings.

I saw this while at work, put a note for myself:

I've been meaning to put aside some time to try and implement this behavior in the firmware itself, but I just couldn't find the time or the energy.

Until today.

The setup

I don't have much of a story to tell tbh. I cloned the repo, downloaded the requirements, compiled the tools.

I compiled and installed firmware/src/keymaps/default_iso.h (by following instructions on firmware/src/README.md) just to see if it works or not, it did, so I continued on.

After setting up this new firmware, I did notice that some functionality worked differently though, such as:

• numlock didn't turn ha3f 6f the 2eyb6ard 5nt6 a n40-ad (numlock didn't turn half of the keyboard into a numpad), but simply allowed the numpad area on the keyboard to be used with fn keys, which is a much better way of doing things.
• Fn+F3 no longer pressed p. p.
• Keyboard/Touchpad name changed from the actual part name to “Pine64 Pinebook Pro”, breaking my xinput set-prop settings. Simply renaming the device on the commands fixed this.
• Sleep button combination (Fn+Esc) did not work (I don't use this combination, but the fact that it had the image on the keyboard and worked prior to the flashing bothered me).

The tinkering

I copied the file default_iso.h to ave_iso.h, trying to figure out how it's structured. I tried to find the power button, and I couldn't find it.

There was this vague keyboard shaped array with key mappings, and I did get how one half of them worked, but I couldn't understand how the other half did:

Well, I dug in the codebase for a couple hours, trying to figure out everything, and it finally made sense.

FR, FS and FK are just arrays that are mapped to fns_regular, fns_special and fns_keypad arrays in the same file respectively. This is all explained on the firmware/src/README.md.

The number (such as 6 on FR(6)) given as argument is the index from said array.

An example entry of REG_FN(KC_Z, KC_NUBS) means that default action is KC_Z, while action when Fn is held down is KC_NUBS.

KC means keycode, and they're mapped in firmware/src/include/keycodes.h. Do note that not all descriptions are correct in practice though, one example is that KC_SYSTEM_POWER says 0xA5, but 0xA5 is actually used for brightness up (I explain why this is the case later).

The R() function used on rest of the keyboard are “Regular” keys, ones that have no actions with Fn. They're directly passed on to their KC_ versions.

If you hate yourself, you can also supply regular integers in place of any of the aforementioned functions and anywhere where you see a KC_, and this did help when I was trying to understand how things work.

FK is only able to be used with Fn keys when numlock is open. I'm not exactly sure what the difference of FR and FS are outside of semantics. (Looking at my own PR, I regret using FR instead of FS as I'm not fitting the semantics properly. Functionality seems the same though.)

I ended up implementing the sleep button combination, and I learned a lot about keyboards while trying to figure out how I could even emulate the power button. I have some links that I used during my adventure at the bottom of this article. I sent a PR with that patch and it got merged.

The realization

After asking around on the Pine64 #pinebook channel, I was told by a helpful person that the power button is wired to the SoC directly, and that SoC sends the power key input itself (or rather, that this input was handled by the device tree in the linux kernel and turned into an actual emulated keypress).

Most importantly however, they said that it could be remapped with udev. Now, I had only used udev rules to date,and it got me rather confused as I had no idea how one would remap anything with that. That got me to research how to do that, and I learned about a tool that I never used before: evtest.

And sure enough, I found it:

Upon picking gpio-key-power and hitting the key, I immediately saw the keypress (this image was taken after the change, so it says KEY_DELETE, before the change it used to say KEY_POWER):

Upon more research, I learned how to write hwdb entries in udev, not rules. Similarly, I found an already existing hwdb file in /etc/udev/hwdb.d/10-usb-kbd.hwdb, which explained why the KC_SYSTEM_POWER key was mapped to brightness up: Because the hwdb was set up this way. For reference, here's what it looks like:

evdev:input:b0003v258Ap001E*
  KEYBOARD_KEY_700a5=brightnessdown
  KEYBOARD_KEY_700a6=brightnessup
  KEYBOARD_KEY_70066=sleep

This also explained to me why KC_POWER caused a sleep action and not a power key action when done through the builtin keyboard (but not through the dedicated power button).

The ending

I quickly wrote a hwdb file myself on /etc/udev/hwdb.d/20-power-button.hwdb:

evdev:name:gpio-key-power*
  KEYBOARD_KEY_0=delete

And upon recreating the hwdb file with # systemd-hwdb update and triggering the hwdb with # udevadm trigger /dev/input/event2, the power button started working as a proper delete key.

evtest saw it as KEY_DELETE, the delay when tapping it rapidly vanished, and stuff like gimp started to acknowledge it. Now I just need to avoid holding it down.

Handy resources

• Detailed definitions for the keycodes: https://github.com/qmk/qmk_firmware/blob/master/docs/keycodes.md
• Explanation of the difference between KCPOWER and KCSYSTEMPOWER (aka KCPWR) (was helpful as I was confused as to why they were different): https://github.com/qmk/qmk_firmware/issues/1994
• More keycode definitions: http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/scancode.doc
• A question from askubuntu that made me realize that udev hwdbs exist: https://askubuntu.com/questions/877404/how-to-remap-xf86sleep-key-to-space-xmodmap-xkbcomp-udev-fail
• A blog post that was essential to me figuring out how to use hwdbs: http://who-t.blogspot.com/2019/02/adding-entries-to-udev-hwdb.html

I've been interested in public transportation for many years, and the systems that are used for collecting fares (as they're sadly paid). In Istanbul, a mifare desfire EV1 card called istanbulkart is used for this purpose. Here's the page for it.

I use public transportation every single workday, and I try to optimize my path in terms of both cost and time. (And internet connectivity, which is why I try to go for Marmaray whenever I can.)

To help myself (and others) optimize in terms of cost, I wrote up a simple tool after talking about istanbulkart with a coworker today. Specifically, he was trying to decide if he wants to get a “mavi kart” (lit. blue card, a name with your picture, name and ID number on it. Only difference from anonymous card that I know is that it allows you to get a monthly subscription- “abonman”).

I had the idea to write up a quick script to get a sum of all your istanbulkart expenses in the last month, so I wrote a quick script while we were in marmaray.

(Actually, it didn't even look like this. It used floats so it was just a big jumbled mess, it didn't show card name or currency, in fact the card number was hardcoded, and it also didn't account for refunds, which is also the case on the picture above but not in the final result)

Later in the day I extended the code and cleaned it a lot, and here's the result: https://gitlab.com/a/ikmon

It's a small project that took me an hour or two to hack together, but I hope you enjoy it regardless.

I've been meaning to figure out a promising alternative to Authy ever since Chrome Apps got killed back in 2017, especially as that was the only way to use Authy on a desktop computer back then.

Since then, Authy made their own electron app, which is the same thing as the chrome app, it just runs a separate chromium instance.

Initially, this covered my needs. I could access my tokens on my laptop, and that's sort of all I asked for.

But each time I launched it, waited for a couple seconds for it to load, scrambled in it to find the right entry, hit copy, alt-tabbed, pasted, alt-tabbed again and shut down Authy Desktop, I died a bit more inside. It just took too long, and required way too much interaction. Surely, there must be a better way to do this, right?

Sadly, I couldn't find any. So I took my time reverse engineering Authy, and hackily reimplemented the parts I needed to get it to work. It took me a weekend, but I had it done back in November and I did find a crypto weakness (more on that later), though I hadn't implemented everything back then. Notably, while I had code for Authy OTP generation, I hadn't actually implemented the API for it, especially as it had a more sophisticated sync mechanism.

Still, out of dozens of keys, only 3 required use me to launch Authy's desktop app, which was good enough. And I could just drop to a terminal, type cauthy hetz and I'd immediately have Hetzner's TOTP code in my clipboard.

Sadly (and thankfully), the “died inside more as I did this” thing still happened ever time I had to do it. I wanted to implement other stuff I wanted to implement, but my laziness kept winning.

Until today (well, yesterday).

Waluthy

Yesterday night, I sat down and started implementing more and more APIs.

After an hour or two, I got far enough that I was able to do authentication:

After a short break, I returned and implemented Authy TOTPs:

I asked for a better name for the project than “authy-cli”, especially as I wanted to make it clear that it's not affiliated with Authy, so I asked in our discord guild. This particular reply led to the cursed name of the project:

After this I extended argparser support so that I could have authentication, sync and token copying etc done from one single script, and finally implemented an interactive authentication:

And I silently released it around UTC+3 4AM. The release was silent mostly because I wanted to get some more work done on it before I posted it (also I wanted this blog post done).

Still, the people that I shared it with seemed to enjoy it, because there were cool logo ideas (by julian, eden, eden and me). I went with the second from last one there by eden for reasons.

Today, I went back and fixed a couple bugs, moved accounts into config file and implemented a local encryption feature (hopefully without the same crypto weaknesses I detailed below) so that data isn't stored plaintext.

I think it's ready enough for me to make a less-silent release, so here it is. The louder release of Waluthy.

Enjoy: https://gitlab.com/a/waluthy

The (Small) Crypto Weaknesses

Basically, there's 2 weaknesses that I spotted, both related to the “Backup Password” feature:

• The IV is 0x00*16, effectively meaning that their AES-128-CBC is actually AES-128-ECB.

• The key is derived using PBKDF2 HMAC using user's password, which is good. However, depending on the settings you use, it can be a make or break. Authy uses SHA1 with 1000 rounds.

Going by this old, 2017 gist, you can get upwards of 101.3 GH/s with a 8x1080Ti rig, which, if I'm interpreting stuff properly, means around 100M password attempts per second.

Neither of these are big issues, but all in all I do not trust the backup password feature to protect my TOTP tokens anymore in the event that my Authy account (or Authy servers) get breached.

Why didn't I report these to Authy, you might ask. Simple: They're owned by Twilio, and their bugcrowd is shared with Twilio. While it is in scope...

It is considered “Other”, which means that I'd practically get no bounty nor kudos for this:

I'm fine with that, it's a free service without ads or in-app purchases after all, but...

Yeah, no, that's not okay. Users deserve to know that this is the case, or if it gets fixed, was the case.

The issue at hand

ACS ACR122U is an inexpensive NFC reader/writer based on the NXP PN532 chip. It's what I do most of my NFC experimentation on.

Other than the limitations of it, I have one big issue with it: It has a loud, monotone buzzer.

You can disable it of course...

However it obviously does not persist between connections, and you cannot send APDUs to it unless there's a card on it. And it buzzes when it detects a card.

So, there's no easy way to prevent the buzzer from making a noise at least once using software alone, which I was reminded about again today by linuxgemini:

How I solved it

I already had my soldering iron and screwdrivers out from some stuff I was tinkering with this morning, and had my ACR122U out from last night. That made me wonder if there was an easy way to get rid of the buzzer.

I looked around on internet to see if anyone had done it before, but I couldn't find anything. Closest thing to an internal view I found was this, from this page on NFC Tools wiki.

So I took it apart (fwiw, the 4 screws are under the 4 rubber feet, I recommend putting a small screwdriver under the large sides of the feet to remove them with least pain and damage).

I was a bit baffled as I couldn't see anything resembling a traditional buzzer, but I suspected that it was the big cube that had 1839+ written on it:

But a quick search for 1839+ buzzer didn't give me much. However, I saw many similar ICs when I searched for SMD buzzer, which likely meant that I was on the right track:

I searched around more, searching for '1839+" "SMD" buzzer, and found a page selling hard to find parts. One of them included CSS-J4B20-SMT by CUI Inc with date code 1839+:

I quickly pulled up the page for CSS-J4B20-SMT-TR, and indeed, it was a SMD buzzer. I searched more, and found the datasheet for CSS-J4B20-SMT too, and that was also a SMD buzzer. The one I saw on board didn't look that much like it, but I pulled out my multimeter and was able to verify that it did indeed have voltage flowing in this direction when it beeped.

So, I desoldered it. This is my first time actually desoldering an IC, so I'm happy that I managed to do so without damaging anything nearby (except a tiny bit of internal plastic, but it doesn't cause harm):

One concern we had with linuxgemini was that it may have been used as a resistor too, and I was worried that I might end up needing to solder a resistor in its place to make it work, but thankfully (as I am horrible with electrical engineering stuff) I didn't need to. I verified that it worked by reading the entirety of a card before closing it back up, and it succeeded.

So now I have an ACR122U that will never ever buzz again. Hurray. That's what I call a success. (And now I'm tempted to practice removing more ICs by borrowing linuxgemini's ACR122U and desoldering the buzzer on that too).