maemo.org Bugzilla – Bug 3306
DUMMY connections not visible in Select connection dialog
Last modified: 2008-09-09 13:26:33 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: osso_software_version: RX-34+RX-44+RX-48_DIABLO_4.2008.23-14_PR_MR0 However, this bug still remains in the final - look here: http://www.internettablettalk.com/forums/showthread.php?t=21263 STEPS TO REPRODUCE THE PROBLEM: Open the Select connection dialog. EXPECTED OUTCOME: DUMMY connections to be visible and selectable. ACTUAL OUTCOME: DUMMY connections are not visible. REPRODUCIBILITY: always OTHER COMMENTS: DUMMY connections are the only easy way to get other than the available networking options running, without draining the battery. User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.0.1pre) Gecko/2008062504 GranParadiso/3.0.1pre
*** This bug has been confirmed by popular vote. ***
I'm a bit afraid it could confuse the "average" user...? And being a newbie not used to dummy connections, can i get a basic explanation and how to create one (even if it's not displayed currently)? Thanks in advance. :-)
http://maemo.org/community/wiki/DummyIAP/ used for instance here: https://wiki.maemo.org/USB_networking
Maybe make it available through the red pill mode?
What's the point of it in red pill? Some people are using PAN and USB connections in their everyday routines. Why stay in red pill all the time (and is red pill mode used in anything else than application manager)?
(In reply to comment #0) > DUMMY connections are the only easy way to get other than the available > networking options running, without draining the battery. What is the non-easy way?
And compared to Chinnok, is this a regression or not?
Two ways: not using connection manager at all (not exactly user friendly) and using ad-hoc connection and dropping wlan after connecting. Yes, this is a regression (was working in Chinook) and fanoush mentioned that another such regression happened in OS2007.
Diablo has a revised version of Internet Connectivity Daemon (icd2) which works somewhat differently compared to the old version (osso-ic). Unfortunately we didn't notice the lack of DUMMY IAP support in time, but we are looking into solving this one.
When I ran usbEthUp.sh manually, it complained about line 36: udhcpc not found.
(In reply to comment #10) > When I ran usbEthUp.sh manually, it complained about line 36: udhcpc not found. Not really a helpful comment... Hardware and software version? What has it to do with this bug report at all?
(In reply to comment #9) > Diablo has a revised version of Internet Connectivity Daemon (icd2) which works > somewhat differently compared to the old version (osso-ic). Unfortunately we > didn't notice the lack of DUMMY IAP support in time, but we are looking into > solving this one. Aapo, is there an internal ticket (Please only the number, no full URLs)? Could not find one... Otherwise I'd forward this.
N800. Diablo. The usbEthUp.sh script is called as part of the flow. --V (In reply to comment #11) > (In reply to comment #10) > > When I ran usbEthUp.sh manually, it complained about line 36: udhcpc not found. > > Not really a helpful comment... Hardware and software version? What has it to > do with this bug report at all? >
As said on the maemo users mailing list the idea is to enable the dummy network feature for icd2 and have it working as before. Ufortunately we discovered a minor bug in the process, but once that gets resolved, I hope we'll have the same dummy network functionality as before.
(In reply to comment #12) > ...is there an internal ticket int-86672 for the bug discovered.
(In reply to comment #15) > int-86672 for the bug discovered. Oh, that did not sound like the same issue to me when searching. Shall I mark int-87041 as a dup of int-86672 then? TIA
This bug is famous now: http://www.edn.com/index.asp?layout=blog&blog_id=400000040&blog_post_id=940030694 :)
(In reply to comment #16) > Oh, that did not sound like the same issue to me when searching. int-87041 is what we'll be waiting for to get fixed and released, as it's blocking the DUMMY network module feature. After that we'll proceed with this one.
OMG, guys, is it possible it can be fixed soon?
Hi Nokia guys, I'm not very experienced with packaging, but do you think it'd be worth the time to package the current workaround, and possibly try to detect connections to the dummy interface to automate PAN connections? Here are the main considerations that I can think of: - Package depends on becomeroot (can be modified to use rootsh or anything more 'standard' that's in the extras repo). - It'd be really nice for it to auto-create an ad-hoc wifi connection that can be used with the PAN startup script. - I think someone mentioned there's DBus integration that could allow auto-execution of the script when a particular wlan connection is made, probably requiring an extra dependency. - Cleanup is important as this is supposed to be a temporary workaround :) I'd be willing to work on this if a fix is going to take a while, but I can't guarantee perfect integration (and would like pointers on the points listed above if packaging seems necesssary).
Is there a work-around so I can use my pc as a gateway through usb again as described on https://wiki.maemo.org/USB_networking until this bug is fixed?
There's a workaround somewhere in this thread: http://www.internettablettalk.com/forums/showthread.php?t=21263
The dummy network module is now uploaded to the repository. From the commandline as root do 'apt-get install libicd-network-dummy', as its not visible through Application manager. The network name is hardcoded for now so one does not need to run the gconf setting command described in the wiki somewhere.
(In reply to comment #23) > The network name is hardcoded for now so > one does not need to run the gconf setting command described in the wiki > somewhere. So this is just quick fix and better solution is coming? We need more dummy connections with different names so more solutions can coexist on same device. This was possible before breaking this. Now it is impossible to differentiate bluetooth pan from usb networking and do the right thing automatically when such dummy connection is opened.
(In reply to comment #24) > So this is just quick fix and better solution is coming? This was supposed to be the solution enabling dummy network support once and for all. > We need more dummy > connections with different names so more solutions can coexist on same device. Ah, that was a usage scenario not envisioned or implemented. Ok, let's fix this as well; now I just need someone from here with some spare time. Unfortunately that may or may not mean 1st week of September. Note to self: It was also pointed out that the debian package section is to contain 'user' for the package to appear in Application manager.
(In reply to comment #25) > Ah, that was a usage scenario not envisioned or implemented. Ok, let's fix this > as well Thank you. Such custom solutions listen to com.nokia.icd connect/disconnect events and check IAP name and do the right thing, see https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/pan-daemon.c?revision=3&root=maemo-pan&view=markup So apart from having more DUMMY connections with custom name, correct name should be sent in the event when specific connection is opened from the GUI (not sure if this is obvious). > Note to self: It was also pointed out that the debian package section is to > contain 'user' for the package to appear in Application manager. > User-friendly solutions such as maemo-pan can pull this as dependency so maybe it is preferable to leave it hidden. Advanced users who can run the gconf command to create dummy IAP can handle apt-get too.
I'm responsible for the USB LAN networking package, which was the other big one that relied on a DUMMY connection so just want to say first off thanks for the quick response on this, at least we have a functional (if not ideal) solution! Hope that things work out and we get back to the "old style" of dummy where we can specify names/etc as pointed out previously, but in the meantime is there any way to enable/disable the DUMMY network? via gconf, removing a file, anything? Just to work as a temp solution until it gets solved right out because at the moment there doesn't seem to be a way for users to even manually enable/disable it... once it's installed, it's always there; once it's uninstalled, it's gone. The best I can come up with at the moment requires a restart of the icd daemon; is there any other slightly less drastic option? Thanks!
I have Diablo installed in QEMU. Upgraded it to latest and installed 'libicd-network-dummy'. When I start QEMU I add emulated USB networking card (as there is no emulation of g_ether or wifi) to be able to connect to outside emulation. It works fine for normal applications (apt-get for example) but when I try to use any maemo app (web browser or app-manager) after long time all I have is "select connection" window with 'dummy network' DISABLED - how to fix it?
(In reply to comment #28) > It works fine > for normal applications (apt-get for example) but when I try to use any maemo > app (web browser or app-manager) after long time all I have is "select > connection" window with 'dummy network' DISABLED - how to fix it? ICd2 should be running, without it maemo apps cannot gain network access.
Fixed, libicd-network-dummy v. 0.12 is now in the repository.
If there are no DUMMY connections visible in Select connection dialog after installing libicd-network-dummy module 0.12 from maemo.org, run gconftool-2 -s -t string /system/osso/connectivity/IAP/DUMMY/type DUMMY gconftool-2 -s -t string /system/osso/connectivity/IAP/DUMMY/name 'Dummy network'" gconftool-2 -s -t boolean /system/osso/connectivity/IAP/DUMMY/autoconnect true