A couple of months ago, Debian bookworm became stable and I decided to upgrade my Orange Pi Zero. I wanted to re-install the system with the smallest amount of physical access and that made the whole process tiresome and longer.

The new system did not work well. It often crashed, and I continuously had to reset the system by power cycling it. As stated in my previous article, physical access to that system is not easy, which made the problem even less bearable.

After one of the crashes, I managed to get some logs, and I saw they mentioned a “kernel bug”. However, I believe high temperatures were to blame, as July was very hot here. Anyway, I had a little hope that installing a more recent kernel could solve my problem, so I tried to run apt upgrade, which gave me this output:

Preparing to unpack .../base-files_12.4+deb12u1_armhf.deb ...
Unpacking base-files (12.4+deb12u1) over (12.4) ...
dpkg: error processing archive /var/cache/apt/archives/base-files_12.4+deb12u1_armhf.deb (--unpack):
 unable to stat '.' (which was about to be installed): Value too large for defined data type
Errors were encountered while processing:
 /var/cache/apt/archives/base-files_12.4+deb12u1_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

I do not have a minimal clue about what this means. It might be related to the Orange Pi being 32-bit and me having created its system from a 64-bit system. But the error is so generic that I struggled to find its cause. … [Leggi il resto]

Almost one year ago, I switched to a Cudy WR2100.

It has worked very well in these months. I installed it, then forgot about it, but it kept doing its job.

A few months ago, we bought a cheap TV, which happened to be an entry-level Android TV, too. I tried to set it up to connect to WiFi, but it did not work. Initially, I blamed the TV, but we did not buy it for its “smart” functionalities, so we just used it as a plain-old TV for some time.

But after a while, I wanted to use my old Oneplus One as a test device with Android 9, and it could not connect, too!

I solved the issue on the phone by updating it to an Android 10 ROM (and I had to find another way to deal with the original problems that needed Android 9 in another way 😮‍💨️).

Therefore, I initially thought Pie was the problem and that Android 10 fixed some bugs. But good luck finding information about an issue like this!

Eventually, a few days ago, I thought of carefully checking OpenWRT settings. I found that “Disassociate On Low Acknowledgement”, which allows the access point to disconnect stations based on low ACK conditions, was enabled. It can be set on a network basis, so it should be turned off separately for the 2,4GHz and the 5GHz, and it is the last item in the latest tab (advanced settings).

That fixed my problems. It is the first time I have found an option that could be a wrong default on OpenWRT in all these years. Or is it a problem with the MediaTek drivers? I am not sure, to be honest.

I must say that some functionalities like YouTube works pretty well and are convenient. I would have loved to use the built-in Chromecast, but I had continuous disconnections. So, maybe the fault must be shared between the TV and the router, after all 😅️.

I have been using TP-Link TD-W8970 as my primary router since 2014.

Then, a pair of weeks ago, its modem died because of a storm. Also, the connected Ethernet ports ceased working. Luckily, the lightning did not propagate over the LAN; otherwise, damages would have been thousands of euros.

The hell of DSL users

The TD-W8970 was one of the few devices based on the Lantiq platform, the only one whose xDSL modem is supported by OpenWrt.

Most of the home networking appliances are based on the Broadcom platform. Their modem employs proprietary drivers that work only with ancient and insecure Linux kernels. And in many cases, with OpenWrt, you also lose some WiFi features.

The usual workaround is to rely on two routers. One in bridge mode, i.e., as a pure modem, connected with another one running OpenWrt. I have never liked it because it is much less clean: more devices, more heat, more power consumption, less integrated, etc… But now, I surrendered to it. … [Leggi il resto]

Il Technicolor TG789vac v2 distribuito da Fastweb è uno dei router più schifosi con cui io abbia mai avuto a che fare, ma, sembrerebbe, anche uno dei più interessanti.

Più schifoso perché, come tutti i router Technicolor distribuiti da Fastweb fino a qualche tempo fa, aveva un’interfaccia di configurazione difficile da usare e piena di bug. Anzi, il router stesso più di qualche volta mi ha dato problemi con la rete Ethernet cablata, penso l’unico con cui mi sia mai successa qualcosa del genere.

Fino a gennaio lo usavamo con una ADSL2, dopodiché sono riuscito a combinare un upgrade a FTTC da 200Mbps, quindi con quella che viene anche chiamata EVDSL. Dunque Fastweb ci ha consegnato un router nuovo, questa volta però della ZTE, e io sono riuscito finalmente a sbarazzarmi di quel dispositivo infernale.

Tuttavia, qualche tempo fa è emersa la sua parte interessante. Mentre cercavo informazioni sul Tim hub, ho trovato un sito che spiega come “hackerarli”, cioè come ottenere una shell di root e sbloccare ogni possibilità di configurazione. E, ciliegina sulla torta, i firmware Technicolor sono basati su OpenWRT. … [Leggi il resto]

Da un po’ di tempo, su uno dei miei computer, avevo creato una chiave SSH con ECDSA, per poi scoprire di non poterla usare per connettermi al mio router che ha OpenWRT. Infatti, per impostazione predefinita di OpenWRT, Dropbear viene compilato senza supporto a questo algoritmo, per risparmiare una cosa come 23KiB.

Normalmente la cosa può avere senso, perché lo spazio sulle flash è sempre estremamente limitato. Tuttavia, io ho già una chiave ECDSA basata su curve NIST e ho una extroot, quindi ho deciso di provare a ricompilare il Dropbear di OpenWRT e posto qui le istruzioni per chi fosse interessato all’argomento, incluso un futuro me.

Come ulteriore nota, vorrei evidenziare che il supporto a ed25519 non è attualmente esistente in Dropbear! C’è la possibilità di usare curve25519-donna per lo scambio di chiavi, ed è anche abilitata di default, ma non c’è nient’altro che riguardi ed25519.

Ho provato personalmente queste impostazioni su OpenWRT 18.06.1 (non ho ancora fatto l’aggiornamento alla minor successiva), sul mio TD-W8970.

Tuttavia, ho deciso di installare l’ultima versione di Dropbear, il che ha reso il tutto un po’ più difficile. … [Leggi il resto]