during boot /dev links are not created on Redhat Enterprise 7.2

Realport
, , , ,
1

PortServer TS 1/2/4
OS -> Redhat Enterprise 7.2
installed Realport Driver for Linux ver. 1.9-36, src.rpm version
rpmbuild --rebuild 40002086_X.src.rpm

rpm -iv dgrp-1.9-36.x86_64.rpm

Preparing packages…
dgrp-1.9-36.x86_64
Running Post Install script…
Added RealPort (dgrp) scripts to system startup
Checking to see if UDEV appears to be used on this system…
Yes, moving Digi RealPort UDEV rules to correct location

directly after installing the driver I could create a new node using the command
/usr/bin/dgrp/config/dgrp_cfg_node init -v -v -s 38400 -e never -m 666 r1 192.168.100.90 1

[root@ivnch dev]# ls -l ttyr*
lrwxrwxrwx 1 root root 13 Oct 16 22:13 ttyr100 -> tty_dgrp_r1_0

I could access the connected modem. Everything was OK.

Then I rebooted the Linux server and since then the /dev devices
are not created anymore.

It seems there is something broken with UDEV.

cat /etc/udev/rules.d/10-dgrp.rules

KERNEL==“tty_dgrp*”, PROGRAM=“/usr/bin/dgrp_udev %k”, SYMLINK+=“%c”, TAG=“systemd”
KERNEL==“cu_dgrp*”, PROGRAM=“/usr/bin/dgrp_udev %k”, SYMLINK+=“%c”, TAG=“systemd”
KERNEL==“pr_dgrp*”, PROGRAM=“/usr/bin/dgrp_udev %k”, SYMLINK+=“%c”, TAG=“systemd”

I uninstalled the dgrp rpm package and removed all settings.
Then reinstalled everything but did not manage to get the /dev devices
created again.

Is the Realport driver verified to work on Redhat Enterprise 7.2?

Regards
Chris

2

The RealPort driver appears to work fine in EL 7.2. You might want to try activating UDEV debugging to determine why the devices are not being created/linked:

udevadm monitor

It may be worth noting that the -m flag will not be valid in this version of Linux since UDEV controls the device permissions when created. A change to the 10-dgrp.ruls file will accommodate device permissions. Examples can be found here:

http://knowledge.digi.com/articles/Knowledge_Base_Article/HOW-TO-Preserve-device-permissions-settings-with-RealPort-in-Linux

Actually, make sure you are booting into the same kernel version the driver was installed under. Also, make sure the daemon is actually starting. This can be checked using dpa.dgrp.

3

Not very helpful …

[root@ivnch ~]# /usr/bin/dgrp/config/dgrp_cfg_node init -v -v -s 38400 -e never -m 666 r1 192.168.100.90 1
/usr/bin/dgrp/config/dgrp_cfg_node: init requested for node r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a loaded module
/usr/bin/dgrp/config/dgrp_cfg_node: testing for r1 in /proc
/usr/bin/dgrp/config/dgrp_cfg_node: double checking the addition of r1
/usr/bin/dgrp/config/dgrp_cfg_node: making the special devices for r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a daemon for r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a daemon for r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a loaded module
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a r1 in /proc
/usr/bin/dgrp/config/dgrp_cfg_node: attempting to start a daemon for r1
/usr/bin/dgrp/config/dgrp_cfg_node: operation completed (init node r1)
[root@ivnch ~]# ls -l /dev/ttyr*
ls: cannot access /dev/ttyr*: No such file or directory

[root@ivnch ~]# udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[48129.789608] add /devices/virtual/digi_realport/nodes/r1 (digi_realport)
UDEV [48129.790645] add /devices/virtual/digi_realport/nodes/r1 (digi_realport)
^C[root@ivnch ~]#

4

I installed a new Centos 6 VM and have the same problem. No /dev devices are created.

What am I doing wrong???

[root@faxserver dev]# uname -a
Linux faxserver 2.6.32-642.6.1.el6.x86_64 #1 SMP Wed Oct 5 00:36:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[root@faxserver digi]# yum install rpm-build
[root@faxserver digi]# yum install kernel-devel
[root@faxserver digi]# yum install openssl-devel ncurses-devel
[root@faxserver digi]# yum groupinstall “Development Tools”
[root@faxserver install]# cd /home/
[root@faxserver home]# mkdir install
[root@faxserver home]# cd install/
[root@faxserver install]# mkdir digi
[root@faxserver install]# cd digi
[root@faxserver digi]# wget http://ftp1.digi.com/support/driver/40002086_X.src.rpm
[root@faxserver digi]# rpmbuild --rebuild 40002086_X.src.rpm
[root@faxserver digi]# cd /root/rpmbuild/RPMS/x86_64/
[root@faxserver x86_64]# ls -l
total 532
-rw-r–r–. 1 root root 467368 Oct 19 13:01 dgrp-1.9-36.x86_64.rpm
-rw-r–r–. 1 root root 70560 Oct 19 13:01 dgrp-debuginfo-1.9-36.x86_64.rpm
[root@faxserver x86_64]# rpm -iv dgrp-1.9-36.x86_64.rpm
Preparing packages for installation…
dgrp-1.9-36
Running Post Install script…
Added RealPort (dgrp) scripts to system startup
Checking to see if UDEV appears to be used on this system…
Yes, moving Digi RealPort UDEV rules to correct location

[root@faxserver dev]# ls -l /dev/ttyr*
ls: cannot access /dev/ttyr*: No such file or directory
[root@faxserver dev]#
[root@faxserver dev]# /usr/bin/dgrp/config/dgrp_cfg_node init -v -v -s 38400 -e never -m 666 r1 192.168.100.90 1
/usr/bin/dgrp/config/dgrp_cfg_node: init requested for node r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a loaded module
/usr/bin/dgrp/config/dgrp_cfg_node: testing for r1 in /proc
/usr/bin/dgrp/config/dgrp_cfg_node: double checking the addition of r1
/usr/bin/dgrp/config/dgrp_cfg_node: making the special devices for r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a daemon for r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a daemon for r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a loaded module
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a r1 in /proc
/usr/bin/dgrp/config/dgrp_cfg_node: attempting to start a daemon for r1
/usr/bin/dgrp/config/dgrp_cfg_node: operation completed (init node r1)
[root@faxserver dev]#
[root@faxserver dev]# ls -l /dev/ttyr*
ls: cannot access /dev/ttyr*: No such file or directory
[root@faxserver dev]#
[root@faxserver dev]# /usr/bin/dgrp/config/dgrp_cfg_node -v -v uninit r1 192.168.100.90 1
/usr/bin/dgrp/config/dgrp_cfg_node: uninit requested for node r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing if any r1 nodes are being accessed
Cannot stat /dev/ttyr1[0-9][0-9]: No such file or directory
Cannot stat /dev/ttyr1[0-9][0-9]: No such file or directory
Cannot stat /dev/prr1[0-9][0-9]: No such file or directory
Cannot stat /dev/prr1[0-9][0-9]: No such file or directory
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a daemon for r1
/usr/bin/dgrp/config/dgrp_cfg_node: attempting to kill r1’s daemon (pid 3883)
/usr/bin/dgrp/config/dgrp_cfg_node: testing for r1 in /proc
/usr/bin/dgrp/config/dgrp_cfg_node: testing if any r1 nodes are being accessed
Cannot stat /dev/ttyr1[0-9][0-9]: No such file or directory
Cannot stat /dev/ttyr1[0-9][0-9]: No such file or directory
Cannot stat /dev/prr1[0-9][0-9]: No such file or directory
Cannot stat /dev/prr1[0-9][0-9]: No such file or directory
/usr/bin/dgrp/config/dgrp_cfg_node: attempting to unregister r1 in /proc
/usr/bin/dgrp/config/dgrp_cfg_node: attempting to remove empty backing store
/usr/bin/dgrp/config/dgrp_cfg_node: attempting to remove special devices for r1
/usr/bin/dgrp/config/dgrp_cfg_node: operation completed (uninit node r1)

5

i’ve rebooted and executed
/usr/bin/dgrp/config/dgrp_cfg_node init -v -v -s 38400 -e never -m 666 r1 192.168.100.90 1
/usr/bin/dgrp/config/dgrp_cfg_node init -v -v -s 38400 -e never -m 666 r2 192.168.100.91 1

now the dev links show up.

configured hylafax
configured the modems
then I rebooted again…

and now only one dev link is available

[root@faxserver ~]# ls -l /dev/ttyr*
lrwxrwxrwx 1 root root 13 Oct 21 09:58 /dev/ttyr100 -> tty_dgrp_r1_0

did
/usr/bin/dgrp/config/dgrp_cfg_node -v -v uninit r2 192.168.100.91 1

and then
/usr/bin/dgrp/config/dgrp_cfg_node init -v -v -s 38400 -e never -m 666 r2 192.168.100.91 1

but no /dev/ttyr200 is available

so I removed all links
/usr/bin/dgrp/config/dgrp_cfg_node -v -v uninit r1 192.168.100.90 1
/usr/bin/dgrp/config/dgrp_cfg_node -v -v uninit r2 192.168.100.91 1

rebooted the server

then

[root@faxserver rules.d]# /usr/bin/dgrp/config/dgrp_cfg_node init -v -v -s 38400 -e never -m 666 r1 192.168.100.90 1
/usr/bin/dgrp/config/dgrp_cfg_node: init requested for node r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a loaded module
/usr/bin/dgrp/config/dgrp_cfg_node: double checking the load
/usr/bin/dgrp/config/dgrp_cfg_node: testing for r1 in /proc
/usr/bin/dgrp/config/dgrp_cfg_node: double checking the addition of r1
/usr/bin/dgrp/config/dgrp_cfg_node: making the special devices for r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a daemon for r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a daemon for r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a loaded module
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a r1 in /proc
/usr/bin/dgrp/config/dgrp_cfg_node: attempting to start a daemon for r1
/usr/bin/dgrp/config/dgrp_cfg_node: operation completed (init node r1)
[root@faxserver rules.d]# ls -l /dev/ttyr*
lrwxrwxrwx 1 root root 13 Oct 21 10:12 /dev/ttyr100 -> tty_dgrp_r1_0
[root@faxserver rules.d]# /usr/bin/dgrp/config/dgrp_cfg_node init -v -v -s 38400 -e never -m 666 r2 192.168.100.91 1
/usr/bin/dgrp/config/dgrp_cfg_node: init requested for node r2
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a loaded module
/usr/bin/dgrp/config/dgrp_cfg_node: testing for r2 in /proc
/usr/bin/dgrp/config/dgrp_cfg_node: double checking the addition of r2
/usr/bin/dgrp/config/dgrp_cfg_node: making the special devices for r2
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a daemon for r2
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a daemon for r2
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a loaded module
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a r2 in /proc
/usr/bin/dgrp/config/dgrp_cfg_node: attempting to start a daemon for r2
/usr/bin/dgrp/config/dgrp_cfg_node: operation completed (init node r2)
[root@faxserver rules.d]# ls -l /dev/ttyr*
lrwxrwxrwx 1 root root 13 Oct 21 10:12 /dev/ttyr100 -> tty_dgrp_r1_0

I can create ttyr100 but not ttyr200

this is really great!!

so did another test
/usr/bin/dgrp/config/dgrp_cfg_node init -v -v -s 38400 -e never -m 666 r1 192.168.100.90 1
works and creates /dev/ttyr100

removed it and tried
/usr/bin/dgrp/config/dgrp_cfg_node init -v -v -s 38400 -e never -m 666 r1 192.168.100.91 1
r1 device but IP address of other realport device
now the /dev link is not created

so I tried to access the configuration webpage on 192.168.100.91.
I can ping 192.168.100.91 but the webserver on the device does not respond.
So the realport device has locked up and this prevents the /dev links to
be created…

6

Make sure you are able to reach the Digi device on the network. The devices will not be created if the device is not reachable.

7

Ensure the Digi device is actively reachable on the network (a quick ping can confirm this). If not, then the devices will not be created as the drive daemon queries the device before creating the nodes.

Also, make sure there are no firewalls blocking the 771 port. This can be easily tested from Linux using telnet:

telnet (IP_of_Digi_unit) 771

If errors are seen, it is a good indication of a firewall blocking the socket.

8

it is no firewall issue.

the Digi device has locked up. I cannot access it with my browser
but it still responds to ping.
So a ping test is not sufficient :slight_smile:

I need to wait until it is resetted. I am doing the installation from a remote site.

it would be nice if the driver daemon would log
a message to syslog if it cannot reach a node
or is not happy with the state of the node.

now I learned that if the /dev link is missing
or not created then I need to check the connection
to the Digi device.

If I look at the following message output, then it is not helpful
in diagnosing the problem.
Everything looks okay here but no /dev links are created.
No error message in the shell. No error message in syslog

[root@faxserver dev]# /usr/bin/dgrp/config/dgrp_cfg_node init -v -v -s 38400 -e never -m 666 r1 192.168.100.90 1
/usr/bin/dgrp/config/dgrp_cfg_node: init requested for node r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a loaded module
/usr/bin/dgrp/config/dgrp_cfg_node: testing for r1 in /proc
/usr/bin/dgrp/config/dgrp_cfg_node: double checking the addition of r1
/usr/bin/dgrp/config/dgrp_cfg_node: making the special devices for r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a daemon for r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a daemon for r1
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a loaded module
/usr/bin/dgrp/config/dgrp_cfg_node: testing for a r1 in /proc
/usr/bin/dgrp/config/dgrp_cfg_node: attempting to start a daemon for r1
/usr/bin/dgrp/config/dgrp_cfg_node: operation completed (init node r1)

9

Are the Digi devices running over dial up PPP? 38400 baud is a small amount of bandwidth considering these typically run at 10/100 Mbps. What sort of ping responses are seen? Sounds like a possible sporadic network problem.

10

We have two fax modems connected to two PortServer TS 1 devices. I think 38400 baud to communicate with the fax modems is fast enough.
ping was flawless. a steady few miliseconds and no loss.

11

The speed of an attached fax modem is not the same as the speed of the daemon connection to from the RealPort host to the Digi unit. These should match LAN network speeds (i.e. 10/100 Mbps). If the Digi unit is remote from the RealPort Linux host, then you would put in a speed closest to your dedicated LAN speed (i.e. 57600 for a leased line speed).

The -m flag is no longer applicable in modern Linux versions. If the Digi unit is local to the Linux host, the following syntax should be used:

dgrp_cfg_node init r1 192.168.100.90 1

Device permissions are set by UDEV:

http://knowledge.digi.com/articles/Knowledge_Base_Article/HOW-TO-Preserve-device-permissions-settings-with-RealPort-in-Linux

Serial baud rates and other port settings are set using ditty-rp:

http://knowledge.digi.com/articles/Knowledge_Base_Article/Setting-TTY-Options

Keeping the port settings over reboots:

http://knowledge.digi.com/articles/Knowledge_Base_Article/How-do-I-configure-my-ditty-rp-port-settings-to-stay-after-rebooting-when-using-RealPort-in-Linux

As for why you cannot connect to the web interface, I cannot explain it without more details. Is the unit local to the PC you are browsing from? Is it possible you were experiencing DNS issues impacting many on Friday? How many servers/TCP connections are being estabished on the unit? Is the unit accessible over the internet?