SMS wasn't sent properly, after that the channel is "stuck"

[PaulFertser]

ogsmd debug log

[jluebbe]

The problem doesn't seem to be the \r without \n, this works well here and in other methods. Instead the PDU data seems to be missing...

Line 12 and 16 of your log:

2009.01.27 16:51:14 ogsmd.channel DEBUG    <MiscChannel via /dev/pts/2>: sending 11 bytes: 'AT+CMGW=34\r'
2009.01.27 16:51:24 ogsmd.channel DEBUG    <MiscChannel via /dev/pts/2>: TIMEOUT 'AT+CMGW=34' => ???

This is sent by SimStoreMessage? in ogsmd/modems/abstract/mediator.py. You tried to store or send an SMS? It should have sent the PDU right after the \r, the same as with SmsSendMessage?.

The 34 is the length calculated form the PDU string so it is definiately not empty. Could you add debug prints to SimStoreMessage? which print the pdu string and the command string generated from it before it is enqueued?

[PaulFertser]

Yes, it makes sense. I sent some sms's that day and one sms didn't appear in the list at all.

Unfortunately, i don't remember the exact contents, so it won't be easy to reproduce. Probably just code analisys can suggest what can go wrong there?

There were no funky unicode chars, just plain ASCII.

[mickey]

You're right, there are potential problems in sending of multiline commands. I need to make these more failure-proof after MS5.

[daniel]

Has this occured again with a recent frameworkd?

[PaulFertser]

No, but i can't say it was easy to reproduce before. ;)

I don't know if Mickey's already fixed "potential problems in sending of multiline commands", so i guess it's up to him to close this ticket once he is ok with it.

[daniel]

Mickey?

[mickey]

Will fix for ms5.5

[mickey]

[9c746079d020f483257c64200cd0e18ca8586f13] should improve this. Please reopen with a log, if you ever see this again.