Bug 134525

*** Bug 133889 has been marked as a duplicate of this bug. ***

ippp* devices are missing.

ll /dev/ippp*

crw-------  1 root root 45, 128 Feb 23  2004 /dev/ippp0
...

workaround: create the devices in the isdn initscript with MAKEDEV

Could you please provide the exact command line for this MAKEDEV?

afolger

The RHEL4-BETA1 kernel rpms (kernel-2.6.8-1.528.2.10) does not provide
isdn modules. If you configure ISDN in the kernel and compile an own
kernel, the isdn modules can only load with modprobe. "service isdn
start" load the isdn module, does not found the /dev/isdn* and unload
the isdn modules. The reason for this is that /sys/class/*/dev do not
contain isdn and udev can not create the relevant device files in
/dev. If you create the device files with MAKEDEV you can use isdn
until you reboot the system new.

For RHEL4 we need a correct isdn implementation.

Permanent workaround:
# /sbin/MAKEDEV -d /etc/udev/devices isdn

i have added a workaround in isdn4k-utils-3.2-18.p1.1, which creates
the missing isdn/ippp devices.

I tried Harald Hoyer's workaround and it didn't work. So I issued the
same command with /dev/ as the target directory, and things work,
however, I fear this will become useless by the next reboot, until I
reissue the command. So, I assume I must be missing a little part of
the advise HH must have assumed I knew.

As far as the updated isdn4k-utils-3.2-18.p1.1 of Ngo Than, I will be
very grateful to try it, but have not found it on the mirror I
checked. Could you post a URL?

NOTE: I am using an AMD64 (Fedora for x86_64).

Is the comment #7 workaround SELinux safe?

Warren, the isdn initscript uses /sbin/MAKEDEV ... so, I assume, yes.

ISDN got inadvertently omitted from earlier kernels, but should be
back in now.

Does this work now for people with currenet devel packages?

[afolger@localhost ~]$ rpm -qa |grep isdn
isdn4k-utils-3.2-18.p1.1
[afolger@localhost ~]$ rpm -q kernel
kernel-2.6.8-1.603
[afolger@localhost ~]$

With the above, isdn works fine. The only problem is that the GUI
doesn't recognize that the interface is up and running (status remains
inactive).

AF

i think it's better if we add the workaround in initscript instead
isdn4k-utils. it will fix this problem

it looks like you did not start start isdn cript (/etc/init.d/isdn
start) before using GUI. Could you please try to start isdn service
before. Does the problem still appear?

Than,

look for http://people.redhat.com/harald/udev.html
 -> "But I really want my device node!"

isdn4k-utils can create the devices during the rpm installation as post.

/sbin/MAKEDEV -d /etc/udev/devices isdn ippp

In RHEL4_BETA1 there is only the udev-030-26 version. Do not work with
this version. A newer version of udev is not available for RHEL4_BETA?
What do you think about that?

Uwe, the current isdn4k-utils in rawhide should work with udev-030-26.

Yes, the workarount in isdn4k-utils-3.2-18.p1.1 works with udev-030-26
at this time.

Replying to #15. I assume you were reacting to my #13 (without 
threading, this system is reaching its limit on bugs such as ours). 
 
I am using runlevel 5, so that I don't have a chance to run 
startisdn. In fact, I discovered that the GUI (System->network device 
control) starts ISDN services, as before that I cannot start ISDN 
using /sbin/isdnctrl dial ippp0 from the command line. 
 
So, indeed, I am not running startisdn before the GUI. But neither 
will most users. This is an issue that deserves fixing. 

Whatever runlevel you're using, the isdn service *should* be running
in it if you need isdn.

The isdn service always starts at boot as default. it's off in your
case. You have to enable isdn service again, (chkconfig isdn on).

it looks like someone has disabled ISDN service on your machine?

Well, it is off by default. The computer tries to start isdn services 
at boot, but invariably fails. Any ideas? 

if it's off by default in your case, please enable it again with

  chkconfig isdn on

it should work by next reboot. I have verified it on my local machine.

this has been in MODIFIED state for over a year, which leads me to believe its
fixed.  Can you confirm ?

Yes, it works.