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