Recently, I wanted to install a legacy OS in a virtual machine with QEMU.

However, for several reasons, I did not want it to be able to access the Internet but still be able to access some services on my host.

I had already done something similar in the past with a tap interface, but it was not very convenient, as you need to bring your own DHCP server or use manual configuration.

So, by reading the fine manual, I found an option I had not heard about before: restricted=yes on the user network mode.

It makes QEMU create a virtual network, with the usual DHCP server and connection to the host, but without Internet access.

In addition, it is possible to specify various guestfwd options.

Sadly, the forward mode opens only one connection when the machine boots. Therefore, if you want to forward every new connection, you will have to go through netcat or a similar program. For example, I used this option to redirect connections to 10.0.2.100 to an HTTP server I created with Python:

-nic 'user,model=virtio-net-pci,restrict=yes,guestfwd=tcp:10.0.2.100:80-cmd:netcat 127.0.0.1 8000'

And that was enough for me to pass a few files without using Samba or swapping isos.

WebSockets and WebRTC

At the beginning of the year, I played a little bit with WebSockets and Rust. I tried to create a backend for a browser game implemented with Three.js.

However, things did not work very well. A friend and I did some tests, but his connection was underperforming, which is actually an advantage for testing. Its delays were very high, packets kept accumulating and being applied all at once. Moreover, I had implemented everything with unbounded queues. Therefore, the server program running on my PC occupied several GB of RAM at a certain point. Good thing we found all these problems soon.

The first suggestion you find when you start programming multiplayer games is that you should use UDP if you can. So, I finally decided to try WebRTC.

I soon discovered that WebSocket and WebRTC are completely different. The former is a protocol for full-duplex communication, usually between a browser and a webserver. The latter is a series of APIs for real-time communications, and spans from media capture, streams, screen sharing to data channels, which is the capability I was interested in. … [Leggi il resto]

Contestualizzazione

Mentre ero in Erasmus in Norvegia, avevo provato WireGuard per rimanere connesso alla rete di casa, in cui si trova il mio NAS.

Da allora, ho continuato a usarlo abbastanza. Qualche volta ho usato ancora OpenVPN, ma preferisco parecchio WireGuard, principalmente perché è molto più leggero e evita che il mio router faccia da collo di bottiglia, e perché è molto più semplice da configurare.

Altre caratteristiche a suo favore sono che a Marzo di quest’anno è stato direttamente integrato nel kernel Linux e che a tal proposito il suo autore ha fatto fare una verifica di sicurezza a terze parti, che hanno espresso un giudizio positivo. Si può volere di più?

Be’, in realtà sì. Per diverso tempo, per avviare la VPN ho usato uno script shell, che aveva bisogno di essere eseguito da root. Questa soluzione non mi entusiasmava troppo, e avrei preferito un’integrazione con Network Manager, possibilmente con la GUI. … [Leggi il resto]

Negli ultimi tempi avevo accumulato un po’ di app che non mi sarebbero più servite, quali applicazioni per i treni di 3 paesi diversi, app per alberghi e aerei, quindi, sfruttando anche il periodo di calma con le ferie, ho deciso di fare pulizia a modo mio: cambiando ROM e aggiornando il mio vetusto Oneplus One ad Android 10/Q.

La cosa non è stata proprio indolore: la prima ROM che ho provato aveva problemi con le gestures di Q, la batteria durava pochissimo, dovevo caricarlo anche due volte al giorno, e il solito problema del WiFi limitato a pochi megabit/s.

Quello della batteria si è rivelato essere un problema collegato alle Gapps: il Google Play Services era la principale causa del consumo di batteria e, fortunatamente, cambiando di nuovo ROM (con MSM Xtended) l’ho risolto. Ma prima di risolverlo, ero quasi arrivato al punto di cambiare telefono, la mia unica speranza era quella di vedere come sarebbero stati i consumi una volta tornato al lavoro.

Quello del WiFi invece mi dava proprio fastidio, anche perché appena installata la ROM non si era verificato e mi ero intestardito a tal punto che ero disposto ad accettare solo un grosso bug: o il WiFi, o la batteria. … [Leggi il resto]

Da alcuni mesi ho un bug decisamente antipatico con il WiFi nel mio portatile ASUS N550, dotato di una Qualcomm Atheros AR9485.

La scheda ha sempre funzionato abbastanza bene, viene gestita dal leggendario driver ath9k, uno dei migliori driver prima dell’arrivo di 802.11AC, anche se comunque il mio modello di scheda non è mai stato considerato uno dei migliori.

Ad un certo punto, però, ho cominciato a riscontrare continue disconnessioni, o in alcuni test con wget e altri computer della LAN, riscontravo un brusco calo della velocità di download fino al fermarsi dello stesso.

In particolare, su dmesg riscontravo questo errore:

[   65.582958] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006100
[   66.744578] wlp4s0: authenticate with e8:de:27:xx:xx:xx
[   66.764530] wlp4s0: send auth to e8:de:27:xx:xx:xx (try 1/3)
[   66.769890] wlp4s0: authenticated
[   66.771192] wlp4s0: associate with e8:de:27:xx:xx:xx (try 1/3)
[   66.775556] wlp4s0: RX AssocResp from e8:de:27:xx:xx:xx (capab=0x431 status=0 aid=6)
[   66.775668] wlp4s0: associated

Come potete vedere, è capitato a solo un minuto dal boot. … [Leggi il resto]