Re: [irda-users] Re: 2.4.19+recent patches -> ircomm problems

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On Fri, Aug 23, 2002 at 05:13:01PM +0200, Fabrice Planchon wrote:
> Here are some logs.
> Just to recap, I am using 2.4.19 (ac4) with the ir240 patches applied
> and your patch from a couple of days.
> The logs show a successful connection using ppp with irtty. However,
> it doesn't always work if one doesn't load the ircomm and ircomm-tty
> modules beforehand (or add a "sleep 5;" in front of the chat call made
> by pppd). I suspect the slight overhead coming from strae was enough
> to make it work in this case. I guess I can live with loading the
> modules *before* (or fussing with the scripts) but there is still a
> latency kind of thing problem somewhere.
> The next e-mail has the same logs, but with the nsc-ircc driver. There
> it fails.
> Hope you might find what is going on with this,

	Well... Bad news. Your phone is totally buggy.
	By the way, if you can't provide me a case where irtty fails,
I won't be able to dig further. But, from what I can see, you phone
has several major flaws. The boys at Ericsson don't know how to
program properly.

1) Invalid min-turn-time
------------------------

--------------------------------------
> 14:33:52.981486 snrm:cmd ca=fe pf=1 d8966f16 > 29c42130 new-ca=f6 
>         LAP QoS: Baud Rate=115200bps Max Turn Time=500ms Data Size=2048B Window Size=7 Add BOFS=0 Min Turn Time=5000us Link Disc=12s (32) 
> 14:33:53.094034 ua:rsp ca=f6 pf=1 d8966f16 < 29c42130 
>         LAP QoS: Baud Rate=115200bps Max Turn Time=500ms Data Size=256B Window Size=3 Add BOFS=0 Min Turn Time=0us Link Disc=12s (31) 
--------------------------------------

	Now, you understand why I asked you for the new
irdadump. Check min turn time. For us, we say 5000us, which is a very
reasonable and safe value. The T39 says 0us. I've never seen any
device that fast.
	The problem here is that we will give the T39 exactly what he
ask for, and the Linux-IrDA stack can be very fast (despite
advertising 5000us, it is much closer to 10us). And guess what, of
course the T39 can't support it.
	Go and play with /proc/sys/net/irda/min_tx_turn_time

2) Dropped frames
-----------------

------------------------------------------
> Aug 23 16:34:06 localhost pppd[537]: sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Aug 23 16:34:06 localhost kernel: ircomm_tty_write(), count=27, hw_stopped=0
> Aug 23 16:34:06 localhost kernel: ircomm_tty_do_softint()
> Aug 23 16:34:06 localhost kernel: ircomm_tty_do_event: state=IRCOMM_TTY_READY, event=IRCOMM_TTY_DATA_REQUEST
> Aug 23 16:34:06 localhost kernel: ircomm_ttp_data_request(), clen=0
> Aug 23 16:34:09 localhost pppd[537]: sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Aug 23 16:34:09 localhost kernel: ircomm_tty_write(), count=28, hw_stopped=0
> Aug 23 16:34:09 localhost kernel: ircomm_tty_do_softint()
> Aug 23 16:34:09 localhost kernel: ircomm_tty_do_event: state=IRCOMM_TTY_READY, event=IRCOMM_TTY_DATA_REQUEST
> Aug 23 16:34:09 localhost kernel: ircomm_ttp_data_request(), clen=0
------------------------------------------
	You see the IPCP ConfReq ? After 3s, PPP has to retry it. So,
who dropped the frame ?

------------------------------------------
> 14:34:06.184027 rr:rsp < ca=f6 pf=1 nr=5 (2) 
> 14:34:06.184090 i:cmd  > ca=f6 pf=1 nr=3 ns=5 LM slsap=10 dlsap=02 TTP credits=0 IrCOMM (33) 
> 14:34:06.204026 rr:rsp < ca=f6 pf=1 nr=6 (2) 
[...]
> 14:34:09.193848 i:cmd  > ca=f6 pf=1 nr=3 ns=6 LM slsap=10 dlsap=02 TTP credits=0 IrCOMM (34) 
> 14:34:09.214024 rr:rsp < ca=f6 pf=1 nr=7 (2) 
------------------------------------------
	Well, the frame is properly acknowledged by the T39 at the
IrDA level (nr goes from 5 to 6). So, it's lost after that.

3) chat is very inefficient
---------------------------

------------------------------------------
> 14:33:54.164076 i:cmd  > ca=f6 pf=1 nr=5 ns=6 LM slsap=10 dlsap=02 TTP credits=1 IrCOMM (7) 
> 14:33:54.174027 i:rsp  < ca=f6 pf=1 nr=7 ns=5 LM slsap=02 dlsap=10 TTP credits=1 IrCOMM (7) 
> 14:33:54.174178 rr:cmd > ca=f6 pf=1 nr=6 (2) 
> 14:33:54.194025 rr:rsp < ca=f6 pf=1 nr=7 (2) 
> 14:33:54.194073 i:cmd  > ca=f6 pf=1 nr=6 ns=7 LM slsap=10 dlsap=02 TTP credits=1 IrCOMM (7) 
> 14:33:54.204028 i:rsp  < ca=f6 pf=1 nr=0 ns=6 LM slsap=02 dlsap=10 TTP credits=1 IrCOMM (7) 
------------------------------------------
	The IrDA header is 6 bytes. So, all those (7) bytes packets
carry only a single char. No wonder it's very slow.
	Is it the fault of IrDA ?

----------------------------------------
> 14:33:58.272778 i:cmd  > ca=f6 pf=1 nr=4 ns=4 LM slsap=10 dlsap=02 TTP credits=0 IrCOMM (59) 
> 14:33:58.294021 rr:rsp < ca=f6 pf=1 nr=5 (2) 
> 14:33:58.294078 rr:cmd > ca=f6 pf=1 nr=4 (2) 
> 14:33:58.314014 i:rsp  < ca=f6 pf=0 nr=5 ns=4 LM slsap=02 dlsap=10 TTP credits=2 IrCOMM (50) 
> 14:33:58.314032 i:rsp  < ca=f6 pf=1 nr=5 ns=5 LM slsap=02 dlsap=10 TTP credits=0 IrCOMM (32) 
----------------------------------------
	When pppd is negociating, the packet sizes are more
normal. So, definitely the fault of chat.

4) NSC-IRCC - same story
------------------------

----------------------------------------
>  14:53:57.741656 snrm:cmd ca=fe pf=1 2cc4b1b4 > 29c42130 new-ca=ae 
> 	 LAP QoS: Baud Rate=4000000bps Max Turn Time=500ms Data Size=2048B Window Size=7 Add BOFS=0 Min Turn Time=1000us Link Disc=12s (33) 
>  14:53:57.877021 ua:rsp ca=ae pf=1 2cc4b1b4 < 29c42130 
> 	 LAP QoS: Baud Rate=1152000bps Max Turn Time=500ms Data Size=256B Window Size=3 Add BOFS=0 Min Turn Time=0us Link Disc=12s (31) 
----------------------------------------
	The good news is that the phone support MIR (1 Mb/s). The bad
news is that it's still as broken as before.
	Note that, as I told you, nsc-ircc is very efficient, so even
more forgiving on the bugs of the T39.

-----------------------------------------
>  14:54:06.901612 i:rsp  < ca=ae pf=1 nr=2 ns=1 LM slsap=00 dlsap=13 GET_VALUE_BY_CLASS: Success 
> 	 IrCOMM Parameters Service Type=NINE_WIRE THREE_WIRE Port Type=PARALLEL (19) 
>  14:54:06.902427 i:cmd  > ca=ae pf=0 nr=2 ns=2 LM slsap=13 dlsap=00 DISC (6) 
>  14:54:06.902541 i:cmd  > ca=ae pf=1 nr=2 ns=3 LM slsap=14 dlsap=00 CONN_CMD (6) 
>  14:54:06.916177 rr:rsp < ca=ae pf=1 nr=4 (2) 
>  14:54:06.916221 rr:cmd > ca=ae pf=1 nr=2 (2) 
>  14:54:06.926153 rr:rsp < ca=ae pf=1 nr=4 (2) 
>  14:54:06.975741 rr:cmd > ca=ae pf=1 nr=2 (2) 
-----------------------------------------
	Linux send a frame, T39 ack it at that IrDA level (nr goes
from 2 to 4), but never bother to answer it.
	That's actually a very nice violation of the IrDA standard,
because it ack a frame that is obviously corrupted.


	I think you can forward this e-mail directly to the engineers
of Ericsson.

	Good luck...

	Jean