Re: can't enter wpa password

2010-07-01 Thread Bin Li
On Fri, Jul 2, 2010 at 12:54 AM, carpetnailz
 wrote:
> I'm using my Linux box (OpenSuse 11.2) with a Sprint MiFi box. In the past
> it has worked fine but yesterday afternoon for some reason is cut me off and
> I haven't been able to get back on. All the other boxes work (using that
> other OS from Washington).
>
> When I try to log on it will only give me the option to enter a WEP code,
> not a WPA. With some jiggling--turning radio off and on, disabling wireless
> and reenabling it, deleting the connection and trying to recreate it, even
> rebooting, I sometimes will get a dialog box that calls for the WPA
> password. But then the "Apply" button is greyed out, so NetworkManager seems
> to be refusing to do anything with my WPA password even when it offers to
> let me enter it.
So how about delete the connection in 'wireless' tab of 'Network
Connections' Dialog, then try to connect the wireless again.

> Help!  I need to be able to work.
>
> Thanks.
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: vpnc works from command line but not from Network Manager.

2010-07-01 Thread Bin Li
On Fri, Jul 2, 2010 at 6:15 AM, Maffitt, David  wrote:
> Using NetworkManager Applet 0.8.0.997 on fedora 13 with vpnc 0.5.3
> vpnc works (I can ping machines on the private network) if I sudo from the 
> command line and enter config info at prompts.
> Running from the applet appears to connect (I get the banner message in 
> pop-up window indicating I've connected), but I cannot ping on the private 
> network). running 'ps ax | grep vpnc' returns
> /usr/libexec/nm-vpnc-service
> /usr/sbin/vpnc --non-inter --no-detach -
>
> any ideas? debugging tips?

* killall -TERM nm-vpnc-service
* in a root terminal, run

VPNC_DEBUG=1 /usr/libexec/nm-vpnc-service

* start your VPN connection
* reproduce the problem
* send the nm-vpnc-service output to the developers

> The material in this message is private and may contain Protected Healthcare 
> Information (PHI).  If you are not the intended recipient, be advised that 
> any unauthorized use, disclosure, copying or the taking of any action in 
> reliance on the contents of this information is strictly prohibited.  If you 
> have received this email in error, please immediately notify the sender via 
> telephone or return mail.
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: ['N-M is not allowed to own the service "org.freedesktop.NetworkManager"']

2010-07-01 Thread ddreamer



 

From: Daniel Gnoutcheff 
To: networkmanager-list gnome org
Subject: Re: ['N-M is not allowed to own the service
"org.freedesktop.NetworkManager"']
Date: Wed, 16 Jun 2010 13:56:06 -0400

  
 
>On 06/16/2010 01:01 PM, ddreamer ms93 url com tw wrote:

>> Hi, Dear:

>> 

>> I am using Ubuntu 10.04 with regular update. There is a red exclamation

>> mark at the right lower corner of the nm-applet icon. Of course, there

>> was no signal level. Clicking it results in the message of

>> "NetworkManager is not running".

>> 

>> Looking up daemon.log, I found the following message:

>> NetworkManager:   nm_dbus_manager_start_service(): Could not

>> acquire the NetworkManager service.#012  Error: 'Connection ":1.216" is

>> not allowed to own the service "org.freedesktop.NetworkManager" due to

>> security policies in the configuration file'

>> NetworkManager:   main(): Failed to start the dbus service.

>

>Yep, that certainly would cause problems, and it's not altogether

>surprising that this would happen. The DBus system daemon has a very

>strong security policy, and daemons like NetworkManager need to setup

>specific security exceptions in order to work. Normally, this is

>something that distributions take care of, but here it seems to have

>broken somehow.

>

>More specifcally, NetworkManager needs to be able to claim the bus name

>"org.freedesktop.NetworkManager" on the DBus system bus. By default, no

>application is allowed to claim any bus names, so we need to configure

>DBus to allow N-M to claim that name.

>

>On Ubuntu, the file

>  /etc/dbus-1/system.d/NetworkManager.conf

>is supposed to take care of that. What does that file contain on your

>system?



Sorry for replying late. Somehow, I didn't receive the messages. I found

messages following my original one only after I viewed the archive by topic.

I have replaced three "deny" by "allow", which were marked at the end of the

line as "#deny". Supposedly, strings following "#" will be ignored as
remark.

Here is the file content of NetworkManager.conf:



http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>





























































































#deny

#deny



#deny











512










--
http://myhome.url.com.tw
進駐智邦社區網, 敦親睦鄰變的更輕鬆有效___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


NM ignoring interfaces

2010-07-01 Thread Mohammed Arafat Kamaal
Hi,

I am trying get NM working on a embedded linux platform. The ethernet
controller is built on SoC(Its not a separate device). The chip vendor
provides the drivers as part of the Board support package.

When NM is started it just ignores the interfaces, and doesn't do any more
operations. From the messages it appears to be a driver issue. Any
patches/workarounds for this issue?

When I Start NM I get the following message:

NetworkManager:   starting...
NetworkManager:   Trying to start the modem-manager...
NetworkManager:SCPlugin-Ifupdown: init!
NetworkManager:SCPlugin-Ifupdown: update_system_hostname
NetworkManager:SCPluginIfupdown: management mode: managed
NetworkManager:SCPlugin-Ifupdown: devices added (path:
/sys/devices/virtual/net/eth0, iface: eth0)
NetworkManager:SCPlugin-Ifupdown: device added (path:
/sys/devices/virtual/net/eth0, iface: eth0): no ifupdown configuration
found.
NetworkManager:SCPlugin-Ifupdown: devices added (path:
/sys/devices/virtual/net/eth1, iface: eth1)
NetworkManager:SCPlugin-Ifupdown: device added (path:
/sys/devices/virtual/net/eth1, iface: eth1): no ifupdown configuration
found.
NetworkManager:SCPlugin-Ifupdown: devices added (path:
/sys/devices/virtual/net/lo, iface: lo)
NetworkManager:SCPlugin-Ifupdown: device added (path:
/sys/devices/virtual/net/lo, iface: lo): no ifupdown configuration found.
NetworkManager:SCPlugin-Ifupdown: end _init.
NetworkManager: Loaded plugin ifupdown: (C) 2008 Canonical Ltd.  To report
bugs please use the NetworkManager mailing list.
NetworkManager: Loaded plugin keyfile: (c) 2007 - 2008 Red Hat, Inc.  To
report bugs please use the NetworkManager mailing list.
NetworkManager:   WiFi enabled by radio killswitch; enabled by state
file
NetworkManager:   WWAN enabled by radio killswitch; enabled by state
file
NetworkManager:SCPlugin-Ifupdown: (5130848) ... get_connections.
NetworkManager:SCPlugin-Ifupdown: (5130848) connections count: 0
NetworkManager:   device_creator(): /sys/devices/virtual/net/eth0:
couldn't determine device driver; ignoring...
NetworkManager:   device_creator(): /sys/devices/virtual/net/eth1:
couldn't determine device driver; ignoring...
ifup: interface lo already configured

Regards,
MAK.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Managing a connection using D-Bus API

2010-07-01 Thread Sathia Narayanan
while all of you are at it I would like to point out that the nm-tool doesnt
behave as expected. Seems like te detail_device() function code is all
messed up. Can you suggest i can use any other function that does the same
job that I can replace in nm-tool.c main function cal?

-Sathia

On Thu, Jul 1, 2010 at 6:11 PM, Daenyth Blank  wrote:

> On Thu, Jul 1, 2010 at 17:04, Ozan Çağlayan  wrote:
> > On 01.07.2010 23:55, Daenyth Blank wrote:
> >> On Thu, Jul 1, 2010 at 16:26, Ozan Çağlayan  wrote:
> >>> On 01.07.2010 16:46, Daenyth Blank wrote:
>  Can you post a link to your current code? I should be able to help you
>  out or I can add something to the API if there's nothing workable
>  right now. It is a little incomplete but should be able to get what
>  you want.
> >>>
> >>>
> http://svn.pardus.org.tr/uludag/trunk/playground/intern/network-client/network
> >> Cool! At work at the moment, but I'll see if I can look into this
> >> later tonight. Just as an FYI, I do plan to change things around
> >> internally because the class structure is pretty junky right now, but
> >> I will try to keep breaking changes to a minimum and put some stuff
> >> out for migration if there are any. I don't expect the NetworkManager
> >> class to change much.
> >
> > Thanks for your interest :) I already packaged python-networkmanager and
> it's
> > available through Pardus repositories. The API is clean, the nm-util.py
> is a
> > very nice example. Actually, the first task of the student was to write a
> > Python API around NM D-Bus interface until I've hit your binding when
> doing some
> > preliminary research in Google. That saved us from reinventing the wheel.
> >
> > Regards,
> >
>
> Thanks! One thing I notice is that you'll want to use nm.devices_map()
> in a few places rather than looping through nm.devices() and
> organizing by type. You also can just do "for key in dict" rather than
> "for key in dict.keys()".
>
> Other than some minor style things, I don't really see anything too
> bad with it. I do plan to change the DeviceType stuff so you don't
> need those dicts all over... What's the issue you're currently running
> into with it?
>  ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


vpnc works from command line but not from Network Manager.

2010-07-01 Thread Maffitt, David
Using NetworkManager Applet 0.8.0.997 on fedora 13 with vpnc 0.5.3
vpnc works (I can ping machines on the private network) if I sudo from the 
command line and enter config info at prompts.
Running from the applet appears to connect (I get the banner message in pop-up 
window indicating I've connected), but I cannot ping on the private network). 
running 'ps ax | grep vpnc' returns
/usr/libexec/nm-vpnc-service
/usr/sbin/vpnc --non-inter --no-detach -

any ideas? debugging tips?

The material in this message is private and may contain Protected Healthcare 
Information (PHI).  If you are not the intended recipient, be advised that any 
unauthorized use, disclosure, copying or the taking of any action in reliance 
on the contents of this information is strictly prohibited.  If you have 
received this email in error, please immediately notify the sender via 
telephone or return mail.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Managing a connection using D-Bus API

2010-07-01 Thread Daenyth Blank
On Thu, Jul 1, 2010 at 17:04, Ozan Çağlayan  wrote:
> On 01.07.2010 23:55, Daenyth Blank wrote:
>> On Thu, Jul 1, 2010 at 16:26, Ozan Çağlayan  wrote:
>>> On 01.07.2010 16:46, Daenyth Blank wrote:
 Can you post a link to your current code? I should be able to help you
 out or I can add something to the API if there's nothing workable
 right now. It is a little incomplete but should be able to get what
 you want.
>>>
>>> http://svn.pardus.org.tr/uludag/trunk/playground/intern/network-client/network
>> Cool! At work at the moment, but I'll see if I can look into this
>> later tonight. Just as an FYI, I do plan to change things around
>> internally because the class structure is pretty junky right now, but
>> I will try to keep breaking changes to a minimum and put some stuff
>> out for migration if there are any. I don't expect the NetworkManager
>> class to change much.
>
> Thanks for your interest :) I already packaged python-networkmanager and it's
> available through Pardus repositories. The API is clean, the nm-util.py is a
> very nice example. Actually, the first task of the student was to write a
> Python API around NM D-Bus interface until I've hit your binding when doing 
> some
> preliminary research in Google. That saved us from reinventing the wheel.
>
> Regards,
>

Thanks! One thing I notice is that you'll want to use nm.devices_map()
in a few places rather than looping through nm.devices() and
organizing by type. You also can just do "for key in dict" rather than
"for key in dict.keys()".

Other than some minor style things, I don't really see anything too
bad with it. I do plan to change the DeviceType stuff so you don't
need those dicts all over... What's the issue you're currently running
into with it?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Managing a connection using D-Bus API

2010-07-01 Thread Ozan Çağlayan
On 01.07.2010 23:55, Daenyth Blank wrote:
> On Thu, Jul 1, 2010 at 16:26, Ozan Çağlayan  wrote:
>> On 01.07.2010 16:46, Daenyth Blank wrote:
>>> Can you post a link to your current code? I should be able to help you
>>> out or I can add something to the API if there's nothing workable
>>> right now. It is a little incomplete but should be able to get what
>>> you want.
>>
>> http://svn.pardus.org.tr/uludag/trunk/playground/intern/network-client/network
> Cool! At work at the moment, but I'll see if I can look into this
> later tonight. Just as an FYI, I do plan to change things around
> internally because the class structure is pretty junky right now, but
> I will try to keep breaking changes to a minimum and put some stuff
> out for migration if there are any. I don't expect the NetworkManager
> class to change much.

Thanks for your interest :) I already packaged python-networkmanager and it's
available through Pardus repositories. The API is clean, the nm-util.py is a
very nice example. Actually, the first task of the student was to write a
Python API around NM D-Bus interface until I've hit your binding when doing some
preliminary research in Google. That saved us from reinventing the wheel.

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


Re: Managing a connection using D-Bus API

2010-07-01 Thread Ozan Çağlayan
On 01.07.2010 23:40, Giovanni Campagna wrote:

> 
> I believe it could help users of some other distros too. Why not
> developing togheter with other NM frontends (nmcli / nm-applet)?
> In particular with regard to modifying connections, you should follow
> closely, as they plan to change the way settings are stored

That's of course possible but I'll prefer waiting 2-3 weeks for the current code
to become more mature and fully functional. I think that the API modifications
in anywhere should be transparent as it is possible thanks to the binding but
I'll keep this in mind.

> 
> According to NetworkManager docs (
> http://projects.gnome.org/NetworkManager/developers/spec-08.html ),
> you can deactivate a connection using NM.DeactivateConnection() (or
> the binding equivalent), except that nm-applet will detect the
> connection going down and, not knowing why, will immediately
> reconnect.

Hm, the stickyness of nm-applet's behaviour is a little bit weird but I think 
that
arises from the tagline of NM which is "NetworkManager attempts to keep an 
active
network connection available at all times."


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


Re: Managing a connection using D-Bus API

2010-07-01 Thread Daenyth Blank
On Thu, Jul 1, 2010 at 16:26, Ozan Çağlayan  wrote:
> On 01.07.2010 16:46, Daenyth Blank wrote:
>> Can you post a link to your current code? I should be able to help you
>> out or I can add something to the API if there's nothing workable
>> right now. It is a little incomplete but should be able to get what
>> you want.
>
> http://svn.pardus.org.tr/uludag/trunk/playground/intern/network-client/network
Cool! At work at the moment, but I'll see if I can look into this
later tonight. Just as an FYI, I do plan to change things around
internally because the class structure is pretty junky right now, but
I will try to keep breaking changes to a minimum and put some stuff
out for migration if there are any. I don't expect the NetworkManager
class to change much.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Managing a connection using D-Bus API

2010-07-01 Thread Giovanni Campagna
On Thu, Jul 1, 2010 at 10:26 PM, Ozan Çağlayan  wrote:
> On 01.07.2010 16:46, Daenyth Blank wrote:
>> Can you post a link to your current code? I should be able to help you
>> out or I can add something to the API if there's nothing workable
>> right now. It is a little incomplete but should be able to get what
>> you want.
>
> http://svn.pardus.org.tr/uludag/trunk/playground/intern/network-client/network
>
> To answer you and Giovanni about why we're writing this instead of using 
> nmcli, nm-util,etc:
>
> We (Pardus Linux[0]) used to use our own networking backend since these days. 
> It was a python and D-Bus
> based networking backend which worked quite well but ever since the new 
> connectivity
> technologies like CDMA, HSPA, VPN, etc. become popular, we've figured out 
> that we are not able to
> maintain and improve it due to lack of time and hardware material.
>
> So with our upcoming releases, we'll migrate to NetworkManager+ModemManager 
> but we don't want
> to break our own userspace utility's behaviour *network* which is an 
> interactive command line tool
> helping users to edit/create/delete new ethernet and wi-fi profiles and 
> managing them.

I believe it could help users of some other distros too. Why not
developing togheter with other NM frontends (nmcli / nm-applet)?
In particular with regard to modifying connections, you should follow
closely, as they plan to change the way settings are stored

> That's way one of our internship students now tries to port it to NM using 
> python-networkmanager.
>
> BTW, does activate/deactivate closes and re-establishes the connection? I 
> didn't have time to
> look at it but that's what my student said. So it seems that he's using 
> connect() disconnect()
> for completely bringing down the interface.

According to NetworkManager docs (
http://projects.gnome.org/NetworkManager/developers/spec-08.html ),
you can deactivate a connection using NM.DeactivateConnection() (or
the binding equivalent), except that nm-applet will detect the
connection going down and, not knowing why, will immediately
reconnect.
Still reading the docs, Device.Disconnect() says that it brings down
it, and no process is allowed to bring it up again without user
intervention (so you're safe from nm-applet). No mention is that you
need to have a connection on it first.

> Thanks for your helps
> Ozan Caglayan
>
> [0]: http://www.pardus.org.tr/eng
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>

Hope this helped more than the first.

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


Re: Managing a connection using D-Bus API

2010-07-01 Thread Ozan Çağlayan
On 01.07.2010 16:46, Daenyth Blank wrote:
> Can you post a link to your current code? I should be able to help you
> out or I can add something to the API if there's nothing workable
> right now. It is a little incomplete but should be able to get what
> you want.

http://svn.pardus.org.tr/uludag/trunk/playground/intern/network-client/network

To answer you and Giovanni about why we're writing this instead of using nmcli, 
nm-util,etc:

We (Pardus Linux[0]) used to use our own networking backend since these days. 
It was a python and D-Bus
based networking backend which worked quite well but ever since the new 
connectivity
technologies like CDMA, HSPA, VPN, etc. become popular, we've figured out that 
we are not able to
maintain and improve it due to lack of time and hardware material.

So with our upcoming releases, we'll migrate to NetworkManager+ModemManager but 
we don't want
to break our own userspace utility's behaviour *network* which is an 
interactive command line tool
helping users to edit/create/delete new ethernet and wi-fi profiles and 
managing them.

That's way one of our internship students now tries to port it to NM using 
python-networkmanager.

BTW, does activate/deactivate closes and re-establishes the connection? I 
didn't have time to
look at it but that's what my student said. So it seems that he's using 
connect() disconnect()
for completely bringing down the interface.

Thanks for your helps
Ozan Caglayan

[0]: http://www.pardus.org.tr/eng
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


can't enter wpa password

2010-07-01 Thread carpetnailz
I'm using my Linux box (OpenSuse 11.2) with a Sprint MiFi box. In the past it 
has worked fine but yesterday afternoon for some reason is cut me off and I 
haven't been able to get back on. All the other boxes work (using that other OS 
from Washington).

When I try to log on it will only give me the option to enter a WEP code, not a 
WPA. With some jiggling--turning radio off and on, disabling wireless and 
reenabling it, deleting the connection and trying to recreate it, even 
rebooting, I sometimes will get a dialog box that calls for the WPA password. 
But then the "Apply" button is greyed out, so NetworkManager seems to be 
refusing to do anything with my WPA password even when it offers to let me 
enter it.

Help!  I need to be able to work.

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


Re: Can't make NM work with local caching DNS resolver

2010-07-01 Thread Robert Nichols

On 07/01/2010 12:26 AM, José Queiroz wrote:


2010/6/29 Robert Nichols mailto:rnichol...@comcast.net>>


I cannot simply hard code the upstream servers in /etc/dnsmasq.conf
because that would ignore what DHCP returns.


And what's the problem in it? Are the server list returned so unstable,
that you can get different upstream DNS servers in different connections?

And what's the problem on using, for instance, OpenDNS as your upstream
servers? They're fast and somewhat reliable.


I will sometimes connect via completely different networks from which my
usual DNS servers will not accept recursive requests, or on WiFi hotspots
that do not permit connections to DNS servers other than their own.

--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Managing a connection using D-Bus API

2010-07-01 Thread Giovanni Campagna
On Thu, Jul 1, 2010 at 2:56 PM, Ozan Çağlayan  wrote:
> Hi,
>
> I'm writing a Python script which uses python-networkmanager for communicating
> with NetworkManager's D-Bus facilities.
>
> I want to disconnect an active connection. Using the nm-applet, we are not
> forced to write a MAC address for a connection.
>
> Say that I want to disconnect the device eth0 AA:BB:CC:DD:EE:FF which is
> currently connected to the connection with the ID "WiredConnection1".
>
> Since the connection doesn't have an hwaddress set, I can't match the
> connection with the device. What I want to do is sth like that:

You need the ActiveConnection object.
That is, obtain ActiveConnections property from /org/freedesktop/NetworkManager.
Obtain the Connection object with the ID you want
Find the ActiveConnection whose Connection property is the Connection
object you found
For each device in the Devices property, invoke Deactivate.

> python network.py down WiredConnection1
>
> Is it ever possible (without providing connection UUID)?

(btw, can't you just use nmcli?)

> Thanks,
>
> ---
> Ozan Çağlayan
> TUBITAK/UEKAE - Pardus Linux
> http://www.pardus.org.tr/eng
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list

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


Re: Managing a connection using D-Bus API

2010-07-01 Thread Daenyth Blank
Can you post a link to your current code? I should be able to help you
out or I can add something to the API if there's nothing workable
right now. It is a little incomplete but should be able to get what
you want.

On Thu, Jul 1, 2010 at 08:56, Ozan Çağlayan  wrote:
> Hi,
>
> I'm writing a Python script which uses python-networkmanager for communicating
> with NetworkManager's D-Bus facilities.
>
> I want to disconnect an active connection. Using the nm-applet, we are not
> forced to write a MAC address for a connection.
>
> Say that I want to disconnect the device eth0 AA:BB:CC:DD:EE:FF which is
> currently connected to the connection with the ID "WiredConnection1".
>
> Since the connection doesn't have an hwaddress set, I can't match the
> connection with the device. What I want to do is sth like that:
>
> python network.py down WiredConnection1
>
> Is it ever possible (without providing connection UUID)?
>
> Thanks,
>
> ---
> Ozan Çağlayan
> TUBITAK/UEKAE - Pardus Linux
> http://www.pardus.org.tr/eng
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Managing a connection using D-Bus API

2010-07-01 Thread Ozan Çağlayan
Hi,

I'm writing a Python script which uses python-networkmanager for communicating 
with NetworkManager's D-Bus facilities.

I want to disconnect an active connection. Using the nm-applet, we are not 
forced to write a MAC address for a connection.

Say that I want to disconnect the device eth0 AA:BB:CC:DD:EE:FF which is 
currently connected to the connection with the ID "WiredConnection1".

Since the connection doesn't have an hwaddress set, I can't match the 
connection with the device. What I want to do is sth like that:

python network.py down WiredConnection1

Is it ever possible (without providing connection UUID)?

Thanks,

---
Ozan Çağlayan
TUBITAK/UEKAE - Pardus Linux
http://www.pardus.org.tr/eng
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: dhcpcd timeout

2010-07-01 Thread Victor Gaydov
On Tue, 22 Jun 2010 17:25:32 -0700
Dan Williams  wrote:

> On Tue, 2010-06-22 at 17:39 +0400, Victor Gaydov wrote:
> > On Tue, 22 Jun 2010 01:21:29 -0700
> > Dan Williams  wrote:
> > 
> > > On Fri, 2010-06-11 at 12:42 +0400, Victor Gaydov wrote:
> > > > On Fri, 04 Jun 2010 19:23:55 -0700
> > > > Dan Williams  wrote:
> > > > 
> > > > > On Thu, 2010-06-03 at 10:34 +0400, Victor Gaydov wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > After upgrade from 0.7 to 0.8 NetworkManager compiled with
> > > > > > dhcpcd can't start connection because of dhcpcd timeout. Is
> > > > > > it a way to change this timeout?
> > > > > > 
> > > > > > Notes:
> > > > > >  - NetworkManager compiled with dhclient works fine
> > > > > >  - dhcpcd executed manually work fine
> > > > > >  - it seems that lease-time from /etc/dhcp/dhcpd.conf
> > > > > > doesn't matter when dhcpcd is executed by NM
> > > > > > 
> > > > > > Log attached.
> > > > > 
> > > > > Is there any chance you could run wireshark on the interface
> > > > > and see if any DHCP packets get out?  This is quite odd and
> > > > > it would point to either a misconfiguraton of dhcpcd on NM's
> > > > > part (maybe sendign the wrong command-line arguments) or it
> > > > > could point to a problem in dhcpcd.  It might also be useful
> > > > > to strace dhcpcd to see what it's doing.
> > > > > 
> > > > > The logs show the problem, but don't really provide any
> > > > > insight into what might be going on.  The other alternative
> > > > > may be to recompile NM and send any debugging or verbose
> > > > > command-line arguments that dhcpcd might use to get more
> > > > > output from it about the issue.
> > > > > 
> > > > > Dan
> > > > > 
> > > > > 
> > > > 
> > > > Hello! Sorry for delay.
> > > > 
> > > > The problem was related to timeouts: 45s is not enough. I
> > > > changed DHCP_TIMEOUT in sources and added '-t' option to dhcpcd
> > > > and everything works fine. Is it a way to change dhcp timeout
> > > > in config file?
> > > > 
> > > > PS. Debug log is attached. I can also send wireshark log if
> > > > necessary - yes, DHCP packets are getting out.
> > > 
> > > So in this case the server is just very, very slow to respond?
> > > Is the network heavily loaded?  Or is the DHCP server heavily
> > > loaded?  I'm not really opposed to upping the timeout by a small
> > > amount, but if the DHCP server isn't responding within a certain
> > > timeframe, there's clearly something wrong with the network,
> > > whether that timeframe is 45 seconds, 60 seconds, or whatever.
> > > At this point, upping the timeout isn't really guaranteed to fix
> > > the problem anyway if it's this bad already...
> > > 
> > > What DHCP timeout worked for you?
> > > 
> > > Dan
> > > 
> > > 
> > > 
> > 
> > Timeout varies from 30 seconds to a minute. It is desktop computer
> > and ADSL modem; provider is "stream" (http://www.stream.ru).
> > Dhclient sends a few (about 3 of 4) queries before server responds.
> > 
> > I can provide any details, if necessary, but in any case I'm not
> > able to configure anything except client side. I think
> > NetworkManager's restrictions looks quite artificial: yes, it may
> > be something wrong with network, but it's more flexible to allow
> > user to configure it by himself.. Anyway, NM compiled with dhclient
> > works fine, so there are no problems for me.
> 
> So dhclient works fine with the default 45 second timeout, but dhcpcd
> does *not* work with the 45 second timeout?
> 
> Dan
> 

After some testing, no, dhclient also sometimes doesn't work. But for
some reason dhcpcd fails more often than dhclient.

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