Message: 6
Date: Wed, 08 Sep 2010 16:07:00 +0200
From: Marcel Holtmann <[email protected]>
To: [email protected]
Subject: Re: Adding a method in connman-0.59 -> src/manager.c
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
> I am tying to add one method in src/manager.c file in connman-0.59.
>
> I added "RequestLoadDriver" method as below.
>
> static GDBusMethodTable manager_methods[] = {
> { "GetProperties", "", "a{sv}", get_properties },
> { "SetProperty", "sv", "", set_property },
> { "GetState", "", "s", get_state },
> { "CreateProfile", "s", "o", create_profile },
> { "RemoveProfile", "o", "", remove_profile },
> { "RemoveProvider", "s", "", remove_provider },
> { "RequestScan", "s", "", request_scan },
> * * { "RequestLoadDriver", "s", "o",
> request_load_driver },
*> * { "EnableTechnology", "s", "", enable_technology,
>
> I had defined
> static DBusMessage *request_load_driver(DBusConnection *conn,
> DBusMessage *msg, void *data)
>
> I compiled and executed with "connmand -d -n".
>
> Now when I try to request load driver using dbus-send
> # dbus-send --system --print-reply --dest=org.moblin.connman /
> org.moblin.connman.Manager.RequestLoadDriver string:"LoadDriver"
> variant:boolean:true
> *Error org.freedesktop.DBus.Error.UnknownMethod: Method
"RequestLoadDriver"
> with signature "sv" on interface "org.moblin.connman.Manager" doesn't
exist*
*the signature has to match for obvious reasons.*
**
[Raghu]: I hope you are telling *{ "RequestLoadDriver", "s", "o",
request_load_driver }, is wrong. *
Will you please tell me what should be the signature here and where/how I
should modify?
Here my requirement is user will request:
dbus-send --system --print-reply --dest=org.moblin.connman
/ org.moblin.connman.Manager.RequestLoadDriver
string:"LoadDriver" variant:boolean:*true*
true/false to set interface up/down.
*However what is this method suppose to be doing anyway?*
[Raghu]: I want to add load/remove of Wi-Fi driver functionality in ConnMan.
So that I can request connman to load the driver and it will execute the
script present in the path say /usr/etc/load_driver.sh
I found one issue with connman, assume we had loaded wifi driver and wifi
interface is down. When I run connman with "connmand -d -n", it is bringing
wifi interface UP and tries to run wpa_supplicant.
I think actually it should be like, if wifi interface is UP, then connmand
should try running wpa_supplicant?
Regards
Marcel
On Thu, Sep 9, 2010 at 4:00 AM, <[email protected]> wrote:
> Send connman mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.connman.net/listinfo/connman
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of connman digest..."
>
>
> Today's Topics:
>
> 1. Re: DNS issues with some german WiFi routers (Tobias Schr?pf)
> 2. RE: [PATCH 2/2] Remove EDNS option when export resolve file
> (Deng, Ying An)
> 3. Adding a method in connman-0.59 -> src/manager.c (Raghavendra. S)
> 4. connmand and wpa_supplicant crashing (Raghavendra. S)
> 5. RE: [PATCH 2/2] Remove EDNS option when export resolve file
> (David Woodhouse)
> 6. Re: Adding a method in connman-0.59 -> src/manager.c
> (Marcel Holtmann)
> 7. Re: connmand and wpa_supplicant crashing (Marcel Holtmann)
> 8. RE: [PATCH 2/2] Remove EDNS option when export resolve file
> (Marcel Holtmann)
> 9. Re: [service-leak PATCH 0/4] fix service leak (Samuel Ortiz)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 7 Sep 2010 21:13:35 +0200
> From: Tobias Schr?pf <[email protected]>
> To: [email protected]
> Subject: Re: DNS issues with some german WiFi routers
> Message-ID:
>
> <[email protected]<aanlktimjm1k06dvzcq-h0%[email protected]>
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> On 7 September 2010 15:43, David Woodhouse <[email protected]> wrote:
> >> this is exactly what we used as a solution. In the release notes of
> >> connman 0.57 I found the hint that 0.57 should fix the bug
> >> http://bugs.meego.com/show_bug.cgi?id=4818 ... after all it does not
> >> fix the bug but at least it gave me the right idea. I've patched
> >> connman's resolver.c to not add "options edns0" to rsolv.conf and this
> >> fixed it. Now all issues with these special WiFi routers disappered.
> >>
> >> I guess this patch should also be added to upstream connman?
> >
> > Of course it shouldn't. By disabling EDNS0, you've simply confirmed that
> > your local network equipment is broken. Now it's up to you to get it
> > fixed.
> >
> > If both EDNS0 and TCP support are broken (and with ConnMan, the latter
> > definitely is), there will be some DNS records that you simply *cannot*
> > fetch.
> >
> > And please don't top-post. You make it extremely hard to follow the
> > conversation when you don't use email properly.
> >
> > ConnMan should probably have some logic to detect that it's working with
> > a broken nameserver, and fall back to not using EDNS0. Such logic does
> > exist in bind already. If/when this happens, we should complain *loudly*
> > and ensure that the user reports the fault to their network provider.
>
> Again... sorry for the top post.
>
> So maybe the network equipment is broken (I agree) but after all users
> that own such a broken router (and from what I can tell there should
> be a lot of them at least in germany) should be able to use the
> internet just like all the others (and it should not happen that the
> connection manger's GUI tells him he's online but the browser tells
> him it cannot resolve any of the hostnames he'd like to visit).
>
> Furthermore as Windows machines (and also NetworkManager based Linux
> ditros) work just fine with these routers users of connman based
> machines might prefer to switch away from connman instead of buying a
> new router or bugging the vendor of the router to fix the firmware.
> I.e. the unexperienced user might consider this a connman bug and not
> a router bug as his windows machine can resolve the hostnames when it
> claims that it's online.
>
> So up to now our solution to this problem is to remove EDNS0 support
> from resolv.conf.
>
> And yes... I agree that connman should detect these kind of routers
> and not use EDNS0 if the router does not support it properly.
>
> Bye,
> Toby
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 8 Sep 2010 10:44:55 +0800
> From: "Deng, Ying An" <[email protected]>
> To: "[email protected]" <[email protected]>
> Subject: RE: [PATCH 2/2] Remove EDNS option when export resolve file
> Message-ID:
> <
> ce59c043d0ec3349b2bf41c0ec72229b2a843...@shsmsx501.ccr.corp.intel.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Dear Marcel,
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > On Behalf Of Marcel Holtmann
> > Sent: Tuesday, September 07, 2010 5:49 PM
> > To: [email protected]
> > Subject: RE: [PATCH 2/2] Remove EDNS option when export resolve file
> >
> > Hi YingAn,
> >
> > please stop top posting on this mailing list. Otherwise I will ignore
> > emails from you. Follow the proper mailing list etiquette.
> >
>
> I changed my outlook2007 setting this time :) Sorry to bring problem in
> the mailing list.
>
> > > Thanks for your hint. Indeed two patches created, but one is 0001-
> > service-don-t-keep-ref-to-a-removed-network.patch, inside it writes:
> > > From a7d29e4866c9d7a4eed2f550c1ac7c8c89b56245 Mon Sep 17 00:00:00
> > 2001
> > > From: Pekka Pessi <[email protected]>
> > > ....
> > >
> > > But that patch should already accepted long ago, curious why it was
> > generated on my side... so I just commit the 2nd patch.
> > > Yes, it should be called EDNS0 according to RFC2671.
> >
> > You still need to explain why do you think this is the right way. As
> > explained in other threads, there are pros and cons for EDNS0 support.
> >
>
> The pros of EDNS0 is obvious: it brings more content through big payload.
> More than 60% DNS service in China support, including the one served me
> at home, it can help get quickest route for web browsing. When EDNS0
> removed on my client side, it still works, maybe the performance is not so
> good as when using EDNS0 option.
> The cons: for some servers, there might be compatible issues... as bug
> http://bugs.meego.com/show_bug.cgi?id=3674 or
> http://bugs.meego.com/show_bug.cgi?id=4818.
> Maybe we need to balance the impact on the two ends.. until find better
> solutions for most users to be able to access internet smoothly.
>
> BTW I noticed Fedora12/Ubuntu10.4 does not enable that option by default.
>
>
> > Currently the DNS proxy inside ConnMan doesn't support DNS over TCP.
> > And
> > there is also an issue with many home routers that have builtin DNS
> > forwarding or caches. They don't support DNS over TCP either. In all
> > these cases EDNS0 is really needed.
> >
> > Regards
> >
> > Marcel
> >
> >
> > _______________________________________________
> > connman mailing list
> > [email protected]
> > http://lists.connman.net/listinfo/connman
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 8 Sep 2010 12:16:56 +0900
> From: "Raghavendra. S" <[email protected]>
> To: [email protected]
> Subject: Adding a method in connman-0.59 -> src/manager.c
> Message-ID:
>
> <[email protected]<nmes4a7bhm4uoml5o6cbqgz%[email protected]>
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi All,
>
>
> I am tying to add one method in src/manager.c file in connman-0.59.
>
> I added "RequestLoadDriver" method as below.
>
> static GDBusMethodTable manager_methods[] = {
> { "GetProperties", "", "a{sv}", get_properties },
> { "SetProperty", "sv", "", set_property },
> { "GetState", "", "s", get_state },
> { "CreateProfile", "s", "o", create_profile },
> { "RemoveProfile", "o", "", remove_profile },
> { "RemoveProvider", "s", "", remove_provider },
> { "RequestScan", "s", "", request_scan },
> * { "RequestLoadDriver", "s", "o",
> request_load_driver },
> * { "EnableTechnology", "s", "", enable_technology,
>
> I had defined
> static DBusMessage *request_load_driver(DBusConnection *conn,
> DBusMessage *msg, void *data)
>
> I compiled and executed with "connmand -d -n".
>
> Now when I try to request load driver using dbus-send
> # dbus-send --system --print-reply --dest=org.moblin.connman /
> org.moblin.connman.Manager.RequestLoadDriver string:"LoadDriver"
> variant:boolean:true
> *Error org.freedesktop.DBus.Error.UnknownMethod: Method "RequestLoadDriver"
> with signature "sv" on interface "org.moblin.connman.Manager" doesn't
> exist*
> **
> **
> Please let me know what is the issue?
>
>
> --
> Regards & Thanks
> Raghavendra. S
> 9880329621
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 8 Sep 2010 12:39:07 +0900
> From: "Raghavendra. S" <[email protected]>
> To: [email protected]
> Subject: connmand and wpa_supplicant crashing
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi All,
>
> I am tried to execute "connmand -d -n" with out loading wifi/wlan driver.
> I am using connman-0.59 and enabled wifi during compilation.
>
> This leads to crash of wpa_supplicant with signal 6.
>
> Core was generated by `/usr/bin/wpa_supplicant -Dwext -B -u -ieth0
> -c/usr/etc/wpa_supplicant.conf -f/t'.
> Program terminated with signal 6, Aborted.
>
> *******************************
> AppName : wpa_supplicant
> signal number : 6
> file name : wpa_supplicant_2224_19700105200355.cs
> pid : 2224
> *******************************
> Mem information
> *******************************
> MemTotal: 336684 kB
> MemFree: 94124 kB
> Buffers: 1612 kB
> Cached: 121256 kB
> *******************************
> extra information
> *******************************
> time = 1970.01.05 20:03:55 ( UTC )
> exe path = /usr/bin/wpa_supplicant
> signal = 6 (SIGABRT)
> si_code = -6
> signal sent by tkill (sent by pid 2224, uid 0)
> TIMER = -2
> r0 = 0x00000000, r1 = 0x000008b0
> r2 = 0x00000006, r3 = 0x000008b0
> r4 = 0x00000006, r5 = 0x4034ebdc
> r6 = 0x4034e000, r7 = 0x0000010c
> r8 = 0x00000bdc, r9 = 0xbe848800
> r10 = 0x400216b0, fp = 0x40021b70
> ip = 0x4037d5a8, sp = 0xbe848764
> lr = 0x40237258, pc = 0x4023728c
> cpsr = 0x20000010
> *******************************
> callstack information (PID:2224)
> *******************************
> cnt_callstack = 10
> 0: gsignal+0x40(0x4023728c) [/lib/libc.so.6]+0x2c28c
> 1: abort+0x1b0(0x4023caa4) [/lib/libc.so.6]+0x31aa4
> 2: (0x401d58f4) [/usr/lib/libdbus-1.so.3]+0x2a8f4
> 3: (0x401d0ec8) [/usr/lib/libdbus-1.so.3]+0x25ec8
> 4: dbus_connection_unregister_object_path+0x11c(0x401b601c)
> [/usr/lib/libdbus-1.so.3]+0xb01c
> 5: (0x3b120) [/usr/bin/wpa_supplicant]+0x33120
> 6: (0x4d38c) [/usr/bin/wpa_supplicant]+0x4538c
> 7: (0x4dbdc) [/usr/bin/wpa_supplicant]+0x45bdc
> 8: (0x52184) [/usr/bin/wpa_supplicant]+0x4a184
> 9: __libc_start_main+0x118(0x402204c4) [/lib/libc.so.6]+0x154c4
> end of call stack
>
>
> When there is no wifi/wlan interface(driver not loaded), why does connmand
> will try to execute wpa_supplicant? Is this a proper behaviour.
>
> --
> Regards & Thanks
> Raghavendra. S
> 9880329621
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 08 Sep 2010 11:09:25 +0100
> From: David Woodhouse <[email protected]>
> To: "Deng, Ying An" <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: RE: [PATCH 2/2] Remove EDNS option when export resolve file
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2010-09-08 at 10:44 +0800, Deng, Ying An wrote:
> >
> > BTW I noticed Fedora12/Ubuntu10.4 does not enable that option by
> > default.
>
> That's because they support DNS over TCP, because they don't get forced
> to go through a broken UDP-only proxy.
>
> I suspect we should stop using an internal proxy and instead use
> dnsmasq, which can be driven over DBus quite happily. It doesn't quite
> do everything we need, but it can be extended.
>
> I know that goes against Marcel's desire to reinvent *everything* for
> ourselves rather than using anything that existed before, but we really
> do need a coherent solution for this before we can consider ConnMan to
> be ready for use in production.
>
> --
> dwmw2
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 08 Sep 2010 16:07:00 +0200
> From: Marcel Holtmann <[email protected]>
> To: [email protected]
> Subject: Re: Adding a method in connman-0.59 -> src/manager.c
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> > I am tying to add one method in src/manager.c file in connman-0.59.
> >
> > I added "RequestLoadDriver" method as below.
> >
> > static GDBusMethodTable manager_methods[] = {
> > { "GetProperties", "", "a{sv}", get_properties },
> > { "SetProperty", "sv", "", set_property },
> > { "GetState", "", "s", get_state },
> > { "CreateProfile", "s", "o", create_profile },
> > { "RemoveProfile", "o", "", remove_profile },
> > { "RemoveProvider", "s", "", remove_provider },
> > { "RequestScan", "s", "", request_scan },
> > * { "RequestLoadDriver", "s", "o",
> > request_load_driver },
> > * { "EnableTechnology", "s", "", enable_technology,
> >
> > I had defined
> > static DBusMessage *request_load_driver(DBusConnection *conn,
> > DBusMessage *msg, void *data)
> >
> > I compiled and executed with "connmand -d -n".
> >
> > Now when I try to request load driver using dbus-send
> > # dbus-send --system --print-reply --dest=org.moblin.connman /
> > org.moblin.connman.Manager.RequestLoadDriver string:"LoadDriver"
> > variant:boolean:true
> > *Error org.freedesktop.DBus.Error.UnknownMethod: Method
> "RequestLoadDriver"
> > with signature "sv" on interface "org.moblin.connman.Manager" doesn't
> exist*
>
> the signature has to match for obvious reasons.
>
> However what is this method suppose to be doing anyway?
>
> Regards
>
> Marcel
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 08 Sep 2010 16:08:23 +0200
> From: Marcel Holtmann <[email protected]>
> To: [email protected]
> Subject: Re: connmand and wpa_supplicant crashing
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> > I am tried to execute "connmand -d -n" with out loading wifi/wlan
> driver.
> > I am using connman-0.59 and enabled wifi during compilation.
> >
> > This leads to crash of wpa_supplicant with signal 6.
> >
> > Core was generated by `/usr/bin/wpa_supplicant -Dwext -B -u -ieth0
> > -c/usr/etc/wpa_supplicant.conf -f/t'.
> > Program terminated with signal 6, Aborted.
>
> that is clearly a bug in wpa_supplicant. Please get this fixed there.
>
> And yes, connmand tries to start wpa_supplicant once via D-Bus system
> activation.
>
> Regards
>
> Marcel
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 08 Sep 2010 16:12:44 +0200
> From: Marcel Holtmann <[email protected]>
> To: [email protected]
> Subject: RE: [PATCH 2/2] Remove EDNS option when export resolve file
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Dave,
>
> > > BTW I noticed Fedora12/Ubuntu10.4 does not enable that option by
> > > default.
> >
> > That's because they support DNS over TCP, because they don't get forced
> > to go through a broken UDP-only proxy.
>
> unless you hit a home router that is UDP-only as well and doesn't
> forwards TCP on port 53. These exists as well. I run into that problem
> as well.
>
> > I suspect we should stop using an internal proxy and instead use
> > dnsmasq, which can be driven over DBus quite happily. It doesn't quite
> > do everything we need, but it can be extended.
> >
> > I know that goes against Marcel's desire to reinvent *everything* for
> > ourselves rather than using anything that existed before, but we really
> > do need a coherent solution for this before we can consider ConnMan to
> > be ready for use in production.
>
> Stop this non-sense bashing please. I already mentioned to you that we
> have more advanced plans with the DNS proxy code than just DNS proxy.
>
> No matter what, we have to make EDNS0 and DNS over TCP work properly.
> There is no other option here. Both are clearly needed to serve all
> requests properly.
>
> Regards
>
> Marcel
>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 8 Sep 2010 20:13:41 +0200
> From: Samuel Ortiz <[email protected]>
> To: [email protected]
> Cc: [email protected]
> Subject: Re: [service-leak PATCH 0/4] fix service leak
> Message-ID: <20100908181340.gb11...@sortiz-mobl>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Pekka,
>
> On Mon, Aug 30, 2010 at 06:21:08PM +0300, [email protected] wrote:
> > Hi all and especially Marcel,
> >
> > Apparently the network and service leak was caused by a call to
> > connman_network_set_group() before the network was added to the device
> > (and probed and registered to D-Bus). I guess the correct thing here is
> > to postpone the service creation after the network is probed.
> All 4 patches applied, thanks.
>
> Cheers,
> Samuel.
>
>
>
> > --Pekka
> >
> > _______________________________________________
> > connman mailing list
> > [email protected]
> > http://lists.connman.net/listinfo/connman
>
> --
> Intel Open Source Technology Centre
> http://oss.intel.com/
>
>
> ------------------------------
>
> _______________________________________________
> connman mailing list
> [email protected]
> http://lists.connman.net/listinfo/connman
>
> End of connman Digest, Vol 20, Issue 7
> **************************************
>
--
Regards & Thanks
Raghavendra. S
9880329621
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
