Hi,
For an embedded project with Linux inside, I am using the kernel N_GSM line
discipline (linux/drivers/tty/n_gsm.c)
It is great to have the 3GPP 27.010 multiplexing protocol integrated as a
kernel driver (previous project used user-space gsmMuxd instead),
and I am thankful for that.
However it happened I struck on some problems with n_gsm.
Who can I contact to discuss issues / submit fixes ?
Examples of problems I spotted:
- gsmld_output can cause a kernel panic dereferencing null pointer
gsm->tty.
This happens especially because gsm_ttty_hangup() calls
gsm_dlci_begin_close() even in the gsm->dead case, leading to asynchronous
send (from timer T1) after gsm->tty was set null.
gsm_tty_hangup() is called synchronously from gsm_cleanup_mux() via
gsm_dlci_release(), a few insstructions before gsmld_detach_gsm() sets
gsmt->tty null.
- When a virtual tty is closed from user-space, the operation is not fully
synchronous: DISC requests can be sent on the DLCI after the system call
has returned.
This is because gsmtty_close does not wait for event DLCI_CLOSED after
calling gsm_dlci_begin_close.
- On line discipline attach, n_gsm use default settings that have no chance
to match what I set in the modem
and when I do the TIOCSETCONF ioctl to configure it correctly, this
previous settings cause it to call gsm_cleanup_mux(), leading to delays and
useless commands to the modem (that won't be answered).
- The CLD command encoding is not strictly compliant with 3GPP 27.010
The TLV built does not have any L byte, whereas it should have one
indicating a zero length for the value field.
The modem I use accept this variant but some may not.
- The understanding of n_gsm as regards line discipline removal seems to
conflict with the logic in the upper tty layer.
In its line discipline removal callback, n_gsm tries to send commands to
the modem to close the mux and wait for the confirmation, but this is bound
to fail at least partially
because the tty layer does not seem to contemplate that the line discipline
makes a final use of the tty at this step:
* When gsmld_close is called because the last field descriptor was closed:
The commands it tries to send will not even reach the modem because
uart_shutdown has already been closed.
As a result the modem will stay in multiplexing mode and next time we send
it a (non-multiplexed) AT command it will not understand it.
* When gsmld_close is called because of a line discipline change (i.e. an
ioctl resets the tty discipline to something different from N_GSM):
The commands can reach the modem, but the line discipline will never gets
the modem answer
because tty_set_ldisc() intentionally sets tty->receive_room to 0 and calls
tty_ldisc_halt() just before calling tty_ldisc_close().
As a result n_gsm uselessly retries the commands with T1 timer because it
does not see the answer.
This issue is the most disturbing for me, as I consequently can see no way
to end mux session in a fully satisfying way.
Thanks in advance for your feedback.
Best regards,
Guillaume Juan
#
" Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles ou ayant un caractère privé. S'ils ne vous sont
pas destinés, nous vous signalons qu'il est strictement interdit de les
divulguer, de les reproduire ou d'en utiliser de quelque manière que ce
soit le contenu. Si ce message vous a été transmis par erreur, merci d'en
informer l'expéditeur et de supprimer immédiatement de votre système
informatique ce courriel ainsi que tous les documents qui y sont attachés."
******
" This e-mail and any attached documents may contain confidential or
proprietary information. If you are not the intended recipient, you are
notified that any dissemination, copying of this e-mail and any attachments
thereto or use of their contents by any means whatsoever is strictly
prohibited. If you have received this e-mail in error, please advise the
sender immediately and delete this e-mail and all attached documents
from your computer system."
#
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
