networkmanager drops connections

2005-05-25 Thread Chris Jones

Hi,

I'm using NetworkManager-0.3.4-1.1.0.fc3 on an FC3 laptop with b44 and 
ipw2100 network devices, and its worked more or less OK for a while. 
However, I have just moved to a new network, and here I an having 
problems with the connection being dropped after periods on the order of 
an hour. I have the same problems with both the wired and wireless 
connections.


I've pasted below the messages for system logs, which show what was 
happening. I'm not sure of this is a problem with NetworkManager, DHCP 
or something else. The network I am using is very well developed so I 
doubt the problems are on that side. Also, if I connect without using 
Networkmanager I don't have such problems.


Any suggestions ?

cheers Chris


May 24 17:57:23 localhost NetworkManager: DHCP: Starting request loop, 
overall

start_time = {1116953843s, 464466us}
May 24 17:57:23 localhost NetworkManager: DHCP: Request sent, waiting for
reply...
May 24 17:57:23 localhost NetworkManager: DHCP: Got some data of length 332.
May 24 17:57:23 localhost NetworkManager: DHCP: Reply message's source port
(68) was not the DHCP server port number (67), won't use it.
May 24 17:57:23 localhost NetworkManager: DHCP: Got some data of length 334.
May 24 17:57:23 localhost NetworkManager: Server replied with 11 DHCP 
options:

May 24 17:57:23 localhost NetworkManager:   Subnet Mask (1):
255.255.0.0
May 24 17:57:23 localhost NetworkManager:   Router (3): 128.141.1.1
May 24 17:57:23 localhost NetworkManager:   Domain Server (6):  
137.138.16.5
May 24 17:57:23 localhost NetworkManager:   Domain Server (6):  
137.138.17.5
May 24 17:57:23 localhost NetworkManager:   Hostname (12):  pclhcbcrj01
May 24 17:57:23 localhost NetworkManager:   Domain Name (15):   
cern.ch
May 24 17:57:23 localhost NetworkManager:   Broadcast Address (28): 
128.141.255.255
May 24 17:57:23 localhost NetworkManager:   Address Time (51):  675
May 24 17:57:23 localhost NetworkManager:   DHCP Msg Type (53): 5
May 24 17:57:23 localhost NetworkManager: 	DHCP Server Id (54): 
137.138.16.6

May 24 17:57:23 localhost NetworkManager:   Renewal Time (58):  0
May 24 17:57:23 localhost NetworkManager:   Rebinding Time (59):0
May 24 17:57:23 localhost NetworkManager:   Your IP Address:
128.141.47.156
May 24 17:57:23 localhost NetworkManager: 	DHCP Server Address: 
137.138.16.6

(HW=0A:00:30:B0:22:81)
May 24 17:57:23 localhost NetworkManager:   Gateway Address:
172.21.34.129
May 24 17:57:23 localhost NetworkManager: DHCP_ACK received from
(137.138.16.6)
May 24 18:03:00 localhost NetworkManager: Sending DHCP_REQUEST for
128.141.47.156 to 137.138.16.6
May 24 18:03:00 localhost NetworkManager: DHCP: Starting request loop, 
overall

start_time = {1116954180s, 525213us}
May 24 18:03:00 localhost NetworkManager: DHCP: Request sent, waiting for
reply...
May 24 18:03:06 localhost NetworkManager: DHCP: Request sent, waiting for
reply...
May 24 18:03:06 localhost NetworkManager: DHCP: Got some data of length 332.
May 24 18:03:06 localhost NetworkManager: DHCP: Reply message's source port
(68) was not the DHCP server port number (67), won't use it.
May 24 18:03:06 localhost NetworkManager: DHCP: Got some data of length 332.
May 24 18:03:06 localhost NetworkManager: DHCP: Reply message's source port
(68) was not the DHCP server port number (67), won't use it.
May 24 18:03:17 localhost NetworkManager: DHCP: Request sent, waiting for
reply...
May 24 18:03:17 localhost NetworkManager: DHCP: Got some data of length 332.
May 24 18:03:17 localhost NetworkManager: DHCP: Reply message's source port
(68) was not the DHCP server port number (67), won't use it.
May 24 18:03:17 localhost NetworkManager: DHCP: Got some data of length 332.
May 24 18:03:17 localhost NetworkManager: DHCP: Reply message's source port
(68) was not the DHCP server port number (67), won't use it.
May 24 18:07:13 localhost NetworkManager: Broadcasting DHCP_REQUEST for
128.141.47.156
May 24 18:07:13 localhost NetworkManager: DHCP: Starting request loop, 
overall

start_time = {1116954433s, 525745us}
May 24 18:07:13 localhost NetworkManager: DHCP: Request sent, waiting for
reply...
May 24 18:07:13 localhost NetworkManager: DHCP: Got some data of length 328.
May 24 18:07:13 localhost NetworkManager: Server replied with 12 DHCP 
options:

May 24 18:07:13 localhost NetworkManager:   Subnet Mask (1):
255.255.0.0
May 24 18:07:13 localhost NetworkManager:   Router (3): 128.141.1.1
May 24 18:07:13 localhost NetworkManager:   Domain Server (6):  
137.138.16.5
May 24 18:07:13 localhost NetworkManager:   Domain Server (6):  
137.138.17.5
May 24 18:07:13 localhost NetworkManager:   Hostname (12):  pclhcbcrj01
May 24 18:07:13 localhost NetworkManager:   Domain Name (15):   
cern.ch
May 24 18:07:13 localhost NetworkManager:   Broadcast Address (28): 
128.141.255.255
May 24 18:07:13 localhost 

NM scanning policy

2005-05-25 Thread Bill Moss

Proposed change to NM scanning policy.

Context menu scan item: three states -- On, Auto, Off

On: NM's current policy which is to always scan but adjust the time 
between scans.


Auto (default): When a wired connection has been established, stop 
scanning (also consider powering down radio). As soon as a wired 
connection is not available, begin scanning. After a wireless connection 
has been made, stop scanning but start again if the signal strength 
falls below a threshold.


Off: Do not scan or stop all wireless devices and power down radios.

Justification: Scanning powers up the radio.  When operationg on battery 
and connected by wire, scanning wastes power. Scans that take a long 
time can be disruptive.


--
Bill Moss
Professor, Mathematical Sciences
Clemson University

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NM scanning policy

2005-05-25 Thread Bastien Nocera
On Wed, 2005-05-25 at 10:19 -0400, Bill Moss wrote:
 Proposed change to NM scanning policy.
 
 Context menu scan item: three states -- On, Auto, Off
 
 On: NM's current policy which is to always scan but adjust the time 
 between scans.
 
 Auto (default): When a wired connection has been established, stop 
 scanning (also consider powering down radio). As soon as a wired 
 connection is not available, begin scanning. After a wireless connection 
 has been made, stop scanning but start again if the signal strength 
 falls below a threshold.
 
 Off: Do not scan or stop all wireless devices and power down radios.
 
 Justification: Scanning powers up the radio.  When operationg on battery 
 and connected by wire, scanning wastes power. Scans that take a long 
 time can be disruptive.

This sounds fair, although I would roll the first 2 ones into one
option, with NetworkManager using HAL to check whether the machine is
running on mains or battery power.
Would obviously need some UI work to allow the user to know that no
wireless networks are being scanned.

Cheers

---
Bastien Nocera [EMAIL PROTECTED] 


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Cisco VPN config files converter

2005-05-25 Thread Bill Moss

A couple of points about decoding encrypted Cisco Group passwords (Secrets).

1. Anyone with an early version of the Cisco VPN client (4.0.3.B) can do 
the conversion without using the web site. All the web site does is 
automate the process.


2. Cisco has announced they will close the security hole but not when.

3. Other vpnc front ends like kvpnc have a similar import utility.

4. What liability is involved in exploiting this security hole? The web 
site you reference has a note that the Secret should be obtained from 
your network admin. Not all network admins may be happy about the decoding.


5. Whatever you do make sure the user is informed if the the import 
utility fails to find the Secret for whatever reason.


--
Bill Moss
Professor, Mathematical Sciences
Clemson University

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list