Thread: DSA patcher (latest in post #1)

dsa-1July2014.

New: BT speed read from the hardware chipset.
Just in case there are different chipsets, the maximum BT speed is read from /proc/barcelona/btspeed.
(I recall that voyteke was complaining about some odd BT connection issues, maybe speed was a cause, now solved?)

dsa-2July2014
New: Bug fix, related to protocol timeout.
Thanks to Zebra92's testing, a bug has been fixed.
I have not checked out this version yet on my device...


dsa-3July2014
New: Enhanced protocol timeout correction.
The protocol timeout issue is definitely solved now. The BT/DUN network raising happens now in parallel, asynchronously.

dsa-4July2014
After performing the GPRS/GSM testing, please collect files log and log2 from device, and publish them (for example, to zippyshare.com ).
Thanks.

dsa-5July2014
New: Revised, optimized code.
This is the recommended version, so far.

dsa-6July2014
if testing GPRS/GSM with it, please collect and publish files log & log2.
A few bugs have been fixed: for instance, networking is now determined correctly as up, only after the updetach pppd option is really in effect.
Before, even with Blue/DUN stopped (or BT off), there was possible a premature networking Connected report.
However, in order to avoid the protocol exchange timeout, which was causing reboots, the Connected state is reached slightly later than the moment when the networking is already up, at next exchange. But it's a small price to pay for making code reboot proof.

Now, I still hope to get more feedback from GPRS/GSM users...

dsa-7July2014
New: BT/DUN connection status is updated promptly.
When BT/DUN networking gets up, the Connected status is updated promptly.
This is for now the recommended version.


dsa-8July2014
to be tested out by GPRS/GSM users.
You may force the BT/DUN mode by creating an empty file called gprs_blue on your device top storage (SD).
And make sure that file gprs_disabled is erased.

This way, the initial mode will be BT/DUN, to overcome the lack of a valid GPRS modem.
But do not expect TomTom LIVE services, only the network will be up, with status Connected.

Since the Toggle GPRS button is a three state switch, first click will disable networking, but next click will bring you back to the GPRS (failed) mode - to be avoided!

dsa-9July2014
New: Bug fix, now it's indeed a three state Toggle GPRS button.

Beside fixing the three state Toggle GPRS switching button, there is an attempt of using a valid (fixed) SIM ID during BT/DUN network setup.

According to keessie74's testing, dual networking, GPRS/GSM and BT/DUN, is functional, and provided that a valid subscription exists, TomTom LIVE services work regardless of the kind of network in use. But the SIM ID must be valid!(?)

If the SIM ID trick will work, we may be closer than ever to getting TT LIVE services in the emulated 24/37/20/36 (mainly x40/50) modes, too!

I may add that real GPRS devices lacking a TT SIM card may also get a patched "good" SIM ID, and another SIM card from a local data provider may be used instead (socket is on the motherboard, I believe). I might be wrong here, though.

(do not forget about file serialnumber.txt which enables us to choose an appropriate device serial, in case it matters to TomTom)




dsa-10July2014

not better and not newer, just providing the extra log files, log & enhanced log2.
And now, let's get ready for the second semi-final!

dsa-11July2014
New: file simid.txt could override the real SIM ID.

Top file simid.txt (Windows text file, editable with notepad) could hold an overriding SIM ID string.
It's useful for testing purposes. Together with file serialnumber.txt, it could change the TT LIVE authentication credentials.

Note that real GPRS devices generate file simid.txt automatically, if missing, and it hopefully will ensure a working BT/DUN connection.
However, an existing file takes precedence.


dsa-12July2014
The debug version is,no better, no newer, just providing log files log & log2.

A surprising dsa.ko bug has also been ironed out (see sources).

dsa-13July2014
New: File simid.txt accepted with or without proper line terminators.

dsa-14July2014
The debug version is,no better, no newer, just provides log files log & log2 .


dsa-15July2014
New: nothing!
This is the recommend version so far.
(previously a .swp file was included by mistake)

dsa-16July2014
The debug version is dsa not newer, not better, just with log files log & log2.

dsa-17July2014
New: The real SIM ID is stored in file simid.txt automatically.
The real SIM ID is saved, unless file simid.txt existed before, to be used across device restarts, in mode BT/DUN.
The SIM ID value from file simid.txt overrides the real SIM ID, too (finally!).



dsa-18July2014
The debug version is dsa, not newer, not better, just with log files, log & log2.
Hopefully it will be no longer needed, sooner than later.

dsa-19July2014
New: Perfect personification of real GPRS devices.
In order to help GO x10/20/30 devices, BT-only capable, to present themselves as a "worthy" GPRS device to the TT LIVE servers, when masquerading a GPRS/GSM network connection via BT/DUN, the following text/Windows files could be added to the main storage, in order to override the built-in values:
serialnumber.txt, holds a new device serial
simid.txt, holds a SIM ID (aka ICCID)
imei.txt, holds an IMEI
usbname.txt, holds a new HW device name
motd.txt, holds a new device name

Only the first two files seem to be mandatory. The remaining three complete a perfect travesty as the desired device, with respect to TT LIVE servers.

I recommend a new x40 serial, and TT-like ICCID & IMEI .

The usbname/HW & device name should be those corresponding to the serial number. For example, for a 940:

usbname.txt should contain GO 940 LIVE
motd.txt should contain TomTom GO 940 LIVE

This part could be automated, in that we could compute the right usb&device names from the serial. Next time...

Unintentionally, the above scheme could be used to clone same class of devices, too.
Or so I heard...


dsa-20July2014
New: A template ppp directory is installed if missing.

It's convenient for users of the BlueDUN app on Android smartphones, in that there is no longer a need to set up a wireless connection in the x30 (25) mode.
Simply add the phone (skip wireless setup) in any, current, mode.

However, if using a real data provider, directory ppp should be configured with real data in the x30 mode, by setting up the wireless connection of the added phone.
Manual editing of file ppp/gprs-connect-chat with real APN, eventual username & password, is possible if knowing the chat syntax.

dsa-21-July-2014
New: Help has been updated with a link explaining how to clone a device.
Improperly called cloning, nevertheless Help details which are the user configurable files, how to connect to TTHome a cloned device, how to buy a new TT LIVE subscription for a BT-only device, how to set up BT/DUN networking, which is the role of the Toggle GPRS button, and last but not least, a policy change proposal for TomTom.

I remind here that by simply creating a new SN, starting with a new combination of two chars, at TT's choosing, meaning "a BT-only device" (e.g. "BTxxxxxxxxxx"), and using it, at server side, as per real x40/50/XL LIVE IQ devices, together with any fake ICCID, the LIVE services will become possible for BT-only devices, in a "smartphone connected" way. A subscription for such "BT" devices will cost less, having the data plan paid by user.

GPRS & BT devices, as dual networking capable devices, will buy a regular, full priced subscription, with a real ICCID, prepaid and working only in the covered areas/countries. However, people traveling between different areas of coverage, for example between EU and USA, will benefit greatly from not loosing their LIVE services when abroad - they simply switch to BT/DUN when abroad, and go from "always connected" to "smartphone connected".

Maybe I should rewrite the proposal in the Help, here it sounds better, it's more clearly explained...
(maybe TT listen, too)