Hi Mike, Thanks for your work and support on diald. My housemate and I have just spent a day bashing our heads against walls trying to get diald working with our new ISDN setup, and we are beginning to feel that we understand what's going on now. I thought it would be worth sharing some of the problems we had with you, in case you can fix them for the benefit of others. - Firstly, actually finding a place to download the latest source from was really quite awkward. The `mirror' (odd choice of word since presumably it should be the master site) on your site seems to be shut down, so we had to find a recent src.rpm via ftpsearch.lycos.com. - The URL for the mailing list archive (ftp://rex.isdn.net/pub/diald) is broken. I just managed to find one at http://www.geocrawler.com/lists/3/Linux/23/0/ after a fair bit of searching, and after the first post I came across on it (from you) immediately fixed a problem we've been grappling with all day, which is: - The parameter to the `device' config command apparently shouldn't contain the `/dev/' bit! We were plagued with stuff like: Nov 14 13:56:22 casals diald[4809]: Unknown request 'Dialing of ippp0 triggered' made. Nov 14 13:56:22 casals diald[4809]: Open device /dev/ippp0 Nov 14 13:56:22 casals diald[4809]: Old /dev/ippp , New device : /dev/ippp 0 Nov 14 13:56:22 casals modprobe: no dependency information for module: "/dev/ippp" Nov 14 13:56:22 casals diald[4809]: failed to read interface status from device /dev/ippp Nov 14 13:56:22 casals modprobe: no dependency information for module: "/dev/ippp" Nov 14 13:56:22 casals diald[4809]: failed to read interface status from device /dev/ippp Nov 14 13:56:22 casals modprobe: no dependency information for module: "/dev/ippp" Nov 14 13:56:22 casals diald[4809]: failed to read interface status from device /dev/ippp and couldn't figure out why the frig it was trying to modprobe a filename! (MAN did that drive us mad!) The diald-examples man page is littered with lines like `/dev/ttyS1' so I think some clarification is needed as to when it's OK and when it isn't (it was fine when we were using diald with modem). We also got weird stuff like Nov 14 13:56:22 casals diald[4809]: Old /dev/ippp , New device : /dev/ippp 0 Nov 14 13:56:22 casals modprobe: no dependency information for module: "/dev/ippp" Nov 14 13:56:22 casals diald[4809]: failed to read interface status from device /dev/ippp where it seemed to split `/dev/ippp0' into `/dev/ippp' and `0'. We even got a `/dev/ipp0' appearing from somewhere, despite a distinct lack of typos in our config! - Another thing seemingly immediately fixed on reading examples from the list: setting connect "/usr/sbin/isdnctrl dial ippp0" disconnect "/usr/sbin/isdnctrl hangup ippp0" rather than having them invoke scripts which would do similar things. We got REALLY weird things happening, e.g. `isdnctrl dial ippp0' not terminating immediately when running inside these scripts. diald seemed to expect that the termination of the script specified by the `connect' should indicate a successful opening of the connection, but of course doing this isdnctrl command only triggers the process which opens the connection, without actually completing it. So we got strange stuff like: diald[1780]: Connect script timed out. Killing script. even after the link had been brought up properly. (Actually, thinking about it now with hindsight, this is probably because it wasn't able to read the interface status for the reasons mentioned above.) - The man page says this of the `connect' config command: This command is not optional unless the mode option is set to "dev", in which case any connect option will be ignored. AFAICS this is simply untrue! Your posts to linux-diald suggest this fact too. - The stuff you've posted on the list about diald/ISDN is most helpful. It would be great if you could add this to diald-examples or something. - Any script assigned to `ip-up' or `ip-down' never seems to get run when in `mode dev' context. - So far I haven't got dctrl to show any information at all. I've enabled all the boxes in the window and set up the fifo at both ends, but still nothing. For now we'll survive with echo queue > /etc/diald/diald.ctl :-) - If I click on `File', `Reconnect' in dctrl I get an error whose stack trace is: can't read "title": no such variable while executing "wm title . "Diald: $title"" (procedure "openMonitor" line 38) invoked from within "openMonitor" invoked from within ".menu.file.m invoke active" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke active]" (procedure "tkMenuInvoke" line 29) invoked from within "tkMenuInvoke .menu.file.m 1" (command bound to event) - Assuming at some point in the future I can get dctrl working, what's the difference between `File' `Connect' and `Control' `Up request'? And what's the `Access Name' for? - diald[5471]: Diald is dieing with code 0 It's spelt `dying' ;-) - The ethertap stuff works great! Very tasty :-) That's all I can think of for now. Hope it's of use. If you want to use us as another data-point and have any questions regarding any of this, feel free to say so. Cheers, Adam -- --- [EMAIL PROTECTED] --- musician and hacker --- http://www.new.ox.ac.uk/~adam/ echo '$_=bless[q]]],q;_;;sub s;{local$_=shift;push@$_,++$0,pop(@$_).$s;;$_}($, =eval((join"\$_->[",qw)Just Another Perl Hacker)).q)$_->[1]]]])))=~s~((?<=.(?{ ++$*})))?_::~$*&&$"~egx,print""=>""=>'|perl -ln0e';s;s\;;_::AUTOLOAD$1;g;eval' - To unsubscribe from this list: send the line "unsubscribe linux-diald" in the body of a message to [EMAIL PROTECTED]
