Managing interface with random MAC address

2009-03-05 Thread Russ Dill
I have an embedded device known as a beagle board that draws power
from my USB port (shows up as usb0). When it boots, it presents itself
as a USB ethernet device. I want to share my connection with the
device from network manager.

Two problems: The first is that network manager sees an unmanaged
device and tries to obtain an IP address, the second, I can't seem to
setup an automatic share my connection connection since every time the
board boots, it has a different hardware address. Any tips?
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: How let the NM set the Hostname which set in DHCPD server?

2009-03-05 Thread Dan Williams
On Wed, 2009-03-04 at 14:51 +0800, Bin Li wrote:
 Hi,
 
  NM support it or not?

Hmm, it appears not to.  That's an oversight.  The hostname doesn't get
from the DHCP handling code to anywhere else.  NM *will* try to do
reverse-address lookup on your IP address if you have not set a
persistent hostname on your machine, though, which may work for you in
the mean time.

Dan


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


Re: NetworkManager auto connect/auto switch policy

2009-03-05 Thread Dan Williams
On Wed, 2009-03-04 at 21:29 +0800, 代尔欣 wrote:
 Hi Dan,
Can you please give me a conceptual description about what is the
 policy of auto connect/switch when more than one network available
 e.g. ethernet wifi(may several)?

All available connections are brought up.  For ethernet, that usually
means when the card indicates it has a carrier.  For wifi, that means
that the card is not rfkilled, and at least one saved AP has been found
in the wifi scan list.  NM will also not automatically activate any
connection where autoconnect has been turned off.

The default route determines where the traffic actually goes; when a
better connection becomes available, NM will switch the default route
to that new connection in one operation, thus the switch is only done
when everything is set up.  When a that better connection goes away,
NM will switch the default route to the next-best connection, if any.

The preference order for better connections is Ethernet  Wifi  3G.

Dan


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


Re: nm_dhcp_manager_handle_event() isn't called on ubuntu7.01

2009-03-05 Thread Dan Williams
On Wed, 2009-03-04 at 22:09 +0800, 代尔欣 wrote:
 Hi Dan,
The NetworkManger-0.7.0 official release, on ubuntu7.01, the signal
 Event can't be sent successfully and nm_dhcp_manager_handle_event()
 isn't called. Then dhcp timeout. But the NetworkManager-0.7.0 r3202
 works fine. Please give suggetsion debug this.
 the log:

Run dbus-monitor --system.  Do you see the Event signal emitted when
the DHCP lease is bound?

This seems like a D-Bus permissions problem; the official release's
D-Bus permission files won't work out-of-the-box on Debian-based
distributions because Debian/Ubuntu use a different mechanism to
restrict permissions that other distros like Fedora and SUSE do.  The
best thing there is to copy the dbus permission files from the Ubuntu
8.10 packages and use those instead.

(mbiebl/asac: can we finally get those upstream so stuff has a chance of
working out of the box?)

Dan


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


Re: Where and how to install D02HW in ConnectionManager?

2009-03-05 Thread Dan Williams
On Thu, 2009-03-05 at 16:33 +0900, Jacobs Shannon wrote:
 Okay, here's the scoop. With the information contained in the
 previously cited URL, I was able to make ConnectionManager work.
 Again:
 
  http://d.hatena.ne.jp/munetoh/20081121
 
 I'll be continuing with the next phase of my testing after I move
 the machine to the other network, but I want to try to describe what
 I did to get it working, and ask what I am supposed to do now to
 help propagate the solution to other people who may be having the
 same problem. (Also, I hope this comment will document things when
 the next normal update zaps part of my current solution.)
 
 First, I modified the 10-model.fdi file with the IS-707-A. I did
 this manually with gedit, and in a later iteration I commented out
 the two previously existing command sets for this device.

Interesting, so it's actually a CDMA part.  0.7.1 should handle this a
lot better because it probes the card instead of using the (often
incorrect) static mappings in 10-modem.fdi.

 Back in ConnectionManager, I was trying to use a modified version of
 the old Mobile Broadband connection that I had created earlier, but
 this didn't seem to work. Instead, I started messing around with a
 new CDMA entry that had appeared. I gave it the dialing string
 *99***1# and em as the user name. Somewhere around here it was
 bouncing me around in the Gnome keyring manager, which I thought I
 had disabled, but I used em as the password, and it bought that on
 the second or third pass.

Try #777 as the number instead; that's the normal CDMA dialup number.

Dan


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


Re: Segment fault when using wireless (adhoc mode)

2009-03-05 Thread Dan Williams
On Thu, 2009-03-05 at 15:10 +0800, 陈杰 wrote:
 Hi Dan,
 I've tried NM-0.7.1-rc3, and got a log about this problem (see
 attachment: adhoc_crash.log), maybe it will be helpful.
 BTW, this adhoc_crash.log contains some log entries printed by the
 code in the attachment debug.patch.

Good info, I'll take a look at this today.

dan


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


Re: Managing interface with random MAC address

2009-03-05 Thread Dan Williams
On Thu, 2009-03-05 at 01:25 -0700, Russ Dill wrote:
 I have an embedded device known as a beagle board that draws power
 from my USB port (shows up as usb0). When it boots, it presents itself
 as a USB ethernet device. I want to share my connection with the
 device from network manager.
 
 Two problems: The first is that network manager sees an unmanaged
 device and tries to obtain an IP address, the second, I can't seem to
 setup an automatic share my connection connection since every time the
 board boots, it has a different hardware address. Any tips?

What is the USB serial number of the device?  The core problem here is
that if there's no unique identifier for the device, there's no way to
lock a specific connection to that device, and thus any generic Wired
connection will be used instead.

Run lsusb -v and look for the iSerial field; is that field something
other than 0?  Do other beagle boards present other serial numbers?

Do you want to keep the wired device unmanaged and ignored by
NetworkManager?  You said sees an unmanaged device and tries to obtain
an IP address, but NM should be ignoring unmanaged devices.  However,
that mechanism depends on HAL UDIs and thus the random MAC address may
well be confusing it.

Dan


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


RE: Secrets D-Bus Interface

2009-03-05 Thread Dan Williams
On Tue, 2009-03-03 at 17:13 -0500, Philip A. Culver wrote:
 I can do the same on my desktop.  The target system has a custom UI and no
 connection editor other then the one coded into our product UI.  It is very
 bizarre for me.  All other fields get saved.  I set wep-key2 to the key and
 set the wep-tx-keyidx to 2 as well and only the wep-key2 gets saved in the
 file.  
 
 Does the nm-system-settings daemon have a debug mode that will log more
 messages? 

Not specifically, but you could certainly add some debugging
information.  For example, you'd want to do something like:

diff --git a/system-settings/plugins/keyfile/nm-keyfile-connection.c 
b/system-settings/plugins/keyfile/nm-keyfile-connection.c
index 9d9427b..ae0dc51 100644
--- a/system-settings/plugins/keyfile/nm-keyfile-connection.c
+++ b/system-settings/plugins/keyfile/nm-keyfile-connection.c
@@ -72,6 +72,18 @@ update (NMExportedConnection *exported,
NMKeyfileConnectionPrivate *priv = NM_KEYFILE_CONNECTION_GET_PRIVATE 
(exported);
gboolean success;
 
+{
+NMConnection *foo;
+GError *foo_error = NULL;
+foo = nm_connection_new_from_hash (new_settings, foo_error);
+if (!foo) {
+   g_message (%s: error creating new connection from hash: %s, 
+  __func__, foo_error  foo_error-message ? 
foo_error-message : (unknown));
+} else
+   nm_connection_dump (foo);
+g_object_unref (foo);
+}
+
success = NM_EXPORTED_CONNECTION_CLASS 
(nm_keyfile_connection_parent_class)-update (exported, new_settings, error);
if (success) {
NMConnection *connection;

That will dump out *exactly* what your tool is sending to the system
settings service.  I'm quite interested to hear if that helps figure out
what the problem is, and if so, what the issue was.

Dan

 Phil
 
 -Original Message-
 From: Dan Williams [mailto:d...@redhat.com] 
 Sent: Tuesday, March 03, 2009 4:11 PM
 To: Philip A. Culver
 Cc: networkmanager-list@gnome.org
 Subject: RE: Secrets D-Bus Interface
 
 On Tue, 2009-03-03 at 14:51 -0500, Philip A. Culver wrote:
  Hi,
  
  I have tracked my issue down a little further.  It seems my problem is
 more
  on the Update side then retrieval.  I pass down a settings block and
  everything except wep-tx-keyidx is saved to the file in system-settings.
  wep-tx-keyidx is still 0 in the file.  Could you point me where in the
 code
  this is handled so I can verify I am passing everything correctly.  No
  errors are thrown the value just isn't committed.  At this point I am
  assuming I am missing some subtlety in the DBus API.
 
 Hmm, I just used the connection editor to save a system connection with
 WEP index 3 and did get the expected wep-tx-keyidx=2 in my keyfile
 connection.  Just to try to narrow down the issue, could you try to
 create a system connection using the connection editor and set the wep
 index to something other than the default, save the keyfile, and see
 what you get?
 
 Dan
 
  Thanks,
  Phil
  
  -Original Message-
  From: Dan Williams [mailto:d...@redhat.com] 
  Sent: Thursday, February 26, 2009 7:06 PM
  To: Philip A. Culver
  Cc: networkmanager-list@gnome.org
  Subject: RE: Secrets D-Bus Interface
  
  On Thu, 2009-02-26 at 18:51 -0500, Philip A. Culver wrote:
   Hi Dan,
   
   I call Connection.GetSettings to get the map of settings.  The
   wep-tx-keyidx value is not in the 802-11-wireless-security submap.
 This
   is being called from a process running as root.
  
  Is the key index is the 'default' value (ie, 0) it won't necessarily
  show up in the dict because default values don't.  If the key index in
  the keyfile is either 1, 2, or 3, then I'd expect it to show up, and not
  showing up in the GetSettings response would be a bug.
  
  Dan
  
   I will double check in the morning that I am setting the value properly
  when
   creating the connection.  I do see the entry in the file created by the
   keyfile plugin in the system-settings directory.
   
   Thanks,
   Phil 
   
   
   -Original Message-
   From: Dan Williams [mailto:d...@redhat.com] 
   Sent: Thursday, February 26, 2009 11:14 AM
   To: Philip Culver
   Cc: networkmanager-list@gnome.org
   Subject: Re: Secrets D-Bus Interface
   
   On Wed, 2009-02-25 at 16:42 -0500, Philip Culver wrote:
Hi,

I was hoping someone here could help me out.  I need to obtain the
currently configured WEP Key Index for a system connection stored via
the keyfile plugin.   This setting doesn't come with the normal
Connection properties so I assume I need to query the Secrets
 interface
to do so.   I am not sure what values I need to pass for the
setting_name and hints parameters to retrieve this value.  I have
 tried
a few different combinations without success.
   
   The WEP key index (wep-tx-keyidx) should come through with the rest of
   the connection settings, as long as it's set in the connection.  Is that
   not what you're seeing?
   
   Dan
   
   
  
 


NetworkManager 0.7.1 rc2 release

2009-03-05 Thread Dan Williams
Hi,

I've tagged and uploaded  the 0.7.1-rc3 release, with the version number
0.7.0.99.  I expect this to be the last release candidate.  Given that,
I'd like to see heavy testing of modem detection since better detection
is a large feature of 0.7.1.

The tarballs can be found in the usual places:

http://ftp.gnome.org/pub/gnome/sources/NetworkManager/0.7/
http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.7/
http://ftp.gnome.org/pub/gnome/sources/NetworkManager-vpnc/0.7/
http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openvpn/0.7/
http://ftp.gnome.org/pub/gnome/sources/NetworkManager-pptp/0.7/
http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openconnect/0.7/

Dan


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


Re: Managing interface with random MAC address

2009-03-05 Thread Kay Sievers
On Thu, Mar 5, 2009 at 13:33, Dan Williams d...@redhat.com wrote:
 On Thu, 2009-03-05 at 01:25 -0700, Russ Dill wrote:
 I have an embedded device known as a beagle board that draws power
 from my USB port (shows up as usb0). When it boots, it presents itself
 as a USB ethernet device. I want to share my connection with the
 device from network manager.

 Two problems: The first is that network manager sees an unmanaged
 device and tries to obtain an IP address, the second, I can't seem to
 setup an automatic share my connection connection since every time the
 board boots, it has a different hardware address. Any tips?

 What is the USB serial number of the device?  The core problem here is
 that if there's no unique identifier for the device, there's no way to
 lock a specific connection to that device, and thus any generic Wired
 connection will be used instead.

 Run lsusb -v and look for the iSerial field; is that field something
 other than 0?  Do other beagle boards present other serial numbers?

 Do you want to keep the wired device unmanaged and ignored by
 NetworkManager?  You said sees an unmanaged device and tries to obtain
 an IP address, but NM should be ignoring unmanaged devices.  However,
 that mechanism depends on HAL UDIs and thus the random MAC address may
 well be confusing it.

A random MAC address is defined by a bit in the MAC address itself.
Maybe these devices should be special handled. At least the MAC should
not be stored somewhere on the system.

The udev persistent netif name rule generator does this:
  # do not use locally administered MAC address
  ENV{MATCHADDR}==?[2367abef]:*, ENV{MATCHADDR}=

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


Re: Managing interface with random MAC address

2009-03-05 Thread Dan Williams
On Thu, 2009-03-05 at 14:53 +0100, Kay Sievers wrote:
 On Thu, Mar 5, 2009 at 13:33, Dan Williams d...@redhat.com wrote:
  On Thu, 2009-03-05 at 01:25 -0700, Russ Dill wrote:
  I have an embedded device known as a beagle board that draws power
  from my USB port (shows up as usb0). When it boots, it presents itself
  as a USB ethernet device. I want to share my connection with the
  device from network manager.
 
  Two problems: The first is that network manager sees an unmanaged
  device and tries to obtain an IP address, the second, I can't seem to
  setup an automatic share my connection connection since every time the
  board boots, it has a different hardware address. Any tips?
 
  What is the USB serial number of the device?  The core problem here is
  that if there's no unique identifier for the device, there's no way to
  lock a specific connection to that device, and thus any generic Wired
  connection will be used instead.
 
  Run lsusb -v and look for the iSerial field; is that field something
  other than 0?  Do other beagle boards present other serial numbers?
 
  Do you want to keep the wired device unmanaged and ignored by
  NetworkManager?  You said sees an unmanaged device and tries to obtain
  an IP address, but NM should be ignoring unmanaged devices.  However,
  that mechanism depends on HAL UDIs and thus the random MAC address may
  well be confusing it.
 
 A random MAC address is defined by a bit in the MAC address itself.
 Maybe these devices should be special handled. At least the MAC should
 not be stored somewhere on the system.
 
 The udev persistent netif name rule generator does this:
   # do not use locally administered MAC address
   ENV{MATCHADDR}==?[2367abef]:*, ENV{MATCHADDR}=

So if not using a MAC address, how does one uniquely identify the
device?  Say I want to tie a connection to a specific device; it's
certainly not possible with udev interface rename rules unless udev uses
some magic UUID I don't know about...  If you plug two of these into a
system, is it simply up to kernel subsystem probing which of these
devices gets eth0 and which gets eth1?

Dan

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


Re: NetworkManager 0.7.1 rc*3* release

2009-03-05 Thread Dan Williams
And I really mean rc*3*, not rc2.  Yay.

Dan

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


Re: Automatic (DHCP) addresses only doesn't work

2009-03-05 Thread Dan Williams
On Thu, 2009-03-05 at 07:49 -0500, Dan Williams wrote:
 On Tue, 2009-03-03 at 10:58 -0500, Neal Becker wrote:
  Fedora F10
  NetworkManager-0.7.0-1.git20090102.fc10.x86_64
  
  I set eth0 (Auto Ethernet) to Automatic (DHCP) addresses, because I need to 
  set the search list.  I set Search Domains to: md.hnsnet, md.hns.com, 
  hns.com
 
 Hmm, I'll check that out...  seems wrong.

I cannot reproduce this issue with 0.7.1-rc3 (0.7.0.99); mind checking
with that version when it hits Fedora updates?

Dan

 dan
 
  Here is the resulting resolv.conf:
   cat /etc/resolv.conf
  # Generated by NetworkManager
  domain md.hnsnet
  search md.hnsnet
  nameserver 139.85.52.104
  nameserver 139.85.52.102
  nameserver 139.85.87.105
  # NOTE: the libc resolver may not support more than 3 nameservers.
  # The nameservers listed below may not be recognized.
  nameserver 139.85.176.102
  
  
  ___
  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

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


Re: Segment fault when using wireless (adhoc mode)

2009-03-05 Thread Dan Williams
On Thu, 2009-03-05 at 15:10 +0800, 陈杰 wrote:
 Hi Dan,
 I've tried NM-0.7.1-rc3, and got a log about this problem (see
 attachment: adhoc_crash.log), maybe it will be helpful.
 BTW, this adhoc_crash.log contains some log entries printed by the
 code in the attachment debug.patch.

So the real question here is not about refcounting, but why Stage 5
keeps getting started.  If you see in your logs, you'll see multiple
connection success messages when there should only be one:

NetworkManager: info  Activation (wlan0/wireless) Stage 2 of 5 (Device
Configure) successful.  Connected to wireless network 'qicq'.

These cause multiple schedules of the rest of the activation process,
which clearly shouldn't happen.  It looks like the root cause is that
the supplicant is sending reconnect events too fast for NM to handle; if
stage3 is already scheduled, NM shouldn't schedule it again, it should
simply ignore the event.  Any chance you could get some timing
information to see how long it is between calls of
supplicant_iface_connection_state_cb_handler() ?

Dan


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


Re: Managing interface with random MAC address

2009-03-05 Thread Kay Sievers
On Thu, Mar 5, 2009 at 15:48, Dan Williams d...@redhat.com wrote:
 On Thu, 2009-03-05 at 14:53 +0100, Kay Sievers wrote:
 On Thu, Mar 5, 2009 at 13:33, Dan Williams d...@redhat.com wrote:
  On Thu, 2009-03-05 at 01:25 -0700, Russ Dill wrote:
  I have an embedded device known as a beagle board that draws power
  from my USB port (shows up as usb0). When it boots, it presents itself
  as a USB ethernet device. I want to share my connection with the
  device from network manager.
 
  Two problems: The first is that network manager sees an unmanaged
  device and tries to obtain an IP address, the second, I can't seem to
  setup an automatic share my connection connection since every time the
  board boots, it has a different hardware address. Any tips?
 
  What is the USB serial number of the device?  The core problem here is
  that if there's no unique identifier for the device, there's no way to
  lock a specific connection to that device, and thus any generic Wired
  connection will be used instead.
 
  Run lsusb -v and look for the iSerial field; is that field something
  other than 0?  Do other beagle boards present other serial numbers?
 
  Do you want to keep the wired device unmanaged and ignored by
  NetworkManager?  You said sees an unmanaged device and tries to obtain
  an IP address, but NM should be ignoring unmanaged devices.  However,
  that mechanism depends on HAL UDIs and thus the random MAC address may
  well be confusing it.

 A random MAC address is defined by a bit in the MAC address itself.
 Maybe these devices should be special handled. At least the MAC should
 not be stored somewhere on the system.

 The udev persistent netif name rule generator does this:
   # do not use locally administered MAC address
   ENV{MATCHADDR}==?[2367abef]:*, ENV{MATCHADDR}=

 So if not using a MAC address, how does one uniquely identify the
 device?  Say I want to tie a connection to a specific device; it's
 certainly not possible with udev interface rename rules unless udev uses
 some magic UUID I don't know about...

Right, we currently depend on the MAC address, the type (netif
type), the dev_id (managed by the driver for multiple instances),
and handle only devices attached to a bus, virtual interfaces are
ignored.

Some subsystems like IBM's S390 use random MAC addresses, but have
special udev rules to manage persistent names based on properties of
the underlying bus.

 If you plug two of these into a
 system, is it simply up to kernel subsystem probing which of these
 devices gets eth0 and which gets eth1?

Yes, devices with random MAC addresses and without specific rules to
handle them, get random interface names. There is today no solution to
make them work properly with a stored system configuration. People
could write custom udev rules to accomplish persistent names, but that
does not happen automatically.

It's a network device specific problem, because you can only have a
single name for a device. Unlike device nodes, where we have a bunch
of symlinks to identify a device, and can choose the type of link
depending on the problem to solve. For serial devices we have
something like:

  $ tree /dev/serial/
  /dev/serial/
  |-- by-id
  |   |-- usb-067b_2303-if00-port0 - ../../ttyUSB0
  |   |-- usb-FTDI_FT232R_USB_UART_A7005uBP-if00-port0 - ../../ttyUSB5
  |   |-- usb-HUAWEI_Technology_HUAWEI_Mobile-if00-port0 - ../../ttyUSB3
  |   |-- usb-HUAWEI_Technology_HUAWEI_Mobile-if01-port0 - ../../ttyUSB4
  |   |-- usb-Palm_Computing__Inc._USB_Serial_Adaptor_00088798-if00-port0
- ../../ttyUSB1
  |   `-- usb-Palm_Computing__Inc._USB_Serial_Adaptor_00088798-if00-port1
- ../../ttyUSB2
  `-- by-path
  |-- pci-:00:1d.0-usb-0:1:1.0-port0 - ../../ttyUSB1
  |-- pci-:00:1d.0-usb-0:1:1.0-port1 - ../../ttyUSB2
  |-- pci-:00:1d.7-usb-0:2.2:1.0-port0 - ../../ttyUSB3
  |-- pci-:00:1d.7-usb-0:2.2:1.1-port0 - ../../ttyUSB4
  |-- pci-:00:1d.7-usb-0:2.3:1.0-port0 - ../../ttyUSB5
  `-- pci-:00:1d.7-usb-0:2.4.2:1.0-port0 - ../../ttyUSB0

where we can choose between the by-path which changes with the port
the device is plugged in, but handles multiple identical devices, and
the by-id which is independent of the port, but can not handle
completely identical devices.

Both are useful and can not replace the other type. For network
interfaces, we have only a single name, and therefore all these
problems, which can not be solved properly with the current network
interface infrastructure.

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


Re: Managing interface with random MAC address

2009-03-05 Thread Russ Dill
On Thu, Mar 5, 2009 at 5:33 AM, Dan Williams d...@redhat.com wrote:
 On Thu, 2009-03-05 at 01:25 -0700, Russ Dill wrote:
 I have an embedded device known as a beagle board that draws power
 from my USB port (shows up as usb0). When it boots, it presents itself
 as a USB ethernet device. I want to share my connection with the
 device from network manager.

 Two problems: The first is that network manager sees an unmanaged
 device and tries to obtain an IP address, the second, I can't seem to
 setup an automatic share my connection connection since every time the
 board boots, it has a different hardware address. Any tips?

 What is the USB serial number of the device?  The core problem here is
 that if there's no unique identifier for the device, there's no way to
 lock a specific connection to that device, and thus any generic Wired
 connection will be used instead.

 Run lsusb -v and look for the iSerial field; is that field something
 other than 0?  Do other beagle boards present other serial numbers?

The serial number is zero. The unique identifier is that its usb0.

 Do you want to keep the wired device unmanaged and ignored by
 NetworkManager?  You said sees an unmanaged device and tries to obtain
 an IP address, but NM should be ignoring unmanaged devices.  However,
 that mechanism depends on HAL UDIs and thus the random MAC address may
 well be confusing it.

I may have got my managed/unmanaged terminology confused. Right now,
NetworkManager handles all devices not listed int
/etc/network/interfaces. I have two wired devices, one is my permanent
eth0. eth0 I want nm to manage. The other is the beagle board.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Managing interface with random MAC address

2009-03-05 Thread Russ Dill
On Thu, Mar 5, 2009 at 6:53 AM, Kay Sievers kay.siev...@vrfy.org wrote:
 On Thu, Mar 5, 2009 at 13:33, Dan Williams d...@redhat.com wrote:
 On Thu, 2009-03-05 at 01:25 -0700, Russ Dill wrote:
 I have an embedded device known as a beagle board that draws power
 from my USB port (shows up as usb0). When it boots, it presents itself
 as a USB ethernet device. I want to share my connection with the
 device from network manager.

 Two problems: The first is that network manager sees an unmanaged
 device and tries to obtain an IP address, the second, I can't seem to
 setup an automatic share my connection connection since every time the
 board boots, it has a different hardware address. Any tips?

 What is the USB serial number of the device?  The core problem here is
 that if there's no unique identifier for the device, there's no way to
 lock a specific connection to that device, and thus any generic Wired
 connection will be used instead.

 Run lsusb -v and look for the iSerial field; is that field something
 other than 0?  Do other beagle boards present other serial numbers?

 Do you want to keep the wired device unmanaged and ignored by
 NetworkManager?  You said sees an unmanaged device and tries to obtain
 an IP address, but NM should be ignoring unmanaged devices.  However,
 that mechanism depends on HAL UDIs and thus the random MAC address may
 well be confusing it.

 A random MAC address is defined by a bit in the MAC address itself.
 Maybe these devices should be special handled. At least the MAC should
 not be stored somewhere on the system.

 The udev persistent netif name rule generator does this:
  # do not use locally administered MAC address
  ENV{MATCHADDR}==?[2367abef]:*, ENV{MATCHADDR}=


Yes, the MAC address always has that bit set and so the udev
persistent netif name rule generator doesn't touch it.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Managing interface with random MAC address

2009-03-05 Thread Robert Piasek
On Thursday 05 March 2009 19:47:28 Russ Dill wrote:
 On Thu, Mar 5, 2009 at 5:33 AM, Dan Williams d...@redhat.com wrote:
  On Thu, 2009-03-05 at 01:25 -0700, Russ Dill wrote:
  I have an embedded device known as a beagle board that draws power
  from my USB port (shows up as usb0). When it boots, it presents itself
  as a USB ethernet device. I want to share my connection with the
  device from network manager.

As far as I'm aware it's using ethernet gadget to provide network interface.

If that's the case - you can modprobe device with parameters like:
modprobe g_ether host_addr=01:23:45:67:89:ab dev_addr=00:11:22:33:44:55:66
(substitute with your desired mac address)

if you have it compiled in, you can use add this to your command line:
g_ether.host_addr=01:23:45:67:89:ab g_ether.dev_addr=00:11:22:33:44:55:66

That was both ends will always have static IP addresses. You can also add 
second part to u-boot env.


Regards,
Rob


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: Managing interface with random MAC address

2009-03-05 Thread Dan Williams
On Thu, 2009-03-05 at 12:47 -0700, Russ Dill wrote:
 On Thu, Mar 5, 2009 at 5:33 AM, Dan Williams d...@redhat.com wrote:
  On Thu, 2009-03-05 at 01:25 -0700, Russ Dill wrote:
  I have an embedded device known as a beagle board that draws power
  from my USB port (shows up as usb0). When it boots, it presents itself
  as a USB ethernet device. I want to share my connection with the
  device from network manager.
 
  Two problems: The first is that network manager sees an unmanaged
  device and tries to obtain an IP address, the second, I can't seem to
  setup an automatic share my connection connection since every time the
  board boots, it has a different hardware address. Any tips?
 
  What is the USB serial number of the device?  The core problem here is
  that if there's no unique identifier for the device, there's no way to
  lock a specific connection to that device, and thus any generic Wired
  connection will be used instead.
 
  Run lsusb -v and look for the iSerial field; is that field something
  other than 0?  Do other beagle boards present other serial numbers?
 
 The serial number is zero. The unique identifier is that its usb0.

And there's the problem.  It won't always be usb0.  If you have two, it
could be usb1.  Thus there isn't any unique identifier.

Dan

  Do you want to keep the wired device unmanaged and ignored by
  NetworkManager?  You said sees an unmanaged device and tries to obtain
  an IP address, but NM should be ignoring unmanaged devices.  However,
  that mechanism depends on HAL UDIs and thus the random MAC address may
  well be confusing it.
 
 I may have got my managed/unmanaged terminology confused. Right now,
 NetworkManager handles all devices not listed int
 /etc/network/interfaces. I have two wired devices, one is my permanent
 eth0. eth0 I want nm to manage. The other is the beagle board.

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


Re: Managing interface with random MAC address

2009-03-05 Thread Russ Dill
On Thu, Mar 5, 2009 at 2:19 PM, Dan Williams d...@redhat.com wrote:
 On Thu, 2009-03-05 at 12:47 -0700, Russ Dill wrote:
 On Thu, Mar 5, 2009 at 5:33 AM, Dan Williams d...@redhat.com wrote:
  On Thu, 2009-03-05 at 01:25 -0700, Russ Dill wrote:
  I have an embedded device known as a beagle board that draws power
  from my USB port (shows up as usb0). When it boots, it presents itself
  as a USB ethernet device. I want to share my connection with the
  device from network manager.
 
  Two problems: The first is that network manager sees an unmanaged
  device and tries to obtain an IP address, the second, I can't seem to
  setup an automatic share my connection connection since every time the
  board boots, it has a different hardware address. Any tips?
 
  What is the USB serial number of the device?  The core problem here is
  that if there's no unique identifier for the device, there's no way to
  lock a specific connection to that device, and thus any generic Wired
  connection will be used instead.
 
  Run lsusb -v and look for the iSerial field; is that field something
  other than 0?  Do other beagle boards present other serial numbers?

 The serial number is zero. The unique identifier is that its usb0.

 And there's the problem.  It won't always be usb0.  If you have two, it
 could be usb1.  Thus there isn't any unique identifier.

In my situation, I don't care. Currently, if I want this to work, I
have to change the hardware address in the network manager settings
every single time I reboot the board. The limitation of only being
able to plug in one at a time seems rather minor to me.

 Dan

  Do you want to keep the wired device unmanaged and ignored by
  NetworkManager?  You said sees an unmanaged device and tries to obtain
  an IP address, but NM should be ignoring unmanaged devices.  However,
  that mechanism depends on HAL UDIs and thus the random MAC address may
  well be confusing it.

 I may have got my managed/unmanaged terminology confused. Right now,
 NetworkManager handles all devices not listed int
 /etc/network/interfaces. I have two wired devices, one is my permanent
 eth0. eth0 I want nm to manage. The other is the beagle board.


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


Re: Managing interface with random MAC address

2009-03-05 Thread Kay Sievers
On Thu, Mar 5, 2009 at 22:38, Russ Dill russ.d...@gmail.com wrote:
 On Thu, Mar 5, 2009 at 2:19 PM, Dan Williams d...@redhat.com wrote:
 On Thu, 2009-03-05 at 12:47 -0700, Russ Dill wrote:
 On Thu, Mar 5, 2009 at 5:33 AM, Dan Williams d...@redhat.com wrote:
  On Thu, 2009-03-05 at 01:25 -0700, Russ Dill wrote:
  I have an embedded device known as a beagle board that draws power
  from my USB port (shows up as usb0). When it boots, it presents itself
  as a USB ethernet device. I want to share my connection with the
  device from network manager.
 
  Two problems: The first is that network manager sees an unmanaged
  device and tries to obtain an IP address, the second, I can't seem to
  setup an automatic share my connection connection since every time the
  board boots, it has a different hardware address. Any tips?
 
  What is the USB serial number of the device?  The core problem here is
  that if there's no unique identifier for the device, there's no way to
  lock a specific connection to that device, and thus any generic Wired
  connection will be used instead.
 
  Run lsusb -v and look for the iSerial field; is that field something
  other than 0?  Do other beagle boards present other serial numbers?

 The serial number is zero. The unique identifier is that its usb0.

 And there's the problem.  It won't always be usb0.  If you have two, it
 could be usb1.  Thus there isn't any unique identifier.

 In my situation, I don't care. Currently, if I want this to work, I
 have to change the hardware address in the network manager settings
 every single time I reboot the board. The limitation of only being
 able to plug in one at a time seems rather minor to me.

  Do you want to keep the wired device unmanaged and ignored by
  NetworkManager?  You said sees an unmanaged device and tries to obtain
  an IP address, but NM should be ignoring unmanaged devices.  However,
  that mechanism depends on HAL UDIs and thus the random MAC address may
  well be confusing it.

 I may have got my managed/unmanaged terminology confused. Right now,
 NetworkManager handles all devices not listed int
 /etc/network/interfaces. I have two wired devices, one is my permanent
 eth0. eth0 I want nm to manage. The other is the beagle board.

Just to throw more stuff into the config matched by MAC address
thing, there are systems where several interfaces have the same MAC
address, some para-virtualized environments create two identical
interfaces, which are only different in the bus they belong to, and
stuff like the PlayStation3 creates wired and wireless interfaces with
the same MAC address. I've run into all that with the udev persistent
net interface rule-generator. :)

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


Re: Accessing previously freed data.

2009-03-05 Thread Drew Moseley
Dan Williams wrote:
 I looked over the code there again, and it's correct AFAICT.
 g_slist_delete_link() in the sync_devices() function should be doing
 what its intended to do; it removes one link from the linked list
 priv-devices and frees the link.  It doesn't free the data of course,
 but that should get correctly unref-ed right below.  And after that, the
 device should no longer be in priv-devices at all.  That doesn't mean
 there isn't a refcounting bug, but I'm still not quite sure what's
 causing the invalid access later on...

Hi Dan,

Looks like the issue is that the delete_link call is incorrect since the node 
being passed in is from the copy of the list.  The patch below addresses this 
by building the new list by adding the items that exist and then deleting the 
old list.

Thoughts?

Drew


diff --git a/src/nm-manager.c b/src/nm-manager.c
index 30660f1..9a8c1e8 100644
--- a/src/nm-manager.c
+++ b/src/nm-manager.c
@@ -1479,12 +1479,11 @@ static void
 sync_devices (NMManager *self)
 {
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
-   GSList *devices;
+   GSList *devices = NULL;
GSList *iter;
 
/* Remove devices which are no longer known to HAL */
-   devices = g_slist_copy (priv-devices);
-   for (iter = devices; iter; iter = iter-next) {
+   for (iter = priv-devices; iter; iter = iter-next) {
NMDevice *device = NM_DEVICE (iter-data);
const char *udi = nm_device_get_udi (device);
 
@@ -1493,13 +1492,14 @@ sync_devices (NMManager *self)
nm_device_set_managed (device, TRUE, 
NM_DEVICE_STATE_REASON_NOW_MANAGED);
else
nm_device_set_managed (device, FALSE, 
NM_DEVICE_STATE_REASON_NOW_UNMANAGED);
+   devices = g_slist_prepend(devices, device);
} else {
-   priv-devices = g_slist_delete_link (priv-devices, 
iter);
remove_one_device (self, device);
}
}
 
-   g_slist_free (devices);
+   g_slist_free (priv-devices);
+   priv-devices = devices;
 
/* Get any new ones */
nm_hal_manager_query_devices (priv-hal_mgr);

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


Re: Where and how to install D02HW in ConnectionManager?

2009-03-05 Thread Jacobs Shannon
Whoops. Sorry I got confused about the name of NetworkManager again.
That's my problem with generic names that have synonyms... Easy to
switch words.

My understanding is that the D02HW is not really a proper CDMA, but
somehow this is required by the way eMobile has configured their
network in Japan. I did initially attempt to use the #777 number,
but that didn't work.

Now I am stuck on the connection sharing part. It seems that I must
install and configure the dhcp-server now. I was hoping that
NetworkManager would handle that automatically when I said I wanted
to share the wired network side. The dhcp-server conf file is pretty
hairy to mess with. I'm not even sure I copied the correct stub file
into the correct directory... Can you (or anyone else) point me at a
good URL for doing this with the current version of Ubuntu? I spent
some time on it last night, but didn't make much progress. That
included searching in the archives of this mailing list.

 Date: Thu, 05 Mar 2009 07:28:54 -0500
 From: Dan Williams d...@redhat.com
 
 On Thu, 2009-03-05 at 16:33 +0900, Jacobs Shannon wrote:
  Okay, here's the scoop. With the information contained in
 the
  previously cited URL, I was able to make ConnectionManager
 work.
  Again:
  
   http://d.hatena.ne.jp/munetoh/20081121
  
  I'll be continuing with the next phase of my testing after I
 move
  the machine to the other network, but I want to try to
 describe what
  I did to get it working, and ask what I am supposed to do
 now to
  help propagate the solution to other people who may be
 having the
  same problem. (Also, I hope this comment will document
 things when
  the next normal update zaps part of my current solution.)
  
  First, I modified the 10-model.fdi file with the IS-707-A. I
 did
  this manually with gedit, and in a later iteration I
 commented out
  the two previously existing command sets for this device.
 
 Interesting, so it's actually a CDMA part.  0.7.1 should
 handle this a
 lot better because it probes the card instead of using the
 (often
 incorrect) static mappings in 10-modem.fdi.
 
  Back in ConnectionManager, I was trying to use a modified
 version of
  the old Mobile Broadband connection that I had created
 earlier, but
  this didn't seem to work. Instead, I started messing around
 with a
  new CDMA entry that had appeared. I gave it the dialing
 string
  *99***1# and em as the user name. Somewhere around here it
 was
  bouncing me around in the Gnome keyring manager, which I
 thought I
  had disabled, but I used em as the password, and it bought
 that on
  the second or third pass.
 
 Try #777 as the number instead; that's the normal CDMA dialup
 number.
 
 Dan


--
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list