Bug 114786 - (TBa7981396) Control.py:56:load:NameError: global name 'getNickName' is not defined
Control.py:56:load:NameError: global name 'getNickName' is not defined
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: redhat-config-network (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-02 16:27 EST by Uwe Beck
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-12 12:21:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Traceback "traceback-ifup.txt" (741 bytes, text/plain)
2004-02-02 16:29 EST, Uwe Beck
no flags Details
Traceback "traceback-start.txt" (1.06 KB, text/plain)
2004-02-02 16:30 EST, Uwe Beck
no flags Details

  None (edit)
Description Uwe Beck 2004-02-02 16:27:59 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030922

Description of problem:
If you configure ISDN with redhat-config-network there are some
tracebacks and other mistaces.

- start redhat-config-network
- create a isdn connection with name "brickxmp"
- save the new connection
- press activate

does not work -> message on window with isdn4k-utils-3.1-76 and LANG=de_DE
------------------------------------------------------------------
brickxmp; /usr/sbin/userisdnctl dial ippp0: Datei oder Verzeichnis
nicht gefunden
------------------------------------------------------------------

- ifup brickxmp
ISDN-Module laden                                          [  OK  ]

-> Traceback see "traceback-ifup.txt"

- restart redhat-config-network again

-> Traceback "traceback-start.txt"

- ifdown brickxmp

Now you can start redhat-config-network.

-> if ippp0 is active, you are not able to use "redhat-config-network"
and also "redhat-control-network".



Version-Release number of selected component (if applicable):
isdn4k-utils-3.1-76

How reproducible:
Always

Steps to Reproduce:
1.configure ISDN
2.funktion activate - not work
3.use "ifup <interface>" -> Traceback "traceback-ifup.txt"
4.if ippp0 is up start redhat-config-network -> Traceback
"traceback-start.txt"

    

Actual Results:  can not use redhat-config-network and
redhat-control-network if ippp0 is up

Expected Results:  redhat-config-network and redhat-control-network
works correct if ippp0 is up

Additional info:
Comment 1 Uwe Beck 2004-02-02 16:29:37 EST
Created attachment 97416 [details]
Traceback "traceback-ifup.txt"
Comment 2 Uwe Beck 2004-02-02 16:30:28 EST
Created attachment 97417 [details]
Traceback "traceback-start.txt"
Comment 3 Harald Hoyer 2004-02-18 09:16:18 EST
Could you please try:
ftp://people.redhat.com/harald/redhat-config-network/RHEL3/1.2.60/
Comment 4 Uwe Beck 2004-02-18 14:25:30 EST
Result of test redhat-config-network-1.2.60-1

The program does not longer crash with traceback at start, if an
ISDN-interface is activ or you want activate it.

It is possible to configure ISDN. You can activate it but it does not
goes in the o.k status. The interface ippp0 comes up. But there is an
message in the windows:

usage: userisdnctl <interface-config> <dial|hangup|status|report

I see this message with providername "brickxmp" and also "ippp0".

It is possible to use /usr/bin/redhat-control-network.

I think the fix for the traceback is o.k.. The other mistaces are
listed in Bug #114876.
Comment 5 Uwe Beck 2004-02-18 14:37:18 EST
Sorry, the other mistaces are listed in Bug #114867.
Comment 6 Harald Hoyer 2004-02-19 04:09:23 EST
I tested this with RHEL 3 and it worked with the RHEL 3 userisdnctl.
which version of isdn4k-utils do you have installed? The RHEL 3 original?
Comment 7 Uwe Beck 2004-02-19 05:18:31 EST
You are right. The isdn4k-utils-3.2-8.p1 with I have installed to find
the reason for the dynamic channel bundling problem is not ready for
RHEL 3 and Than was tell me that.

With the original isdn4k-utils you can activate the ISDN with dial if
you have configure it. All time later you are start
redhat-config-network and the ippp0 is already up I see that the ISDN
status is "deacativ". It is not possible to deactivate and if you use
the activate buttom the messange is "ippp0: Resource temporarily
unavailable".

The message "Dialing of ippp0 triggered" I see only one time if I
configure ISDN new.
The same problem I see in redhat-control-network.
I think, the problem is, that the status of interface will not refresh
 . Refresh the status was the problem for traceback.


This mistace is not relevant for me because I use Dial on Demand.


Comment 8 Harald Hoyer 2004-02-19 05:46:57 EST
the status is refreshed by:
# isdnctrl status ippp0
return code 0    -> activated
return code != 0 -> deactivated

so:
# isdnctrl status ippp0 && echo Activated || echo Not Activated
Comment 9 Harald Hoyer 2004-02-19 05:47:53 EST
btw, a manual:

# ifdown ippp0
# ifup ippp0

solved the "Resource temporarily unavailable" problem here...
Comment 10 Uwe Beck 2004-02-19 06:31:11 EST
This is a Dial on Demand problem I found out now.

# ifup ippp0
# isdnctrl status ippp0 && echo "Activated" || echo "Not Activated"
ippp0 is not connected
Not Activated
# ifdown ippp0
# isdnctrl status ippp0 && echo "Activated" || echo "Not Activated"
ippp0: No such device
Not Activated
# ifup ippp0
# ping 172.16.39.81
# isdnctrl status ippp0 && echo "Activated" || echo "Not Activated"
ippp0 connected from 7119035642
Activated

Now I use a configuration without Dial on Demand. The "Activate" works
correct. The connection close after HUPTIMEOUT=300. I am not able to
cancel the connection with "Deactivate" before hanguptimeout it hangs.

I use a callback connection. Normaly there is Dail on Demand relevant
for me.
In the Dial on Demand mode the "Activate" and "Deactivat" functions
are not needed.

If the "Activate" and "Deaktivate" works correct in your own tests, I
think, then the tool is o.k..

I see it again, the problem with default route, if the ifcfg-xxx is
not named ifcfg-ippp0. ifcfg-providername does not work correct, see
other reports.
Comment 11 Steffen Mann 2004-03-02 04:53:41 EST
This bug is apparently fixed.
Comment 12 John Flanagan 2004-05-12 12:21:00 EDT
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-076.html

Note You need to log in before you can comment on or make changes to this bug.