PDA

View Full Version : Anyone tried synching over 802.11s wireless mesh networking?



epoch1970
2018-02-05, 15:39
I'm a bit curious about this, but I've never used 802.11s in any capacity.
It looks like RPI3 and its integrated wifi adapter would support it? (Hum. I don't think it does in fact.)

epoch1970
2018-02-13, 15:29
The plot thickens.

The Pi doesn't support 802.11s but batman-adv (https://www.open-mesh.org/projects/open-mesh/wiki) works.
A short install guide (https://www.reddit.com/r/darknetplan/comments/68s6jp/how_to_configure_batmanadv_on_the_raspberry_pi_3/) for Raspbian was posted on Reddit.

I've added the batman-adv module to pcp 3.22 (it's not available from the GUI I think, but I found it in the 4.9.50-pcpCore_v7_modules.tar.gz archive on SF.net)
Then I compiled batctl (see the Reddit post; optional), and could create and manage my first bat0 interfaces.
I attach to this message these 2 files, compiled for pcpCore 4.9.50 "non-Audio" version on Pi 3:
tc@clt3:/mnt/nfs/tce/optional$ md5sum batctl.tcz
71f77ddd67e5f4ca0ff16a8e3d6f0ef4 batctl.tcz
tc@clt3:/mnt/nfs/tce/optional$ md5sum batman-adv.tcz
9a06abf2d1380d82a3408037fb227cb3 batman-adv.tcz

From there, you can create batman mesh wireless interfaces on PCP 3.22 "non-Audio" version, and try your luck synching players.

I have synched 3 players: one has bat0 bridged with eth0, so it can reach LMS; the 2 others are only using the mesh network. I am not testing in the ideal conditions (and with analog out on the Pi 3s) but for CD-resolution music (<1Mbps) the 3 players did sync quite well.
On HD tracks things went downhill, but this was a test with 0 optimization to say the least.
The mesh network somewhat reminds me of syncing with hardware SBs: when sync break they all stop at the same time. With the mesh when a node in the middle can't keep up, its peers stop as well :)

It's not better than good wifi coverage from an AP. But it might be better than bad wifi coverage.
Overall this seems encouraging, perhaps others will care to try and report their findings.



PS: some extra information that will probably confuse the hell out of you.

Just in case, my current onboot.lst. Quite a mess:
pcp.tcz
flac.tcz
ipv6-4.9.50-pcpCore_v7.tcz
#git.tcz
#tcl-dev.tcz
#compiletc.tcz
#bc.tcz
nano.tcz
#autoconf.tcz
squashfs-tools.tcz
batman-adv.tcz
batctl.tcz
libnl-dev.tcz
netfilter-4.9.50-pcpCore_v7.tcz
iproute2.tcz
net-bridging-4.9.50-pcpCore_v7.tcz
bridge-utils.tcz
firmware-atheros.tcz
firmware-brcmwifi.tcz
firmware-rpi3-wireless.tcz
firmware-ralinkwifi.tcz
firmware-rtlwifi.tcz
wifi.tcz

You need wifi.tcz (iwconfig and firmware for your adapter) for batman to work, but the idea was to make a player work without an AP.
The pCP GUI wipes out the firmware and wifi-related tcz packages from onboot.lst if you don't activate wifi. So the trick here is to activate wifi from the GUI, save, then edit /usr/local/sbin/config.cfg and set WIFI="off" instead of "on". Don't forget to "pcp bu" after that.
Or do the deed by hand with "tce-load -w -i <pacakge>" until you have enough packages to fulfill the dependencies.

Because I am short of SDs and expected to crash a lot, I decided to revive my attempt at netbooting, so the the pCP installs would be on a server and easier to access even when a player is stranded. The SD-free netboot seems slightly better than it was, but still not up to snuff.
Since netbooting works only over ethernet, I added insult to injury and bridged the ethernet link with the batman interface created later at boot. After boot I can unplug the ethernet cord on 2 players out of 3 (one must be able to reach LMS on the ethernet LAN)

These are the scripts I've been using:

/opt/bootlocal.sh (the NFS boot part is incidental)

#!/bin/sh
# put other system startup commands here

GREEN="$(echo -e '\033[1;32m')"

echo
echo "${GREEN}Running bootlocal.sh..."
#pCPstart------
/home/tc/www/cgi-bin/do_rebootstuff.sh 2>&1 | tee -a /var/log/pcp_boot.log
#pCPstop------

# Wireless stuff
/home/tc/batman.sh

# NFS mounting. See http://forum.tinycorelinux.net/index.php?topic=19913.0
for i in `cat /proc/cmdline`; do
case $i in
nfsboot*)
# Allows to update pCP boot config over NFS
NFSBOOT=${i#*=}
BOOTMNT="/mnt/mmcblk0p1"
SERVER=$(echo $NFSBOOT | awk -F: '{ print $1 }')
DIR=$(echo $NFSBOOT | awk -F: '{ print $2 }')
OPTS=$(echo $NFSBOOT | awk -F: '{ print $3 }' | tr ',' ' ')
OPTS=$(echo defaults noauto nolock addr=${SERVER} ${OPTS} | tr ' ' ',')
echo "Creating directory ${BOOTMNT}"
sudo mkdir ${BOOTMNT} >/dev/null 2>&1
# pCP checks in fstab for device /dev/mmcblk itself so mounts fail...
# echo "Creating /etc/fstab entry for ${BOOTMNT} over NFS"
# ME="$0"
# sudo sh -c "cat << EOF >> /etc/fstab
## Added by $ME
#${SERVER}:${DIR} ${BOOTMNT} nfs ${OPTS} 0 0
#EOF
#"
# ... so instead we mount permanently as pCP won't mount/unmount
# if mounted already.
echo "Mounting ${SERVER}:${DIR} to ${BOOTMNT}"
sudo mount -t nfs -o ${OPTS} ${SERVER}:${DIR} ${BOOTMNT}
;;
nfsmount*)
# Keep pCP happy with a normal-looking SD mount
NFSMOUNT="/mnt/nfs"
TCEMNT="/mnt/mmcblk0p2"
echo "Creating directory ${TCEMNT}"
sudo mkdir ${TCEMNT} >/dev/null 2>&1
echo "Adding bind mount for ${TCEMNT}"
sudo mount -o bind ${NFSMOUNT} ${TCEMNT} >/dev/null 2>&1
;;
esac
done
/home/tc/batman.sh (slight variations in the end from player to player. Basically copied from the Reddit post)

#!/bin/sh
# Activate batman-adv
modprobe batman-adv
# Disable and configure wlan0
ip link set wlan0 down
ifconfig wlan0 mtu 1532
iwconfig wlan0 mode ad-hoc
iwconfig wlan0 essid mesh
#RPi built-in doesn't seem to support a MAC instead of any
iwconfig wlan0 ap any
iwconfig wlan0 channel 8
sleep 1
ip link set wlan0 up
sleep 1
batctl if add wlan0
sleep 1
ifconfig bat0 up
# Using DHCP and bridging, make sure br0 will use the MAC of eth0
# Otherwise we change of IP address and the previous NFS mount goes stale. No good.
ip link set dev bat0 address fe:12:3c:4e:5f:6a
sleep 1
#bridge
brctl addbr br0
brctl setfd br0 2
# Kill the lease on eth0
killall udhcpc
ifconfig br0 0.0.0.0 up
ifconfig eth0 0.0.0.0 up
ifconfig bat0 0.0.0.0 up
brctl addif br0 eth0
brctl addif br0 bat0
/sbin/udhcpc -b -i br0 -x hostname clt3 -p /var/run/udhcpc.br0.pid
I really don't think bridging is a good idea; I needed it due to NFS booting. The bridge has to have an address on the LAN, when a wireless mesh with ipv4ll addresses would be much more suited (assuming LMS uses an ipv4ll address too). The bridges in mesh nodes hold all the MACs in the LAN, something tells me that might not be completely necessary...
cmdline.txt (nothing specific to wireless, only NFS-related)

cmdline.txt
host=clt3 nfsmount=172.17.71.1:/export/01234abcd/TCE nfsboot=172.17.71.1:/export/01234abcd/BOOT:udp,vers=3,noatime tz=CET-1CEST,M3.5.0,M10.5.0/3 dwc_otg.fiq_fsm_mask=0xF dwc_otg.lpm_enable=0 console=tty1 root=/dev/ram0 elevator=deadline rootwait quiet nortc loglevel=3 noembed smsc95xx.turbo_mode=N noswap cron consoleblank=0 waitusb=2

Kernel version, ifconfig dump:
tc@clt3:~$ uname -a
Linux clt3 4.9.50-pcpCore_v7 #1 SMP Sat Sep 16 15:11:38 EDT 2017 armv7l GNU/Linux
tc@clt3:~$ ifconfig
bat0 Link encap:Ethernet HWaddr FE:12:3C:4E:5F:6A
inet6 addr: fe80::fc87:8fff:fef6:d94e%1996314752/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:765738 errors:0 dropped:0 overruns:0 frame:0
TX packets:1335851 errors:0 dropped:40236 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:103950787 (99.1 MiB) TX bytes:1864822746 (1.7 GiB)

br0 Link encap:Ethernet HWaddr B8:27:EB:XX:XX:XX
inet addr:172.17.255.47 Bcast:172.17.255.255 Mask:255.255.0.0
inet6 addr: fe80::ba27:ebff:xxxx:xxxx%1996314752/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:886479 errors:0 dropped:0 overruns:0 frame:0
TX packets:424919 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1129381640 (1.0 GiB) TX bytes:33966158 (32.3 MiB)

eth0 Link encap:Ethernet HWaddr B8:27:EB:XX:XX:XX
inet6 addr: fe80::ba27:ebff:xxxx:xxxx%1996314752/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2130870 errors:0 dropped:447 overruns:0 frame:0
TX packets:1151174 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2933366455 (2.7 GiB) TX bytes:103045592 (98.2 MiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1%1996314752/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:581 (581.0 B) TX bytes:581 (581.0 B)

wlan0 Link encap:Ethernet HWaddr B8:27:EB:XX:XX:XX
inet6 addr: fe80::ba27:ebff:xxxx:xxxx%1996314752/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1532 Metric:1
RX packets:997527 errors:0 dropped:0 overruns:0 frame:0
TX packets:1491753 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:169223559 (161.3 MiB) TX bytes:1979863957 (1.8 GiB)

epoch1970
2018-02-13, 16:08
Oh, and I just noticed: massive VLAN hop-ing via the bat0 interface. This thing sees and discloses way too many MACs. Some fine-tuning required, I think ;)