Blueman GUI Bluetooth Network Access Point - fixing Bridging

[biketool]

This post is as much notes for me to look back on as a request for better minds to review my attempts.
(edit) Skip to the bottom post where I have the PAN protocol pairing via Blueman GUI but there is still a problem with getting the network bridge working.

I added the bluetoothpan.sh as per link below and after reviewing I assume the iptables commands in the script will work without editing them.

The problem is the pinephone is not reporting in its bluetooth UUID list that it is available as a network access point.
here is the UUID from my old N900 used for years as a bluetooth network access point

Code:

<snip>
00000002-0000-1000-8000-0002ee000002 Proprietary
00001103-0000-1000-8000-00805f9b34fb Dialup Networking (DUN)
00001104-0000-1000-8000-00805f9b34fb IrMC Sync
00001105-0000-1000-8000-00805f9b34fb OBEX Object Push
00001106-0000-1000-8000-00805f9b34fb OBEX File Transfer
0000110a-0000-1000-8000-00805f9b34fb Audio Source
0000110c-0000-1000-8000-00805f9b34fb Remote Control Target
0000110e-0000-1000-8000-00805f9b34fb Remote Control
00001115-0000-1000-8000-00805f9b34fb PANU
00001116-0000-1000-8000-00805f9b34fb Network Access Point
00001117-0000-1000-8000-00805f9b34fb Group Network
0000112f-0000-1000-8000-00805f9b34fb Phonebook Access (PBAP) - PSE
00001132-0000-1000-8000-00805f9b34fb Message Access Server
00005005-0000-1000-8000-0002ee000001 Proprietary
00005601-0000-1000-8000-0002ee000001 Proprietary
/org/bluez/hci0

VS pinephone as is after script, unpair, reboot, and re-pair

Code:

<snip>
00001104-0000-1000-8000-00805f9b34fb IrMC Sync
00001105-0000-1000-8000-00805f9b34fb OBEX Object Push
00001106-0000-1000-8000-00805f9b34fb OBEX File Transfer
00001108-0000-1000-8000-00805f9b34fb Headset
0000110a-0000-1000-8000-00805f9b34fb Audio Source
0000110b-0000-1000-8000-00805f9b34fb Audio Sink
0000110c-0000-1000-8000-00805f9b34fb Remote Control Target
0000110d-0000-1000-8000-00805f9b34fb Advanced Audio
0000110e-0000-1000-8000-00805f9b34fb Remote Control
0000111f-0000-1000-8000-00805f9b34fb Handsfree Audio Gateway
0000112f-0000-1000-8000-00805f9b34fb Phonebook Access (PBAP) - PSE
00001132-0000-1000-8000-00805f9b34fb Message Access Server
00001133-0000-1000-8000-00805f9b34fb Message Notification Server
00001200-0000-1000-8000-00805f9b34fb PnP Information
00001800-0000-1000-8000-00805f9b34fb Generic Access
00001801-0000-1000-8000-00805f9b34fb Generic Attribute
0000180a-0000-1000-8000-00805f9b34fb Device Information
00005005-0000-1000-8000-0002ee000001 Proprietary
usb:v1D6Bp0246d053E
/org/bluez/hci0

I followed the old N900 PAN script exactly after reviewing it
https://wiki.maemo.org/Bluetooth_PAN
I realize that the package genwall is probably what is doing the work bridging mobile data and bnep0 http://maemo.org/packages/view/genwall/
but not sure where/how the PAN and BT network access point profiles are generated on the N900 but not the Pinephone

Code:

When connecting the PinePhone through the USB cable it creates a network the PC will join. The PinePhone has the IP address 10.66.0.1 fixed but the IP address of your PC will vary. Set up ip-forwarding on your PC and set up NAT on your outgoing internet interface:

sudo sysctl net.ipv4.ip_forward=1
sudo iptables -P FORWARD ACCEPT
DEV=$(ip route get 1 | grep -o 'dev .*' | cut -d ' ' -f 2)
sudo iptables -t nat -D POSTROUTING -o "$DEV" -j MASQUERADE 2> /dev/null || true
sudo iptables -t nat -A POSTROUTING -o "$DEV" -j MASQUERADE

Afterwards, on the PinePhone, e.g., through SSH to 10.66.0.1, you need to set the default route to be your PC's USB network interface, and you need to define a DNS server (here 1.1.1.1 from Cloudflare):

sudo ip route add default via "$(arp -n | grep 10.66.0. | grep ether | cut -d ' ' -f 1)"
sudo resolvectl dns usb0 1.1.1.1
sudo resolvectl default-route usb0 true

When you disconnect the cable without rebooting any device, on reconnecting you only need to repeat the commands on the PinePhone to set up the default route again.

the above from https://wiki.mobian-project.org/doku.php...pc-via-usb still requires SSHing into your phone VS using it as an automated BT net access point.

UFW https://wiki.mobian-project.org/doku.php...g#firewall might work to bridge mobile data to bnep0 but we still have the UUID problem.

and do I need to kludge about with scripting a bnep0?

https://www.linuxquestions.org/questions...157-print/

I dont think so because the

Code:

/etc/udev/rules.d/98-bnep0.rules:

ACTION=="add", SUBSYSTEM=="net",  KERNEL=="bnep0", RUN+="/etc/udev/bluenet.sh"
ACTION=="remove", SUBSYSTEM=="net",  KERNEL=="bnep0", RUN+="/etc/udev/bluenet.sh"

generates the bnep0 device

additionaly the /etc/udev/bluenet.sh script might be a bit wonky

just to note it here a friend suggested to me
>this is why often, folks write stuff like    if [ x$ACTION = x"add" ]; then
>you need to export ACTION = "add"
> if you want to run this script manually
> or
> Action=add /etc/udev/bluenet.sh
> for debugging you may insert a line#2 of    logger "this is /etc/udev/bluenet.sh action: $ACTION"  and see what you get in syslog
> logger "this is /etc/udev/bluenet.sh action: $ACTION"« is also a good way to check if the udev on your target platform maybe defines other actions than "add" for $ACTION
> which might well be the real root of your problem
>arbitrary example (I plugged in a USB memstick) https://termbin.com/m7h7
> mobian@mobian:/usr/sbin$ sudo /etc/udev/bluenet.sh
> will fail, like you seen
> you need
> mobian@mobian:/usr/sbin$ sudo ACTION=add /etc/udev/bluenet.sh

this document probably has everything needed as it creates a PAN for an OpenWRT router
https://elinux.org/images/1/15/ELC_NA_20...0814r1.pdf
including the below

Code:

root@OpenWrt:~# dbus-send --system
--dest=org.bluez /org/bluez/hci0
--type=method_call
org.bluez.NetworkServer1.Register
string:“00001116-0000-1000-8000-00805f9b34fb”
string:"br-lan"

which full circle seems to address the UUID issue, maybe better minds will see the answer in the steps I have taken and info gathered in this post.

[TRS-80]

The problem is the pinephone is not reporting in its bluetooth UUID list that it is available as a network access point.

It's quite possible (likely even, IMO) that profile has simply not been implemented yet.

[biketool]

The problem is the pinephone is not reporting in its bluetooth UUID list that it is available as a network access point.

It's quite possible (likely even, IMO) that profile has simply not been implemented yet.

Yes, I suspect so since Mobian is moving form desktop Debian.  I will try to dig into the filesystem in my N900 but I have not done much with bluetooth software side of things until now.  I dont think it is that difficult and I suspect even the linked notes for OpenWRT should get it mostly done.
So either it needs to be scripted by us, copied and edited from my N900, or there is a package to implement it somewhere in the repos.
In any case I feel that this is more important or at least the same importance as WiFi hotspot due to the massive reduction in battery mA/h per Mb..

[biketool]

The problem is the pinephone is not reporting in its bluetooth UUID list that it is available as a network access point.

It's quite possible (likely even, IMO) that profile has simply not been implemented yet.

This is how it was done around 2008, probably how we did it with the N900; some conf editing, I will try it later.
https://debian-bluetooth.blogspot.com/20...ebian.html
It looks to add the BT profile, we will see.
I will post it to fight bitrot as the web search results are mostly not the solution to making a working access point, mostly people failing and asking for help.

Code:

When you use Bluetooth for network services (as opposed to wireless microphone, wiresless mouse, etc), you are using its PAN, or Personal Area Network profile. PAN is provied by the PAN daemon, pand, from the bluez-utils package. PAN uses the BNEP protocol. BNEP stands for Bluetooth Network Encapsulation Protocol.
Kernel configuration
Get a recent 2.6.x kernel, and enable the following features, either as module or built-in:

    CONFIG_BRIDGE_NETFILTER
    CONFIG_BT
    CONFIG_BT_L2CAP
    CONFIG_BT_RFCOMM
    CONFIG_BT_BNEP
    CONFIG_BT_HCIUSB

Debian packages
Install the following Debian packages:

    bridge-utils (for brctl)
    bluez-utils (for pand)

Configuration files

    Edit /etc/bluetooth/hcid.conf to set class to 0x020100;
    Edit /etc/default/bluez-utils to set PAND_ENABLED=1 and PAND_OPTIONS="--listen --role NAP"
    Create /etc/bluetooth/pan/dev-up with this contents:

               #!/bin/sh
             ifconfig $1 0.0.0.0
             brctl addif br0 $1
       

    Add a bridge as a network interface to /etc/network/interfaces by using something like this (I use 192.168.192.x as my local address space).

            auto br0
          iface br0 inet manual
            up   echo     "Adding ethernet bridge between LAN and PAN"
            up   ifconfig eth0 0.0.0.0
            up   brctl    addbr br0
            up   brctl    setfd br0 0
            up   brctl    stp br0 off
            up   brctl    addif br0 eth0
            up   ifconfig br0 192.168.192.1 netmask 255.255.255.0 up
            down echo     "Removing ethernet bridge between LAN and PAN"
            down ifconfig br0 down
            down brctl    delif br0 eth0
            down brctl    delbr br0
       

Operation
First check, whether your USB dongle has been detected by the kernel. You can check this by running 'hciconfig -a'. You should get information on the hci0 interface. Now, if a client bluetooth device will request network service, the PAN daemon, pand, will respond to this. Check your process list to see if pand is running. If not, '/etc/init.d/bluez-utils start' is required. Once the two bluetooth devices connect, a network device called 'bnep0' is created, and pand will execute the /etc/bluetooth/pan/dev-up script. In this script, we will bridge the newly created bnep0 to eth0, using the bridge called br0. To kill the connection at either side, run 'pand -K'.
Clients
A linux client for the bluetooth network, can connect to the server by using this command:

    pand --nodetach --role PANU --search

UPDATE: I've found that I need to have 'dbus' installed to get rid of the error "Inquiry failed. No such device" I recently experienced. Without dbus, /etc/init.d/bluetooth would fail.
Notes
Don't forget that your dhcpd server should now listen on the bridge br0, not on the LAN eth0. Edit /etc/init.d/dhcpd to change this.

The whole deal with the bridging is required, so that dhcpd can function regardless wether bnep0 exists or not. You cannot bring up dhcpd to listen on bnep0, if there is no bluetooth PAN connection. You can, however, have dhcpd listen on the br0 bridge, and attach it to bnep0 whenever a bluetooth client connects.

If you experience troubles, check the /var/log/daemon.log file for more information.
References
http://fedoranews.org/contributors/muhammad_al_ismail/bluetooth/
http://bluez.sourceforge.net/contrib/HOWTO-PAN

and bitrot proofing those two PAN how-to references which seem to be identical.

Code:

=============================================================================
    HowTo set up common PAN scenarios with BlueZ's integrated PAN support
=============================================================================

The Bluetooth PAN feature offers (amongst other features) IP support over
Bluetooth (i.e. L2CAP), (more or less) comparable to Wireless LAN on a PC.
Participants in a BlueZ PAN can take on the following roles (see [1]):

- PAN user (PANU):
  Client of a NAP or client-type member of a GN (see below)

- Group ad-hoc Network (GN) controller:
  Forwarding node in a peer-to-peer style network (Bluetooth Piconet).
  Interconnects up to 7 (active) PANUs to a real peer-to-peer network.

             +------+     +------+     +------+
             | PANU |     | PANU |     | PANU |
             +------+     +------+     +------+
                 \           |           /
                  \          |          /
                   \         |         /
                    \        |        /
                     \       |       /
                      \      |      /
                       \     |     /
                        +---------+
                        |   GN    |
                        +---------+
                       /     |     \
                      /      |      \
                     /       |       \
                    /        |        \
                   /         |         \
                  /          |          \
              +------+    +------+    +------+
              | PANU |    | PANU |    | PANU |
              +------+    +------+    +------+


- Network Access Point (NAP):
  Acts as proxy, router or bridge between an existing network infrastructure
  (typically LAN) and (up to 7 active) wireless clients (PANUs).

                   +====================+
                   | LAN Infrastructure |
                   +====================+
                             |
                             |
                             |
                        +---------+
                        |   NAP   |
                        +---------+
                       /     |     \
                      /      |      \
                     /       |       \
                    /        |        \
                   /         |         \
                  /          |          \
              +------+    +------+    +------+
              | PANU |    | PANU |    | PANU |
              +------+    +------+    +------+


General Setup

To make use of the PAN functionality of BlueZ, it is necessary to build the
following BlueZ packages: "BlueZ-Kernel 2.2", "BlueZ-Libs 2.0",
"Bluez-Utils 2.0", "BlueZ-SDP 0.7" and "BlueZ-PAN 1.0" (or any of the
respective follow-up packages). To build BlueZ packages in general, please
refer to the README files of the individual packages. Be careful, however,
with the README and INSTALL files from BlueZ-PAN 1.0. They refer to an
outdated version of PAN ("BlueNIC"), hence don't apply anymore.

BlueZ-PAN 1.0 is built just like any other BlueZ package:
    # ./configure
    # make
    # make install

Before building, make sure you have the right Linux kernel version: BlueZ-PAN
1.0 requires either a kernel out of the 2.2 series or a 2.4.19 kernel with
the patch from http://bluez.sf.net/patches/patch-2.4.19-bluetooth-* applied
(kernel recompilation required). Kernel with version numbers >= 2.4.20 will
most likely already contain any necessary patches. Information on how to
build a new kernel is contained in the README file of the kernel source tree.
If you're required to build the kernel, see also the section "Ethernet
Bridging" below.

Once everything is built successfully, make sure that the HCI daemon ('hcid')
is running and the respective BlueZ device is "up" (i.e., 'hciconfig' shows
you device number, address etc. of the respective device).

To set up a PAN node, you have to load the module bnep.o first:
    # modprobe bnep

Now you have to start the PAN daemon process ('pand') on one node. The idea
behind 'pand' is that you start it on one side in a server (daemon) fashion,
using the '--listen' parameter.
    # pand --listen --role <PANU | GN | NAP>

Note that on the GN and NAP side, the BlueZ device has to be able to act as
Bluetooth master. Therefore, the master/slave switch has to be enabled in the
BlueZ configuration file '/etc/bluetooth/hcid.conf':
    lm accept, master

(You have to uncomment this in the default version of
'/etc/bluetooth/hcid.conf'.)
Alternatively, you can make a BlueZ PAN node BT master with:
    # pand --master

Now you can establish an explicit connection between PANU and GN or NAP,
respectively, from the other node:
    # pand --connect <destination BT device address>

Here's an example:

To connect a PANU node (00:37:5C:67:D3:01) with a GN (00:37:5C:67:D3:02),
BlueZ must be operational on both sides. The GN must be able to run as
Bluetooth master (see above).

Enter
    # modprobe bnep

on both nodes. Then enter
    # pand --listen --role GN

on the GN side.

After that, you you can connect from the PANU side:
    # pand --connect 00:37:5C:67:D3:02

In case of problems, the system log files under /var/log/ (i.e. 'messages'
and 'warn') may give you further information about the cause of failure.


Note that it is a good idea to start 'pand' as server on the GN (or NAP,
respectively) rather than the PANU, since then you have a consistent access
scheme from any possible PANU. When you do so, 'pand' permanently listens for
connection attempts from other nodes, thus becomes resident.
In case you have only one PANU, however, you may also swap roles and start
'pand' as server (i.e. using the '--listen' parameter) on the PANU side, and
connect from the GN (or NAP) side.


SDP

Optionally, the Bluetooth 'Service Discovery Protocol' (SDP, see [2]) may be
used within 'pand' to register GN or NAP as SDP-searchable services. To use
SDP, make sure that the SDP daemon ('sdpd') is running. SDP is activated with
'pand' when 'pand' is started as GN or NAP:
    # pand --listen --role <GN | NAP> --sdp

In this case, an explicit connection between PANU and GN or NAP, respectively,
is established as follows:
    # pand --connect <destination BT device address> --service <GN | NAP>

with GN/NAP being the desired service at the destination host. Again, the
connection may also be established from the NAP/GN side, so that roles are
swapped.


Search Functionality

To make life easier in case you don't know the device address of your desired
communication partner, the optional parameter '--search' allows you to search
for PAN communication partners, e.g.:
    # pand --role PANU --search [duration]

performs Bluetooth inquiry for PAN devices in the vicinity and tries to
connect to any discovered device. The search continues for no longer than
'duration' units of 1.28 seconds.

Using SDP, the search can pe performed selectively. E.g.:
    # pand --role PANU --search --service NAP --sdp

will search and connect to NAP nodes only.

In case of problems, you can find the results of 'pand's search results in
'/var/log/messages'. You may also want to double-check the expected search
results with 'hcitool scan'.


Interfaces

During connection establishment (this may take a few seconds), a virtual
network interface 'bnep0' is created on both nodes. This interface can be
configured (just like every other regular network interface) using 'ifconfig'.

E.g.:
    # ifconfig bnep0 10.0.0.1

on the GN, and
    # ifconfig bnep0 10.0.0.2

on the PANU creates a private IP network in the 10.x.x.x address range. Now
it should be possible that the nodes ping each other.

Normally, however, it is not necessary to configure 'bnep0' manually. The
Linux "hotplug" mechanism that claims responsible for IP address assignment
(static address or DHCP) for classic ethernet adapters can do the same job
for our PAN as well. Therefore, it is necessary to place a config file named
'ifcfg-bnep0' in /etc/sysconfig/network-scripts/ (reportedly for Redhat).

For static addresses, 'ifcfg-bnep0' could look like follows:
    DEVICE=bnep0
    BOOTPROTO=static
    IPADDR=10.0.0.1
    NETMASK=255.0.0.0
    ONBOOT=no

For DHCP, 'ifcfg-bnep0' could look like follows:
    DEVICE=bnep0
    BOOTPROTO=DHCP
    ONBOOT=no

With SuSE 8.0, 'ifcfg-bnep0' (in /etc/sysconfig/network/) for static
addresses would look like follows:
    BOOTPROTO=static
    IPADDR=10.0.0.1
    NETMASK=255.0.0.0
    STARTMODE=hotplug

Furthermore, you have to set 'HOTPLUG_NET_DEFAULT_HARDWARE=net' in
/etc/sysconfig/hotplug (SuSE 8.0).

For other distributions as well as further configuration details do a 'man
hotplug' and/or 'man ifup'. In case of problems, also check the system log
files.


The file 'ifcfg-bnep0' itself is processed whenever 'bnep0' is created.The
'bnepx' network interfaces ('bnep0' is the first of them) are created
(and deleted) in a fully dynamic way, i.e. one interface is created per
PAN connection, named 'bnep0', 'bnep1' etc. Whereas this behavior usually
doesn't cause any problems on the PANU side (you aren't very likely to have
more than one PAN connection here), it clearly means a problem in a Group
ad-hoc Network, where the GN is supposed to serve up to 7 active PANUs. You
wouldn't want to have up to 7 virtual network interfaces (with different IP
addresses) for 1 physical BT adapter on your node, would you? Furthermore,
you would need several (up to 7) 'ifcfg-bnepx' config files to autoconfigure
the individual interfaces, but to which addresses (7 different ones or
what?)?


Ethernet Bridging

To clean up this messy situation, "802.1d Ethernet Bridging" comes into play,
which is a component of the 2.4.x Linux kernel. The initial idea of this
feature is to tie separate layer 2 networks together into one new network. For
BlueZ PANs, however, we "only" make use of its ability to combine separate
network interfaces into a (one) new one.

In order to activate "802.1d Ethernet Bridging", make sure that it is
actually built:
    # make menuconfig

Select "Networking options" -> "802.1d Ethernet Bridging" (as part of the
kernel or compiled as a module). If you had to change the setting in this
dialog, don't forget to subsequently call
    # make modules
    # make modules_install

to really build the new kernel modules. Reboot.

The bridge kernel module, however, requires an additional control SW package,
called "bridge utils", which most likely is not part of your Linux
distribution. If not, you can download it from http://bridge.sf.net. With
most distributions, the binary RPM should install well (I could verify this
with SuSE 8.0). If not, you may want to download the "bridge utils" source
package and build it.

Finally you should have a working 'brctl' program. To create a PAN bridge on
the GN, enter:
    # brctl addbr pan0
    # ifconfig pan0 10.0.0.1

The 'pan0' interface now is the unique interface to proxy any subsequently
created 'bnepx' interface. In case you are not going to connect complex layer
2 networks, where loops could occur, you should now also disable some of the
smarter features of "802.1d Ethernet Bridging" (namely the "Spanning Tree
Protocol" - STP and the "Listening and Learning States") by typing:
    # brctl setfd pan0 0
    # brctl stp pan0 disable

As a result, the bridge will be functional instantly after a new 'bnepx'
interface has been created. If you don't make these calls, bridge
establishment may take up to ~ 30 seconds (depending on the complexity of
the bridged networks).

Normally (unless you connect your PAN to a complex network) you should make
these 2 calls.

In case you want to create a NAP, simply add the interface of the
"infrastructure" network (typically 'eth0') to the bridge (see also example
2):
    # brctl addif pan0 eth0

Once the bridge port 'bnep0' (or any further port 'bnepx') has been created
on the GN, just add it:
    # brctl addif pan0 bnep0
    # ifconfig bnep0 0.0.0.0'

To check the current status of the bridge, you may call:
    # brctl show

which gives you a list of affected interfaces, and
    # brctl showmacs

to give you a list of connections (per interface) forwarded over the bridge so
far.


'dev-up' Script

"But hey, how will I ever learn that a 'bnepx' interface has been created on
the GN, if the PAN connection was initiated from the PANU?", you may ask.
Indeed, you won't, unless you're the person who's in charge of both
manually initiating the connection on the PANU and subsequently configuring
the bridge on the GN appropriately. Apparently, we need some help from BlueZ
here. So what happens is that the PAN daemon 'pand' calls a script named
'dev-up' in /etc/bluetooth/pan/ whenever a 'bnepx' interface has been
created. It passes the interface name as the first parameter, and the device
address of the remote device as the second. This script may look as follows:
    #!/bin/sh
    # 'dev-up' script to do dynamic bridge management on GN
    brctl addif pan0 $1    # $1 is the new if name, passed by 'pand'
    ifconfig $1 0.0.0.0

On the PANU side, 'dev-up' would look like this:
    #!/bin/sh
    # 'dev-up' script to do dynamic interface management on PANU
    ifconfig $1 10.0.0.2

Make sure that the 'dev-up' scripts have both the 'Read' and 'eXecutable'
attribute set.

Alternatively, on the PANU side, you may stick with the 'ifcfg-bnep0'
configuration file, as outlined above.

You can verify the correct functioning of 'dev-up' by calling 'ifconfig'
manually subsequently. It should show the newly created interface (amongst
others) with the HW device address of the BlueZ adapter and its correct IP
(v4) address. In the GN case, you will only see 'pan0' ('bnepx' is shown,
but doesn't have an IP (v4) address. In the PANU case, you will see 'bnepx'
with a valid IP address.


NAP

The instructions just given on how to set up a Group ad-hoc Network (GN)
apply accordingly for the Network Access Point (NAP) case. Just replace the
'GN' parameter token consequently with 'NAP'.


Miscellaneous options

'pand' offers (among other options that are too trivial to enumerate here;
call 'pand' to get the full list of options) the following additional command
line options:

- '--device <name>'
  allows you to specify a name different from 'bnepx' for dynamic interface
  name association. E.g., if you specify '--device pandev', an interface
  'pandev' will be created.

- '--source <bdaddr>'
  allows you to specify the BT device to be chosen in case more than one
  device is registered (and "up") with BlueZ. You may specify either the
  HCI device number (e.g. 'hci0') or the device address itself. If you call
  e.g.
    # pand --role NAP --listen --source 00:37:5C:67:D3:05

  the device with the address 00:37:5C:67:D3:05 will listen, and no other.

- '--kill <bdaddr>'
  allows you to disconnect a PAN connection, the remote device address of
  which you explicitly know (e.g. because you created it with '--connect
  <bdaddr>').
  To obtain a list of existing connections, use the option '--show':

- '--show' or '--list'
  displays a list of currently existing PAN connections, including the
  device address of the respective remote device and the role of the local
  device in this connection.

- '--persist [interval]
  allows you to reconnect to an existing connection once it has been dropped
  and re-establishment becomes (technically) possible again.
  The exact behavior depends on the way how 'pand' has been started:
  If 'pand' was started like:
    # pand --connect <bdaddr> --persist

  it will always try to connect to the same address.
  If, however it was started like:
    # pand --search --persist

  it will perform the search again instead of just trying to reconnect the
  previous connection. Reconnection is attempted periodically, with 'interval'
  specifying the period, after which a reconnection is attempted (in seconds).
  'interval' defaults to 5.

- '--encrypt'
  activates BT security (authentication and encryption) on the server (GN or
  NAP) side. PANUs connect in a normal way, i.e. no further changes are
  necessary. If no pairing has taken place so far, the PANU user will be
  prompted to enter a PIN.
  For details reg. the BlueZ security support, please read the respective
  discussion threads in the "bluez-users" and "bluez-devel" mailing list
  archives.



Second Example

This example is going to show how PANUs automatically connect (and reconnect)
to a NAP, creating a 192.168.0.x subnet. At the same time, the NAP acts as a
router to a corporate 10.x.x.x network, using 'eth0' as adapter on the
10.x.x.x side, and 'pan0' as adapter for the 192.168.0.x side. The NAP shall
own 10.0.0.1 as 'eth0' IP address and 192.168.0.1 as 'pan0' address. All nodes
use static IP addresses.

After full installation of BlueZ ('hcid' and 'sdpd' running, all BlueZ devices
are "up", "bridge utils" are installed on NAP, the NAP must be able to run as
Bluetooth master, see above.) on NAP and PANU(s), the
following configuration steps are necessary:

On NAP:
Setup bridge:
    # brctl addbr pan0
    # ifconfig pan0 192.168.0.1
    # brctl setfd pan0 0
    # brctl stp pan0 disable
    # brctl addif pan0 eth0

Place a script 'dev-up' in /etc/bluetooth/pan/ (without leading tabs, 'Read'
and 'eXecutable' attributes set):
    #!/bin/sh
    brctl addif pan0 $1    # $1 is the new if name, passed by 'pand'
    ifconfig $1 0.0.0.0

Start NAP server:
    # pand --listen --role NAP --sdp


On PANU:
Place a configuration file 'ifcfg-bnep0' in /etc/sysconfig/network-scripts/
(without leading tabs, Redhat version shown):
    DEVICE=bnep0
    BOOTPROTO=static
    IPADDR=192.168.0.x
    NETMASK=255.255.255.0
    ONBOOT=no

with 'x' being an IP address fragment (2 ... 254) that is unique for each PANU.

Start connection establishment (with reconnection option):
    # pand --role PANU --search --service NAP -sdp --persist


Furthermore, each node that is supposed to participate in communication
across the router requires a proper 'route' entry.

I.e. on the PANUs:
    # route add 10.0.0.0 gw 192.168.0.1

and on the nodes in the 10.x.x.x network (i.e. the machines "behind" the
router):
    # route add 192.168.0.0 gw 10.0.0.1


Now the PANUs should automatically connect to the 10.x.x.x network as soon as
they come into reach of the NAP. Furthermore, they automatically reconnect
after a broken connection when they come into NAP reach next time.

Enjoy!



References:

[1]    "Specification of the Bluetooth System", Volume 1,
    http://www.bluetooth.com/pdf/Bluetooth_11_Specifications_Book.pdf

[2]    "Personal Area Networking Profile", Revision 0.95a,
    http://www.bluetooth.com/pdf/PAN_Profile_0_95a.pdf



Author:    Michael Schmidt, University of Siegen, Germany
    schmidt@nue.et-inf.uni-siegen.de

Please don't hesitate to send me your comments, criticisms, proposals,
supplements etc.

But for now I dont see a quick GIU day even with blueman installed and NMPANSupport clicked in pluginson the pinephone(I think this is PAN support as a client only??), BTW Blueman does work but the GUI is pretty squashed and barely works, but that means it does work.
The upside is if we are working pinephone settings and conf files in the CLI I can do everything by SSH, so much nicer!

---

[biketool]

Soooooo.... big development that uses a different solution to the problem than all of my previous work

It is supposed to be working, blueman is now giving the option of a network access point, I can associate with it as a client from my laptop, but the bridge seems to not be working.
sudo apt install blueman on the pinephone
open blueman(it is in the non-mobile friendly apps)
view -> plugins -> (plugins window opens) check - NMPANSupport (this should give you the required pand and DHCP support)
next again in blueman
view -> Local Services
The Local Services window pops up
check - Network Access Point(NAP)

The Blueman UI is mostly usable with auto-resizing on, My only issue is I couldn't see all of the profiles when paired on the pinephone screen.  It works and plays well so far with the Phosh bluetooth and settings UI.

Again this is nearly done with no hand coding or added scripts required but while I have usable internet from my mobile provider on the PP and I have a network connection from my client laptop to the host PP the network bridge is not routing my traffic.  I will remove my old N900 era scripts hoping that fixes everything(done).  I still wonder if I have broken something playing with .conf settings and scripts and failing to write it in notes during late night hacking sessions.
this is 'route' on my laptopI have xxx'ed out mac addresses)

Code:

Kernel IP routing table
Destination    Gateway        Genmask        Flags Metric Ref    Use Iface
10.108.82.0    0.0.0.0        255.255.255.0  U    0      0        0 pan1
link-local      0.0.0.0        255.255.0.0    U    1000  0        0 pan1

ifconfig:

Code:

bnep0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::2e0:4cff:fe23:9987  prefixlen 64  scopeid 0x20<link>
        ether xx:xx:xx:xx:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 275  bytes 52277 (51.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 236  bytes 134144 (131.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 33  bytes 3167 (3.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 33  bytes 3167 (3.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.36.225.1  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::e8ad:18ff:fe73:2bbe  prefixlen 64  scopeid 0x20<link>
        ether xx:xx:xx:xx:xx:xx txqueuelen 1000  (Ethernet)
        RX packets 275  bytes 49307 (48.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 246  bytes 135977 (132.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

here is some dmesg -w outputs form the kernel when I connect via BT

Code:

[   30.032557] 8723cs: module is from the staging directory, the quality is unknown, you have been warned.
[   30.359071] Bluetooth: Core ver 2.22
[   30.369860] NET: Registered PF_BLUETOOTH protocol family
[   30.375346] Bluetooth: HCI device and connection manager initialized
[   30.382233] Bluetooth: HCI socket layer initialized
[   30.387417] Bluetooth: L2CAP socket layer initialized
[   30.392660] Bluetooth: SCO socket layer initialized
[   30.440357] EXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[   30.449185] i2c i2c-1: Added multiplexed i2c bus 5
[   30.767332] Bluetooth: HCI UART driver ver 2.3
[   30.771855] Bluetooth: HCI UART protocol H4 registered
[   30.813890] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   30.860338] Bluetooth: HCI UART protocol Broadcom registered
[   31.496152] Bluetooth: hci0: RTL: examining hci_ver=07 hci_rev=000b lmp_ver=07 lmp_subver=8703
[   31.509797] Bluetooth: hci0: RTL: chip_type status=0 type=5
[   31.519243] Bluetooth: hci0: RTL: rom_version status=0 version=1
[   31.525404] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723cs_xx_fw.bin
[   31.552417] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723cs_xx_config.bin
[   31.621383] Bluetooth: hci0: RTL: cfg_sz 63, total sz 19427
[   32.005285] Bluetooth: hci0: RTL: fw version 0xaa5ca4dc
[   32.065267] using random self ethernet address
[   32.069807] using random host ethernet address
[   32.169236] usb0: HOST MAC xx:xx:xx:xx:xx:xx
[   32.173633] usb0: MAC xx:xx:xx:xx:xx:xx
[   34.159548] zram: Added device: zram0
[   34.272174] ov5640 3-004c: firmware upload success
[   34.287234] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   34.292655] Bluetooth: BNEP filters: protocol multicast
[   34.298044] Bluetooth: BNEP socket layer initialized
[   34.328447] zram0: detected capacity change from 0 to 3067112
[   34.390779] NET: Registered PF_ALG protocol family
[   34.457459] sun8i-ce 1c15000.crypto: Fallback for ecb-aes-sun8i-ce is ecb-aes-ce
[   34.577228] ov5640 3-004c: uploaded firmware didn't start, got to 0x7f, retrying...
[   34.592765] Adding 1533552k swap on /dev/zram0.  Priority:100 extents:1 across:1533552k SSFS
[   34.905227] ov5640 3-004c: uploaded firmware didn't start, got to 0x7f
[   34.912209] ov5640 3-004c: ov5640_set_ctrl_focus: no autofocus firmware loaded
[   38.761267] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   39.905175] ps: disabling
[   39.908634] dc1sw: disabling
[   39.916931] vcc-1v2-hsic: disabling
[   39.924208] usb0-vbus: disabling
[   42.886303] hdmi-audio-codec hdmi-audio-codec.5.auto: Only one simultaneous stream supported!
[   42.894984] hdmi-audio-codec hdmi-audio-codec.5.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -22
[   42.905306]  1c22800.i2s-i2s-hifi: soc_pcm_open() failed (-22)
[   47.119843] ov5640 3-004c: firmware upload success
[   47.451638] ov5640 3-004c: uploaded firmware didn't start, got to 0x7f, retrying...
[   47.783296] usb 2-1: new high-speed USB device number 2 using ehci-platform
[   47.790492] ov5640 3-004c: uploaded firmware didn't start, got to 0x7f
[   47.797132] ov5640 3-004c: ov5640_set_ctrl_focus: no autofocus firmware loaded
[   47.970983] usb 2-1: New USB device found, idVendor=2c7c, idProduct=0125, bcdDevice= 3.18
[   47.979451] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   47.986802] usb 2-1: Product: EG25-G
[   47.990522] usb 2-1: Manufacturer: Quectel
[   48.108784] usbcore: registered new interface driver usbserial_generic
[   48.120274] usbserial: USB Serial support registered for generic
[   48.143209] usbcore: registered new interface driver cdc_wdm
[   48.197788] qmi_wwan 2-1:1.4: cdc-wdm0: USB WDM device
[   48.205395] usbcore: registered new interface driver option
[   48.222738] qmi_wwan 2-1:1.4 wwan0: register 'qmi_wwan' at usb-1c1b000.usb-1, WWAN/QMI device, 16:f9:92:73:6b:9a
[   48.232613] usbserial: USB Serial support registered for GSM modem (1-port)
[   48.240828] usbcore: registered new interface driver qmi_wwan
[   48.244015] option 2-1:1.0: GSM modem (1-port) converter detected
[   48.253938] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB0
[   48.261341] option 2-1:1.1: GSM modem (1-port) converter detected
[   48.268230] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB1
[   48.276367] option 2-1:1.2: GSM modem (1-port) converter detected
[   48.283201] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB2
[   48.290617] option 2-1:1.3: GSM modem (1-port) converter detected
[   48.297402] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB3
[   48.478802] Bluetooth: RFCOMM TTY layer initialized
[   48.483784] Bluetooth: RFCOMM socket layer initialized
[   48.496758] Bluetooth: RFCOMM ver 1.11
[   54.776907] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   55.501462] rfkill: input handler disabled
[   67.853926] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[   71.505899] ov5640 3-004c: firmware upload success
[   71.810970] ov5640 3-004c: uploaded firmware didn't start, got to 0x7f, retrying...
[   72.127017] ov5640 3-004c: uploaded firmware didn't start, got to 0x7f
[   72.133739] ov5640 3-004c: ov5640_set_ctrl_focus: no autofocus firmware loaded
[   74.861122] ov5640 3-004c: firmware upload success
[   75.162870] ov5640 3-004c: uploaded firmware didn't start, got to 0x7f, retrying...
[   75.474871] ov5640 3-004c: uploaded firmware didn't start, got to 0x7f
[   75.481492] ov5640 3-004c: ov5640_set_ctrl_focus: no autofocus firmware loaded
[   77.780273] pan1: port 1(bnep0) entered blocking state
[   77.785514] pan1: port 1(bnep0) entered disabled state
[   77.792685] device bnep0 entered promiscuous mode
[   77.811632] pan1: port 1(bnep0) entered blocking state
[   77.816862] pan1: port 1(bnep0) entered forwarding state
[   77.822602] IPv6: ADDRCONF(NETDEV_CHANGE): pan1: link becomes ready
[   78.277707] ov5640 3-004c: firmware upload success
[   78.582950] ov5640 3-004c: uploaded firmware didn't start, got to 0x7f, retrying...
[   78.900086] ov5640 3-004c: uploaded firmware didn't start, got to 0x7f
[   78.907332] ov5640 3-004c: ov5640_set_ctrl_focus: no autofocus firmware loaded
[  243.339224] pan1: port 1(bnep0) entered disabled state
[  243.347421] device bnep0 left promiscuous mode
[  243.353867] pan1: port 1(bnep0) entered disabled state
[  459.455661] pan1: port 1(bnep0) entered blocking state
[  459.461610] pan1: port 1(bnep0) entered disabled state
[  459.468600] device bnep0 entered promiscuous mode
[  459.479536] pan1: port 1(bnep0) entered blocking state
[  459.484801] pan1: port 1(bnep0) entered forwarding state

most interesting is the (bnep0) entered blocking state, (bnep0) entered disabled state, and failed firmware loads.

It has been years since I have played with routing and dnsmasq but I assume that bluez and blueman should have the whole routing implemented so I would like to hear form others before I start breaking my system again.

[wibble]

The things we used to do by other means, but are now meant to 'Just Work' with NetworkManager...but 'Just Fail' with whatever GUI you're using, resulting in a disagreement between the interface and backend developers about who's doing it wrong. The WireGuard gui springs to mind with a parameter the backend requires, but the gui doesn't (or didn't) set, to to get the connection to actually work you have to set that one via the cli...

There's a man page example for nmcli that presumably shows how it's meant to work, but I haven't tried it so can't say it actually does. It's right at the bottom of the page:
https://man.archlinux.org/man/nmcli-examples.7.en

[biketool]

The things we used to do by other means, but are now meant to 'Just Work' with NetworkManager...but 'Just Fail' with whatever GUI you're using, resulting in a disagreement between the interface and backend developers about who's doing it wrong. The WireGuard gui springs to mind with a parameter the backend requires, but the gui doesn't (or didn't) set, to to get the connection to actually work you have to set that one via the cli...

There's a man page example for nmcli that presumably shows how it's meant to work, but I haven't tried it so can't say it actually does. It's right at the bottom of the page:
https://man.archlinux.org/man/nmcli-examples.7.en

When I have time in a few days I will try using blueman which is standard bt manager on Ubuntu Mate, I will see if I can make it work to bridge wifi to BT NAP.   The settings are identical to blueman in mobian. But I am with you automagic stuff which 'just works' is cool until it doesn't, then it is nice to remember editable scripts and config fiels to hack with. Bothe are great if they work I guess.

[biketool]

I took some more time and found that I didn't have dnsmasq installed which will be the bridge

Code:

Setting up dnsmasq (2.86-1.1) ...
Job for dnsmasq.service failed because the control process exited with error code.
See "systemctl status dnsmasq.service" and "journalctl -xeu dnsmasq.service" for details.
invoke-rc.d: initscript dnsmasq, action "start" failed.
× dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2022-04-20 21:17:01 EEST; 70ms ago
    Process: 2656 ExecStartPre=/etc/init.d/dnsmasq checkconfig (code=exited, status=0/SUCCESS)
    Process: 2661 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=2)
        CPU: 131ms

Apr 20 21:17:01 mobian systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server...
Apr 20 21:17:01 mobian dnsmasq[2661]: dnsmasq: failed to create listening socket for port 53: Address already in use
Apr 20 21:17:01 mobian dnsmasq[2661]: failed to create listening socket for port 53: Address already in use
Apr 20 21:17:01 mobian dnsmasq[2661]: FAILED to start up
Apr 20 21:17:01 mobian systemd[1]: dnsmasq.service: Control process exited, code=exited, status=2/INVALIDARGUMENT
Apr 20 21:17:01 mobian systemd[1]: dnsmasq.service: Failed with result 'exit-code'.
Apr 20 21:17:01 mobian systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS server.

[biketool]

I seem to have done something in settings perhaps toggling PAN form blueman to networkmanager; I can no longer associate and pull an IP address, the network pair fails now.
As it was before I could have paired and then used SSH forwarding to get a non-automatic PAN-like connection, now I am not even connecting networks.
I tried apt remove --purge blueman but the settings remain after reinstall

I am leaving this here for anyone else to also read and hopefully contribute, blueman troubleshooting

https://github.com/blueman-project/bluem...leshooting

[boroli]

this is 'route' on my laptopI have xxx'ed out mac addresses)

Code:

Kernel IP routing table
Destination    Gateway        Genmask        Flags Metric Ref    Use Iface
10.108.82.0    0.0.0.0        255.255.255.0  U    0      0        0 pan1
link-local      0.0.0.0        255.255.0.0    U    1000  0        0 pan1

ifconfig:

Code:

bnep0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::2e0:4cff:fe23:9987  prefixlen 64  scopeid 0x20<link>
        ether xx:xx:xx:xx:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 275  bytes 52277 (51.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 236  bytes 134144 (131.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 33  bytes 3167 (3.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 33  bytes 3167 (3.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.36.225.1  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::e8ad:18ff:fe73:2bbe  prefixlen 64  scopeid 0x20<link>
        ether xx:xx:xx:xx:xx:xx txqueuelen 1000  (Ethernet)
        RX packets 275  bytes 49307 (48.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 246  bytes 135977 (132.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I just saw that your bnep0 network device is IPv6only.

Can that be the routing issue, as it doesn't get assigned a IPv4 network address? There are similar IPv6 routing issues for USB and WiFi tethering:

https://gitlab.com/mobian1/issues/-/issues/408
https://gitlab.manjaro.org/manjaro-arm/i...issues/236