tions in case of several
> > DHCP servers on several networks. IMHO, the client should be
> > tolerant and ignore DHCPNAK if the server-id is different.
>
> I checked again and the internal client doesn't do any filtering based
> on the server-id. In the dhclient log at:
>
imeout. dhclient apparently ignores the NAK, but I haven't found yet
> > in the code where this is done and based on what.
>
> It seems that RFC 2131 has some contradictions in case of several
> DHCP servers on several networks. IMHO, the client should be
> tolerant and ignore DHCPNA
On 2019-08-09 16:05:11 +0200, Beniamino Galvani wrote:
> in the traces I see that there are 3 servers and one of them
> advertises a subnet different from other two. This setup makes the
> behavior non-deterministic because clients can get an address either
> in the 10.0.1.0/24 or in the
On Fri, Aug 09, 2019 at 01:10:55PM +0200, Vincent Lefevre wrote:
> On 2019-08-09 09:42:10 +0200, Beniamino Galvani wrote:
> > On Thu, Aug 08, 2019 at 06:07:41PM +0200, Vincent Lefevre wrote:
> ...
> > Could you capture DHCP packets with:
> >
> > tcpdump -i enp0s25 -s 0 -w dhcp.pcap udp port 67
On 2019-08-09 09:42:10 +0200, Beniamino Galvani wrote:
> On Thu, Aug 08, 2019 at 06:07:41PM +0200, Vincent Lefevre wrote:
> > On 2019-08-08 13:37:04 +0200, Michael Biebl wrote:
> > > Bringing Vincent into the loop here.
> > >
> > > Vincent, can you gather the information Beniamino is asking for?
On Thu, Aug 08, 2019 at 06:07:41PM +0200, Vincent Lefevre wrote:
> On 2019-08-08 13:37:04 +0200, Michael Biebl wrote:
> > Bringing Vincent into the loop here.
> >
> > Vincent, can you gather the information Beniamino is asking for?
> >
> > Am 08.08.19 um 09:51 schrieb Beniamino Galvani:
> > >
On 2019-08-08 13:37:04 +0200, Michael Biebl wrote:
> Bringing Vincent into the loop here.
>
> Vincent, can you gather the information Beniamino is asking for?
>
> Am 08.08.19 um 09:51 schrieb Beniamino Galvani:
> > Would it be possible to capture a dump of DHCP packets for a success
> > and for
Bringing Vincent into the loop here.
Vincent, can you gather the information Beniamino is asking for?
Am 08.08.19 um 09:51 schrieb Beniamino Galvani:
> On Wed, Aug 07, 2019 at 05:00:01PM +0200, Michael Biebl wrote:
>> Full downstream bug report at
>> https://bugs.debian.org/cgi-bi
Full downstream bug report at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933930
Weitergeleitete Nachricht
Betreff: Re: [Pkg-utopia-maintainers] Bug#933930: Bug#933930:
Bug#933930: network-manager: Ethernet connection no longer works
Datum: Wed, 7 Aug 2019 15:58:04 +0200
On Tue, Dec 27, 2016 at 02:44:43PM +0800, 志 wrote:
> Hi All,
> It's so nice to join this mailing list.
> Recently I encounter a issue that nm-applet not show wwan options on menu
> in my Ubuntu Xeinal 16.04.1:
> https://bugzilla.gnome.org/show_bug.cgi?id=776384
Hi,
the bug is now
Hi All,
It's so nice to join this mailing list.
Recently I encounter a issue that nm-applet not show wwan options on menu
in my Ubuntu Xeinal 16.04.1:
https://bugzilla.gnome.org/show_bug.cgi?id=776384
investigation:
* In nm-applet, it caused by device-added signal comes before
mm_new_ready()
ould be that. Or of course, running your local caching DNS server
yourself.
See `man NetworkManager.conf` for main.dns and main.rc-manager
settings.
You are also not supposed to kill processes started by NetworkManager.
If you really want to forcefully restart the DNS plugin, `killall -HUP
Ne
First a caveat...
My system is an Ubuntu 16.04 Desktop system.
I
use it for daily management of a 54 device network
of Windows PC's
(10), cameras (9), scales (4), Linux DVR's (2)
CentOS Pos system and
many other Iot type stuff.
My system functions as the network router,
firewall,
On Wed, 2016-12-07 at 14:47 -0500, Calvin Arndt wrote:
> NetworkManager documentation does not document proper way to use
> different tools for dns /dhcp management.
> This additional documentation will need to be written by someone who
> develops this package. Its the philosophy
> behind the
to unconnect and reconnect
manually.
Is this behaviour expected or is it a bug?
Andreas
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
automatically after saving
connection changes - with 1.0.2 I have to unconnect and reconnect
manually.
Is this behaviour expected or is it a bug?
I think that's actually a bug in 0.9.8; changes to the connection are
only supposed to be saved to the config files and are not applied until
to Manual/Fixed ip. When doing so
0.9.8 did unconnect and reconnect automatically after saving
connection changes - with 1.0.2 I have to unconnect and reconnect
manually.
Is this behaviour expected or is it a bug?
I think that's actually a bug in 0.9.8; changes to the connection are
only
On Sun, 2015-04-19 at 15:36 -0600, Chris Murphy wrote:
On Sun, Apr 19, 2015 at 2:57 PM, Dan Mossor danofs...@gmail.com
wrote:
I've noticed something else,also - I can't get F22 to see my wired
interface
to compare with wireless to see if I can narrow it down some more.
The GUI
On 22.04.2015 12:29, Pavlo Rudyi wrote:
On Sun, 2015-04-19 at 15:36 -0600, Chris Murphy wrote:
On Sun, Apr 19, 2015 at 2:57 PM, Dan Mossor danofs...@gmail.com
wrote:
I've noticed something else,also - I can't get F22 to see my wired
interface
to compare with wireless to see if I can
On Sun, Apr 19, 2015 at 2:57 PM, Dan Mossor danofs...@gmail.com wrote:
I've noticed something else,also - I can't get F22 to see my wired interface
to compare with wireless to see if I can narrow it down some more. The GUI
applet simply won't activate the interface, and nmcli tells me
Error:
On Sun, Apr 19, 2015 at 9:20 AM, Dan Mossor danofs...@gmail.com wrote:
Greetings, folks.
I and at least one other individual have noticed an annoying bug with
NetworkManager-1.0.0-8.fc22.x86_64 but we aren't sure of the root cause so
we can't legitimately file a BZ on it yet. The issue we're
On Sun, 2015-04-19 at 13:21 -0600, Chris Murphy wrote:
On Sun, Apr 19, 2015 at 9:20 AM, Dan Mossor danofs...@gmail.com wrote:
Greetings, folks.
I and at least one other individual have noticed an annoying bug with
NetworkManager-1.0.0-8.fc22.x86_64 but we aren't sure of the root cause so
On 04/19/2015 02:21 PM, Chris Murphy wrote:
On Sun, Apr 19, 2015 at 9:20 AM, Dan Mossor danofs...@gmail.com wrote:
Greetings, folks.
I and at least one other individual have noticed an annoying bug with
NetworkManager-1.0.0-8.fc22.x86_64 but we aren't sure of the root cause so
we can't
Greetings, folks.
I and at least one other individual have noticed an annoying bug with
NetworkManager-1.0.0-8.fc22.x86_64 but we aren't sure of the root cause
so we can't legitimately file a BZ on it yet. The issue we're seeing is
that with a fully updated Fedora 22 Beta system, once NM
Hi,
I opened tracker bug nm-patch (742780) which comes together with the
bug 'nm-review' (728406).
https://bugzilla.gnome.org/showdependencytree.cgi?id=742870hide_resolved=1
The idea is, bugs that are currently being worked on should either block
'nm-patch' or 'nm-review'.
A bug should only
Hi there,
Michael asked to forward this to the list, so here it is...
The patch 0005-Mark-virtual-ethernet-interfaces-as-unmanaged.patch
(debian Jessie) messes up with my virtual interfaces (vmware
vmnet1/vmnet8).
Even if I set them manually unmanaged (from /etc/network/interfaces or
using
devices by
changing their configuration, that would be a bug in NM, and we need to
find it and fix it.
Thanks!
Dan
Even if I set them manually unmanaged (from /etc/network/interfaces or
using keyfile plugin), they finally appear connected and make me lose my
internet connection if my ethernet
Hi all,
Pavel created a tracker bug for all reviews and added all the existing
patch/branch review bugs that he could find. Having them all collected
in one place makes it a lot easier for everyone to see the outstanding
reviews and process them more quickly. Not sure why we didn't do
On Tue, 2014-04-29 at 11:59 -0500, Dan Williams wrote:
Hi all,
Pavel created a tracker bug for all reviews and added all the existing
patch/branch review bugs that he could find. Having them all collected
in one place makes it a lot easier for everyone to see the outstanding
reviews
On Tue, 2014-04-29 at 19:46 +0200, Bastien Nocera wrote:
On Tue, 2014-04-29 at 11:59 -0500, Dan Williams wrote:
Hi all,
Pavel created a tracker bug for all reviews and added all the existing
patch/branch review bugs that he could find. Having them all collected
in one place makes
Even ignore-carrier devices need to be aware of carrier-up events so
they can continue DHCP when the link comes up. They just ignore all
carrier-down events.
---
src/devices/nm-device.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/devices/nm-device.c
On Wed, 2014-04-02 at 09:18 -0500, Dan Williams wrote:
Even ignore-carrier devices need to be aware of carrier-up events so
they can continue DHCP when the link comes up. They just ignore all
carrier-down events.
Acked by thaller danw on IRC, pushed to master. Does this fix the
issue for
On 02.04.2014 16:36, Dan Williams wrote:
On Wed, 2014-04-02 at 09:18 -0500, Dan Williams wrote:
Even ignore-carrier devices need to be aware of carrier-up events so
they can continue DHCP when the link comes up. They just ignore all
carrier-down events.
Acked by thaller danw on IRC,
Authentication Required dialogue box.
It seems there is some kind of caching going on in situation B1, and in
situation B2 the certs just aren't being compared at all. Isn't this a
security bug? And C2 seems to be a UI bug.
C2 works as expected(?) :) -- See above
B1b I wouldn't expect. You
on in situation B1, and in
situation B2 the certs just aren't being compared at all. Isn't this a
security bug? And C2 seems to be a UI bug.
If having the Wireshark dumps from each of these four situations would
help, I'd be glad to provide them. Please CC me in any response to this
mail, as I'm set
a patch to re-orders the dhcp4 state change to before the
call to
dhcp4_lease_change.
Attached the patch to the bug, and also including it here for review.
Thanks,
Scott
diff --git a/src/devices/nm-device.c b/src/devices/nm-device.c
index 61bb2aa..55b4ff8 100644
--- a/src/devices/nm-device.c
is triggered before the dhcp4 state has been
updated.
I've attached a patch to re-orders the dhcp4 state change to before the
call to
dhcp4_lease_change.
Attached the patch to the bug, and also including it here for review.
Pushed, thanks! I also made the same change to the DHCPv6 code.
Dan
Please pull from:
git://iam.tj/network-manager-openvpn.git gnome712710
There is a bug in the parsing of multiple remote gateway specifications.
The tooltip says:
po/id.po:402:msgid Remote host name or IP address. You can specify multiple
items for redundancy (use commas to separate
Please pull from:
git://iam.tj/network-manager-openvpn.git gnome712720
This patch is based on my branch gnome712710 fixing the --remote separator
issue.
When the remote gateway is specified as IP PORT [PROTO] the entire string would
be passed as a single argument on the openvpn
On 7 Jun 2013 07:57, Paul Connor mrphcon...@gmail.com wrote:
I am seeing a bug with network manager even tho I have now updated to the
latest version 0.9.4.1-0ubuntu2
I am running ubuntu 11.04 LTS 32 bit as my OS
When I first startup it works fine.. I can connected and disconnect to
any
I am seeing a bug with network manager even tho I have now updated to the
latest version 0.9.4.1-0ubuntu2
I am running ubuntu 11.04 LTS 32 bit as my OS
When I first startup it works fine.. I can connected and disconnect to any
wireless network I should like.
However after being connected
Im running Debian jessie(testing), and after some recent updates with
network-manager to 0.9.8, i can no longer maintain a connection to my
wireless network. I have no problems on 0.9.4, (so i reverted back for
now), also, the access point is PEAP/MSCHAPv2, which might be important.
Im wondering
On Fri, 2013-05-31 at 12:23 +0200, John Greene wrote:
Im running Debian jessie(testing), and after some recent updates with
network-manager to 0.9.8, i can no longer maintain a connection to my
wireless network. I have no problems on 0.9.4, (so i reverted back for
now), also, the access point
On Fri, Nov 02, 2012 at 07:38:37PM +0100, Mathieu Trudel-Lapierre wrote:
I actually did the porting in Ubuntu. The patch probably doesn't apply
quite as cleanly on git master; but see the attached file which
migrates the calls to gtk_table_* to gtk_grid_*.
Applies cleanly on git master.
: In function ‘add_row’:
vpn-password-dialog.c:127:2: error: ‘gtk_table_attach_defaults’ is deprecated
(declared at /usr/include/gtk-3.0/gtk/deprecated/gtktable.h:120): Use 'GtkGrid'
instead [-Werror=deprecated-declarations]
The autoconf script enables -Werror by default. The original bug report
On Thu, Nov 01, 2012 at 06:59:13PM +0100, Clemens Buchacher wrote:
nm-pptp-service.name.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This patch is for network-manager-pptp. If accepted I can provide
analogous patches for network-manager-vpnc and
network-manager-openconnect.
On Fri, 2012-11-02 at 11:59 +0100, Clemens Buchacher wrote:
So this has been an issue for a while, and the -Werror flag does not
help anything besides breaking the build.
You're going to have to learn how to pass options to configure if
you're building software in general. It's really the
On Fri, Nov 02, 2012 at 09:16:29AM -0400, Colin Walters wrote:
On Fri, 2012-11-02 at 11:59 +0100, Clemens Buchacher wrote:
So this has been an issue for a while, and the -Werror flag does not
help anything besides breaking the build.
You're going to have to learn how to pass options to
On Fri, Nov 02, 2012 at 09:16:29AM -0400, Colin Walters wrote:
On Fri, 2012-11-02 at 11:59 +0100, Clemens Buchacher wrote:
So this has been an issue for a while, and the -Werror flag does
not
help anything besides breaking the build.
You're going to have to learn how to pass
On Fri, Nov 02, 2012 at 10:32:25AM -0400, Pavel Simerda wrote:
On Fri, Nov 02, 2012 at 09:16:29AM -0400, Colin Walters wrote:
On Fri, 2012-11-02 at 11:59 +0100, Clemens Buchacher wrote:
So this has been an issue for a while, and the -Werror flag does
not
help anything besides
And it is therefore not a solution to do nothing and force the
package maintainers to deal with this issue.
I still prefer a proper solution like the one from Dan Winship:
https://bugzilla.gnome.org/show_bug.cgi?id=679130
___
networkmanager-list
On Fri, Nov 02, 2012 at 11:36:46AM -0400, Pavel Simerda wrote:
And it is therefore not a solution to do nothing and force the
package maintainers to deal with this issue.
I still prefer a proper solution like the one from Dan Winship:
https://bugzilla.gnome.org/show_bug.cgi?id=679130
On Fri, Nov 2, 2012 at 3:43 PM, Clemens Buchacher dri...@aon.at wrote:
On Fri, Nov 02, 2012 at 10:32:25AM -0400, Pavel Simerda wrote:
On Fri, Nov 02, 2012 at 09:16:29AM -0400, Colin Walters wrote:
On Fri, 2012-11-02 at 11:59 +0100, Clemens Buchacher wrote:
So this has been an issue
-shell. Prepend the
libexecdir to make the path unambiguous.
Note that this requires gnome-shell to recognize absolute paths, which
it does since version 3.6 (Bug #679212).
This fixes https://bugzilla.gnome.org/show_bug.cgi?id=679225.
Signed-off-by: Clemens Buchacher dri...@aon.at
---
nm-pptp
This fixes https://bugzilla.gnome.org/show_bug.cgi?id=679130.
Signed-off-by: Clemens Buchacher dri...@aon.at
---
m4/compiler_warnings.m4 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/m4/compiler_warnings.m4 b/m4/compiler_warnings.m4
index 95ad3fb..ac21b89 100644
---
What is it supposed to fix?
- Original Message -
From: Clemens Buchacher dri...@aon.at
To: networkmanager-list@gnome.org
Sent: Thursday, November 1, 2012 6:58:05 PM
Subject: [PATCH] fix build: disable -Werror by default (Bug #679130)
This fixes https://bugzilla.gnome.org
Where's the bug tracker for modem manager?
I've discovered that on all of the CDMA devices I've tried, sending the
D-Bus Activate method results in modem-manager dieing with a segfault.
Thanks,
David
___
networkmanager-list mailing list
networkmanager
On Thu, 11 Oct 2012 08:50:40 -0400
David Pfeffer wrote:
Where's the bug tracker for modem manager?
https://bugzilla.redhat.com/buglist.cgi?component=ModemManagerproduct=Fedoraquery_format=advancedresolution=---order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_idquery_based_on
I've discovered that on all of the CDMA devices I've tried, sending the
D-Bus Activate method results in modem-manager dieing with a segfault.
There's currently no implementation of CDMA activation (neither manual
nor automatic) in released ModemManagers, so that's not expected to
work.
On 10/11/2012 03:06 PM, Brian Morrison wrote:
On Thu, 11 Oct 2012 08:50:40 -0400
David Pfeffer wrote:
Where's the bug tracker for modem manager?
https://bugzilla.redhat.com/buglist.cgi?component=ModemManagerproduct=Fedoraquery_format=advancedresolution=---order=changeddate%20DESC
Hi, all
I'm using debian testing, and the version is
network-manager-openvpn-0.9.4.0.
I can connect to my openvpn server successfully, but after a while, my
CPU usage got high:
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
11039 root 20 0 74032 3576
Or maybe I should investigate why the socket to localhost:1194 got
closed in the first place, I mean, is this a normal behavior? But as I'm
not familiar with openvpn internals, I have chose to fix it in the easy
way.
PS, please kindly put me in the CC: as I am not subscribed to the list,
thanks!
On 09/26/2012 04:51 PM, Pavel Simerda wrote:
The proper keyfile configuration is for example:
[connection]
id=Ethernet
uuid=d880f3bb-8c51-4ca4-aef7-1954e022820f
type=802-3-ethernet
[802-3-ethernet]
mac-address=52:54:00:eb:e9:fb
[ipv4]
method=auto
[ipv6]
nmmethod=auto
I believe you have a type
- Original Message -
From: Gene Czarcinski g...@czarc.net
To: networkmanager-list@gnome.org
Cc: Pavel Simerda psime...@redhat.com
Sent: Friday, September 28, 2012 7:09:18 PM
Subject: Re: NM bug 684242 and other stuff
On 09/26/2012 04:51 PM, Pavel Simerda wrote:
The proper
On 09/25/2012 07:55 PM, Pavel Simerda wrote:
I'll divide my reaction into four parts and post it also to NM mailing list so
that anyone can
benefit.
1) DHCPv6 currently works according to IETF standards and has been tested with
NetworkManager
commit 70f64fbc4277c636c0a373d6e6eddf0574d53827
On Wed, 2012-09-26 at 14:04 -0400, Gene Czarcinski wrote:
On 09/25/2012 07:55 PM, Pavel Simerda wrote:
I'll divide my reaction into four parts and post it also to NM mailing list
so that anyone can
benefit.
1) DHCPv6 currently works according to IETF standards and has been tested
On 09/26/2012 02:38 PM, Dan Williams wrote:
There's some example keyfiles here:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/keyfile/tests/keyfiles
manual IPv6 is for example:
On 09/25/2012 07:55 PM, Pavel Simerda wrote:
I'll divide my reaction into four parts and post it also to NM
mailing list so that anyone can
benefit.
1) DHCPv6 currently works according to IETF standards and has been
tested with NetworkManager
commit
On 09/26/2012 02:04 PM, Gene Czarcinski wrote:
BTW, my testing that worked was using named/dhcpd/dhcp6 on the
server. I now need to test dnsmasq to make sure that it works too. It
is possible that for a small network (which is the primary use of
dnsmasq), you might not need radvd because
On Wed, 2012-09-26 at 14:56 -0400, Gene Czarcinski wrote:
On 09/26/2012 02:38 PM, Dan Williams wrote:
There's some example keyfiles here:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/keyfile/tests/keyfiles
manual IPv6 is for example:
- Original Message -
From: Dan Williams d...@redhat.com
To: Gene Czarcinski g...@czarc.net
Cc: networkmanager-list@gnome.org
Sent: Wednesday, September 26, 2012 11:07:04 PM
Subject: Re: NM bug 684242 and other stuff
On Wed, 2012-09-26 at 14:56 -0400, Gene Czarcinski wrote
On Wed, 2012-09-26 at 17:21 -0400, Pavel Simerda wrote:
- Original Message -
From: Dan Williams d...@redhat.com
To: Gene Czarcinski g...@czarc.net
Cc: networkmanager-list@gnome.org
Sent: Wednesday, September 26, 2012 11:07:04 PM
Subject: Re: NM bug 684242 and other stuff
Hi all,
* Dan Williams
On Wed, 2012-09-26 at 14:56 -0400, Gene Czarcinski wrote:
What I am looking for (without diving into the Networkmanager code any
more than I have too) is a keyfile configuration which will cause RA to
be used for the default route and dhcpv6 for the client's IPv6
I'll divide my reaction into four parts and post it also to NM mailing list so
that anyone can
benefit.
1) DHCPv6 currently works according to IETF standards and has been tested with
NetworkManager
commit 70f64fbc4277c636c0a373d6e6eddf0574d53827 before merging the 'ipv6'
branch into
master.
: is this a feature, or a bug?
From the user perspective, it's certainly a bug. Whether we can do
anything about it depends on how much we know about the failure
mode. AFAIK there are some cases where the credentials have changed
and something else has gone wrong (e.g. interference
Ajay Garg ajaygargn...@gmail.com writes:
Whenever a wifi AP goes out of range, we see the popup (repeatedly at
regular intervals), asking for the passphrase key(s).
This is observed on F17 (and F14 as well).
I was just wondering: is this a feature, or a bug?
From the user perspective, it's
Hi all.
Whenever a wifi AP goes out of range, we see the popup (repeatedly at
regular intervals), asking for the passphrase key(s).
This is observed on F17 (and F14 as well).
I was just wondering: is this a feature, or a bug?
If this is in fact a feature, I would be grateful, if I could let
Can anyone help me, please?
https://bugzilla.gnome.org/show_bug.cgi?id=665630
It's very frustrating reboot the system each time!
Thanks in advance
--
gianted
___
networkmanager-list mailing list
networkmanager-list@gnome.org
On Fri, 2011-12-16 at 00:38 +0100, Gianluca wrote:
Can anyone help me, please?
https://bugzilla.gnome.org/show_bug.cgi?id=665630
It's very frustrating reboot the system each time!
Updated the bug with some questions for you.
Dan
Thank you very much for your answer.
It actually solved my issue.
Jean
Le mercredi 05 octobre 2011 à 13:53 -0500, Dan Williams a écrit :
On Tue, 2011-10-04 at 17:07 +0200, Jean Parpaillon wrote:
Hi again :)
Your original crash is a dbus-glib bug, which likely was a regression in
dbus
On Tue, 2011-10-04 at 17:07 +0200, Jean Parpaillon wrote:
Hi again :)
Your original crash is a dbus-glib bug, which likely was a regression in
dbus-glib 0.94 and is fixed by:
http://cgit.freedesktop.org/dbus/dbus-glib/commit/?id=3e0828f57c3925ea9b63d22ab82d991a0fea0536
ie it's been fixed
Hi all,
I'm using NetworkManager from master branch.
Running the following python code crash NetworkManager:
###
import dbus
import sys
NM_DBUS_SERVICE = org.freedesktop.NetworkManager
NM_MANAGER_PATH = /org/freedesktop/NetworkManager
NM_MANAGER_IFACE = org.freedesktop.NetworkManager
Hi again :)
I'm quite confused on using NetworkManager DBUS API on master branch.
1/ When getting the object with the path returned by
NetworkManager.GetDevices() method, NM crashes (path is of the
form: /org/freedesktop/NetworkManager/Devices/0)
2/ If I get the Device object with path
like
On Saturday 28 of May 2011 11:55:21 Andreas Schwab wrote:
---
cli/src/connections.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/cli/src/connections.c b/cli/src/connections.c
index 2646aa9..a0b6c17 100644
--- a/cli/src/connections.c
+++
---
cli/src/connections.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/cli/src/connections.c b/cli/src/connections.c
index 2646aa9..a0b6c17 100644
--- a/cli/src/connections.c
+++ b/cli/src/connections.c
@@ -400,6 +400,7 @@ show_connection (NMConnection *data,
---
cli/src/connections.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/cli/src/connections.c b/cli/src/connections.c
index 2646aa9..a0b6c17 100644
--- a/cli/src/connections.c
+++ b/cli/src/connections.c
@@ -400,6 +400,7 @@ show_connection (NMConnection *data,
Hi,
I filed this bug https://bugzilla.redhat.com/show_bug.cgi?id=698054
with Fedora 15 beta, but i wonder if it is actually a part of
NetworkManager or Fedora 15 or Gnome 3.
Thanks,
Elison
___
networkmanager-list mailing list
networkmanager-list
No response? This is how you treat users reporting *major* bugs? Nice,
indeed.
On Thu, Feb 10, 2011 at 12:04 AM, Daniel Duris dus...@gmail.com wrote:
I am reporting bug - after update of Ubuntu Mint, 3g modem is unable
to connect. SIM card is correctly connected I can assure you despite
On Fri, 18 Feb 2011 00:16:06 +0100
Daniel Duris dus...@gmail.com wrote:
No response? This is how you treat users reporting *major* bugs? Nice,
indeed.
No, only the ones who appear to be pretentious assholes with a
sense of entitlement.
Sarcasm aside, you should check with your distribution
I am reporting bug - after update of Ubuntu Mint, 3g modem is unable
to connect. SIM card is correctly connected I can assure you despite
the message from the network manager. as no chabnge to the sim card
has been done. only change is complete update of ubuntu mint. same
error (unable to connect
hi,
thank you for your hard work to make linux better!
on the way of using my lively ubuntu i found a little problem that become
big to me.
i have a laptop sony vaio vgn-c240e and is assembled with pci express
network card. it works fine but some times the signal is not good. because
of that i
Le mercredi 20 octobre 2010 à 23:56 +0300, Trifon Tashev a écrit :
hi,
thank you for your hard work to make linux better!
on the way of using my lively ubuntu i found a little problem that become
big to me.
i have a laptop sony vaio vgn-c240e and is assembled with pci express
network card.
I tried to build the latest git source with debian squeeze.
For i386, all works fine. But for armel, i got the following error:
./autogen.sh
...
...
checking for LIBNL... yes
checking for libnl address caching bug... ?
configure: error: libnl test program failed
Any ideas?
Cheers,
Tom
On Friday 04 of June 2010 10:45:03 toabctl wrote:
I tried to build the latest git source with debian squeeze.
For i386, all works fine. But for armel, i got the following error:
./autogen.sh
...
...
checking for LIBNL... yes
checking for libnl address caching bug... ?
configure: error
. However when disconnecting, the
dispatcher script is called with the parameters eth0 down. It has been
like that for quite some time now, but only recently has it started to
annoy me enough to investigate.
Is that worth a bug report?
Hm, I just realized NM actually takes down eth0 when I
like that for
quite some time now, but only recently has it started to annoy me enough to
investigate.
Is that worth a bug report?
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager
is called with the parameters eth0 down. It has been
like that for quite some time now, but only recently has it started to
annoy me enough to investigate.
Is that worth a bug report?
Hm, I just realized NM actually takes down eth0 when I take down ppp0. What
the dispatcher script does is start
On Mar 18, 2010, at 20:49, Dan Williams wrote:
Is that the intended behaviour? To me, autoconnect indicates that it's
Yes.
to be automatically connected unless I tell it otherwise, which is what
deactivateConnection() would logically do.
You're probably looking for the Disconnect()
Hello,
I'm playing with NetworkManager 0.80, specifically the (new) autoconnect
feature.
I've found that if autoconnect is set to true on a Connection, the
backend runs GetSettings() on all of the Connections that have
autoconnect set and brings them up. This appears correct.
However, if
On Thu, 2010-03-18 at 15:35 -0400, Pat Suwalski wrote:
Hello,
I'm playing with NetworkManager 0.80, specifically the (new) autoconnect
feature.
I've found that if autoconnect is set to true on a Connection, the
backend runs GetSettings() on all of the Connections that have
autoconnect
1 - 100 of 238 matches
Mail list logo
