From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; SunOS 5.8 sun4u) After updating to RH 7.1 I'm no longer able to dial out. It dials the number and then aborts with an e001b error. Reproducible: Always Steps to Reproduce: Upgrade to RH 7.1 and initiate a dialup Actual Results: Apr 17 20:07:49 mail kernel: ippp0: dialing 1 0207400099... Apr 17 20:07:56 mail kernel: isdn: line0,ch0 cause: E001B Apr 17 20:07:57 mail kernel: isdn_net: local hangup ippp0 Apr 17 20:07:57 mail kernel: ippp0: Chargesum is 0 Expected Results: Only the first line with an acknowledge that the dialup was successfull. After the initial upgrade I did not even get the hisax driver to allocate the IRQ for the card. After som messing about it appeared that if I changed the IRQ from 3 to 4 the driver loaded nicely. Is this intentionally? An oversight in isapnp? Should I report this separately? Before this everything was working correctly, also in my vanilla 2.4.2 kernel. I upgraded and ran the RH 2.4.2-2 kernel with the aforementioned result. I tried my old 2.4.2 kernel with exactly the same result. Hence my guess it's isdn4k-utils which is at fault. Since I don't have internet access I'm writing this at work. However I am downloading the sources now and will compile it when I get back home. Hopefully I will succede and be able to post and update on this. However, I thought I should mention this as it's clearly rather nasty, also since I'm not sure when I'll be able to come back (I'm on holidays right now).
OK! I have done the following: 1) Upgraded to the 2.4.3 kernel with the latest hisax patches and isdn4k-utils. No dice 2) 'Downgraded' to the 2.4.2 kernel (which worked before the upgrade). No dice. 3) Also recompilled and installed the isdn4k-utils-3.1-32.src.rpm. No dice. 4) Installed 7.1 from scratch. No dice. 5) Installed 7.0 from scratch. No dice! I have now a windows PC (argh) online from the same outlet. The errormessage E001B is explained (man isdn_cause) as: o E means error o 00 means "Message generated by user." o 1B means "Destination out of order" However, this is clearly not the case as I can dial out from the windows machine. I have also tried several ISPs. I have a TeleS16.3c ISA PnP card. I have used my ISDN setup (with only minor changes) since RH 6.0 and has since then upgraded to 6.2, 7.0 and now 7.1. None of these has been new installations. Since this also happens with 7.0 I'm not sure if this is a bug anymore, but I can't get it to work anyhow. Any suggestions?
I think it's perhaps a bug in ISDN configuration. In order to fix this problem I need the following files: /etc/isapnp.conf /etc/sysconfig/isdncard /etc/sysconfig/provider/* Note: if you need to reach an outside line, you should add any numbers to your prefix ( in germany mostly adds 0)
Created attachment 16686 [details] /etc/isapnp.conf
Created attachment 16687 [details] /etc/sysconfig/isdncard
Created attachment 16688 [details] /etc/sysconfig/provider/*
Sorry for the amount of mail this generated... I'm inclined to believe that this is also a configuration issue. However, I have reverted more or less to the way it is supposed to work from RH (I had my own scripts etc. previously). It is not necessary to add a prefix on the ISPs phone number in Norway (unless something has changed fundamentally from within the calling scripts/isdn4k-utils).
Sorry for the delay, but it appears that the upgrade to RH 7.1 somehow triggered a IRQ/IO conflict with the sound card. I have not yet been able to pinpoint the problem, and 'pnpdump -c' does not give a suggestion. However, I can get one of the going, but not yet at the same time. It's a HB Giga GA-686LX mainboard. The strange part is that the vanilla RH 7.0 installation had the same trouble, but not the RH 7.0 upgrade. Could this be a bug/feature in isapnptools which was not updated in the upgrade?
OK! I have something. In /etc/rc.d/rc.sysinit, if I change : #if [ -x /sbin/isapnp -a -f /etc/isapnp.conf -a ! -f /proc/isapnp ]; then to: if [ -x /sbin/isapnp -a -f /etc/isapnp.conf ]; then everything starts working again. Is this an ovesight, bug or intentional?
It's just a workaround to this problem. Of course it's intentional to ignore isapnp if /proc/isapnp exists with kernel-2.4.x. The bug is in internet-config, i will fix it later.
It's fixed in internet-config-0.41-1. You will find it on ftp://people.redhat.com/than