Re: [SlimDevices: Unix] Anyone tried synching over 802.11s wireless mesh networking?

2018-02-13 Thread epoch1970

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 ;)



3 SB 3 • Libratone Loop, Zipp Mini • iPeng (iPhone + iPad) • LMS 7.9
(linux) with plugins: CD Player, WaveInput, Triode's BBC iPlayer by bpa
• IRBlaster by Gwendesign (Felix) • Server Power Control by Gordon
Harris • Smart Mix, Music Walk With Me, What Was That Tune? by Michael
Herger • PowerSave by Jason Holtzapple • Song Info, Song Lyrics by
Erland Isaksson • AirPlay Bridge by philippe_44 • WeatherTime by Martin
Rehfeld • Auto Dim Display, SaverSwitcher, ContextMenu by Peter Watkins.

epoch1970's Profile: http://forums.slimdevices.com/member.php?userid=16711
View this thread: http://forums.slimdevices.com/showthread.php?t=108670

___
unix mailing list
unix@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/unix


Re: [SlimDevices: Unix] Anyone tried synching over 802.11s wireless mesh networking?

2018-02-13 Thread epoch1970

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 these 2 files, compiled for the "normal" pcpCore 4.9.50 on Pi
3:
Code:

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


Attached file: batctl+batman-adv.zip 24564

>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:  
Code:

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 " 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) 

Code:

#!/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 $