distros using fso-gsm0710muxd will not register

[BillK]

I have never been able to register to a carrier with the gsm0710muxd
Ive tried 4 vodafone SIMs - one ~7-8 yrs old, others between a year or two
One Telstra 3g grey sim purchased 22/01/2009

All work in 2007.2 (3 of the vodafone sims), and 2008.x - none work with the mux, even on 2008.x if I use the mux as per the wiki.

Appearance is that the mux never receives any data after sending the first wakeup and just goes silent.
attached is a logread, frameworkd.log and ophoned.log

The distro here is shr-lite from unstable downloaded 23/01/2009 with the latest fso-gs0710muxd (9.3) built today (but results are identical no matter what distro I use with any version of the mux). I modified it here to permanently turn on verbose messages for the logread as I couldnt get shr to do so using the -v argument.

Results are identical with a standard gsm0710muxd using the -v argument - no matter what distro or version of the mux.

BillK

[BillK]

logread with -v flag set in gsm0710muxd

[BillK]

Spent a couple of hours yesterday (23/01/2009) with Paul Furtser on IRC going through this:
found that the GSM uart settings on the bad GTA02 are different to the working one.

Defaults before the serial port open are very different - but probably irrelevant - 9600 baud instead of 115200 and other settings are not the same.

After the port is open the differences are:
stty -a -F /dev/ttySAC0 on the good FR after the port is opened:
debian-gta02:~/devel/gsm0710muxd/src# stty -a -F /dev/ttySAC0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = ^{?; kill =} U; eof = ^{D; eol =
<undef>; eol2 = <undef>;
swtch = <undef>; start = <undef>; stop = <undef>; susp = <undef>; rprnt =} R;
werase = ^{W; lnext =} V;
flush = ^{O; min = 0; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon
-ixoff -iuclc -ixany -imaxbel
-iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke
debian-gta02:~/devel/gsm0710muxd/src#}

On the bad GTA02, the same command gives (differences in bold):
speed 115200 baud; rows 24; columns 80;
intr = <undef>; quit = <undef>; erase = ^{?; kill =} U; eof = ^{D; eol =
<undef>; eol2 = <undef>; start = <undef>; stop = <undef>; susp = <undef>;
rprnt =} R; werase = ^{W;
lnext =} V; flush = ^{O; min = 0; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon
-ixoff -iuclc -ixany -imaxbel
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke}

Tests were done with/without the SIM and SD card, using the SHR-lite distro, but the results are the same under 2008.12, with the SIM and SD card present.

The bad uart appears to be running in a terminal mode (24 rowsx80cols) and does not have the line discipline option. There is also a "swtch" setting on the good uart that isnt on the bad one.

So perhaps the mux needs some changes to deal with the differently setup mux??

BillK

[BillK]

ok, found the difference, but needs a serial guru to make sense of it:)

I straced qtopia (working) and the mux (not working) and found that there is a difference in the termio c_cflags used.
qtopia: c_cflags=0x18b2
mux: c_cflags=0x800018b2

According to "bits/termio.h" (if I have decoded it right) the mux is setting CRTSCTS flowcontrol.
However, this is again set a couple of lines later using an IOCTL. qtopia only sets CRTSCTS using the IOCTL.

if I use stty to force it off, the repeating " AT COMMAND READY" messages stop, and I can again communicate with the modem via minicom etc. If the bit is set, all I get are the messages.

The weirdest part is that after it uses the ioctl, qtopia appears to have reset the uart to 0x800018b2 (which is actually what I expect), and keeps working.

I have not been able to get the mux to behave this way so far, however I can cure the "AT COMM..." messages by just turning CRTSCTS off using the "stty" command.

BillK

[mickey]

No serial expert either, but let me add to the mystery. My device works perfectly with gsm0710muxd although stty -F /dev/ttySAC0 emits the same parameters as your nonworking one.

I can't find a way to enable the line 0 discipline (tried with ioctl TIOCSETD) or change rows/columns here either.

Could this be some race in the kernel?

[BillK]

There should be a specific line discipline used for the ti-calypso in some cases - and the ficgta01 multiplexor (in 2008.12 source) has it - the gsm0710muxd does not set it that can I see:

in "ficgta01multiplexer.cpp":

bool Ficgta01MultiplexerPlugin::detect( QSerialIODevice *device )
{
The FIC needs a special line discipline set on the device.

QSerialPort *port = qobject_cast<QSerialPort *>( device );
if (port) {

int discipline = N_TIHTC;
::ioctl(port->fd(), TIOCSETD, &discipline);

}

and:
​http://www.handhelds.org/hypermail/htc-pxa/0/0089.html

[mickey]

The TIHTC line discipline has been developed for some HTC devices, it's neither useful on our hardware nor present in our kernels. Qtopia's call will just silently fail and I'm surprised to see it in there.

[BillK]

Initialisation file - run immediately before loading mux

[BillK]

Patch for mux

[BillK]

ok, I have a working mux.

I moved the power and reset lines outside the mux for convenience - the important line in the initialisation is the stty line in "mygsm" the attachment to setup the uart.

The two lines that read, then set the flags+O_NONBLOCK are the probable cause?

I am hoping that when the changes to the serial port stuff filter through, this will go away as what I am seeing doesnt make sense if everything was being properly handled.

I have upgraded in the interim to moko11beta firmware with no change to this problem.

BillK