I’ve joined my brothers & sister and their families at my sister’s flat in London for an Easter lunch. The Easter bunny has visited and my nieces have, with usual amounts of screaming and a little bit of help, located all of the chocolate eggs left here by the Easter bunny. Currently people are watching some mediocre quality 80s style Easter day viewing – Agatha Christi’s Poirot in Evil Under the Sun, although I think most people have tired of it now and are leaving soon.

On the way here I was fairly pointlessly using my soon to be replaced Nokia 6230 with O2 GPRS and Bluetooth to say “woot *on train*” on IRC, and check the times for when and where I had to change train. As with other times I’ve used GPRS, it’s been intensely frustrating. I can cope with a slow connection, and a lossy connection, so long as ssh doesn’t drop, and web pages load eventually, but the problem that continues to vex is the horribly unreliable connections. It can’t seem to keep a connection up for more than about 5 minutes – the PPP connection keeps dropping for one of a variety of reasons.

One I don’t understand is the phone just dropping the PPP connection with the laptop – it’s supposed to be a packet data service, so why can’t the phone keep the connection up with the laptop even when there’s no signal? I’d rather a few packets get lost than have to re-restablish the connection. You even get the old-fashioned NO CARRIER message if you try to establish the connection when there’s no coverage.

The second is more understandable but I think still ill-conceived. I get this error in syslog: kernel: rfcomm_recv_frame: bad checksum in packet. Looking at the code, every rfcomm packet payload has its checksum verified, and the whole packet is unceremoneously dropped with apparently no nak or retransmission if the checksum doesn’t match the data. As an emulation of a serial link, I think this is pretty poor – serial links may scramble bits, but I doubt they lose a few k of consecutive bits. Unsurprisingly, pppd’s packets with their own checksumming and such can’t deal with this, so the connection just drops.

I can’t put persist on in pppd either, because when this error happens, the connection seems to drop uncleanly and is not closed from the phone’s perspective, so it doesn’t reply to requests to open a new rfcomm connection. To compound the problem, the “Disconnect all active clients?” prompt when you try to disable Bluetooth doesn’t actually work – I have to powercycle the phone. Does anyone grok rfcomm? What happens if I just comment out the checksum check, or modify the code to allow data packets with invalid checksums to propogate up to pppd?

Hopefully the situation will get better when my new phone is activated, although I’m suspicious that the even patchier 3G coverage will just make the connection even worse, and they won’t yet have realised that packet connections should actually persistent even when there’s no coverage. Even more hopefully the phone’s Bluetooth implementation will be less buggy and not need powercycling when the connection gets dropped. I need to get gnokii talking to my old phone (either with Bluetooth or with the USB cable that came with my new one) so I can load the contacts and calendar entries onto my new phone.

And when powernowd scales the CPU downwards, rhythmbox skips, but let’s not get started about rhythmbox… a series of patches are forthcoming. 🙂