Re: Bond eth-wifi
Hi, > > After simply turning wifi on and off the slave reconnects again and every > thing is working again. > > What do i miss? It is hard to say exactly. I have wifi - ethernet bonding running fine for quite some time now. But I run newer NM (1.9.3) and I have made bonded interface to use wifi's mac. Not sure if last part if important though. -- Martynov Nikolay. Email: mar.ko...@gmail.com ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Use default active interface, even if it is of unsupported class
Hi.
Just a kind ping. This patch was sent at the same time as one other
patch - which got merged quite some time ago. Just wanted to make sure
this one doesn't fall through the cracks.
Thanks!
2017-05-16 23:15 GMT-04:00 Nikolay Martynov :
> Currently if I have bond interface running as my default interface and
> I try to establish VPN connection I get route to VPN server added to
> physical ethernet interface - one of bond slaves. This makes no sense
> - that slave doesn't even have IP address, and obviously such VPN
> connection fails to work.
>
> The problem happanes because we try to determine what interface has
> default route and we skip all interfaces that we do not know
> about (i.e. anything that is not ethernet, wifi, wwan, modem and
> BT). Since bond is not on the list code skips it.
>
> It looks like code doesn't really care what type the 'default'
> interface is - so that check is really not nessesary. Removing that
> check fixes 'VPN with default route via bond' problem.
>
> Signed-off-by: Nikolay Martynov
> ---
> src/applet.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/applet.c b/src/applet.c
> index 2929863d..cb9229cb 100644
> --- a/src/applet.c
> +++ b/src/applet.c
> @@ -248,8 +248,12 @@ applet_get_default_active_connection (NMApplet *applet,
> NMDevice **device)
> continue;
>
> candidate_dev = g_ptr_array_index (devices, 0);
> - if (!get_device_class (candidate_dev, applet))
> - continue;
> +
> + /* We have to return default connection/device even if they
> are of an
> +* unknown class - otherwise we may end up returning non
> +* default interface which has nothing to do with our default
> +* route, e.g. we may return slave ethernet when we have
> +* defult route going through bond */
>
> if (nm_active_connection_get_default (candidate)) {
> if (!default_ac) {
> --
> 2.11.0
>
--
Martynov Nikolay.
Email: mar.ko...@gmail.com
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Do not skip wifi slave connections
Hi. 2017-05-18 12:22 GMT-04:00 Beniamino Galvani : > On Thu, May 18, 2017 at 11:42:47AM -0400, Nikolay Martynov wrote: >> Just to clarify: this patch only affects wifi bonded connections. >> 'Classic' ethernet bond slaves are still skipped - so this change >> should not affect existing users. >> I think the intention of original patch was to hide ethernet ones. >> The problem with wifi slaves is that they are not hidden since they >> actually come from scan results - they still pop up in the list of >> available APs. And this is the good thing - this means I can connect >> and disconnect wifi bond slave at will from the applet. >> So, with this in mind - could you please clarify why you think this is >> not the right thing to do so I could try to address that? :) >> > > Since wifi slave connection are displayed only if the matching SSID is > found, and they don't waste space in the menu because they are grouped > in the AP submenu, I think it's ok to display them. > > On the other hand, you still wouldn't be able to control the bond and > the ethernet slave from the applet, so I wonder if this is really > useful. As I've sort of tried to explain in comment to the patch: * Before this patch clicking on AP that is bond slave makes NM create new connection for that AP name (i.e. it asks for secrets and everything) - this is not what user would normally want because he already has this SSID configured as bond slave * With this patch clicking same AP actually establishes bond slave connection that was configured before and doesn't create a new one. From this perspective this is actually useful. > > Anyway, the patch LGTM. Thanks! -- Martynov Nikolay. Email: mar.ko...@gmail.com ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Do not skip wifi slave connections
Hi. Thanks for your response! 2017-05-18 11:32 GMT-04:00 Thomas Haller : > On Tue, 2017-05-16 at 22:13 -0400, Nikolay Martynov wrote: >> If slave connection is a wifi connection we should still display it >> Otherwise this AP gets scanned regardless, but when user clicks it >> new >> network is created in NM's configuation - which is unlikely what user >> desired > > Hi Nikolay, > > I see what the patch does, but I am not convinced that it's the right > thing to do. > > In a way, it changes > https://git.gnome.org/browse/network-manager-applet/commit/?h=0abe8a8f46bcdce5907882ba355ec69156b33164 > > Other opinions? Just to clarify: this patch only affects wifi bonded connections. 'Classic' ethernet bond slaves are still skipped - so this change should not affect existing users. I think the intention of original patch was to hide ethernet ones. The problem with wifi slaves is that they are not hidden since they actually come from scan results - they still pop up in the list of available APs. And this is the good thing - this means I can connect and disconnect wifi bond slave at will from the applet. So, with this in mind - could you please clarify why you think this is not the right thing to do so I could try to address that? :) Thanks! -- Martynov Nikolay. Email: mar.ko...@gmail.com ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Use default active interface, even if it is of unsupported class
Currently if I have bond interface running as my default interface and
I try to establish VPN connection I get route to VPN server added to
physical ethernet interface - one of bond slaves. This makes no sense
- that slave doesn't even have IP address, and obviously such VPN
connection fails to work.
The problem happanes because we try to determine what interface has
default route and we skip all interfaces that we do not know
about (i.e. anything that is not ethernet, wifi, wwan, modem and
BT). Since bond is not on the list code skips it.
It looks like code doesn't really care what type the 'default'
interface is - so that check is really not nessesary. Removing that
check fixes 'VPN with default route via bond' problem.
Signed-off-by: Nikolay Martynov
---
src/applet.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/applet.c b/src/applet.c
index 2929863d..cb9229cb 100644
--- a/src/applet.c
+++ b/src/applet.c
@@ -248,8 +248,12 @@ applet_get_default_active_connection (NMApplet *applet,
NMDevice **device)
continue;
candidate_dev = g_ptr_array_index (devices, 0);
- if (!get_device_class (candidate_dev, applet))
- continue;
+
+ /* We have to return default connection/device even if they are
of an
+* unknown class - otherwise we may end up returning non
+* default interface which has nothing to do with our default
+* route, e.g. we may return slave ethernet when we have
+* defult route going through bond */
if (nm_active_connection_get_default (candidate)) {
if (!default_ac) {
--
2.11.0
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Do not skip wifi slave connections
If slave connection is a wifi connection we should still display it
Otherwise this AP gets scanned regardless, but when user clicks it new
network is created in NM's configuation - which is unlikely what user desired
Signed-off-by: Nikolay Martynov
---
src/applet.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/applet.c b/src/applet.c
index 0ee9eb8e..2929863d 100644
--- a/src/applet.c
+++ b/src/applet.c
@@ -286,12 +286,13 @@ applet_get_all_connections (NMApplet *applet)
all_connections = nm_client_get_connections (applet->nm_client);
connections = g_ptr_array_new_full (all_connections->len,
g_object_unref);
- /* Ignore slave connections */
+ /* Ignore slave connections unless they are wifi connections */
for (i = 0; i < all_connections->len; i++) {
connection = all_connections->pdata[i];
s_con = nm_connection_get_setting_connection (connection);
- if (s_con && !nm_setting_connection_get_master (s_con))
+ if (s_con && (!nm_setting_connection_get_master (s_con)
+ || nm_connection_get_setting_wireless
(connection)))
g_ptr_array_add (connections, g_object_ref
(connection));
}
--
2.11.0
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Bonding wifi and wired
Hi. 2016-03-08 15:55 GMT-05:00 José Queiroz : > > > 2016-03-08 14:30 GMT-03:00 Dan Williams : >> >> >> I know it's been done before, but one caveat is that the wifi driver >> and the supplicant have to correctly support setting the WiFi device's >> MAC address since bonding requires they have the same one. That's been >> a problem in the past and required fixes to the supplicant and drivers. >> But yeah, I'm sure we'd take patches fixing anything on the NM side. >> > > Hi Dan, > > And what about if NM assume this to be done based on the WiFi's MAC? This > way we could use this feature despite the drive in use... Yeah, that's exactly what I do currently. Just to clarify: this whole idea works on 'stock' ubuntu's NM since at least 14.04, and probably before that. I've setup my eth interface to clone MAC from my wifi. This way bond interface gets MAC that is equal to wifi's MAC. Without this wifi (at least one that I have) refuses properly authenticate on AP. On router side I had to enable wifi clients isolation and LAN bridge hairpin so two bonded clients can properly talk to each other and other AP clients. Things work in a sense that I can pull the plug out of laptop during hangout call and not notice anything, and I can put it back in and see traffic flowing on wire. But NM's clearly gets confused by this setu. But since it sounds like NM's team would welcome patches I hope I will be able to address some of those problems. -- Martynov Nikolay. Email: mar.ko...@gmail.com ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Bonding wifi and wired
Hi. I just wanted to reach out to ask what's NetworkManager team's position on allowing bonding of wifi and wired interface? Are there any plans to support this? If not - it is due to no one being interested implementing it or because this feature would go against some large plans/ideology? I was able to make it work with NM on client side and OpenWRT on router side. Router side is easy. On NM side there is some manual config editing (which is fine) and some kinds that make day-to-day life less enjoyable than it should (like inability to manually connect to bonded wifi). SO I was curious - would patches fixing those smaller kinks be acceptable at all or is it something that NM team is just not interested in? Thanks! -- Martynov Nikolay. Email: mar.ko...@gmail.com ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
