eth0 + wlan0
Hi crew, I've just subscribed to this list and I would like at first to thank all developers for their precious work! :) Moreover I have a small problem and I wish if somebody can help me. Objectives: > Use eth0 to connect to a specified NFS folder using a fix IP (connection to > be established every time the cable is plugged) > AND > Use wlan0, in DHCP mode, to surf on Internet > Requisites: > Use only NetworkManager (if possible) to handle both connections. > Problem: > Every interface individually works, however if plug the cable (eth0), I > cannot surf on Internet any more (it try to "surf" using the cable). Can you help me please? Here below some technical details. Thank you very much, giopas - Environment: > 1. Debian SID > 2. 2.6.31-1-686 > 3. Gnome 2.28.2 > 4. NetworkManager 0.8 > Configuration: > 1. eth0 using a fix ip (192.168.2.2) > 2. wlan0 using a DHCP ifconfig > eth0 Link encap:Ethernet HWaddr 00:11:2f:be:2a:2a > inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0 > inet6 addr: fe80::211:2fff:febe:2a2a/64 Scope:Link > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:157 errors:0 dropped:0 overruns:0 frame:0 > TX packets:821 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:66992 (65.4 KiB) TX bytes:83128 (81.1 KiB) > Interrupt:21 Base address:0xe400 > > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:164 errors:0 dropped:0 overruns:0 frame:0 > TX packets:164 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:13768 (13.4 KiB) TX bytes:13768 (13.4 KiB) > > wlan0 Link encap:Ethernet HWaddr 00:30:f1:f5:6f:cb > inet addr:192.168.1.40 Bcast:192.168.1.255 Mask:255.255.255.0 > inet6 addr: fe80::230:f1ff:fef5:6fcb/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:6673 errors:0 dropped:0 overruns:0 frame:0 > TX packets:6624 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:4617943 (4.4 MiB) TX bytes:1570214 (1.4 MiB) > > wmaster0 Link encap:UNSPEC HWaddr > 00-30-F1-F5-6F-CB-65-74-00-00-00-00-00-00-00-00 > UP RUNNING MTU:0 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > /etc/networks: > # The loopback network interface > auto lo > iface lo inet loopback > > # The primary network interface > allow-hotplug eth0 > iface eth0 inet static > address 192.168.2.2 > netmask 255.255.2550 > /etc/NetworkManager/nm-system-settings.conf > [main] > plugins=ifupdown,keyfile > > no-auto-default=00:11:2f:be:2a:2a, > > [ifupdown] > managed=false > ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: The logic behind user/system settings
On Friday 12 of March 2010 02:51:33 Dan Williams wrote: > On Wed, 2010-03-10 at 07:04 +0300, Andrey Borzenkov wrote: > > On Wednesday 10 of March 2010 04:12:19 Dan Williams wrote: > > > As you've discovered, there are user-specific settings (which are > > > only available when that user is logged in) and system-wide > > > settings (which are available to all users *and* before any user > > > has logged in). The problem you're hitting is when there aren't > > > any settings at all, like right after an install. > > > > > > So NetworkManager creates an internal "Auto " connection that > > > at least allows your system to get online if there are any > > > DHCP-configured ethernet devices on the system. This is a > > > "system-wide" connection and should be available at boot and > > > before login. > > > > Are they created by NM service or nm-connection-editor/nm-applet? > > Should they be present even if other, explicitly defined > > connections exist? > > It is created by NM itself. It's present only if no other /system/ > connections are defined that apply to that device. How NM decides that /system/ connection applies to device? I always see two auto connections for wlan interface - "Auto Wireless" and "Auto $CURRENT_SSID" even though there are system connections with $CURRENT_SSID defined. Wired interface OTOH correctly picks up system connection and does not offer "Auto" one. Thank you! signature.asc Description: This is a digitally signed message part. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Modem Manager gets into a funny state with CDMA modems
Dan,
Novatel U760. The modem appears to be fine (not sure what you mean drop off
the bus. If I reopen the device all is fine). I hacked up my version of
the code (mm-generic-cdma.c) to always call mm_serial_port_open() before
using the file descriptor, and it works great. But I don't think this is a
good solution.
-Jason
diff --git a/src/mm-generic-cdma.c b/src/mm-generic-cdma.c
index 50cd86c..7f44775 100644
--- a/src/mm-generic-cdma.c
+++ b/src/mm-generic-cdma.c
@@ -598,6 +598,10 @@ connect (MMModem *modem,
info = mm_callback_info_new (modem, callback, user_data);
command = g_strconcat ("DT", number, NULL);
+if (!mm_serial_port_open (priv->primary, &info->error)) {
+g_assert (info->error);
+/* TODO(jglasgow): what should we do? */
+}
mm_serial_port_queue_command (priv->primary, command, 90, dial_done,
info);
g_free (command);
}
@@ -620,7 +624,9 @@ disconnect_flash_done (MMSerialPort *port,
MM_MODEM_STATE_REASON_NONE);
}
} else {
-mm_port_set_connected (MM_GENERIC_CDMA_GET_PRIVATE
(info->modem)->data, FALSE);
+MMGenericCdmaPrivate *priv = MM_GENERIC_CDMA_GET_PRIVATE
(info->modem);
+
+mm_port_set_connected (priv->data, FALSE);
update_enabled_state (MM_GENERIC_CDMA (info->modem), FALSE,
MM_MODEM_STATE_REASON_NONE);
}
@@ -753,6 +759,10 @@ get_card_info (MMModem *modem,
port = priv->secondary;
}
+if (!mm_serial_port_open (port, &info->error)) {
+g_assert (info->error);
+/* TODO(jglasgow): what should we do? */
+}
mm_serial_port_queue_command_cached (port, "+GMI", 3,
get_manufacturer_done, info);
mm_serial_port_queue_command_cached (port, "+GMM", 3, get_model_done,
info);
mm_serial_port_queue_command_cached (port, "+GMR", 3, get_version_done,
info);
@@ -867,6 +877,10 @@ get_signal_quality (MMModemCdma *modem,
}
info = mm_callback_info_uint_new (MM_MODEM (modem), callback,
user_data);
+if (!mm_serial_port_open (port, &info->error)) {
+g_assert (info->error);
+/* TODO(jglasgow): what should we do? */
+}
mm_serial_port_queue_command (port, "+CSQ", 3, get_signal_quality_done,
info);
}
@@ -913,6 +927,10 @@ get_esn (MMModemCdma *modem,
}
info = mm_callback_info_string_new (MM_MODEM (modem), callback,
user_data);
+if (!mm_serial_port_open (port, &info->error)) {
+g_assert (info->error);
+/* TODO(jglasgow): what should we do? */
+}
mm_serial_port_queue_command_cached (port, "+GSN", 3, get_string_done,
info);
}
@@ -1136,6 +1154,11 @@ get_serving_system (MMModemCdma *modem,
G_CALLBACK (callback),
user_data);
+if (!mm_serial_port_open (port, &info->error)) {
+g_assert (info->error);
+/* TODO(jglasgow): what should we do? */
+}
+
mm_serial_port_queue_command (port, "+CSS?", 3, serving_system_done,
info);
}
@@ -1380,6 +1403,12 @@ get_registration_state (MMModemCdma *modem,
}
info = mm_generic_cdma_query_reg_state_callback_info_new
(MM_GENERIC_CDMA (modem), callback, user_data);
+
+if (!mm_serial_port_open (port, &info->error)) {
+g_assert (info->error);
+/* TODO(jglasgow): what should we do? */
+}
+
mm_serial_port_queue_command (port, "+CAD?", 3,
get_analog_digital_done, info);
}
On Thu, Mar 11, 2010 at 6:46 PM, Dan Williams wrote:
> On Wed, 2010-03-10 at 18:03 -0500, Jason Glasgow wrote:
> > I've been working with a Novatel Modem on a 2.6.31 kernel using the
> > generic CDMA driver. If I enable the modem via ModemManager and then
> > connect, everything works fine. But if I disconnect the modem using
> > the DBUS API, and shut down ppp, ModemManager gets confused. The
> > internal modem state indicates that the modem is now REGISTERED, but
> > the kernel appears to have sent a hangup (G_IO_HUP) to the usb port,
> > so mm-serial-port.c has closed the port (->fd == -1).
>
> Does the modem crash at that point, or drop off the bus? This may
> indicate a USB driver problem or just a bug in ModemManager. But
> normally with serial ports, when you get a hangup, you're done.
>
> Also, what specific novatel device?
>
> Dan
>
> >
> > Other than Disable(), no command works because the ->fd is now -1.
> >
> >
> > Do you have any thoughts on the best way to fix this? And what the
> > semantics of receiving a HUP on the modem port should be. My thought
> > is that disconnect() should leave the modem in a registered (or
> > enabled) state, and that fp should still be valid.
> > * Might it be reasonable to ignore the G_IO_HUP?
> > * Should we automatically reopen then port for all commands that
> > are issued? Seems like a bad idea.
> > * Should we automatically reopen the port if
> > mm_modem_get_state() > MM_MODEM_STATE_ENABLED?
> > * Maybe the most logical is to ha
Re: Determine connectivity status
Dan Williams wrote, On 03/12/2010 12:35 AM: On Wed, 2010-03-10 at 20:07 +0100, Mads Kiilerich wrote: Mads Kiilerich wrote, On 03/10/2010 02:17 PM: How can an application be made aware of the machines "online/offline" status? I assume there is a fine dbus method/event - but which? Reply to self and archive: It is called State in NM lingo and can be accessed as below. Yup, you found it... Out of curiosity, how easy was it to find out the answer? 7! ;-) In the beginning I wasn't sure how NMs "having a network connection" concept was, how explicit it was and how useful it was. I didn't know what to google for - and you know how most google hits for NM looks like ... "state" could mean so many things. I think I thought it was referring to the daemon itself, not to how successful it had been managing the network. "The overall state of the NetworkManager daemon" is IMHO not exact. Something like "The overall (connectivity) state of the NetworkManager connections" would have helped me more. The documentation in spec-08.html looks nice, but the deep nesting and lots of whitespace makes it easy to get lost. (Minor comment: It would help a bit if method names GetDevices were marked up as code.) Try to search through the page for "state" - there are lots of hits, but they are referring to different kind of states, and it isn't obvious what the context is. Once I know what to look for and code against there were no problem. Especially with the help of d-feet. (D-bus hint: Accept that you _do_ have to repeat yourself all the time ...) /Mads ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
