Red Hat Bugzilla – Bug 37462
Refuses to dial after update from RH 7.0 to 7.1
Last modified: 2007-04-18 12:32:49 EDT
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.
Steps to Reproduce:
Upgrade to RH 7.1 and initiate a dialup
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
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
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:
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]
Created attachment 16687 [details]
Created attachment 16688 [details]
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
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
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