From: Jean T. <jt...@bo...> - 2004-03-11 22:02:13
|
Volker Gehrs wrote : > > Irdadump started on the esquirt server shows me: > incoming snrm:cmd > outgoing ua:rsp and rr:rsp (ua:rsp with correct daddr) > > Irdadump started on the esquirt client shows me: > outgoing snrm:cmd (4 times with the correct daddr) > incoming nothing !! > > I have 2 Notebooks both with Linux OS. > Sony Vaio: FIR nsc-ircc > Toshiba: SIR smc-ircc If you don't see the same traffic on both end just after the connection attempt, this is a speed change issue. One driver doesn't program the new speed properly just after negociation, so they can't talk anymore. > ok you all think rtfm ;) I read it. > Its not the max_baude_rate problem, I think. > I can get a connection from Toshiba Laptop to Sony Vaio. But the other > direction does not work. > > Irdadump on Toshiba notebook: > > 14:37:42.322481 snrm:cmd ca=fe pf=1 0ab281f4 < 4a81915b new-ca=5e (32) > 14:37:42.322505 ua:rsp ca=5e pf=1 0ab281f4 > 4a81915b (31) > 14:37:55.317599 rr:rsp > ca=00 pf=0 nr=0 (0) > > Toshiba driver is smc-ircc v0.4 and smcinit. > Kernel 2.4.21 > > As said, I can connect from Toshiba to Sony Vaio but not the other way. Your irdadump is mostly useless, because you are using an obsolete version of irdadump, and it's a bit on hte short side. If it works one way, one more reason to believe it's a speed change issue. The way you change speed as a primary and a secondary are different, so one driver may handle properly only one of the case (changing as secondary is usually where there is problem). Kernel 2.6.X contains fixes to the nsc-ircc driver for speed change. This might help. Also, smc-ircc is not a very good driver, especially at FIR, and the smsc-ircc2 driver in 2.6.X is supposed to fix some of its bugs and work at FIR (but I never tried it). Of course, restricting to SIR speed via max_baud_rate may solve the problem, because SIR is much more forgiving. Good luck... Jean |