From: Alan J. M. <ala...@ya...> - 2006-09-13 21:05:14
|
In article news:200...@so..., Samuel Ortiz wrote: > On Tue, Sep 12, 2006 at 10:58:36PM +0000, surfzoid surfzoid wrote: >> [root@surfzoidPC eric]# >> with the mitsubishi : >> [root@surfzoidPC eric]# obexftp -i -l / >> Connecting...done >> Receiving "/"... Sending ""... failed: / >> failed: / >> Disconnecting...done > Oh, that's different. It's not only irdadump that's crashing, but also > obexftp... > Ok, so please do the following: > 1) As root: "echo 5 > /proc/sys/net/irda/debug". > 2) run "obexftp -i -l /" with your Mitsubishi phone. > 3) send us the full output of the "dmesg" command. > It may or may not be useful, and I don't want to interfere with the investigation that is ongoing, but I'd like to see the raw bytes in the frames. :-) Human parsing of the frame may show some oddity that's causing the fault... Now, one can use -b to have irdadump print the raw bytes in the frames, but unfortunately the parsing of the frame is done first (in the version I've looked at), so the crash is likely happening before the raw printing. (If i'm correct in understanding that _both_ irdadump and obexftp etc are crashing?) So one would also need to disable the parsing, with -p. If two similar runs can be made, with one using -p -b, then I'd cast my eye across the logs and see if I can spot anything. Other options might be necessary, for instance if the frames are long then use -s. Again, surfzoid, only think of doing this if it is not interfering with Samuel's investigations. :-) -- Alan J. McFarlane http://www.alanjmcf.me.uk/ Please follow-up in the newsgroup for the benefit of all. |