From: Jean Tourrilhes <jt@bo...> - 2002-07-22 18:04:15
Claudiu Costin wrote :
> After a blackout because of HDD corruption, I managed
> to work again and update the Linux-IrDA website.
> The status page is in sync:
> Finally I have a kernel 2.5.26 working.
I'll start getting 2.4.X more up to date as soon as 2.4.19 is
> The ir252_hashbin_fixes.diff din't fix anything
> for me, so the kernel crashed short & hard.
If you want me to debug, you will have to send me a lot more
> BTW, there must be a limit to the number of
> open & bind IrDA sockets. Specs say 127+1.
Hmm... I think that would be even less. You will exhaust the
LSAP space pretty quickly.
> Also must be a way to not le users open IrDA
> in exclusive mode and let it that way. It's
> a bit like a DoS and a IrDA protocol weakness.
> So, to set a capability() ?
What are you talking about ?
On Monday 22 July 2002 21:02, Jean Tourrilhes wrote:
> > The ir252_hashbin_fixes.diff din't fix anything
> > for me, so the kernel crashed short & hard.
> If you want me to debug, you will have to send me a lot more
CPU: Cyrix 266MHz=20
Motherboard: ALI M5243 +
VGA: Matrox "Mistique" 2M RAM=20
Ethernet: RTL 8029
Audio: Crystal CS4281
Debian (up to 3.0)
compiled very tight, only sound + ethernet for my need,
framebuffer for Matrox, for CPU 5x86, APM support
IrdA: _all_ compiled as modules and without IrCOMM because
doesn't compile, _all_ drivers as modules
I applied hashbin fixes version 2 & compiled a new kernel.
After reboot exec'd only:
I compiled & exec'd tst3.c as normal user (opend 256=20
irda sockets & binded).
Then as root:
instant reboot. No oops, no panic. Just reboot.
In cases when I run "tst3", then stop then run, then stop
and after that run the cat /proc/... are chances
to have a delayed reboot.
In few cases even a full output from "irias", another cases
just a partial output because my "cat" process get killed.
> > BTW, there must be a limit to the number of
> > open & bind IrDA sockets. Specs say 127+1.
> Hmm... I think that would be even less. You will exhaust the
> LSAP space pretty quickly.
That's the protocol, nothing to add. IAS is on 0, users have=20
mux'ed LSAPs on 1-126 and 127 (0x7f) is for exclusive access
to LAP connection if I recall corectly. But see below...
> > Also must be a way to not le users open IrDA
> > in exclusive mode and let it that way. It's
> > a bit like a DoS and a IrDA protocol weakness.
> > So, to set a capability() ?
> What are you talking about ?
The IrDA specs have been designed with Windows & DOS like systems in mind.
No provision for multiuser systems. It's easy for a user to catch the 0x7f=
selector and aquire exclusive access to IrDA for that LAP link.
I think will be nice to ensure that processes wich have some=20
capability, e.g. CAP_NET_BIND_SERVICE.
Claudiu Costin, claudiuc@...
Linux-KDE Romania http://www.ro.kde.org