Re: Seeking RPM Server package for OpenWrt
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > Date: Wed, 23 Mar 2022 07:28:07 -0400 > From: Rich Brown > To: openwrt-devel@lists.openwrt.org > Cc: "Richard E. Brown" , Rpm > > Subject: Seeking RPM Server package for OpenWrt > Message-ID: <94079409-e562-40e6-bf4e-a0a94a926...@gmail.com> > Content-Type: text/plain; charset=us-ascii > > The Apple "RPM Tool" is great for measuring network responsiveness. > > High numbers from the tool (measured in round-trips per minute - or "RPM") > show your network is responsive, even when it's heavily loaded with traffic. > This also implies you have low "bufferbloat" - which is good. > > There are several RPM clients available: > > * `/usr/bin/networkQuality` on macOS Monterey > * an iOS 15 version described at https://support.apple.com/en-gb/HT212313 > * a golang implementation at > https://github.com/network-quality/goresponsiveness Both are LLVM languages. I don’t think every OpenWrt target is supported by LLVM. > * a Docker implementation in the same repository > > BUT... These all test against servers "out on the internet". There's another > interesting test to be had: testing against the local router. > > This is useful because it would help test the responsiveness of the Wi-Fi > network/drivers of your router. It would allow you to measure whether in > fact, you actually are too far from the router, and whether moving closer > would help. > > My request... Is anyone interested in creating an OpenWrt package that > implements an RPM server? > I’m interested to write an implementation. However: 1) I haven’t looked at the proposal thoroughly 2) I assume that the lowest common denominator for OpenWrt is C. It would be nice to write in e.g. rust but as before there’s the LLVM thing to be taken into account, or the GCC rust backend. Regards, Eugenio Tampieri smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath9k: support for Extreme Networks AP3805i
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > Hello Eugenio, > > On Sat, Feb 26, 2022 at 1:22 PM Eugenio Tampieri via openwrt-devel > wrote: > >> The sender domain has a DMARC Reject/Quarantine policy which disallows >> sending mailing list messages using the original "From" header. >> >> To mitigate this problem, the original message has been wrapped >> automatically by the mailing list software. > > Please consider configuring the DMARC DNS record properly for mailing > lists usage, it is quite annoying to reply to a message that was > wrapped to another message by the mailing list software. BTW, use the > bottom-posting (https://en.wikipedia.org/wiki/Posting_style), please. > > All this is boring, let's talk about something more interesting. > >> -- Forwarded message -- >> From: Eugenio Tampieri >> To: openwrt-devel@lists.openwrt.org >> Date: Sat, 26 Feb 2022 11:08:56 +0100 >> Subject: ath9k: support for Extreme Networks AP3805i >> Sorry for resubmitting this but yesterday I submitted without a subject... >> I'm a CS student and I've used OpenWrt for years. I'm writing to this >> mailing list because I'd like to contribute to the project by adding >> support of the aformentioned device. >> From what I can see, there's already an open PR >> (https://github.com/openwrt/openwrt/pull/3762). I've merged the current >> master into my fork (https://github.com/eutampieri/openwrt) and I've >> built it. I can boot it from ramdisk but as soon as I flash the >> sysupgrade I get this into the serial log: > > |Kernel panic - not syncing: No working init found. Try passing init= >> option to kernel. See Linux Documentation/admin-guide/init.rst for >> guidance.| >> As far as I can tell, the init var isn't passed from the bootloader >> (uboot), but how can I fix this? > > If you are running OpenWrt, the message about a missed init executable > file means that you had some issues with a rootfs partition. OpenWrt > uses the default init path, so there is no need to specify it > manually. So if the kernel reports it can not find a working init, > then the init was really missed. > >> Thanks to Benjamin Kallus we've found that the problem may lay here: >> >> [ 0.433506] 0x0228-0x03f4 : "firmware" >> [ 0.441125] 2 uimage-fw partitions found on MTD device firmware >> [ 0.447182] Creating 2 MTD partitions on "firmware": >> [ 0.452225] 0x-0x005c : "kernel" >> [ 0.458674] 0x005c-0x01cc : "rootfs" >> [ 0.464437] mtd: device 12 (rootfs) set to be root filesystem >> [ 0.471011] mtdsplit: no squashfs found in "rootfs" >> >> When I download the mtdblock for rootfs, I get >> >> DECIMAL HEXADECIMAL DESCRIPTION >> >> 0 0x0 JFFS2 filesystem, big endian >> 10223696 0x9C0050 Zlib compressed data, compressed >> 10224308 0x9C02B4 Zlib compressed data, compressed >> 10225004 0x9C056C Zlib compressed data, compressed > > It looks like a sysupgrade image you used to flash your device lacks > the rootfs part. The JFFS2 signature that you see was written by the > firmware on first boot. Check your sysupgrade image with binwalk to > make sure. > > OpenWrt produces several output files, what file exactly did you use > to flash the device. Does its name contain the 'squashfs-sysupgrade' > suffix? > > I also noticed that you merged Albinhe's commit to the latest OpenWrt > version. Merging can cause unintentional breaking of the firmware > image build. Try to build and flash clean unmerged code, possibly just > from the Albinhe tree. If the clean version boots successfully, then > something went wrong during the merge with the upstream master branch. > If the clean version also fails to boot, then a deeper investigation > into the build process will be required > >> Il 25/02/22 14:23, Benjamin Kallus ha scritto: > > That's right; the rootfs doesn't need specific offsets, you just need > to tell the kernel which partition to use as the rootfs on the kernel > command line. Good luck getting things working! > > On Fri, Feb 25, 2022 at 1:15 PM Eugenio Tampieri > wrote: > > First of all, thanks for your reply. > Second thing, sorry for the empty subject in my previous email. I > was caught off guard by
ath9k: support for Extreme Networks AP3805i
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Sorry for resubmitting this but yesterday I submitted without a subject... I'm a CS student and I've used OpenWrt for years. I'm writing to this mailing list because I'd like to contribute to the project by adding support of the aformentioned device. From what I can see, there's already an open PR (https://github.com/openwrt/openwrt/pull/3762). I've merged the current master into my fork (https://github.com/eutampieri/openwrt) and I've built it. I can boot it from ramdisk but as soon as I flash the sysupgrade I get this into the serial log: >|Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.| As far as I can tell, the init var isn't passed from the bootloader (uboot), but how can I fix this? Thanks to Benjamin Kallus we've found that the problem may lay here: [ 0.433506] 0x0228-0x03f4 : "firmware" [ 0.441125] 2 uimage-fw partitions found on MTD device firmware [ 0.447182] Creating 2 MTD partitions on "firmware": [ 0.452225] 0x-0x005c : "kernel" [ 0.458674] 0x005c-0x01cc : "rootfs" [ 0.464437] mtd: device 12 (rootfs) set to be root filesystem [ 0.471011] mtdsplit: no squashfs found in "rootfs" When I download the mtdblock for rootfs, I get DECIMAL HEXADECIMAL DESCRIPTION 0 0x0 JFFS2 filesystem, big endian 10223696 0x9C0050 Zlib compressed data, compressed 10224308 0x9C02B4 Zlib compressed data, compressed 10225004 0x9C056C Zlib compressed data, compressed Regards, Eugenio Tampieri Il 25/02/22 14:23, Benjamin Kallus ha scritto: That's right; the rootfs doesn't need specific offsets, you just need to tell the kernel which partition to use as the rootfs on the kernel command line. Good luck getting things working! On Fri, Feb 25, 2022 at 1:15 PM Eugenio Tampieri wrote: First of all, thanks for your reply. Second thing, sorry for the empty subject in my previous email. I was caught off guard by the (totally sane and agreeable) rejection of multipart HTML emails so I missed the subject. About the rootfs: I already have the dumps, just not with me. I'll try with different offsets. Does the rootfs partition need to have a particular label (i.e. rootfs)? I thought that by pointing the bootloader to it was enough. Thanks again, Eugenio Tampieri --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hello, I'm new to this list and I hope I'm not doing anything wrong. I'm a CS student and I've used OpenWrt for years. I'm writing to this mailing list because I'd like to contribute to the project by adding support of the aformentioned device. From what I can see, there's already an open PR (https://github.com/openwrt/openwrt/pull/3762). I've merged the current master into my fork (https://github.com/eutampieri/openwrt) and I've built it. I can boot it from ramdisk but as soon as I flash the sysupgrade I get this into the serial log: >Kernel panic - not syncing: No working init found. Try passing init= option to >kernel. See Linux Documentation/admin-guide/init.rst for guidance. As far as I can tell, the init var isn't passed from the bootloader (uboot), but how can I fix this? Moreover, other users on the PR haven't reported any issue with the setup. Regards, Eugenio Tampieri --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
