Re: Issues with iPhone tethering after phone disconnect
On 03/10/2010 04:31 PM, Valent Turkovic wrote: How can I troubleshoot this to go further? Any idea what other packages should I downgrade? Cheers! This is definitely now Linux/Fedora/NetworkManager/Bluez issue, because I booted into Windows, paired laptop and iPhone and DHCP fails even there. This is definitely issue with Jailbroken iPhones. If you have one non-Jailbroken phone test this, but I believe this is the case... Its not a jailbreak issue. I had this problem on my phone before the jailbreak. Its an OSX issue. There might be some way to work around it in bluez, but I suspect Apple will be required for a fix. I should be clear that the problem I see in F13 is *not* related to the Apple bug. Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Issues with iPhone tethering after phone disconnect
On 03/10/2010 03:06 PM, Valent Turkovic wrote: On Wed, Mar 10, 2010 at 8:51 PM, Nathaniel McCallum wrote: On 03/10/2010 02:44 PM, Valent Turkovic wrote: The only way I've found to fix this is to turn off bluetooth on the iPhone and then turn it back on. 1. Go to: Settings ->General ->Bluetooth 2. Flip the Bluetooth switch off 3. Count to 5 4. Flip it back on Rebooting the phone does *not* work. This is either an iPhone bug or bluez is doing something funky to put the iPhone bluetooth daemon in a weird state. Nathaniel I'm also having this issue. Has anybody resolved this issue? I had bluetooth working on Fedora 12 with iPhone in December 2009 so I guess some of updates since them broke something. Any suggestions? Cheers! I had the same problems with F12 in December. In fact, I've always had the problem. I think the bug is actually an iphone bug, but is triggered by bluez. Cross your fingers that it will be fixed in iphone OS 4.0. Nathaniel I have windows on my business laptop (HP Mini 5101) and tested it there under windows and iPhone sees it immediately, reboot to Fedora 12 and iPhone doesn't see it :( I checked that laptop has enabled discovery under bluetooth settings. Tried downgrading gnome-bluetooth* packages and rebooting still same issue :( What packages can I try do downgrade also? I saw reports that some users have issue with bluetooth pairing and tethering with jailbroken iPhones... but why does it work with Windows?!? Maybe to downgrade NetworkManager packages? Actually, I'm running the latest NM from F13 and my tethering appears not to work at all. I think its hanging on carrier detection. If I run dhclient in a terminal, I get an IP immediately, but NM just keeps circling Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Issues with iPhone tethering after phone disconnect
On 03/10/2010 02:44 PM, Valent Turkovic wrote: The only way I've found to fix this is to turn off bluetooth on the iPhone and then turn it back on. 1. Go to: Settings -> General -> Bluetooth 2. Flip the Bluetooth switch off 3. Count to 5 4. Flip it back on Rebooting the phone does *not* work. This is either an iPhone bug or bluez is doing something funky to put the iPhone bluetooth daemon in a weird state. Nathaniel I'm also having this issue. Has anybody resolved this issue? I had bluetooth working on Fedora 12 with iPhone in December 2009 so I guess some of updates since them broke something. Any suggestions? Cheers! I had the same problems with F12 in December. In fact, I've always had the problem. I think the bug is actually an iphone bug, but is triggered by bluez. Cross your fingers that it will be fixed in iphone OS 4.0. Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP client ID not sent
On 02/13/2010 11:29 AM, Neal Becker wrote: Dan Williams wrote: On Fri, 2010-02-12 at 15:14 -0500, Nathaniel McCallum wrote: On 02/12/2010 03:05 PM, Dan Williams wrote: On Wed, 2010-02-10 at 14:44 -0500, Nathaniel McCallum wrote: In the connection editor, under IPv4 Settings I can specify a "DCHP client ID." I assumed that this ID would be sent to the DHCP server. Except it isn't. Is this a bug or a feature? NetworkManager-0.7.997-2.git20091214.fc12.x86_64 What you get in /var/run/nm-dhclient-ethX.conf during the DHCP request? That's where whatever is in the dhclient field should end up. It's there: send dhcp-client-identifier "myDHCPId"; # added by NetworkManager The dhcp server is dnsmasq, and sets up dns entries for the dhcp client id. It works for all my windows and mac systems. But none of my Linux systems work (all NM). My router (which runs dnsmasq) also shows a list of dhcp clients and their ids. Again, win/mac work but NM doesn't. What else should I check? Wireshark, to ensure that the client ID gets sent out on the wire. If it's in the config file, then that's where NM's sphere of influence stops (besides ensuring that NM gives the client the right config file, but that's easy enough to check for in /var/log/messages since NM prints out the command-line it's running dhclient with). Next, wireshark on the server to ensure that the DHCP request comes through correctly with the client ID. If it does, then dnsmasq is doing something badly... Dan Did you want DHCP_CLIENT_ID, or maybe you wanted DHCP_HOSTNAME? The latter is what I need (and nm doesn't seem to support) I want whichever one will make dnsmasq do the right thing and assign a dns entry for the device. Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP client ID not sent
On 02/12/2010 03:05 PM, Dan Williams wrote: On Wed, 2010-02-10 at 14:44 -0500, Nathaniel McCallum wrote: In the connection editor, under IPv4 Settings I can specify a "DCHP client ID." I assumed that this ID would be sent to the DHCP server. Except it isn't. Is this a bug or a feature? NetworkManager-0.7.997-2.git20091214.fc12.x86_64 What you get in /var/run/nm-dhclient-ethX.conf during the DHCP request? That's where whatever is in the dhclient field should end up. It's there: send dhcp-client-identifier "myDHCPId"; # added by NetworkManager The dhcp server is dnsmasq, and sets up dns entries for the dhcp client id. It works for all my windows and mac systems. But none of my Linux systems work (all NM). My router (which runs dnsmasq) also shows a list of dhcp clients and their ids. Again, win/mac work but NM doesn't. What else should I check? Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
DHCP client ID not sent
In the connection editor, under IPv4 Settings I can specify a "DCHP client ID." I assumed that this ID would be sent to the DHCP server. Except it isn't. Is this a bug or a feature? NetworkManager-0.7.997-2.git20091214.fc12.x86_64 Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Issues with iPhone tethering after phone disconnect
On 01/20/2010 12:55 AM, Dan Williams wrote: On Tue, 2010-01-12 at 20:35 +0100, Jonathan Petersson wrote: Actually my bad, I did find some logs: Jan 12 20:31:38 jpetersson2-desktop bluetoothd[3960]: Connection refused (111) Jan 12 20:31:38 jpetersson2-desktop NetworkManager: nm_device_bt_connect_cb(): Error connecting with bluez: Connection refused (111) Yeah, seems bluetooth related. You could try to remove the pairing in gnome-bluetooth and create it again? Or did this just magically go away? The only way I've found to fix this is to turn off bluetooth on the iPhone and then turn it back on. 1. Go to: Settings -> General -> Bluetooth 2. Flip the Bluetooth switch off 3. Count to 5 4. Flip it back on Rebooting the phone does *not* work. This is either an iPhone bug or bluez is doing something funky to put the iPhone bluetooth daemon in a weird state. Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Bluetooth support
I've been working on it up until recently. The main wall that I've hit is that NMDevice assumes that the "device" (whatever that means; in bluetooth land, its not so clear) lifecycle is greater than the NMDevice lifecycle and that the device exists in HAL. I've not really found a way around that, but perhaps dcbw would like to comment... Nathaniel On Tue, Dec 23, 2008 at 9:33 AM, Yosef Akhtman wrote: > Hi > > I'd love to help with the implementation of the GPRS over Bluetooth in NM. > Is it an active project and is there any way I could contribute at the > moment? > I have it working using manual configuration on > Ubuntu 8.10 > bluez-utils 4.12 > Samsung D500 phone on a prepaid Vodaphone service in UK > > All the best, > Jos > > On Wed, 2008-12-10 at 10:45 +1100, Mikel Ward wrote: > > Hi > > > > I'd love to be able to have GPRS over Bluetooth work, even if it > > required properly configuring /etc/bluetooth/rfcomm.conf at first > > (it's the manual PPP stuff I hate). > > We've got a plan, and BT is a top work item for NM 0.8, which I'll try > to detail soon on this list. It won't involve any mucking with > rfcomm.conf since all that can be done automatically with the Bluez > D-Bus interface. It may require a fairly recent version of Bluez though > (like 3.29 or later). > > > Is there any way I can help? > > We'll need testing at some point, of course. At the moment though, > we're in the planning stages. What distro are you running and what > version of the bluez-utils packages do you have? > > Dan > > ___ > 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: openvpn plugin http-proxy support patch
Tomas Kovacik wrote: Hi, this is my first code after 8 years, I hope it's ok . Basically it's only copy/paste :). Proxy auth is not implemented yet. Perhaps this is a good time to bring back up libproxy (http://code.google.com/p/libproxy/) and talk about how to think about proxy configuration, evaluation and authentication more systematically? Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Rawhide OpenVPN is Broken
Dan Williams wrote: On Wed, 2008-09-10 at 13:10 -0400, Nathaniel McCallum wrote: Current OpenVPN plugin doesn't work at all on rawhide. Rawhide's openvpn requires the '--script-security' option to run external scripts. However, even with adding that option, you still get this failure: --script-security got added upstream here late last week so it'll roll out soon for Rawhide. Any chance you could kill any existing nm-openvpn-service, then (as root): gdb /usr/libexec/nm-openvpn-service and then try to activate the VPN connection, then when gdb drops back to the (gdb) prompt, enter bt and paste the backtrace in here? Also, valgrind gives me this: ==2378== Invalid free() / delete / delete[] ==2378==at 0x4A0609F: free (vg_replace_malloc.c:323) ==2378==by 0x3508212D4A: g_ptr_array_foreach (garray.c:627) ==2378==by 0x40274F: (within /usr/libexec/nm-openvpn-service) ==2378==by 0x402C91: (within /usr/libexec/nm-openvpn-service) ==2378==by 0x36FD602BF6: impl_vpn_plugin_connect (nm-vpn-plugin.c:306) ==2378==by 0x36FD603E5B: dbus_glib_marshal_nm_vpn_plugin_BOOLEAN__BOXED_POINTER (nm-vpn-plugin-glue.h:95) ==2378==by 0x350620C887: gobject_message_function (dbus-gobject.c:1282) ==2378==by 0x3505A1C550: _dbus_object_tree_dispatch_and_unlock (dbus-object-tree.c:856) ==2378==by 0x3505A0EFC5: dbus_connection_dispatch (dbus-connection.c:4447) ==2378==by 0x3506209764: message_queue_dispatch (dbus-gmain.c:101) ==2378==by 0x350823772A: g_main_context_dispatch (gmain.c:2142) ==2378==by 0x350823AF0C: g_main_context_iterate (gmain.c:2775) ==2378== Address 0x403d2b is not stack'd, malloc'd or (recently) free'd ** Message: openvpn started with pid 2387 ** (process:2378): WARNING **: openvpn_watch_cb(): openvpn exited with error code 1 ==2378== ==2378== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 4 from 1) ==2378== malloc/free: in use at exit: 78,873 bytes in 748 blocks. ==2378== malloc/free: 1,812 allocs, 1,066 frees, 546,109 bytes allocated. ==2378== For counts of detected errors, rerun with: -v ==2378== searching for pointers to 748 not-freed blocks. ==2378== checked 371,536 bytes. ==2378== ==2378== LEAK SUMMARY: ==2378==definitely lost: 0 bytes in 0 blocks. ==2378== possibly lost: 5,616 bytes in 25 blocks. ==2378==still reachable: 73,257 bytes in 723 blocks. ==2378== suppressed: 0 bytes in 0 blocks. ==2378== Rerun with --leak-check=full to see details of leaked memory. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Rawhide OpenVPN is Broken
Dan Williams wrote: On Wed, 2008-09-10 at 13:10 -0400, Nathaniel McCallum wrote: Current OpenVPN plugin doesn't work at all on rawhide. Rawhide's openvpn requires the '--script-security' option to run external scripts. However, even with adding that option, you still get this failure: --script-security got added upstream here late last week so it'll roll out soon for Rawhide. Any chance you could kill any existing nm-openvpn-service, then (as root): gdb /usr/libexec/nm-openvpn-service and then try to activate the VPN connection, then when gdb drops back to the (gdb) prompt, enter bt and paste the backtrace in here? Here's the backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00350667c513 in __libc_free (mem=) at malloc.c:3614 3614 ar_ptr = arena_for_chunk(p); (gdb) bt #0 0x00350667c513 in __libc_free (mem=) at malloc.c:3614 #1 0x003508212d4b in IA__g_ptr_array_foreach (array=optimized out>, func=, user_data=out>) at garray.c:627 #2 0x00402750 in g_file_test () at gfileutils.c:184 #3 0x00402c92 in g_file_test () at gfileutils.c:184 #4 0x0036fd602bf7 in nm_vpn_plugin_connect () at nm-vpn-plugin.c:306 #5 impl_vpn_plugin_connect (plugin=, properties=, error=) at nm-vpn-plugin.c:354 #6 0x0036fd603e5c in dbus_glib_marshal_nm_vpn_plugin_BOOLEAN__BOXED_POINTER (closure=optimized out>, return_value=, n_param_values=, param_values=out>, invocation_hint=, marshal_data=optimized out>) at nm-vpn-plugin-glue.h:95 #7 0x00350620c888 in invoke_object_method () at dbus-gobject.c:1282 #8 gobject_message_function (connection=, message=, user_data=) at dbus-gobject.c:1424 #9 0x003505a1c551 in _dbus_object_tree_dispatch_and_unlock (tree=, message=) at dbus-object-tree.c:856 #10 0x003505a0efc6 in dbus_connection_dispatch (connection=optimized out>) at dbus-connection.c:4447 #11 0x003506209765 in message_queue_dispatch (source=optimized out>, callback=, user_data=optimized out>) at dbus-gmain.c:101 #12 0x00350823772b in g_main_dispatch () at gmain.c:2142 #13 IA__g_main_context_dispatch (context=) at gmain.c:2694 #14 0x00350823af0d in g_main_context_iterate (context=optimized out>, block=, dispatch=out>, self=) at gmain.c:2775 #15 0x00350823b43d in IA__g_main_loop_run (loop=out>) at gmain.c:2983 #16 0x0040201b in g_file_test () at gfileutils.c:184 #17 0x00350661e566 in __libc_start_main (main=, argc=, ubp_av=, init=, fini=, rtld_fini=, stack_end=Could not find the frame base for "__libc_start_main". ) at libc-start.c:220 ---Type to continue, or q to quit--- #18 0x00401e09 in g_file_test () at gfileutils.c:184 #19 0x7fffe788 in ?? () #20 0x001c in ?? () #21 0x0001 in ?? () #22 0x7fffe9a5 in ?? () #23 0x in ?? () ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Rawhide OpenVPN is Broken
Current OpenVPN plugin doesn't work at all on rawhide. Rawhide's openvpn requires the '--script-security' option to run external scripts. However, even with adding that option, you still get this failure: NetworkManager: VPN plugin state changed: 3 NetworkManager: vpn_service_watch_cb(): VPN service 'org.freedesktop.NetworkManager.openvpn' died with signal 11 NetworkManager: connection_state_changed(): The name org.freedesktop.NetworkManager.openvpn was not provided by any .service files NetworkManager: VPN service 'org.freedesktop.NetworkManager.openvpn' disappeared, cancelling connections ** (process:25696): WARNING **: send_ip4_config(): Could not send failure information: The name org.freedesktop.NetworkManager.openvpn was not provided by any .service files ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Broken OpenVPN
Dan Williams wrote: On Fri, 2008-08-01 at 17:46 -0400, Nathaniel McCallum wrote: So I upgraded to the stuff in F9 updates-testing and it broke NM-OpenVPN. Particularly, the problem is routing. Routing before the upgrade: $ route -n | grep tun 10.254.0.1 10.254.0.9 255.255.255.255 UGH 0 0 0 tun0 10.254.0.9 0.0.0.0 255.255.255.255 UH0 0 0 tun0 Routing after the upgrade: $ route -n | grep tun 10.254.0.1 10.254.0.9 255.255.255.255 UGH 0 0 0 tun0 10.254.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 What ends up breaking here? Do you just want traffic to 10.254.0.9 to go out over tun0 and everything else (including all other 10.254.0.x/24) to still go out over the local network? Also, what does the openvpn server config look like? The only difference between the two dumps above should be that in the second, all 10.254.0.0/24 traffic goes out over the tunnel now. Sorry, I think I pasted the wrong thing before. Routing before the upgrade: $ route -n | grep tun0 10.254.0.5 0.0.0.0 255.255.255.255 UH0 00 tun0 10.254.0.1 10.254.0.5 255.255.255.255 UGH 0 00 tun0 10.175.211.010.254.0.5 255.255.255.0 UG0 00 tun0 Routing after the upgrade: $ route -n | grep tun0 10.254.0.1 10.254.0.5 255.255.255.255 UGH 0 00 tun0 10.254.0.0 0.0.0.0 255.255.255.0 U 0 00 tun0 You can see that after the update the route to 10.175.211.0/24 is gone. Using openvpn directly from the CLI, I get the same results as pre-upgrade. So apparently the new NM is dropping the 10.175.211.0/24 advertised route somewhere (I've not manually configured this route anywhere)... There is also another bug I've found. When going into the new VPN connection editing interface, and to IPv4 Settings I can add static routes. If I add a static route, when I make the connection, the gateways are always "0.0.0.0" regardless of what is in the Gateway field. Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: wha is ipv4 prefix?? (why not netmask)
Derek Atkins wrote: Miguel Angel Cañedo <[EMAIL PROTECTED]> writes: I was pulling my hair trying to set static ipv4 settings. Until I realized that NM 0.7 asks for PREFIX instead of NETMASK Now, my netmask should be 255.255.0.0 How do I transalte that into the Prefix? /16 ? I also thought the wording was less-than-clear. Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Broken OpenVPN
So I upgraded to the stuff in F9 updates-testing and it broke NM-OpenVPN. Particularly, the problem is routing. Routing before the upgrade: $ route -n | grep tun 10.254.0.1 10.254.0.9 255.255.255.255 UGH 0 00 tun0 10.254.0.9 0.0.0.0 255.255.255.255 UH0 00 tun0 Routing after the upgrade: $ route -n | grep tun 10.254.0.1 10.254.0.9 255.255.255.255 UGH 0 00 tun0 10.254.0.0 0.0.0.0 255.255.255.0 U 0 00 tun0 Interface info: $ ifconfig tun0 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.254.0.10 P-t-P:10.254.0.9 Mask:255.255.255.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:19 errors:0 dropped:0 overruns:0 frame:0 TX packets:171 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:2643 (2.5 KiB) TX bytes:11045 (10.7 KiB) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Fixing NetworkManager-openvpn
Short story: stock plugin doesn't work for me and here's a patch that makes it work. Long story: There are two issues. 1. When attempting to set the direction on the --tls-auth option, the direction should only be set if it is a non-empty string. This is trivial and can be merged right away. 2. Why does NM set --ns-cert-type? Won't this just break half of the VPN's out there whose admins didn't set up a server cert. Does it *really* matter? Patch is attached. Nathaniel nm-openvpn.patch Description: Binary data ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager and Browser Proxy
The real solution is libproxy, but libproxy is new and most programs have not adopted it yet... http://code.google.com/p/libproxy/ On Sat, Jun 14, 2008 at 9:01 AM, van Schelve <[EMAIL PROTECTED]> wrote: > Hello List. > > Does someone know if it is possible to change the Proxy Settings for > Mozilla or other applications when the Network interface gets up? > I think it must have to go with the NetworkManagerDispatcher but > I have currently no Idea how to do it. > > Best regards. > ___ > 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: PATCH: Support for Bluetooth NAP devices
If we aren't periodically scanning for bluetooth devices than I assume we will NEVER autoconnect... Is that the intention? So for the UI, we'd have something like VPNs? If that is correct, can you point me to where I need to start in the code? On Tue, May 13, 2008 at 10:13 PM, Dan Williams <[EMAIL PROTECTED]> wrote: > On Tue, 2008-05-13 at 21:09 -0400, Nathaniel McCallum wrote: > > So what is the right way to scan for devices and determine what > > features they support? How is that handled in balance with battery > > life? > > We don't scan with Bluetooth automatically. We should scan when > initially setting up the DUN or PAN or NAP connection (or in the > connection editor when modifying the connection), because that's the > user hitting a "Scan" button explicitly to find the device they want to > connect to. But NM should not be scanning for BT devices like it does > for wifi APs. > > Battery life won't really be affected since if the user is dumb enough > to keep hitting the "Scan" button in the connection editor when editing > a connection, they get the battery life they deserve :) > > Basically, when setting up the connection, there should be an entry for > the BT address of the thing you want to connect to on the other side (be > it a phone or a remote NAP or whatever). You can either type in the BT > MAC there, or there should be a little "scan" button next to the entry > that brings up a list of BT devices that are in range and advertise the > right profiles, just like the current Gnome BT applet allows you to look > for devices that support OBEX. > > For things like BT which require heavier-weight initial configuration, > you won't be able to just connect to something from the applet menu > until you've set up the connection manually. We can try to streamline > that setup process as much as possible though, and punt really advanced > stuff to the connection editor. > > Dan > > > > > On Tue, May 13, 2008 at 7:38 PM, Marcel Holtmann <[EMAIL PROTECTED]> wrote: > > > Hi Dan, > > > > > > > > > > > Unfortunately, I left my cell phone at home. I'll have to provide > > > > > lshal output later. However, I don't really think it is necessary. > > > > > > > > > > An Access Point is to wifi what a NAP (Network Access Point) is to > bluetooth. > > > > > > > > Right; where does the NAP get defined? > > > > > > the Bluetooth network service has the definition. You can use D-Bus to > > > retrieve the list of configured access point. > > > > > > Remember that Bluetooth has a 1:N mapping for host controller to access > > > points. You can connect to multiple access points at the same time using > > > the same Bluetooth radio. > > > > > > > > > > > The major differences is that for wifi the interface (ex. wlan0) > > > > > pre-exists the wireless connection, while for bluetooth the > interface > > > > > (bnep0) has the same lifecycle as the wireless connection. Once the > > > > > connection is established via Bluez (bnep), the pseudo-Ethernet > > > > > interface is created. If the connection is torn down, the interface > > > > > disappears. While the interface exists, it is treated exactly like > a > > > > > normal Ethernet interface. > > > > > > > > NM should be taking care of telling BlueZ to establish the bnep > device; > > > > that's the issue here and why the patch you posted isn't a complete > > > > solution. > > > > > > Using the Bluetooth network service you simply call Connect() via D-Bus > > > on the access point path. > > > > > > The BlueZ source contains a file network-api.txt with the API > > > description of the network service. > > > > > > > > > > It's the same thing with DUN: NM needs to control the whole lifecycle > of > > > > the rfcomm connection. I don't want to have to set the thing up first > > > > in BlueZ, and then in NetworkManager. You might have to pair the > device > > > > with BlueZ, but that's fine. > > > > > > > > NM connections should contain enough information to tell BlueZ what to > > > > do with the device. You plug in your device, and NM recognizes that > has > > > > a connection for that device. NM te
Re: PATCH: Support for Bluetooth NAP devices
So what is the right way to scan for devices and determine what features they support? How is that handled in balance with battery life? On Tue, May 13, 2008 at 7:38 PM, Marcel Holtmann <[EMAIL PROTECTED]> wrote: > Hi Dan, > > > > > Unfortunately, I left my cell phone at home. I'll have to provide > > > lshal output later. However, I don't really think it is necessary. > > > > > > An Access Point is to wifi what a NAP (Network Access Point) is to > bluetooth. > > > > Right; where does the NAP get defined? > > the Bluetooth network service has the definition. You can use D-Bus to > retrieve the list of configured access point. > > Remember that Bluetooth has a 1:N mapping for host controller to access > points. You can connect to multiple access points at the same time using > the same Bluetooth radio. > > > > > The major differences is that for wifi the interface (ex. wlan0) > > > pre-exists the wireless connection, while for bluetooth the interface > > > (bnep0) has the same lifecycle as the wireless connection. Once the > > > connection is established via Bluez (bnep), the pseudo-Ethernet > > > interface is created. If the connection is torn down, the interface > > > disappears. While the interface exists, it is treated exactly like a > > > normal Ethernet interface. > > > > NM should be taking care of telling BlueZ to establish the bnep device; > > that's the issue here and why the patch you posted isn't a complete > > solution. > > Using the Bluetooth network service you simply call Connect() via D-Bus > on the access point path. > > The BlueZ source contains a file network-api.txt with the API > description of the network service. > > > > It's the same thing with DUN: NM needs to control the whole lifecycle of > > the rfcomm connection. I don't want to have to set the thing up first > > in BlueZ, and then in NetworkManager. You might have to pair the device > > with BlueZ, but that's fine. > > > > NM connections should contain enough information to tell BlueZ what to > > do with the device. You plug in your device, and NM recognizes that has > > a connection for that device. NM tells BlueZ to create the bnep > > interface, and then NM connects with the bnep interface. > > > > For DUN, NM show all the DUN connections you have defined, when you have > > a BT adapter plugged in. When you chose one of those connections from > > the menu, NM will request BlueZ connect to the phone defined in that > > connection, and get something to create the rfcomm device, which it will > > then hand to pppd for the PPP connection. > > You can use the Bluetooth serial service for creating this RFCOMM > device. Check serial-api.txt document from the BlueZ source. > > > > > I hope this makes sense. Ideally, NM should treat each bluetooth > > > adapter (hci) as an "interface" (even though there is no interface) > > > and have NAP presence detection (similar to scanning for wifi APs). > > > > NM should treat the adapter as a top-level device, just like wifi, cdma, > > gsm, and ethernet devices are treated. When you want to connect via a > > NAP (or when NM autoconnects as such) then NM should instruct BlueZ to > > make the BT bits happen, and NM will handle the rest (layer 3 and > > above). > > > > > However, this is non-trivial, and may not even be desirable. However, > > > with this trivial patch, NetworkManager can work with these devices > > > NOW, it just requires that the connection be established outside of NM > > > (via bluez pand or the bluez network service). > > > > Unfortunately, I'd like to fix this correctly, because if you don't, you > > either have to break API later or carry around the functionality people > > expect. Bastien Nocera is working on bringing up DUN support which > > we'll use as the driver use-case for BT devices. > > > > Any interest in expanding the patch to treat hci devices as top-level > > objects? I think we can hash out some of the details if you are. > > Actually using the HCI top-level device is the only right way of doing > this. That is also your entry point into the network and serial service. > > Regards > > Marcel > > > ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PATCH: Support for Bluetooth NAP devices
On Tue, May 13, 2008 at 4:11 PM, Dan Williams <[EMAIL PROTECTED]> wrote: > On Sat, 2008-05-10 at 14:42 -0700, Nathaniel McCallum wrote: > > Bluetooth NAP devices are pretty simple really. You connect and (at > > least in Linux) they emulate an ethernet device. > > Can you send me the lshal output for when you've got one of these > devices plugged in? > > Also, what sets up the device? How do you pair it? When you plug it > in, do you need to do any additional setup on the device before it has a > bnepX interface? Unfortunately, I left my cell phone at home. I'll have to provide lshal output later. However, I don't really think it is necessary. An Access Point is to wifi what a NAP (Network Access Point) is to bluetooth. The major differences is that for wifi the interface (ex. wlan0) pre-exists the wireless connection, while for bluetooth the interface (bnep0) has the same lifecycle as the wireless connection. Once the connection is established via Bluez (bnep), the pseudo-Ethernet interface is created. If the connection is torn down, the interface disappears. While the interface exists, it is treated exactly like a normal Ethernet interface. When the bnep interface is created, HAL creates two new objects. HAL does NOT report this as an ethernet device because, in reality, it isn't. So instead of 'net.80203' occurring in both the info.capability and info.category keys, 'net.bluetooth' appears. HAL also does not report the driver because in every case this type of device will use the bnep module. So my patch basically tells NetworkManager: assume 'net.bluetooth' == 'net.80203'. The FDI file makes HAL report the driver name (which will ALWAYS be 'bnep' on this type of device). This FDI should not be in upstream HAL because it is really specific to NM's usage of HAL. I'll leave it up to you to determine if NM's behaviour in this regard is correct. If it is correct, than the FDI file will need to be installed with NM. If it is not correct, then fix NM and the FDI file can be ignored. I hope this makes sense. Ideally, NM should treat each bluetooth adapter (hci) as an "interface" (even though there is no interface) and have NAP presence detection (similar to scanning for wifi APs). However, this is non-trivial, and may not even be desirable. However, with this trivial patch, NetworkManager can work with these devices NOW, it just requires that the connection be established outside of NM (via bluez pand or the bluez network service). Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PATCH: Support for Bluetooth NAP devices
On Sat, May 10, 2008 at 5:42 PM, Nathaniel McCallum <[EMAIL PROTECTED]> wrote: > Bluetooth NAP devices are pretty simple really. You connect and (at > least in Linux) they emulate an ethernet device. > > However, NetworkManager doesn't work with these devices because HAL > gives them the capability and category of "net.bluetooth". Attached > are a patch and a HAL fdi file. To connect to a Bluetooth NAP device > on Linux, do: > pand -n -c $BSSID -d NAP > > With the attached patch/fdi file, NetworkManager will automatically > pick up the device and use it when connected. > > Questions? Comments? Can this be committed? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PATCH: Support for Bluetooth NAP devices
On Sat, May 10, 2008 at 3:33 PM, Marcel Holtmann <[EMAIL PROTECTED]> wrote:
> Hi Nathaniel,
>
>> Bluetooth NAP devices are pretty simple really. You connect and (at
>> least in Linux) they emulate an ethernet device.
>>
>> However, NetworkManager doesn't work with these devices because HAL
>> gives them the capability and category of "net.bluetooth". Attached
>> are a patch and a HAL fdi file. To connect to a Bluetooth NAP device
>> on Linux, do:
>> pand -n -c $BSSID -d NAP
>
> the pand program is deprecated btw. You should look into the Bluetooth
> network service.
Doesn't the bluetooth network service use the bnep kernel module?
Is the bnep kernel module deprecated?
>> With the attached patch/fdi file, NetworkManager will automatically
>> pick up the device and use it when connected.
>
> What is the FDI file for? I don't see its need, because HAL already
> perfectly classifies the bnepX interfaces.
from src/nm-hal-manager.c:
static char *
nm_get_device_driver_name (LibHalContext *ctx, const char *udi)
{
char *origdev_udi;
char *driver_name = NULL;
origdev_udi = libhal_device_get_property_string (ctx, udi,
"net.originating_device", NULL);
if (!origdev_udi) {
/* Older HAL uses 'physical_device' */
origdev_udi = libhal_device_get_property_string (ctx,
udi, "net.physical_device", NULL);
}
if (origdev_udi && libhal_device_property_exists (ctx,
origdev_udi, "info.linux.driver", NULL)) {
char *drv = libhal_device_get_property_string (ctx,
origdev_udi, "info.linux.driver", NULL);
driver_name = g_strdup (drv);
libhal_free_string (drv);
}
libhal_free_string (origdev_udi);
return driver_name;
}
...
# device fails to create if driver doesn't exist
driver = nm_get_device_driver_name (priv->hal_ctx, udi);
device = (GObject *) nm_device_802_3_ethernet_new (udi, iface, driver, managed);
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
PATCH: Support for Bluetooth NAP devices
Bluetooth NAP devices are pretty simple really. You connect and (at least in Linux) they emulate an ethernet device. However, NetworkManager doesn't work with these devices because HAL gives them the capability and category of "net.bluetooth". Attached are a patch and a HAL fdi file. To connect to a Bluetooth NAP device on Linux, do: pand -n -c $BSSID -d NAP With the attached patch/fdi file, NetworkManager will automatically pick up the device and use it when connected. Questions? Comments? Nathaniel NetworkManager-0.7.0-bluetooth-nap.patch Description: Binary data 20-bluetooth-nap.fdi Description: Binary data ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Patches for PPTP plugin
The stateless MPPE patch was committed a while back. On 6/4/07, Craig Box <[EMAIL PROTECTED]> wrote: Hi, There are a number of patches on the GNOME bugzilla for the PPTP VPN component currently, including three easy ones for HIGification of the dialog boxes and one for fixing a memory leak. Could these please be committed to SVN? I am happy to rebase the patches for stateless MPPE and PAP authentication against the new HIGified dialog if required. Regards, Craig ___ 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: keyring manager
On Thu, 2007-03-15 at 14:16 +, Jon Escombe wrote: > If you just want to avoid entering the password after logon, you could also > look at pam_keyring which will silently give it the logon password.. Which doesn't work if you are using a non-password based login technique (key, fingerprint, etc). Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
org.freedesktop.NetworkManager.getActiveDevice() ?
What happened to the org.freedesktop.NetworkManager.getActiveDevice() method describe here: http://people.redhat.com/dcbw/NetworkManager/NetworkManager%20DBUS%20API.txt ? What is the best way to get the current active device? Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
gnome-proxy and NM
As some of you may have seen, I announced
( http://mail.gnome.org/archives/desktop-devel-list/2007-January/msg00390.html
) a proof of concept for proxy configuration. This is of course just a proof
of concept and not an actual release. Currently, gnome-proxy makes heavy use
of gconf. However, with NM moving away from gconf, I thought I would write to
see if there is any interest in having similar functionality in NM itself.
This functionality would be limited to:
1. Proxy autoconfiguration (PAC)
2. PAC autodetection (WPAD)
3. Per-network proxy settings
4. GUI to configure per-network proxy settings (optional)
Though I'm not sure if some of this may go against the "no-profiles"
design goal of NetworkManager, it should generally JustWork. Here are
some use cases:
John is a consultant. Each time he arrives at a different firm, he has
to configure using their local proxy settings. Most of these sites are
WPAD enabled. He wishes that when he plugged in or connected via Wifi
that his computer would JustWork.
John occasionally has a client FooCorp who has a proxy but doesn't
support WPAD. Each time he connects to the client's Wifi, he has to
manually adjust his proxy settings. He wishes that he could specify
"use proxy.foo.com as the proxy for the FooCorp wireless network" and
that every time he connected to that network, it would setup the proxy
for him.
John has a client BarCo whose WPAD enabled wireless network has a stale
PAC that returns a bogus proxy server. He wishes he could say "Ignore
the PAC on the BarCo wireless network."
Some outline of the current design is in order. libwpad
http://code.google.com/p/wpad/ does all the heavy WPAD/PAC lifting.
Everything else is pretty much just a matter of per-network settings.
PAC requires that the PAC script be run for each URL requested, so a
D-Bus method to do this is probably in order (see
org.gnome.Proxy.getProxy(url) in gnome-proxy). That method would
probably return a struct like:
{
char *pac_url; // The URL of the discovered PAC (if any)
int cacheability; // 0 = no cache, 1 = cache for this protocol, etc
char *proxy_host; // The host of the proxy to use (if any)
int proxy_port; // The port of the proxy to use
int proxy_type; // 0 = http, 1 = socks, etc
}
Anyway, I look forward to hearing your comments.
Nathaniel
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
What does ndiswrapper need? (WAS: NetworkManager FC5 -- No WEP key)
I filed a bug for ndiswrapper to fully support WEXT-18 (https://sourceforge.net/tracker/index.php?func=detail&aid=1459522&group_id=93482&atid=604450). However, the maintainer is not aware of any area where it is lacking. What is actually needed from ndiswrapper to get it working out of the box with NM >= 0.6? Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager FC5 -- No WEP key
On Mon, 2006-03-27 at 12:10 -0500, Dan Williams wrote: > On Mon, 2006-03-27 at 09:09 -0500, Nathaniel McCallum wrote: > > On Sat, 2006-03-25 at 20:58 -0500, Darren Albers wrote: > > > ***Stupid gmail has the default reply back to the sender! Grr*** > > > > > > This is what I think he is refering to, > > > http://mail.gnome.org/archives/networkmanager-list/2006-March/msg00068.html > > > but I think (And I could be wrong) that this is only for WPA support > > > on the listed chipsets and I also think that this patch might already > > > be in the FC5 package.. > > > > > > There was a lot of "I think's" in that above statement so maybe Robert > > > or Dan can pop in? ;-) > > > > I was able to get it working with the patch. The patch it not a part of > > the FC5 rpms, but should be (at least a build option). I know the patch > > isn't desired in upstream. But if so, then NM shouldn't lie and say > > that ndiswrapper (etc) is "fully-supported": > > > > wlan0: Device is fully-supported using driver > > 'ndiswrapper'. > > > > Perhaps a "wlan0: Device 'ndiswrapper' is not supported due to lack of > > WEXT compliance" message would be better. > > Likely you're right... file a bug on gnome.org for it? Done: http://bugzilla.gnome.org/show_bug.cgi?id=336221 Any chance of getting the workaround patch in the next NM package for FC5? This would at least give ndiswrapper, etc a chance to get their act together without punishing the end users (ie. make it clear the patch isn't going upstream and won't exist in FC6/RHEL5). Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager FC5 -- No WEP key
On Sat, 2006-03-25 at 20:58 -0500, Darren Albers wrote: > ***Stupid gmail has the default reply back to the sender! Grr*** > > This is what I think he is refering to, > http://mail.gnome.org/archives/networkmanager-list/2006-March/msg00068.html > but I think (And I could be wrong) that this is only for WPA support > on the listed chipsets and I also think that this patch might already > be in the FC5 package.. > > There was a lot of "I think's" in that above statement so maybe Robert > or Dan can pop in? ;-) I was able to get it working with the patch. The patch it not a part of the FC5 rpms, but should be (at least a build option). I know the patch isn't desired in upstream. But if so, then NM shouldn't lie and say that ndiswrapper (etc) is "fully-supported": wlan0: Device is fully-supported using driver 'ndiswrapper'. Perhaps a "wlan0: Device 'ndiswrapper' is not supported due to lack of WEXT compliance" message would be better. Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager FC5 -- No WEP key
On Sat, 2006-03-25 at 23:39 +0100, [EMAIL PROTECTED] wrote: > See Robert Love's wireless driver work around. > A question, why you don't use gentoo? ;) Gentoo isn't an approved distro for our work computers. I'm not sure where I should look for Robert's workaround... Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager FC5 -- No WEP key
I'm running NM on FC5 with ndiswrapper and when I try to connect to an AP it won't connect. Doing it manually via iwconfig/dhclient works fine. Steps to reproduce: * Select an encrypted AP (I haven't tried unencrypted) * Get prompted for a WEP Key * Attempts to connect, but fails Upon further investigation: * While monitoring with iwconfig, the essid/etc is set, but not the key * Setting the key with iwconfig during connection makes connection work * ... though the key gets unset after a period of time * setting the key in a loop with a pause allows me to keep connection * The key *is* saved in the keyring. It worked under FC4 and Ubuntu, but seems to have broken with NM 0.6. The log of a failed session is attached. Nathaniel NetworkManager:starting... NetworkManager:wlan0: Device is fully-supported using driver 'ndiswrapper'. NetworkManager:nm_device_init(): waiting for device's worker thread to start NetworkManager:nm_device_init(): device's worker thread started, continuing. NetworkManager:Now managing wireless (802.11) device 'wlan0'. NetworkManager:Deactivating device wlan0. NetworkManager:eth0: Device is fully-supported using driver 'tg3'. NetworkManager:nm_device_init(): waiting for device's worker thread to start NetworkManager:nm_device_init(): device's worker thread started, continuing. NetworkManager:Now managing wired Ethernet (802.3) device 'eth0'. NetworkManager:Deactivating device eth0. NetworkManager:Updating allowed wireless network lists. NetworkManager: nm_dbus_get_networks_cb (): nm-dbus-nmi.c:527 (nm_dbus_get_networks_cb): error received: org.freedesktop.NetworkManagerInfo.NoNetworks - There are no wireless networks stored.. NetworkManager: [1143320539.372729] nm_device_802_11_wireless_get_activation_ap (): Forcing AP 'Welles' NetworkManager:User Switch: /org/freedesktop/NetworkManager/Devices/wlan0 / Welles NetworkManager:Deactivating device wlan0. NetworkManager:Device wlan0 activation scheduled... NetworkManager:Activation (wlan0) started... NetworkManager:Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager:Activation (wlan0) Stage 1 of 5 (Device Prepare) started... NetworkManager:Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... NetworkManager:Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. NetworkManager:Activation (wlan0) Stage 2 of 5 (Device Configure) starting... NetworkManager:Activation (wlan0/wireless): access point 'Welles' is encrypted, but NO valid key exists. New key needed. NetworkManager:Activation (wlan0) New wireless user key requested for network 'Welles'. NetworkManager:Activation (wlan0) Stage 2 of 5 (Device Configure) complete. NetworkManager:Activation (wlan0) New wireless user key for network 'Welles' received. NetworkManager:Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager:Activation (wlan0) Stage 1 of 5 (Device Prepare) started... NetworkManager:Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... NetworkManager:Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. NetworkManager:Activation (wlan0) Stage 2 of 5 (Device Configure) starting... NetworkManager:Activation (wlan0/wireless): access point 'Welles' is encrypted, and a key exists. No new key needed. NetworkManager:SUP: sending command 'INTERFACE_ADD wlan0 wext/var/run/wpa_supplicant ' NetworkManager:SUP: response was 'OK' NetworkManager:SUP: sending command 'AP_SCAN 1' NetworkManager:SUP: response was 'OK' NetworkManager:SUP: sending command 'ADD_NETWORK' NetworkManager:SUP: response was '0' NetworkManager:SUP: sending command 'SET_NETWORK 0 ssid 57656c6c6573' NetworkManager:SUP: response was 'OK' NetworkManager:SUP: sending command 'SET_NETWORK 0 key_mgmt NONE' NetworkManager:SUP: response was 'OK' NetworkManager:SUP: sending command 'SET_NETWORK 0 wep_key0 ' NetworkManager:SUP: response was 'OK' NetworkManager:SUP: sending command 'SET_NETWORK 0 wep_tx_keyidx 0' NetworkManager:SUP: response was 'OK' NetworkManager:SUP: sending command 'ENABLE_NETWORK 0' NetworkManager:SUP: response was 'OK' NetworkManager:Activation (wlan0) Stage 2 of 5 (Device Configure) complete. ioctl[SIOCGIWSCAN]: Resource temporarily unavailable NetworkManager:wpa_supplicant(5159): Global control interface '/var/run/wpa_supplicant-global' NetworkManager:wpa_supplicant(5159): RX global ctrl_iface - hexdump_ascii(len=50): NetworkManager:wpa_supplicant(5159): 49 4e 54 45 52 46 41 43 45 5f 41 44 44 20 77 6c INTERFACE_ADD wl NetworkManager:wpa_supplicant(5159): 61 6e 30 09 09 77 65 78 74 09 2f 76 61 72 2f 72 an0__wext_/var/r NetworkManager:wpa_supplicant(5159): 75 6e 2f 77 70 61 5f 73 75 70 70 6c 69 63 61 6e un/wpa_supplican Netw
Re: NetworkManager on ubuntu Dapper?
On Tue, 2006-02-21 at 13:12 -0700, Mike Bydalek wrote: > Ian Campbell wrote: > > Has anyone else had problems with NetworkManager on Ubuntu Dapper? > > > I did a fresh install from Flight 3 (applied all the updates), and have > no problems with network-manager at all. The only thing I did notice > was that this weekend I updated from network-manager_0.5.1-0ubuntu11 to > network-manager_0.5.1-0ubuntu14, and the 14 package was severely broke. > Downgrading back to 11 worked. > > I just noticed that there is a 16 available, but I haven't had time to > try it yet. 16 is broken too, as is the new dhcp3-client package they just pushed. I'd recommend holding off for a few as they get it sorted out. One notable thing though, the new packages have a separate nm-applet package. So if you do try upgrading, make sure you also install nm-applet. Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: gentoo patch
I think long term that diamond is the best solution. Nathaniel On Fri, 2005-07-01 at 18:41 +0200, Magnus Ottosson wrote: > The problem I have found is the dhclient patches from redhat. I solved > this by installing the binaries from redhat. The I used the ebuild from > gentopia (https://dev.cardoe.com/gentopia/) and this actually works > quite well. I hav not had enough time to test it so much but it works > fairly good. But the problem is still the patches from redhat. > > Magnus ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: gentoo patch
On Fri, 2005-07-01 at 09:11 -0400, Dan Williams wrote: > On Fri, 2005-07-01 at 08:29 +0200, Magnus Ottosson wrote: > > Yes! I have that... I hav not had time to try your patch yet. Maybe today. > > I was kind of waiting to apply the gentoo patch until somebody said it > worked, but if you don't get to it today I'll apply it anyway. The problem with the patch is that our config files for networking have just changed and are immensely complex. I'm thinking about just bypassing/ignoring them altogether. Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: gentoo patch
On Tue, 2005-06-28 at 18:16 +0200, Magnus Ottosson wrote: > I will try the patch when I get home and see if I can get it working... Did > you also make an ebuild? > > Magnus > > -Original Message- > From: Jos Dehaes <[EMAIL PROTECTED]> > To: networkmanager-list@gnome.org > Date: Mon, 27 Jun 2005 17:08:04 +0200 > Subject: gentoo patch > > Hi, > > I patched the gentoo backend to compile at least (based on the Suse > version). But NetworkManager still won't work. Wired (8139too), nor > wireless (prism54). Also, I get no GUI feedback at all, how should I > start NetworkManager (I used /etc/init.d/NetworkManager start)? > > I can send logs if anyone is interested in helping out. You most likely need dhclient with redhat patches (patches not in portage) and dhcdbd. Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Re: Gentoo packages unavailable?
On Fri, 2005-05-27 at 19:07 +0200, Jonas wrote: > Hi, > > > HOWEVER, NetworkManager does not yet work reliably on Gentoo. And since > > it involves a lot of dependencies that aren't in the tree yet, I'd > > advise you not to use it. > > you mean, don't use at all? or would building from source be fine? > > if the latter, what specific parts aren't of use yet? > if there was kind of a todo list, i wouldn't care to fix them, > given the source is readable (understandable) ;) That NM ebuild requires the new hal and dbus, which aren't in the tree yet and which break a lot of other stuff. We're trying to get that stuff in the tree, and once its in, you could start messing with it. But even to build NM right now will require dependencies that will break your system. So I strong advise against it. You can track the progress by getting ahold of us in #gentoo-desktop on freenode.net. Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gentoo packages unavailable?
On Fri, 2005-05-27 at 17:24 +0200, Jonas wrote: > there are no NetworkManager packages remaining in the Gentoo portage tree. > At least i couldn't find any. > > Anyone still has the ebuilds? NetworkManager ebuilds are availabe here: http://dev.gentoo.org/~cardoe/utopia/ HOWEVER, NetworkManager does not yet work reliably on Gentoo. And since it involves a lot of dependencies that aren't in the tree yet, I'd advise you not to use it. Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: No NetworkManagerInfo
On Wed, 2005-05-11 at 09:24 -0400, Dan Williams wrote: > On Wed, 2005-05-11 at 10:53 +0200, Magnus Ottosson wrote: > > Hi! > > > > I just compiled NM with under gentoo with the atached ebuild. After > > compilation I started NM with success. But when I try to start > > NetworkManagerInfo this binary does not exist! I only have the binaries > > NetworkManager and NetworkManagerDispatch. Has the NetworkManagerInfo > > changed name since the 0.4 release or is something wrong? > > > > magnus > > Hi, > > I merged NetworkManagerInfo and the applet, which is now called > "nm-applet" defaulting to /usr/libexec. I'm one of the maintainers for that package (which is in a private overlay tree, not the main tree). I rewrote the backend for Gentoo to more closely resemble RedHats (and to work, it was broken). Once I'm confident that the backend is somewhat stable, I'll pass it up to you. The daemon seems to work fine. However, the applet has problems. After install (and restarting dbus/hal), when you run the applet it says it has permissions problems. So I changed "default" in /etc/dbus-1/system.d/nm-applet to allow, the applet loads fine, but shows no devices detected. I'm not really sure how to go about debugging this, so any help you could offer would be great. Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Association timout problem
With NM on Gentoo and an Atheros Wifi, NM won't work without this (attached) patch. Nathaniel --- src/NetworkManagerDevice.c.old 2005-03-07 23:53:28.0 -0500 +++ src/NetworkManagerDevice.c 2005-03-07 23:57:50.0 -0500 @@ -1878,7 +1878,7 @@ ((auth == NM_DEVICE_AUTH_METHOD_SHARED_KEY) ? "Shared Key" : "unknown"))); /* Bring the device up and pause to allow card to associate. */ - g_usleep (G_USEC_PER_SEC * 2); + g_usleep (G_USEC_PER_SEC * nm_device_get_association_pause_value (dev)); /* Some cards don't really work well in ad-hoc mode unless you explicitly set the bitrate * on them. (Netgear WG511T/Atheros 5212 with madwifi drivers). Until we can get rate information ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
