From: Jean Tourrilhes <jt@hp...> - 2006-03-09 18:53:08
Paul wrote :
> I want to sniff the traffic between two infrared enabled devices (two
> mobile phones) using a linux laptop.
> Is it possible to (re)configure the irda modules so that it is
> possible to only sniff the traffic, and that the laptop does not
> interact with the phones? I have the problem that the phones want
> to comunicate with the laptop instead with each other.
> Disabling Discovery on the laptop does not help. Any pointers in the right
> direction are highly appreciated.
That's actually an interesting project, but there is some work
to do, and some of it might be messy. Most of what you need is already
in place. The only problem is to manage speed changes.
The first issue is that IrDA is directional with a narrow
angle, which make it impossible to aim in two different directions at
180 degrees. One solution is to use multiple dongles to spy on the
linux box. The other solution is to use a mirror, and have all 3
devices in front of the mirror. Lastly, irdadump parsing support
unbalanced parsing, so even if you spy only one device, irdadump can
do something with that.
Now, for discovery. In theory, phones should only try to
connect to devices that implement the service they require. They often
use the 'hint' bits to select which device to connect to. So, you you
unload all ircomm modules and kill any Obex application, Linux should
stop advertising those services, and the phone should try to connect
to the other phone.
Well, that's assuming those phones implement IrDA according to
spec. If they don't, add a sysfs entry to inhibit discovery reply,
that should be fairly trivial to implement. You go in irlap_event, in
NDM state, for RECV_DISCOVERY_XID_CMD, and prevent sending a frame and
entering reply mode (but don't inhibit the notification).
Now, the problem is speed change.
After connecting, the phone will switch to the negociated
speed. Some dongles are able to receive any SIR speed without knowing
it in advance, however most receiver must be programmed with the
In theory, there is a driver ioctl to set the speed. irdadump
would need to extract the negociated speed from IrLAP frames and pass
that to the driver directly via this ioctl. However, I'm not sure how
the IrDA stack will react to that. And I don't know how many driver
implement this ioctl properly.
It might be better to have those kind of speed setting done
through the stack. Have a setsockopts on the IrDA socket to force a
speed, and percolate that to IrLAP, and pass that to the driver via
the standard API, which is known to work. The good thing would be that
it would enable to get rid of the ioctl in each driver, which is
mostly dead code/bloat anyway.
Don't be afraid, it's not as bad as it sounds...