Send connman mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.01.org/mailman/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. connmanctl scan wifi: Error /net/connman/technology/wifi: Not
      implemented ([email protected])
   2. Re: WISPr authentication (Daniel Wagner)
   3. Re: Any C / C++ test program available? (Daniel Wagner)
   4. Re: [PATCH 0/1] Start online check on IP address update
      (Daniel Wagner)
   5. Re: [PATCH 1/1] service: Start online check on IP address
      update (Daniel Wagner)
   6. Re: connmanctl scan wifi: Error /net/connman/technology/wifi:
      Not implemented (Daniel Wagner)
   7. Re: Failed to create storage directory: No such file or
      directory (Daniel Wagner)
   8. Re: Failed to create storage directory: No such file or
      directory (Jussi Laakkonen)


----------------------------------------------------------------------

Message: 1
Date: Tue, 26 Mar 2019 20:09:26 +0100
From: <[email protected]>
To: [email protected]
Subject: connmanctl scan wifi: Error /net/connman/technology/wifi: Not
        implemented
Message-ID: <20190326133519.06dc698c@huit>
Content-Type: text/plain; charset=US-ASCII

Hi,

I have a problem to make wifi work within connman.

I tried to google, tried, googled, tried, but can't get around
it :/  ... so I really hope someone can give me a hint.

'connmanctl scan wifi' always gives me a
Error /net/connman/technology/wifi: Not implemented

I am currently using iwd, it's running. iwd can access wifi 
and scan all good [1].
Just connman seems to have a problem connecting to it. 

[1] for instance all of this works fine:
  'sudo iw wlan0'
  'iwctl device list'
  'iwctl station wlan0 scan'
  'iwctl station wlan0 get-networks'

I had first tried wpa_supplicant... and am now using iwd 
(supposedly iwd is a bit more stable / better ?!)
Both showed the same symtptoms and problems.

I then stopped iwd and connman (via systemctl).
Then I started logging journalctl right before
starting iwd via systemctl.
--> see journalctl.log
   http://sprunge.us/hJog0I

Started connmand via CONNMAN_SUPPLICANT_DEBUG=1 connmand -n -d
--> see conmand.log
   http://sprunge.us/8iz5eV

And issued some connmanctl commands
--> see cli.txt
   http://sprunge.us/eYpuKG

The only thing I noticed was that 
        'connmanctl enable agent' 
consistantly gave me a
        Error agent: Method "SetProperty" with signature "sv" on
        interface "net.connman.Technology" doesn't exist
(but the command returns with exit code 0 ?!))

But not sure what to do with this.

Thaaaaaaanks a lot for any help with this to unstuck me,

Tormen


PS:
My goal is actually to use cmst later.
For now within cmst the "Rescan" button is grayed out.
(most likely because the connection to the wifi agent is broken)



------------------------------

Message: 2
Date: Wed, 27 Mar 2019 08:13:54 +0100
From: Daniel Wagner <[email protected]>
To: Thomas Green <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: WISPr authentication
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Hi Thomas,

On Fri, Mar 22, 2019 at 09:16:01PM +0000, Thomas Green wrote:
> Thank you for your reply.  Please find the associated log file below:
> 
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xdb1e0
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xd6118
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xd1e00
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xd83d8
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xdaae8
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xd3618
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xccb70
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xcbf40
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xd2728
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xd9290
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xd3f30
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xd07a0
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xd4880
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xcf008
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xd4de0
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xd57e8
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xdd4f0
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xe0bd0
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xc9c08
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xce200
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xcfe00
> connmand[11365]: src/wispr.c:__connman_wispr_stop() service 0xcc3f0

I didn't see any __connman_wispr_start(). Maybe is EnableOnlineCheck
set to false?

Thanks,
Daniel


------------------------------

Message: 3
Date: Wed, 27 Mar 2019 08:17:16 +0100
From: Daniel Wagner <[email protected]>
To: JH <[email protected]>
Cc: connman <[email protected]>
Subject: Re: Any C / C++ test program available?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Hi,

On Sun, Mar 24, 2019 at 09:24:01PM +1100, JH wrote:
> Hi,
> 
> The Git source has a test directory but they are all Python test
> programs, are there any C / C++ test programs available for:
> 
> (1) Set up WiFi connection based on input of SSID and password.
> 
> (2) Get current connected network interface at configuration of
> SingleConnectedTechnology = true
> 
> (3) Monitor network signal strength for WiFi and cellular.

I think a good starting point are the existing UI. check the list of
frontends on Arch's wiki:

https://wiki.archlinux.org/index.php/ConnMan

Thanks,
Daniel


------------------------------

Message: 4
Date: Wed, 27 Mar 2019 08:28:00 +0100
From: Daniel Wagner <[email protected]>
To: Robert Tiemann <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 0/1] Start online check on IP address update
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Hi Robert,

On Tue, Mar 26, 2019 at 11:14:52AM +0100, Robert Tiemann wrote:
> To fix this, I have prepared a patch against master which triggers the
> online check when the IP address is updated. It works, but I am not
> sure if this is a good solution or if the patch is just fighting a
> symptom caused by a problem which should be fixed somewhere else.

Well, not sure either. address_updated() was introduced to fix the
problem whenever a new IP is assigned we need to check the timeserver
etc. again. From this perspective it seems a reasonable place to
trigger also the online check again.

Thanks,
Daniel


------------------------------

Message: 5
Date: Wed, 27 Mar 2019 08:31:05 +0100
From: Daniel Wagner <[email protected]>
To: Robert Tiemann <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 1/1] service: Start online check on IP address
        update
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Hi Robert,

> +static void start_online_check(struct connman_service *service,
> +                             enum connman_ipconfig_type type)
> +{
> +     if (connman_setting_get_bool("EnableOnlineCheck"))
> +             if (type == CONNMAN_IPCONFIG_TYPE_IPV4) {
> +                     check_proxy_setup(service);
> +             } else {
> +                     __connman_service_wispr_start(service, type);
> +             }
> +     else
> +             connman_info("Online check disabled. "
> +                     "Default service remains in READY state.");
> +}
> +

I think we should cancel any pending online check first. Just checked
the wispr file and it looks like we could trigger an online check
while one is running. Probably a bad thing.

Thanks,
Daniel


------------------------------

Message: 6
Date: Wed, 27 Mar 2019 08:38:40 +0100
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: connmanctl scan wifi: Error /net/connman/technology/wifi:
        Not implemented
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Hi Tormen,

On Tue, Mar 26, 2019 at 08:09:26PM +0100, [email protected] wrote:
> Hi,
> 
> I have a problem to make wifi work within connman.
> 
> I tried to google, tried, googled, tried, but can't get around
> it :/  ... so I really hope someone can give me a hint.

No worries. I know that feeling.

> 'connmanctl scan wifi' always gives me a
> Error /net/connman/technology/wifi: Not implemented
> 
> I am currently using iwd, it's running. iwd can access wifi 
> and scan all good [1].
> Just connman seems to have a problem connecting to it. 
> 
> [1] for instance all of this works fine:
>   'sudo iw wlan0'
>   'iwctl device list'
>   'iwctl station wlan0 scan'
>   'iwctl station wlan0 get-networks'
> 
> I had first tried wpa_supplicant... and am now using iwd 
> (supposedly iwd is a bit more stable / better ?!)

iwd is far easier to use from ConnMan's perspective. The only problem
is that I haven't updated the plugin for a while.

> Both showed the same symtptoms and problems.
> 
> I then stopped iwd and connman (via systemctl).
> Then I started logging journalctl right before
> starting iwd via systemctl.
> --> see journalctl.log
>    http://sprunge.us/hJog0I

I see that ConnMan detects the iwd service on D-Bus. But that's about
it. There is no interaction. I suppose that is a API issue. The plugin
needs to be updated to a recent version of iwd.

> PS:
> My goal is actually to use cmst later.
> For now within cmst the "Rescan" button is grayed out.
> (most likely because the connection to the wifi agent is broken)

And the scan feature needs to be added as well.

I'll update the plugin if no one else is stepping up. But don't expect
me to be done with it in few days :)

Thanks,
Daniel


------------------------------

Message: 7
Date: Wed, 27 Mar 2019 08:46:16 +0100
From: Daniel Wagner <[email protected]>
To: JH <[email protected]>
Cc: connman <[email protected]>
Subject: Re: Failed to create storage directory: No such file or
        directory
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Hi,

On Tue, Mar 19, 2019 at 09:44:25PM +1100, JH wrote:
> connmand[25650]: ./src/iptables.c:__connman_iptables_append() -t
> mangle -A connman-INPUT -j CONNMARK --restore-mark
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000000000 in ?? ()
> (gdb) backtrace
> #0  0x0000000000000000 in ?? ()
> #1  0x00007ffff7669080 in xtables_find_target ()
>    from /usr/lib/x86_64-linux-gnu/libxtables.so.12
> #2  0x00007ffff766949b in ?? () from 
> /usr/lib/x86_64-linux-gnu/libxtables.so.12
> #3  0x00007ffff7669152 in xtables_find_target ()
>    from /usr/lib/x86_64-linux-gnu/libxtables.so.12
> #4  0x00005555555dc77a in prepare_target (
>     target_name=0x555555842a90 "CONNMARK", table=0x555555867840)
>     at ./src/iptables.c:1574
> #5  parse_rule_spec (table=<optimised out>, ctx=0x555555867f80)
>     at ./src/iptables.c:1993
> #6  0x00005555555dd1d8 in __connman_iptables_append (
>     table_name=table_name@entry=0x5555558419c0 "mangle",
>     chain=chain@entry=0x555555842c10 "connman-INPUT",
>     rule_spec=rule_spec@entry=0x555555862460 "-j CONNMARK --restore-mark")
>     at ./src/iptables.c:2196
> #7  0x00005555555e7094 in insert_managed_rule (
>     rule_spec=0x555555862460 "-j CONNMARK --restore-mark",
>     chain_name=<optimised out>, table_name=0x5555558419c0 "mangle")
>     at ./src/firewall.c:180
> #8  __connman_firewall_enable (ctx=ctx@entry=0x555555841820)
>     at ./src/firewall.c:336
> ---Type <return> to continue, or q <return> to quit---
> #9  0x00005555555d4a68 in init_firewall ()
>     at ./src/session.c:219
> #10 0x00005555555d6cd5 in init_firewall ()
>     at ./src/session.c:1740
> #11 __connman_session_init ()
>     at ./src/session.c:1734
> #12 0x0000555555572270 in main (argc=<optimised out>, argv=<optimised out>)
>     at ./src/main.c:670


iptables is a bit tricky, especially error handling. I am not 100%
convienced this code works right. But I don't want to touch it
either. Too many gray haires already. The last brave soul to touch it
was Jussi and I think he spend a lot of time hunting stuff.

If possible try to use the nftable backend instead of the iptables,
because there we have proper APIs to use.

That said, I see ConnMan was able to remove the old rules and fails
adding the CONNMARK rule to the mangle table. Is the CONNMARK and
mangle table available?

Thanks,
Daniel


------------------------------

Message: 8
Date: Wed, 27 Mar 2019 10:31:15 +0200
From: Jussi Laakkonen <[email protected]>
To: Daniel Wagner <[email protected]>, JH <[email protected]>
Cc: connman <[email protected]>
Subject: Re: Failed to create storage directory: No such file or
        directory
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Daniel and JH,


On 3/27/19 9:46 AM, Daniel Wagner wrote:
> Hi,
> 
> On Tue, Mar 19, 2019 at 09:44:25PM +1100, JH wrote:
>> connmand[25650]: ./src/iptables.c:__connman_iptables_append() -t
>> mangle -A connman-INPUT -j CONNMARK --restore-mark
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000000000000000 in ?? ()
>> (gdb) backtrace
>> #0  0x0000000000000000 in ?? ()
>> #1  0x00007ffff7669080 in xtables_find_target ()
>>     from /usr/lib/x86_64-linux-gnu/libxtables.so.12
>> #2  0x00007ffff766949b in ?? () from 
>> /usr/lib/x86_64-linux-gnu/libxtables.so.12
>> #3  0x00007ffff7669152 in xtables_find_target ()
>>     from /usr/lib/x86_64-linux-gnu/libxtables.so.12
>> #4  0x00005555555dc77a in prepare_target (
>>      target_name=0x555555842a90 "CONNMARK", table=0x555555867840)
>>      at ./src/iptables.c:1574
>> #5  parse_rule_spec (table=<optimised out>, ctx=0x555555867f80)
>>      at ./src/iptables.c:1993
>> #6  0x00005555555dd1d8 in __connman_iptables_append (
>>      table_name=table_name@entry=0x5555558419c0 "mangle",
>>      chain=chain@entry=0x555555842c10 "connman-INPUT",
>>      rule_spec=rule_spec@entry=0x555555862460 "-j CONNMARK --restore-mark")
>>      at ./src/iptables.c:2196
>> #7  0x00005555555e7094 in insert_managed_rule (
>>      rule_spec=0x555555862460 "-j CONNMARK --restore-mark",
>>      chain_name=<optimised out>, table_name=0x5555558419c0 "mangle")
>>      at ./src/firewall.c:180
>> #8  __connman_firewall_enable (ctx=ctx@entry=0x555555841820)
>>      at ./src/firewall.c:336
>> ---Type <return> to continue, or q <return> to quit---
>> #9  0x00005555555d4a68 in init_firewall ()
>>      at ./src/session.c:219
>> #10 0x00005555555d6cd5 in init_firewall ()
>>      at ./src/session.c:1740
>> #11 __connman_session_init ()
>>      at ./src/session.c:1734
>> #12 0x0000555555572270 in main (argc=<optimised out>, argv=<optimised out>)
>>      at ./src/main.c:670
> 
> 
> iptables is a bit tricky, especially error handling. I am not 100%
> convienced this code works right. But I don't want to touch it
> either. Too many gray haires already. The last brave soul to touch it
> was Jussi and I think he spend a lot of time hunting stuff.
> 
> If possible try to use the nftable backend instead of the iptables,
> because there we have proper APIs to use.
> 
> That said, I see ConnMan was able to remove the old rules and fails
> adding the CONNMARK rule to the mangle table. Is the CONNMARK and
> mangle table available?
> 
> Thanks,
> Daniel

To JH:

Which version of ConnMan are you using? According to the line numbers in 
the GDB output the version you have does not include the improved error 
handling for iptables, see [1],[2].

And I think these are requried to be enabled in kernel configs to use 
CONNMARK target and match:
CONFIG_NETFILTER_XT_CONNMARK
CONFIG_NETFILTER_XT_TARGET_CONNMARK
CONFIG_NETFILTER_XT_MATCH_CONNMARK
CONFIG_NET_ACT_CONNMARK (not sure if this is needed)

I hope adding those to kernel configs helps with this issue.


To Daniel:

Yes, finding out these things with iptables takes time :) We have now 
iptables 1.8.2 in use and as of now it seems that patch I mentioned in 
[2] is no longer necessary. It applied only for iptables 1.6.1 (and most 
likely, for 1.6.x).

Sincerely,
  Jussi Laakkonen


[1] 
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=b209d1ac4048d5fdfc480113f9fdaa005667a10e
[2] 
https://git.kernel.org/pub/scm/network/connman/connman.git/tree/src/iptables.c#n2682
 

[3] https://lists.01.org/pipermail/connman/2019-January/023146.html


------------------------------

Subject: Digest Footer

_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman


------------------------------

End of connman Digest, Vol 41, Issue 27
***************************************

Reply via email to