tomeshnet / mesh-orange Goto Github PK

It seems the Raspberry Pi 2 is not executing /init

i tried booting it with init=/init as a command line argument for the kernel and that didn't seem to work either.

See: https://github.com/phillymesh/cjdns-optimizations#optimized-build

Had a conversation with @jedahan who brought up the use case of having one Pi with a blank SD be able to bootstrap off another, perhaps with a USB-SD adapter, or some sort of netboot mechanism. This could be related (but not exactly) to the OS upgrade flow. Tracking that question here to explore options.

Current master is broken. Building for both Raspberry Pi 2 and Orange Pi Zero will hang on this line:

...
mkdir -p build/debian.stretch.armhf/dev
sudo mknod build/debian.stretch.armhf/dev/urandom c 1 9
sudo mkdir -p build/debian.stretch.armhf/usr/sbin/
sudo cp policy-rc.d build/debian.stretch.armhf/usr/sbin/policy-rc.d

Head of confd branch works properly.

In order to improve the way we are handling the firmware, I need to remove most of the firmware files that are currently installed. To ensure that we still have the firmware needed to support for all the expected hardware, I need to ensure some files are added in - but I dont have access to most (all?) of the required hardware to confirm the needed files.

We need to compile a list of supported hardware and the matching firmware.

@benhylau, @darkdrgn2k can you both add all the details you have for this?

#27 and #22 look like they might help

Current list of hardware I know about:

Still need exact firmware file names for most of those though.

Works on raspberrypi3 but not on sun8i-h2-plus-orangepi-zero:

[ 158.290385] usb 3-1: new high-speed USB device number 2 using ehci-platform
[ 158.501113] usb 3-1: New USB device found, idVendor=0cf3, idProduct=9271
[ 158.507829] usb 3-1: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[ 158.515251] usb 3-1: Product: USB2.0 WLAN
[ 158.519264] usb 3-1: Manufacturer: ATHEROS
[ 158.523381] usb 3-1: SerialNumber: 12345
[ 158.564330] usb 3-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[ 158.571740] usbcore: registered new interface driver ath9k_htc
[ 158.577691] usb 3-1: Direct firmware load for ath9k_htc/htc_9271-1.4.0.fw failed with error -2
[ 158.586336] usb 3-1: Falling back to user helper
[ 158.602860] usb 3-1: ath9k_htc: Firmware htc_9271.fw requested
[ 158.608778] usb 3-1: Direct firmware load for htc_9271.fw failed with error -2
[ 158.616118] usb 3-1: Falling back to user helper
[ 158.632714] usb 3-1: no suitable firmware found!
[ 158.637367] usb 3-1: ath9k_htc: Failed to get firmware htc_9271.fw
[ 158.644108] usb 3-1: ath9k_htc: USB layer deinitialized

https://cryptpad.fr/code/#/1/view/dmkJT52Eww3TNFt32m0Afw/AdW4GzPCat7402rFI+sHVovvbTyyALkyy+ZBaJPF1gU

The SD card is a MBR disk containing at least one FAT partition:

• Some unpartitioned space before the first partition contains uboot and some allwinner stuff
• The FAT partition contains:
  • conf.d/ (configs)
  • boot/ (everything else)

To upgrade the node software, the user can mount the FAT filesystem on a computer, then drag-and-drop replace:

• The kernel zImage or other components in boot/
• Drop custom configs into conf.d/

In the rare case that the bootloader (uboot being not in the FAT filesystem) needs to be upgraded, the user can back-up conf.d then reflash the SD card, and drop the backed up config directory into the new FAT filesystem.

Probably should write up something about no IR, radar detection / DFS and setting the regulatory domain.

See:
http://superuser.com/questions/809282/wifi-5ghz-ap-mode-what-does-no-ir-means-and-can-i-bypass-it
http://pisarenko.net/blog/2015/05/05/updates-to-the-802-dot-11ac-guide/

Hello, I've just built an image booted up my orangePi for the first time. Could you give some advice on how to connect to Hyperboria for instance, 'cause I do not see any cjdroute.conf configuration files or any others.

Thanks

There is more info in the scrollback leading up to that bookmark, but the path decided starts from this message onwards:
https://riot.im/app/#/room/!yzLpKcnymfPsdJyjnB:tomesh.net/$1493263569668182qcLJZ:matrix.org

The current orange pi build does not output anything to serial after "Starting kernel ..."

After poking at it i found the issue is probably in zImage
replacing the stock zImage from Armbian yields

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Would like to use mesh-orange for a workshop. What would it take to support the board?

Discussion on network management, naming & enumeration of interfaces:
https://riot.im/app/#/room/!yzLpKcnymfPsdJyjnB:tomesh.net/$1493259582631337zHSQt:matrix.org

Discussed during a video call. Currently, the only real way to demonstrate or experiment with the mesh node platform is to use physical hardware.

As a first step towards allowing virtual environments (regardless of the virtual implementation - local virtual machines, cloud services or even something more exotic), we should generate artifacts for i386/amd64 platformas - similar to the ARM board image artifacts.

For a xD image, this must be a disk image file - the RD image has some more flexibility, so consider creating a bootable ISO image instead of a disk image file.

To make this artifact more usable, the following should also be considered:

• how to configure multiple network interfaces (one for "LAN" and one for "Mesh")
• what options are possible to pass configuration from a cloud automation platform into the booted system

When using http://github.com/benhylau/mesh-router-builder to build the mesh-workshop profile the RPI 3B+ will no longer boots and complains about EOF on the ram disk. However using the same builder without the "mesh-workshop" extras (default profile) it boots fine (just like stock mesh-orange).

It seems the only difference between the two are package that are added.

I have included the error copied form serial console durring boot, and the difference between Default and Mesh-Workshop profiles.

 100.660858] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[  100.666492] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
[  100.673149] of_cfs_init
[  100.675730] of_cfs_init: OK
[  100.679199] RAMDISK: lzma image found at block 0
[  100.706675] RAMDISK: EOF while reading compressed data
[  100.706683] unexpected EOF
[  100.716473] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[  100.724084] Please append a correct "root=" boot option; here are the available partitions:
[  100.732593] 0100            4096 ram0
[  100.732598]  (driver?)
[  100.738788] 0101            4096 ram1
[  100.738792]  (driver?)
[  100.744996] 0102            4096 ram2
[  100.745001]  (driver?)
[  100.751190] 0103            4096 ram3
[  100.751195]  (driver?)
[  100.757401] 0104            4096 ram4
[  100.757406]  (driver?)
[  100.763611] 0105            4096 ram5
[  100.763615]  (driver?)
[  100.768089] mmc1: new high speed SDIO card at address 0001
[  100.775376] 0106            4096 ram6
[  100.775381]  (driver?)
[  100.781587] 0107            4096 ram7
[  100.781592]  (driver?)
[  100.787780] 0108            4096 ram8
[  100.787784]  (driver?)
[  100.791254] usb 1-1: new high-speed USB device number 2 using dwc_otg
[  100.791370] Indeed it is in host mode hprt0 = 00001101
[  100.805737] 0109            4096 ram9
[  100.805742]  (driver?)
[  100.811948] 010a            4096 ram10
[  100.811952]  (driver?)
[  100.818229] 010b            4096 ram11
[  100.818233]  (driver?)
[  100.824527] 010c            4096 ram12
[  100.824532]  (driver?)
[  100.830808] 010d            4096 ram13
[  100.830812]  (driver?)
[  100.837113] 010e            4096 ram14
[  100.837117]  (driver?)
[  100.843410] 010f            4096 ram15
[  100.843418]  (driver?)
[  100.849702] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[  100.858091] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.14.34-v7+ #1110
[  100.864799] Hardware name: BCM2835
[  100.868275] [<8010ffd8>] (unwind_backtrace) from [<8010c240>] (show_stack+0x20/0x24)
[  100.876142] [<8010c240>] (show_stack) from [<807840a4>] (dump_stack+0xd4/0x118)
[  100.883570] [<807840a4>] (dump_stack) from [<8011dc34>] (panic+0xf0/0x274)
[  100.890555] [<8011dc34>] (panic) from [<80b014f8>] (mount_block_root+0x1e8/0x2b8)
[  100.898154] [<80b014f8>] (mount_block_root) from [<80b017e8>] (mount_root+0x12c/0x134)
[  100.906193] [<80b017e8>] (mount_root) from [<80b01990>] (prepare_namespace+0x1a0/0x1e8)
[  100.914320] [<80b01990>] (prepare_namespace) from [<80b010ac>] (kernel_init_freeable+0x2a8/0x2bc

Difference in build

vagrant@stretch:~/mesh-orange-images/mesh-orange/mesh-workshop/debian-config$ diff debian.stretch.multistrap ../../default/debian-config/debian.stretch.multistrap 
2c2
< bootstrap=Stretch Docker Local
---
> bootstrap=Stretch Local
17d16
< # TODO get selected mesh router from node-profiles
19,27d17
< 
< [Docker]
< # TODO add keyring
< source=https://download.docker.com/linux/debian
< suite=stretch
< omitdebsrc=true
< components=nightly
< 
< packages= docker-ce

vagrant@stretch:~/mesh-orange-images/mesh-orange/mesh-workshop/debian-config$ diff packages.txt  ../../default/debian-config/packages.txt 
5,14d4
< # common ssl certificates
< ca-certificates
< 
< # mdns
< avahi-daemon
< libnss-mdns
< 
< # networking tools
< curl
< iperf3
16,18d5
< netcat
< 
< # text editor

Change GitHub project description to something more descriptive of what this project has become.

Current:

Image for a cjdns + IPFS mesh node running on the Orange Pi Zero + TOP-GS07 RT5572 WiFi adapter

Propose:

A small ramdisk system running modern Debian to support mesh networking on single-board computers

After dissecting mesh orange a bit I realized that the way you get the ram disk is by never leaving the initrd stage one boot.

I have not been able to figure out how leechie builds a separate initial initrd and writes the rest of the data to the sd card. Since i was unable to figure out exactly how/where the leechipi writes its

I had some success using the Armbian stock uInitrd to boot the mesh orange with an SD Card (dumping mesh's orange uinitrd into the partition) but there are some incompatibilities so thats not an option.

What do you think the best (or easiest way for now) way to

• Start with a small uInitrd
• Write the mesh orange OS to the partition instead the uInitrd

Even if you can help me figure out the first point the rest i can "Worked around"

Building both a ramdisk and non-ramdisk .img has been discussed between @hamishcoleman @darkdrgn2k and I.

Connection to HostAP establishes fine, but no DNS servers are offered over dhcp.

The motivation for this platform is a low-cost device (USD 20 per node) that can self-organize to form a mesh network. This is expected for use running workshops and also to form ad-hoc or permanent city meshnets.

Preliminary prototyping on both the hardware (Orange Pi Zero 512 MB + TOP-GS07 RT5572 WiFi adapter) and software (Armbian + cjdns + IPFS) have convinced us this is a viable path where we can expect 20 Mbps of cjdns encrypted traffic from node to node (similar performance as a Raspberry Pi 2), carried over 802.11s Mesh Point links at 5 GHz, with support for live update of each node over the mesh.

Software:

• Run everything on RAM so the setup behaves as an embedded system with minimal persisted data
• Documentation to configure or build a custom image
• Package scripts to bring up TOP-GS07 as Mesh Point interface and join the appropriate mesh id
• Package and keep cjdns running all the time
• Package and keep IPFS running all the time
• A config storage solution to persist any required data outside of the ramdisk
• Partition SD card to support live update, storing and versioning system images properly for loading/swapping into RAM
• Securely push and download system images through the mesh itself

Hardware:

• Prototype with various antenna connectors and document range with different antenna gains
  • Default omnidirectional antenna
  • RP-SMA connector with coaxial wire soldered onto board
  • Directional antennas with RP-SMA connector
  • Directional antennas with N-type connector (bridged to board over adapter or pigtail)
• Experiment with a dual-antenna setup by swapping the omnidirectional ceramic antenna on the TOP-GS07 board (there are currently two antennas to the RT5572 chip, one leading to an external antenna and the other to a ceramic package)
• Convert USB adapter board into an Orange Pi Zero hat (see USB pinout)
  

From Linux:

$ cat build/sun8i-h2plus-orangepi-zero.raw > /dev/$SDCARD

From Windows (?):
https://riot.im/app/#/room/!yzLpKcnymfPsdJyjnB:tomesh.net/$1493519399489626cWGRX:matrix.org

Verify:

one way to check - eject it and re-insert it, see if it has a filesystem on it with "/boot" now

NOTE: We may be changing .raw to .img.

I was digging more into systemd and their ini files. Speaking with some of the people in the #systemd rooms the pointed me to the x- prefix that is to be used for settings that are not system.d native

Unit files may contain additional options on top of those listed here. If systemd encounters an unknown option, it will write a warning log message but continue loading the unit. If an option or section name is prefixed with X-, it is ignored completely by systemd. Options within an ignored section do not need the prefix. Applications may use this to include additional information in the unit files. source

Perhaps this is something that we should think of implementing in our link files to prevent future conflict and current log errors?

Error I got trying to make from Gallium OS Chromebook:

After this operation, 105 MB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
  gcc-6-base libc6 libgcc1 mawk base-files sensible-utils debianutils libbz2-1.0 liblzma5 multiarch-support libpcre3 libselinux1 zlib1g libattr1
  libacl1 tar dpkg dash libtinfo5 bash libgpg-error0 libgcrypt20 liblz4-1 libsystemd0 bsdutils coreutils diffutils e2fslibs libaudit-common
  libcap-ng0 libaudit1 perl-base debconf libpam0g libsemanage-common libsepol1 libustr-1.0-1 libsemanage1 libdb5.3 libpam-modules-bin libpam-modules
  passwd libuuid1 libblkid1 libcomerr2 libss2 libfdisk1 libmount1 libncursesw5 libsmartcols1 libudev1 util-linux e2fsprogs findutils grep gzip
  hostname libpam-runtime login mount ncurses-bin sed libdebconfclient0 base-passwd init-system-helpers libc-bin ncurses-base sysvinit-utils
  libapparmor1 libcap2 dmsetup libdevmapper1.02.1 libcryptsetup4 libidn11 libip4tc0 libkmod2 libseccomp2 adduser systemd lsb-base libncurses5
  libprocps6 procps udev tzdata gpgv debian-archive-keyring kmod libssl1.0.2 libbsd0 libedit2 libkeyutils1 libkrb5support0 libk5crypto3 libkrb5-3
  libgssapi-krb5-2 openssh-client dhcpcd5
E: There were unauthenticated packages and -y was used without --allow-unauthenticated
apt download failed. Exit value: 100
Makefile:58: recipe for target 'build/tags/multistrap-pre.armhf' failed
make: *** [build/tags/multistrap-pre.armhf] Error 100

I probably just need to do this in a Debian VM.

During a video call, we discussed adding board support for some additional hardware. I (Hamish) have some hardware available that we will look into adding support for:

• turris omnia (https://omnia.turris.cz/en/)
• expressobin (https://espressobin.net/)
• dragino librerouter (pre-release hardware available - https://librerouter.org/document/schematic-v1/)

Both the omnia and the expressobin are using cpus from the Marvell MVEBU line, but the expressobin is 64bit, which might make it harder to add support.

Can we safely generate keys (e.g. cjdns) on the node if we install haveged?

Is there a reason why raspberrypi2 uses tmpfs and sun8i-h2-plus-orangepi-zero uses ramfs?

I am trying to back the fs with swap memory and it works on Raspberry Pi 3 but not on Orange Pi Zero, possibly due to lack of swap support on ramfs.

After video conference discussion, we have decided that the path forwards for non-ramdisk support should first consider how to work with Raspberry Pi hardware and only secondly consider how to implement some kind of 'factory default' rollback.

Thus, we will be implementing generic ext4 sdcard filesystem image support.

(See also #36 and #48 for older related tickets)

No output on serial on boot
But looks like there is a new dtb

 bcm2710-rpi-3-b-plus.dtb

1 of 10 times nodes would not process everything in conf.d. For example, config doesn't get picked up and the SSID shows as test2 occasionally. Perhaps we just need to increase the wait time for the SD, but this could be unrelated because sometimes there are partial proessing (e.g. SSID and hostname get picked up from conf.d but some .sh did not execute.