Alessandro Lannocca

Hi Thomas, thanks for your report - I was thinking about a cronjob too o something that monitors dmesg nevertheless, as a mitigation to avoid a reboot when wifi stops I can suggest: sudo rmmod sprdwl_ng && sudo modprobe sprdwl_ng Definitely not elegant, but gets wifi back from the dead until the next band hop Hope it helps Ale

Dear All, in order to learn about Armbian and experiment a little, I came up with some really basic config files / scripts / patches to adapt my SBC experience to my kali needs (wants) Please bear with me for my lame practices and "coding" style - here's my repo, should it be helpful to anyone Kali Customizing & Co I just own an orangepizero3 and orangepizero2w, with a 5plus in them mail, so conent in my repo will likely cover just those Thank you for managing this project and for supporting us users Grazie 🙏🏻 Ale

After blaming: - networkmanager - ifupdown - systemd - my router - my provider - myself I tested with a separate wifi AP (not managed by my provider) and sprdwl_ng crashes to the point of being incapable of "seeing" any network again (until rmmod and insmod) when the same ESSID is broadcast both under 2.4Ghz and 5.5Ghz My wild assumption is that this driver doens't like (buggy perhaps?) to be "band-steered" Whens ticking to a single band, no issue. Hope it helps someone in my same situation

Dear All, I get frequent and random disconnection from orangepizero3 onboard wifi with armibian community (self-built) both trunk and 24.02 current kernel, 6.6.26 and 6.6.28 message is always [21738.338021] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21848.116072] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21915.426734] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection sm_state (5), status: (2)! [21915.426817] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection Vodafone-CSC failed status code:1! [21919.477424] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [[21738.338021] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21848.116072] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21915.426734] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection sm_state (5), status: (2)! [21915.426817] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection Vodafone-CSC failed status code:1! [21919.477424] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it Full logs available at armbianmonitor -u Any help/hint/solution deeply appreciated

Thank you everyone, I appreciate getting feedback from so many experts! Let me answer by point, hopefully some of my experience might be useful @Igor I get your point, Kali is mostly userspace and the convenience to have everything packaged (and rolling) in the same place - the only thing Armbian lacked was wifi injection capabilities which I solved by placing kali kernel patches in userpatches/kernel/archive/sunxi64-6.6 -rw-r--r-- 1 alex alex 17K apr 13 19:55 dwav-usb-mt-driver.patch -rw-r--r-- 1 alex alex 4,8K apr 13 19:55 kali-wifi-injection.patch -rw-r--r-- 1 alex alex 2,3K apr 13 19:55 wireless-carl9170-Enable-sniffer-mode-promisc-flag-t.patch Got them fresh from Kali's GitLab repo (an they're compatible up to kernel 6.6) Now, here's my build config file: userpatches/config-opi03.conf BOARD=orangepizero3 BRANCH=current RELEASE=trixie DEST_LANG="it_IT.UTF-8" COMPRESS_OUTPUTIMAGE=sha,xz KERNEL_CONFIGURE=no BSPFREEZE=yes CLEAN_LEVEL=debs,images,cache BUILD_DESKTOP=no BUILD_MINIMAL=yes BUILD_EXTERNAL=yes EXTERNAL_NEW=compile INSTALL_HEADERS=yes NO_APT_CACHER=yes ARTIFACT_IGNORE_CACHE=yes #KERNEL_GIT=shallow ENABLE_EXTENSIONS=kali HOST=opi03 #LOCALVERSION=-kali and here's my output from sudo apt update && sudo apt list --updateable pt-utils/kali-rolling 2.7.12+kali1 arm64 [aggiornabile da: 2.7.12] apt/kali-rolling 2.7.12+kali1 arm64 [aggiornabile da: 2.7.12] base-files/kali-rolling 1:2024.1.0 arm64 [aggiornabile da: 24.2.1-13-trixie] bluetooth/kali-rolling 5.71-1+kali1 all [aggiornabile da: 5.71-1] bluez/kali-rolling 5.71-1+kali1 arm64 [aggiornabile da: 5.71-1] command-not-found/kali-rolling 23.04.0-1+kali3 all [aggiornabile da: 23.04.0-1] dpkg/kali-rolling 1.22.4+kali2 arm64 [aggiornabile da: 1.22.4] init-system-helpers/kali-rolling 1.66+kali1 all [aggiornabile da: 1.66] init/kali-rolling 1.66+kali1 arm64 [aggiornabile da: 1.66] libapt-pkg6.0/kali-rolling 2.7.12+kali1 arm64 [aggiornabile da: 2.7.12] libbluetooth3/kali-rolling 5.71-1+kali1 arm64 [aggiornabile da: 5.71-1] libdpkg-perl/kali-rolling 1.22.4+kali2 all [aggiornabile da: 1.22.4] libpolkit-agent-1-0/kali-rolling 124-1+kali1 arm64 [aggiornabile da: 124-1] libpolkit-gobject-1-0/kali-rolling 124-1+kali1 arm64 [aggiornabile da: 124-1] linux-headers-current-sunxi64/trixie 24.2.1 arm64 [aggiornabile da: 24.2.1] linux-image-current-sunxi64/trixie 24.2.1 arm64 [aggiornabile da: 24.2.1] polkitd/kali-rolling 124-1+kali1 arm64 [aggiornabile da: 124-1] As you can see there are Armbian packages being overriden by Kali's counterpart: how may I know there's no "Frankestein" effect under the hood? I'd feel much safer knowing that Kali packages have been bootstrapped during image build itself - If I select "Bookworm" with "kali-extension.sh", the list gets much longer So I tried: Bootstrapping a kali snapshot rootfs (no kernel, no headers, no firmware, no u-boot, no dtbs, and no u-boot-menu, then proceeded installing: -rw-rw-r-- 1 alex alex 21K apr 14 11:55 armbian-bsp-cli-orangepizero3_24.2.1_arm64__1-PC13d1-Ve726-He72f-Ba537-R6632.deb -rw-rw-r-- 1 alex alex 1,7M apr 14 11:55 armbian-bsp-cli-orangepizero3-current_24.2.1_arm64__1-PC13d1-Ve726-He72f-Ba537-R6632.deb -rw-rw-r-- 1 alex alex 133K apr 14 11:53 armbian-config_24.2.1_all__1-SAfb17-B0293-R448a.deb -rw-rw-r-- 1 alex alex 225M apr 14 11:55 armbian-firmware_24.2.1_all__1-SA6b6f-B90f5-R448a.deb -rw-rw-r-- 1 alex alex 414M apr 14 11:54 armbian-firmware-full_24.2.1_all__1-SA6b6f-SMfbef-B90f5-R448a.deb -rw-rw-r-- 1 alex alex 2,4M apr 14 11:52 linux-dtb-current-sunxi64_24.2.1_arm64__6.6.16-Seb3e-D6b4a-P5d69-Cc165Hfe66-HK01ba-Vc222-B067e-R448a.deb -rw-rw-r-- 1 alex alex 94M apr 14 11:52 linux-headers-current-sunxi64_24.2.1_arm64__6.6.16-Seb3e-D6b4a-P5d69-Cc165Hfe66-HK01ba-Vc222-B067e-R448a.deb -rw-rw-r-- 1 alex alex 149M apr 14 11:52 linux-image-current-sunxi64_24.2.1_arm64__6.6.16-Seb3e-D6b4a-P5d69-Cc165Hfe66-HK01ba-Vc222-B067e-R448a.deb -rw-rw-r-- 1 alex alex 911K apr 14 11:52 linux-u-boot-orangepizero3-current_24.2.1_arm64__2024.01-S866c-P6305-H7b37-Vb97c-B11a8-R448a.deb It works a charm and no potential messing between package repos/distributions are present (hopefully), as the above packages are in a locally hosted repo which I manually added to Kali rootfs But this is a tedious work, manual and I can't say if it's good or not, to be honest it works great I'd feel it would be done the "right" way by integrating kali distrib into build scripts @going I'll definitely test KEEP_ORIGINAL_OS_RELEASE=yes and report back @c0rnelius Kali network services, especially avahi being able to broadcast services, thus giving away a penetration tester "presence", are disabled by default - in the past HCIUART was disabled by default too due to some reason I can't remember; nevertheless everything can be (re-)enabled, unmasked, etc by standard means - Kali does even include some fancy cryptroot-luks kernel patches that automatically "destroy" data on boot when full-disk-encryption is active in case of specific passwords being passed (like a dead man's switch I suppose) Thank you for your support guys!

Not strange at all, and by the way, thanks for your interest/support! I need special changes in the kernel, but I managed to get them built via armbian using userpatches I would prefer to keep armbian kernel + headers + firmware + dtb + uboot as they work perfectly I'd find the best solution to have armbian-config manage system configuration (on kali there's kalipi-config but it's raspberrypi oriented) For everything else, I'd prefer a clean rootfs, with kali repositories packages, installed directly at build time via chroot in armbian build framework If I change sources.list afterwards, I get some armbian packages mixed with kali's and vice-versa So ideally, I'd just select "Kali" instead of "trixie" or "bookworm" as distribution, while keeping the final rootfs structure armbian-pristine It isn't any different than enjoying armbian with ubuntu jammy instead of debian bookwork; do I give the idea? Specifically Kali has a lot of metapackages provididing wireless tools, metasploit and windows powershell toolkits and so on; it's specialized in offensive/defensive security; an assortment difficult to find elsewhere without major efforts

Hi @going, thanks for following up! Kali is the de-facto (in my opinion) penetration-testing and learning platform (I'm passionate about wireless) - orangepi boards are very decent hardware-wise but software support is lacking I enjoyed learning and playing around with armbian for the past 3 days, and I think it's the best framework for building self-contained small distros I'm looking towards a clean, lean, cli distro for my SBCs, kali is a great platform and Armbian with its framework works better than the patched-up google-drive solutions from vendor (kernel 6.1 vs kernel 6.6) Being a debian derivative (kali), I see the potential of converging armbian cleanliness with kali - especially since with older framework GoVanguard did it for some boards, and orangepi itself is based on a previous generation of armbian As of now, for running kali, I'm bound to RaspberryPI boards, as are the only ones with broad "mainline" kali coverage - in full honesty though I think armbian is a much superior framework than kali-arm for building I like a lot mainline support and armbian brought mainline support for both u-boot and kernel on orangepizero3 - I want to try and come up with a board config for orangepizero2w on armbian as soon as I find a kali solution! And my orangepi5plus is on its way, I want to play with it too! These topics bring out my beloved nerdiness

Dear All, I found armbian by chance and it's the best supporting linux solution for my orangepizero3 - will later start tinkering with orangepizero2w and orangepi5plus I'd love, along with Debian and Ubuntu, to have Kali selectable as distribution option - linux kernel, dtb, headers, u-boot, overlays and armbian-config would be the perfect base for it (and every other distribution imho) Being inspired by GoVanguard/karmbian, which is based on armbian's previous framework, I tried grossly "injecting" kali support into armbian branch v24.02 - but I'm lost; definitely no developer, just playing around specifically I'm stuck with "lib/functions/general/apt-utils.sh" function "apt_find_upstream_package_version_and_download_url()" - I don't know how to get kali deb packages url - kali tracker doesn't behave like Debian/Ubuntu - my clumsy approach is available at https://github.com/alexl83/build.git branch v24.02 I think orange pi boards are nice and hold potential, but manufacturer is stuck at an old forked armbian framework, old kernel and hacky dtbs - Armbian is great and I hope to get kali tools on it without "Frankensteining" Debian with overlapping repos, conflicts and pinnings Would love to get some proper support - sunxi64-current (6.6) works a charm, injection patches are ok, but even when deployed on trixie and using a kali extension script, the are overlapping packages - It would be great to have Kali distro just integrated in this framework Thanks for those who read all this Fingers crossed Alex