edison-fw / edison-oobe

MIT License
1 stars 2 forks source link

rewrite-wip: pairing with bluetooth is not working #9

Closed htot closed 3 years ago

htot commented 3 years ago

This should be working as described here https://htot.github.io/meta-intel-edison/4.6-contact.html#bluetooth-tether

3 pushes on the PWR button should enable pairing without pin or pw. Instead we have:

root@yuna:~# connect_bluetooth.sh
Error bluetooth: Already enabled
Changing pairable on succeeded
Changing discoverable on succeeded
  File "/usr/bin/simple-agent", line 148
    f.close()
            ^
TabError: inconsistent use of tabs and spaces in indentation
Changing pairable off succeeded
Changing discoverable on succeeded

python really pisses me off. I don't know what's wrong or where.

After pairing manually through bluetoothctl, then I get: afbeelding

But connman shows:

connmanctl> services 
*AO OP35 Extra 5G        wifi_784b87ad4d70_4f503335204578747261203547_managed_psk
*AR Wired                gadget_000000000000_usb
    ZTE Ferry            bluetooth_984FEE03CAE9_6073BC238F3E

And using connect bluetooth_984FEE03CAE9_6073BC238F3E:

connmanctl> services 
*AO OP35 Extra 5G        wifi_784b87ad4d70_4f503335204578747261203547_managed_psk
* R ZTE Ferry            bluetooth_984FEE03CAE9_6073BC238F3E
*AR Wired                gadget_000000000000_usb

And: afbeelding

So, starting to work. Not quite there yet.

mwallnoefer commented 3 years ago

Please find the fix for simple-agent (don't know in which branch of meta-intel-edison-bsp you would like to apply it). The problem was the use of a single eight white-space-indentation instead of a tabulator char.

diff --git a/meta-intel-edison-bsp/recipes-support/pwr-button-handler/files/simple-agent b/meta-intel-edison-bsp/recipes-support/pwr-button-handler/files/simple-agent
index 7f7e8eb..0569803 100755
--- a/meta-intel-edison-bsp/recipes-support/pwr-button-handler/files/simple-agent
+++ b/meta-intel-edison-bsp/recipes-support/pwr-button-handler/files/simple-agent
@@ -145,7 +145,7 @@ def get_pin():
        for c in serial:
                if c.isdigit():
                        pin = pin + c
-        f.close()
+       f.close()
        return pin[-6:]

 if __name__ == '__main__':
htot commented 3 years ago

Thanks, but I already found that one and also that GObject is deprecated. I push it here https://github.com/htot/meta-intel-edison/commits/dunfell as 97ec4632. It seems to be working now, have you tried?

mwallnoefer commented 3 years ago

Okay, so I need to re-build Yocto on behalf of your dunfell branch. Doing that I got some error with the new flash-led service: bitbake.log

htot commented 3 years ago

Sorry about that. Now I actually built it. Or to be honest I built oobe which takes oobe.git from a local repo, but is equal to the remote.

htot commented 3 years ago

I just got bluetooth to pair using the PWR button (https://htot.github.io/meta-intel-edison/4.6-contact.html#bluetooth-tether). But it doesn't connect. Checking connman via serial line shows the service is present, but it didn't connect automatically. We might need to modify something in the connect_bluetooth.sh script to make that happen.

Helping connman to connect, I can use my phone to connect wifi to AP using oobe. Progress!

mwallnoefer commented 3 years ago

Some other issue with dunfell: build.log

htot commented 3 years ago

That's weird. Do you run make image or bitbake edison-image? make image will always first run bitbake -c cleansstate linux-yocto which is sometimes needed when switching to a new kernel.

I just did a build from scratch and did not see this error.

mwallnoefer commented 3 years ago

Yeah, I've done that. The interesting thing is that the compilation step succeds, so it breaks afterwards. log.do_compile states:

...
  OBJCOPY arch/x86/boot/vmlinux.bin
  ZOFFSET arch/x86/boot/zoffset.h
  AS      arch/x86/boot/header.o
  LD      arch/x86/boot/setup.elf
  OBJCOPY arch/x86/boot/setup.bin
  BUILD   arch/x86/boot/bzImage
Kernel: arch/x86/boot/bzImage is ready  (#1)
DEBUG: Shell function do_compile finished
htot commented 3 years ago

When you switched from zeus to dunfel did you make clean?

htot commented 3 years ago

Seems related to https://patches.openembedded.org/patch/174158/

mwallnoefer commented 3 years ago

Ok, the patch did it, thanks a lot 😄 !

Some last issue with perf: bitbake.log

htot commented 3 years ago

Yeah, these things seem to happen switch Yocto versions without cleaning, typically always in kernel and perf.

htot commented 3 years ago

Ok I am finding now that I can turn my phone to tethering via bluetooth and have Edison connect. But it is almost impossible to have the phones browser connect to oobe. As the phone is the dhcp server and gateway and edison doesn't register it's address you need to do a network scan to find edison's ip address to type that in the browser. It does work then.

From a laptop it would be easy to scan the bluetooth network, but it's not so easy to make the laptop a bt tethering device.

So I think that for initial connect from phone/laptop is best to turn bt tether on in edison (the other way around) using connmanctl tether bluetooth on when the PWR buttom is pushed 3x to start pairing. This allows reaching oobe from phone and setup wifi.

Or the PWR button should be pressed once > 2 sec to act as Wifi AP and then oobe should allow PAN connect to a paired tethering phone to provide internet access AP clients.

So we need some work in this area still.

mwallnoefer commented 3 years ago

The ML thread https://www.spinics.net/lists/kernel/msg3292055.html deals with my issue in respect to perf and provides the solution to manually copy the script bpf_helpers_doc.py.

So applying the patch from https://patches.openembedded.org/patch/174158/ and performing the manual copy allowed me to build the dunfall branch. So I propose to integrate at least the patch.

htot commented 3 years ago

@mwallnoefer Like I said, I built dunfell from scratch without this issue. I suspect it happens in your case because you switched from zeus to dunfell without make clean. Are you sure we need to modify anything now? If so, we are already overriding perf.bb, so it should go here: https://github.com/htot/meta-intel-edison/blob/master/meta-intel-edison-bsp/recipes-kernel/perf/perf.bb

But at least you got image, have you installed btrfs or ext4 version?

mwallnoefer commented 3 years ago

Okay, so let us paste this TODO here for further reference:

I do realize now that in the bt form we say there are connections available, but we do not yet provide a selection box to choose one.

mwallnoefer commented 3 years ago

Okay, upgraded the image and launched connect_bluetooth.sh bluetooth.log. Paired with my smartphone and enabled Bluetooth tethering as written here: https://edison-fw.github.io/meta-intel-edison/4.3-bluetooth.html.

But then I am not able to see the BT connection in the connmanctl services list (just the wifi one).

Ah, and looking at the ringbuffer (dmesg) I have noticed the sketch_reset process crashing (sketch_reset.log).

htot commented 3 years ago

It might be that you need to have tethering on your phone enabled while paring. Not sure if you can enable afterwards.

And yes sketch_reset is broken, haven't investigated why. I believe it even causes oopses in kernel.

mwallnoefer commented 3 years ago

It might be that you need to have tethering on your phone enabled while paring. Not sure if you can enable afterwards.

Yeah, exactly, I had to enable BT tethering before enabling BT.

Okay, now the connection is shown, but I struggle when enabling it:

connmanctl> services
*   Fairphone 3          bluetooth_984FEE030B6D_84CFBF8D8B27

connmanctl> connect bluetooth_984FEE030B6D_84CFBF8D8B27
Error /net/connman/service/bluetooth_984FEE030B6D_84CFBF8D8B27: Input/output error
htot commented 3 years ago

Long ago I had that too iirc. The problem then was BT has the default kernel address (a fake address) that disallowed ethernet over BT. So I wrote a script that changes BT address to the one provided in /factory/bluetooth_address. But probably that is 984FEE030B6D right?

mwallnoefer commented 3 years ago

yes, exactly.

htot commented 3 years ago

So, than what? Are you tethering from edison and phone side simultaneously?

mwallnoefer commented 3 years ago

Retried today and it worked immediately.

mwallnoefer commented 3 years ago

These patches bring us closer to the goal: https://github.com/mwallnoefer/edison-oobe/commit/627c7f9bf4d208b426b1a9a152d8550068d413c1

htot commented 3 years ago

Indeed. So, now I can select a BT NAP from the drop down box nicely!

Have you also tried pressing the PWR button 3x within 2sec? It should start the LED to blink fast and allow your phone to pair to the Edison (if not already) and then use the Edison as NAP. If you can find the IP address from your phone browser you can see it works. Except connman technologies shows we are tethering but no one is connected. Consequent our BT Tab shows the same: bluetooth on, Unconnected, Connections available. That might be a but in connman we can't fix. Can you reproduce?

mwallnoefer commented 3 years ago

Yes, it works as you have described:

root@edison:~# journalctl -b -f
-- Logs begin at Thu 2020-03-05 12:31:07 CET. --
Mar 03 13:43:42 edison pwr_button_handler[609]: Requesting pin: 009501 from peer
Mar 03 13:43:42 edison pwr_button_handler[609]: Agent registered
Mar 03 13:43:42 edison pwr_button_handler[609]: AuthorizeService (/org/bluez/hci0/dev_84_CF_BF_8D_8B_27, 0000111e-0000-1000-8000-00805f9b34fb)
Mar 03 13:43:42 edison pwr_button_handler[609]: Agent unregistered
Mar 03 13:43:42 edison pwr_button_handler[609]: Changing pairable off succeeded
Mar 03 13:43:42 edison pwr_button_handler[609]: Changing discoverable on succeeded
Mar 03 13:43:42 edison pwr_button_handler[609]: Edison PWR button was pressed 3 times
Mar 03 13:43:43 edison pwr_button_handler[609]: Error bluetooth: Already enabled
Mar 03 13:43:43 edison pwr_button_handler[609]: Changing pairable on succeeded
Mar 03 13:43:43 edison pwr_button_handler[609]: Changing discoverable on succeed

connman output:

/net/connman/technology/bluetooth
  Name = Bluetooth
  Type = bluetooth
  Powered = True
  Connected = *False*
  Tethering = False

For now I would let it go and suggest to close the issue, since it is a rather small glitch...