Robotic Tendencies
The personal blog of Robert McQueen

March 27, 2005


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. 🙂

posted by ramcq @ 4:12 pm
Comments (1) .:. Trackback .:. Permalink

One response to “NO CARRIER”

  1. Riku Voipio says:

    Sounds like a problem with your kernel and/or your bluetooth device on your laptop. There really shouldn’t be checksum errors at that stage – even if the connection between linux box and and the phone is poor. The other possibility is that the phone is somehow physically broken (tiny crack on the bt antenna etc).

    I would try switching the phone and bt dongle before going to the code – there seems to be only one other user in google who has had the same problem.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.