n_gsm issues

n_gsm issues

[Guillaume JUAN]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 4366 bytes --]


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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: n_gsm issues

[Alan Cox]

> Who can I contact to discuss issues / submit fixes ?

This list and me more specifically.

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

That one is intentional.

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

We start in passive mode to tyr and avoid useless commands but could
certainly be improved.

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

What kernel verison is this ?

> This issue is the most disturbing for me, as I consequently can see no way
> to end mux session in a fully satisfying way.

Probably we need to split 'ldisc close' and 'ending a mux'

(eg have an ioctl for 'mux shutdown')

Alan

Réf. : Re: n_gsm issues

[Guillaume JUAN]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 5052 bytes --]

Hi Alan,

Thanks for your quick reply.

> > - 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.
>
> What kernel verison is this ?

I'm using a 2.6.35 kernel, but I have upgraded specifically n_gsm.c to the
latest version I found in
      git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
('git describe' tells me it is v3.5-8833-g2d53492)
I also checked that I had all the n_gsm changes from
      git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
Is there anything newer ?

About CLD command I referred to the following line of code:
      gc = gsm_control_send(gsm, CMD_CLD, NULL, 0);
Passing NULL makes the function not put any L byte in the TLV.
The 3GPP 27.007 chapter 5.4.6.1 states
"
All [control] messages sent between the multiplexers conform to the
following type, length, value format:
      Type  Length      Value 1     Value2      …     Value n
Each box in the diagram represents a field of minimum size one octet.
"
From which I understand length should be present even if 0.
Of course the receiver can still infer the length from the Type or the
wrapping UIH framing but this is somewhat a layering violation.
So the source code could be replaced by:
      u8 len = 0 << 1 | EA;
      gc = gsm_control_send(gsm, CMD_CLD, &len, 1);
This is how gsmMuxd formats CLD command.


> > gsmtty_close does not wait for event DLCI_CLOSED after
> > calling gsm_dlci_begin_close.
>
> That one is intentional.

Oh. I thought it was safer for close to be synchronous.
Is it intentional in gsmtty_hangup too ?
I am not very familiar with the concept of tty hangup but I believed it
imposed to cease I/O on the tty after the function returns.
Moreover the call to tty_vhangup() from gsm_cleanup_mux() will lead to arm
the T1 timer and if left asynchronous, to try to send stuff after
gsmld_detach_gsm has set gsm->tty NULL.


> Probably we need to split 'ldisc close' and 'ending a mux'
> (eg have an ioctl for 'mux shutdown')

That would sure give better control to user-space on when the mux is
closed, but on the other hand:
- that would add some new states to manage, where the ld is attached but
not muxing
- I liked the idea to (try to) close the mux when all files descriptor on
the physical tty are closed.
When eg the user space application is killed and has not the opportunity to
call the ioctl, it would be cleaner if the modem was not left in mux mode
(all the more that the tty layer force reset to N_TTY line discipline and
thus you have no clue left that the peer is still muxing)

I was half-hoping you would identify other line discipline callbacks that
could be useful for this purpose, or ways for the ld to tell the tty layer
it needs to access the tty at closing time.
Just for a try, on my side I
- commented the code disabling reception in tty_set_ldisc
- moved the 'mux shutdown' code in gsmld_flush_buffer and in uart_close I
moved the call to tty_ldisc_flush() a few lines upwards, before
uart_shutdown(), right after 'tty->closing = 1'

It worked fined for the use I make of n_gsm, but of course this is not
clean as
- I don't know the impact it could have on other line disciplines
- I guess I am diverting callback tty_ldisc_ops.flush_buffer from its
intended use
BTW what is the meaning of "flush" here ? Is it "push the last bytes to the
tty" or "discard the bytes you have in store" ?
If the latter meaning, isn't there a lack for a callback that would give a
last opportunity for the line discipline to send bytes ? Is n_gsm the only
to have this need ?


BRs
Guillaume
#
" 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: n_gsm issues

[Alan Cox]

> I'm using a 2.6.35 kernel, but I have upgraded specifically n_gsm.c to the
> latest version I found in
>       git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> ('git describe' tells me it is v3.5-8833-g2d53492)
> I also checked that I had all the n_gsm changes from
>       git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
> Is there anything newer ?

No - the Linux tty git and linux-next are the current tree. All
development that matters is done upstream.

> > > gsmtty_close does not wait for event DLCI_CLOSED after
> > > calling gsm_dlci_begin_close.
> >
> > That one is intentional.
> 
> Oh. I thought it was safer for close to be synchronous.
> Is it intentional in gsmtty_hangup too ?

Yes. The underlying serial events are modelled on the way actual physical
serial links operate

	hangup blocks all further access to that user app

	open waits until the port is back ready to use

	close does not normally block for long (this is actually
	configurable on some drivers and maybe n_gsm should support that
	too)

> I am not very familiar with the concept of tty hangup but I believed it
> imposed to cease I/O on the tty after the function returns.
> Moreover the call to tty_vhangup() from gsm_cleanup_mux() will lead to arm
> the T1 timer and if left asynchronous, to try to send stuff after
> gsmld_detach_gsm has set gsm->tty NULL.

Which would be a bug!

The basic idea of hangup goes back to modems. You want to prevent an end
user leaving an app hanging on a dial in port pretending to be the login
process and collecting authentication data.

(its basically using carrier a secure attention key)

> I was half-hoping you would identify other line discipline callbacks that
> could be useful for this purpose, or ways for the ld to tell the tty layer
> it needs to access the tty at closing time.

There is no facility for this in the tty layer currently.

> BTW what is the meaning of "flush" here ? Is it "push the last bytes to the
> tty" or "discard the bytes you have in store" ?

discard

> If the latter meaning, isn't there a lack for a callback that would give a
> last opportunity for the line discipline to send bytes ? Is n_gsm the only
> to have this need ?

It is - and trying to block there causes lots of difficult locking
problems. It's something that eventually wants addressing but we have a
lot of other locking to sort out first !

Alan