Re: Buildbots missing for ipq60xx?
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 --- Hi On 2024-08-10, Daniel Nilsson via openwrt-devel wrote: > I was taking a look at the ipq60xx target, and noticed that none of > it's devices are available on the firmware selector. I saw on > https://buildbot.openwrt.org/images/#/builders that the target doesn't > have a builder, is this the reason why the devices are missing? qualcommax/ipq60xx is explicitly marked as source-only and intentionally not built on the buildbots, yet: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/qualcommax/ipq60xx/target.mk AFAIK the major reason for that is the current state of the wireless firmware for ath11k not playing nice with the (typically older) BDF definitions for its devices. > With the upcoming branching of 24.x, it would be good to have that > configured so it at least gets built as part of the next release. It won't be part of the next release, until this is resolved and the source-only flag gets removed - pending a new (and official, not via third parties) wireless firmware release from QCA. Regards Stefan Lippers-Hollmann pgpoUDeNUHhFd.pgp Description: Digitale Signatur von OpenPGP --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: qca-wireless: ipq50xx: ipq5018: add bdf for ikuai sw8
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 --- Hi [this equally applies to all the posted bdf additions for this device] On 2024-02-07, Isaev Ruslan wrote: > This is second bdf for the device: ikuai sw8 > > This one is for ipq5018 chip (stock fw: bdwlan.b24) Given that ipq50xx support is not merged into OpenWrt yet, nor expected to be merged within months (I'm not aware of anyone actively working on qualcommax/ipq50xx for OpenWrt), wouldn't it make more sense to approach kvalo to merge it upstream via QCA/ linux-firmware? Once it is available there, adding it to the ipq-wifi packaging would be straight forward as part of the subtarget/ device support patches. In general, ipq-wifi is only understood as a stopgap measure, to provide the board data files before they're available via linux-fimware (which may take weeks or months), but in this case I'm not seeing ipq50xx as a whole to become available in OpenWrt any time soon (at least multiple months, if someone were to actively work on getting the subtarget merged), so that will give it the time needed to get available via linux-firmware. At least these files should be submitted to kvalo first, if they haven't been merged to linux-firmware by the time OpenWrt is about to get qualcommax/ipq50xx and sw8, this could be revisited, of course. Just at this point I don't see any reason to take these files into ipq-wifi, as long as it is completely unclear if the whole subtarget or the device in question will ever be supported by OpenWrt. Disclaimer: Obviously I'm not an OpenWrt developer and can't for the project in any way. so take this as my personal suggestion for an ideal way forward. Regards Stefan Lippers-Hollmann --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/1] kernel/x86: merge "generic" into "legacy"
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 --- Hi On 2024-01-03, Elliott Mitchell wrote: > On Tue, Jan 02, 2024 at 04:44:04PM -0800, Elliott Mitchell wrote: […] > > --- a/target/linux/x86/legacy/config-6.1 > > +++ b/target/linux/x86/legacy/config-6.1 > > > @@ -92,35 +113,91 @@ CONFIG_DRM_RADEON=y > > CONFIG_DRM_SCHED=y > > CONFIG_DRM_TTM=y > > CONFIG_DRM_TTM_HELPER=y > > +CONFIG_DRM_VIRTIO_GPU=y > > CONFIG_DRM_VRAM_HELPER=y > > +CONFIG_EFI=y > > +CONFIG_EFIVAR_FS=m > > I'm unsure about this. I don't know whether any P4s actually had EFI > firmware. According to the handy resource, initial versions of EFI were > out by 2004 so some P4s might have had EFI. I never touched them due to > their terrible characteristics so I don't actually know. Second generation Atom had 64 bit capable CPUs, but often a 32-bit UEFI, given that our x86_64 images only ship with 64 bit UEFI support, using an i386 image with 32 bit UEFI might be necessary for those (it's not ideal, of course). > > @@ -154,15 +237,38 @@ CONFIG_ISA_BUS_API=y > > CONFIG_ISO9660_FS=y > > # CONFIG_JOLIET is not set > > CONFIG_KCMP=y > > +CONFIG_KVM=y > > +CONFIG_KVM_AMD=y > > +CONFIG_KVM_ASYNC_PF=y > > +CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y > > +CONFIG_KVM_GUEST=y > > +CONFIG_KVM_INTEL=y > > +CONFIG_KVM_MMIO=y > > +CONFIG_KVM_VFIO=y > > +# CONFIG_KVM_XEN is not set > > +CONFIG_KVM_XFER_TO_GUEST_WORK=y > > Apparently it is genuinely possible to use KVM on some non-amd64 x86 > processors. Core (1) solo was 32 bit only, but kvm capable. This weird combination only lasted a short time, but it exists (but I seem to remember that qemu might have dropped support for kvm on i386 hosts rather recently)… […] > > +CONFIG_PHYS_ADDR_T_64BIT=y > > +CONFIG_PINCTRL=y > > +CONFIG_PINCTRL_ALDERLAKE=y > > +CONFIG_PINCTRL_BAYTRAIL=y > > +CONFIG_PINCTRL_BROXTON=y > > +CONFIG_PINCTRL_CANNONLAKE=y > > +CONFIG_PINCTRL_CHERRYVIEW=y > > +CONFIG_PINCTRL_DENVERTON=y > > +CONFIG_PINCTRL_ELKHARTLAKE=y > > +CONFIG_PINCTRL_EMMITSBURG=y > > +CONFIG_PINCTRL_GEMINILAKE=y > > +CONFIG_PINCTRL_INTEL=y > > +CONFIG_PINCTRL_JASPERLAKE=y > > +CONFIG_PINCTRL_LAKEFIELD=y > > +CONFIG_PINCTRL_LEWISBURG=y > > +CONFIG_PINCTRL_LYNXPOINT=y > > +CONFIG_PINCTRL_METEORLAKE=y > > +CONFIG_PINCTRL_SUNRISEPOINT=y > > +CONFIG_PINCTRL_TIGERLAKE=y > > Yes, CONFIG_X86_INTEL_LPSS=y made its way into "generic" and thus it got > here. I'm unaware of any of these ever being paired with a non-amd64 > processor. This seems wrong, but that is what was in "generic". These are all x86_64. […] > > +CONFIG_VIRTIO=y > > +CONFIG_VIRTIO_BALLOON=y > > +CONFIG_VIRTIO_BLK=y > > +CONFIG_VIRTIO_CONSOLE=y > > +CONFIG_VIRTIO_DMA_SHARED_BUFFER=y > > +CONFIG_VIRTIO_INPUT=y > > +CONFIG_VIRTIO_MMIO=y > > +CONFIG_VIRTIO_NET=y > > +CONFIG_VIRTIO_PCI=y > > +CONFIG_VIRTIO_PCI_LEGACY=y > > +CONFIG_VIRTIO_PCI_LIB=y > > +# CONFIG_VIRTIO_PMEM is not set > > +CONFIG_VIRTUALIZATION=y > > Rather less commonly used for "legacy"-class machines, but it was > genuinely available. Running an i386 VM on x86_64 hosts is not uncommon, these are for the emulated hardware in a VM, not (necessarily) the host. > > +CONFIG_XEN=y […] > > Xen got started on this class of machine. At the time 4GB of memory > would have been a $20K+ computer, but these did exist. Anything "legacy" > *can* use Xen, though I'm doubtful very many people will continue to use > it on this type of hardware. Some of those are in the same boat as kvm/ virtio drivers, necessary inside the VM, but I'm not a specialist on XEN (and XEN underwent massive architectural changes to be accepted mainline, making the details even more complex). Regards Stefan Lippers-Hollmann --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 11/11] kernel/x86: enable x32 support for amd64
Hi On 2023-11-14, Elliott Mitchell wrote: > On Wed, Nov 15, 2023 at 05:35:11AM +0100, Stefan Lippers-Hollmann wrote: > > On 2023-11-14, Elliott Mitchell wrote: [...] > > What would be the reason for enabling x32? > > There is very little upstream buy-in for x32, when this question came > > up for Debian, it was rejected to be enabled for -among other reasons- > > concerns about the the system call ABI and its security hardening, as > > well as concerns about the long term ABI compatibility (the later of > > which probably not that relevant for OpenWrt, the former however is). > > What I see seems like x32 is still making progress on Debian. I note > musl has a x32 target. While it still isn't a release architecture for > Debian, I could see it becoming one. I wouldn't really consider this to be very likely, if at all, it has become even less likely than it was over a decade ago. > > I do understand that this is a pet peeve among the high-density > > virtualization crowd, but anywhere else, x32 as a concept is dead (and > > never took off in the first place). > > In my view x32 has some substantial use cases. Have you ever seen `ls`, > `rm`, `grep`, `find`, or `test` needing more than 4GB of memory? Any > of these needing that much memory would suggest something was wrong > (or perhaps someone was trying to abuse them in an impressive way). For > quite a number of shell utilities being able to use more than 4GB of > memory is pointless. The counter question would be, does it hurt? Yes, the x32 proponents (mostly from the high-density virtualization crowd and, as Linus called it "extreme benchmarking" environments) will point out that pure-x32 uses slightly less disk space and slightly less RAM than pure64, but we are talking about very little in today's world. > This is speculation, but I suspect there would be substantial value in > having mixed systems where some utilities were x32 and some were amd64. Please point out what exactly those would be, especially in the context of OpenWrt. If you really want to mix x32 and amd64 binaries, you will need a full library set (binary packages - co-installable) for both x32 and x86_64 installed and in RAM - which is completely detrimental to any of the gains promised above. x32 only works, if you have (aside from the kernel itself) a pure-x32 userspace, or your losses in terms of additional disk space and RAM usage outweigh your gains by an order of magnitude. In a general purpose distribution you might ignore that by claiming that 'only' your big database management system (and its dependencies) would have to be a 64 binary (or some other -very isolated, compared to the rest of the running system- big component), but the situation for OpenWrt is different. This kind of mixed userspace would be a nightmare for complexity on the source side - and/or would require Debian-style multiarch support. Neither of which is very likely to succeed for OpenWrt (let alone for opkg). > > *If* (and imho, again purely my own irrelevant opinion, that is a > > big IF) x32 would really be deemed worthwhile for OpenWrt, it still > > doesn't make sense to enable this whole userspace ABI for the x86_64 > > kernel now, before your desired additional patches are available > > (and even then, you'd probably want a dedicated x32 subtarget instead > > of killing off the pure64 target for OpenWrt - something I'd > > personally be even less in favour of). > > Enabling the kernel support is always the first step. How does one test > userspace if the kernel won't even load the executables? In a general purpose distribution one might say that, however even there one would expect quite a lot of testing having happened before enabling a complete new/ additional ABI to userspace (duplicate to the native one), something akin to the semi-official debian-ports infrastructure, used for bootstrapping of new ports or retiring old ones that still have some form of interest. But in this case there is nothing to test in isolation, as there are no x32 binaries compatible with OpenWrt (you could only test inside a non-OpenWrt x32 chroot, but that's barely grounds for enabling x32 in OpenWrt's kernel, just in case; otherwise float emulation would be enabled for mips, to facilitate Debian chroots - spoiler, it's not). In contrast to the changes necessary (buildsystem, image generation, kernel configs, etc.) to test an OpenWrt x32 subtarget, a lazy-man's two-line patch of enabling X86_X32 && X86_X32_ABI would be trivial in comparison to anything of the rest that would be needed. Given that OpenWrt doesn't have any binary compatibility between major versions and needs to get rebuilt in total for each new revision, there is no need to stage- and phase in addi
Re: [PATCH 11/11] kernel/x86: enable x32 support for amd64
Hi On 2023-11-15, Stefan Lippers-Hollmann wrote: > On 2023-11-14, Elliott Mitchell wrote: > > Date: Thu, 30 Mar 2023 16:30:49 -0700 > > > > Full amd64 support isn't really appropriate for most situations > > OpenWRT is deployed. Whereas x86-x32 seems extremely appropriate for > > these situations. As such enable x86-x32 support. [...] > What would be the reason for enabling x32? > There is very little upstream buy-in for x32, when this question came > up for Debian, it was rejected to be enabled for -among other reasons- > concerns about the the system call ABI and its security hardening, as > well as concerns about the long term ABI compatibility (the later of > which probably not that relevant for OpenWrt, the former however is). Just to add some references to this: - Can we drop upstream Linux x32 support? https://lkml.org/lkml/2018/12/10/1145 the whole thread is interesting and doesn't display too much sympathy for x32 - information about the never merged/ defunct x32 port proposed for Debian https://wiki.debian.org/X32Port Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 11/11] kernel/x86: enable x32 support for amd64
Hi On 2023-11-14, Elliott Mitchell wrote: > Date: Thu, 30 Mar 2023 16:30:49 -0700 > > Full amd64 support isn't really appropriate for most situations > OpenWRT is deployed. Whereas x86-x32 seems extremely appropriate for > these situations. As such enable x86-x32 support. > > CONFIG_ARCH_MMAP_RND_COMPAT_BITS is required to follow along, > otherwise the kernel build breaks. > > Signed-off-by: Elliott Mitchell > --- > > I suggest OpenWRT should place some effort towards x86-x32. x86-x32 > seems a rather superior generic target for OpenWRT. Only issue is > it could be valuable to have at least minimal amd64 userland support > alongside the x86-x32 version. > > Note, this simply enables kernel support. Until userspace building > is added, this does almost nothing. What would be the reason for enabling x32? There is very little upstream buy-in for x32, when this question came up for Debian, it was rejected to be enabled for -among other reasons- concerns about the the system call ABI and its security hardening, as well as concerns about the long term ABI compatibility (the later of which probably not that relevant for OpenWrt, the former however is). I do understand that this is a pet peeve among the high-density virtualization crowd, but anywhere else, x32 as a concept is dead (and never took off in the first place). Talking about x86_64, as we have it right now, I don't see much of a reason to change the current concept of 64-bit kernel and pure64 userland (and that's far from being a minimal setup, running on the bare iron and having loaded quite bulky adblock lists): # free -m totalusedfree shared buff/cache available Mem:3924052 75720 36407323424 207600 3768960 Swap: 0 0 0 *If* (and imho, again purely my own irrelevant opinion, that is a big IF) x32 would really be deemed worthwhile for OpenWrt, it still doesn't make sense to enable this whole userspace ABI for the x86_64 kernel now, before your desired additional patches are available (and even then, you'd probably want a dedicated x32 subtarget instead of killing off the pure64 target for OpenWrt - something I'd personally be even less in favour of). What's the purpose for this patch now? OpenWrt doesn't ship anything needing the x32 (yet), the only use for it would be running x32 binaries in a non-OpenWrt x32 chroot (and there aren't that many general purpose distributions available to choose from) on top of OpenWrt. That aside, I may be confused by the config stacking order, but... If I read it correctly, you enable CONFIG_X86_X32 in target/linux/x86/config-*, while explicitly disabling it in the only subtarget config (target/linux/x86/64/config-*) where it would matter, is that really the intended way round and in line with the commit description? Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 08/11] kernel/x86: move SCx200 support from generic to geode
Hi
On 2023-11-14, Elliott Mitchell wrote:
> Date: Thu, 13 Apr 2023 17:07:20 -0700
>
> The SCx200 is part of the Geode platform. As such generic x86
> doesn't need the driver, but Geode does.
Not objecting against this patch, just taking it as an opportunity to ask
an orthogonal question...
Are three 32-bit x86 subtargets still needed/ warranted?
I mean all of these targets are basically obsolete and very low-end/
low-speed (hard to compete against mt7621a), so do the subtarget
specific optimizations really make sense anymore (are there any rough
performance comparisons or other reasons to keep them separate)?
Maintenance for three i386 subtargets is quite signficant, while at
the same time not very motivating to do the same steps three times
for e.g. kernel bumps.
/*
Very much imho (and my opinion is not at all relevant), bumping the
baseline to generic or dropping it down to legacy (geode?) would
be preferable to the status quo (so one x86_64 subtarget and one
combined i486/i586/i686 subtarget).
*/
Regards
Stefan Lippers-Hollmann
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
Hi
On 2023-09-14, Paul Spooren wrote:
> Hi,
>
> I’d like to merge the PR which adds the Mellanox Spectrum SN2100 to
> OpenWrt[1]. In its current state a new x86 image would be added next
> to the generic x86 image. Another approach is to add all related
> packages to the default image. Either way creates a working image.
>
> I remember that people were complaining about a “bloated” x86 image
> which slows down their container/VM needs. So what would be a simple
> way forward here?
[...]
If at all reasonably possible (assuming the size increase is roughly in
the ball park of 1-2 MB for the total image), I'd suggest to stick to a
single x86_64 image for maintenance and testing reasons alone. The bump
of the x86 targets to kernel v6.1 -while easy- is mostly stalled due to
there being three 32 bit x86 sub-targets and the need to go through the
kernel config rebase three times, which is wearing thin the patience and
motivation of doing so (x86_64 alone would have been ready >2 months
ago). Unless these SN2100 devices suddenly become a cheap commodity and
ubiquitous among OpenWrt developers and -users, I fear that it would
just add to this churn and pretty much rot away in the tree, while at
the same time making progress harder for the other x86{,_64} devices.
Regards
Stefan Lippers-Hollmann
pgpbyqv1ZCjkx.pgp
Description: Digitale Signatur von OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
Hi On 2023-05-03, Elliott Mitchell wrote: > On Tue, May 02, 2023 at 02:45:43AM +0200, Alberto Bursi wrote: > > On 26/04/23 22:17, Elliott Mitchell wrote: [...] > > Then there is the virtualized drivers that were just added to the kernel > > and not properly modulized, maybe it was easier like that, don't know. > > These two are the same issue. Not including the drivers for a hypervisor > could make the image not boot on that hypervisor. Though most > hypervisors will include some fallback device emulation which provides > inferior performance. > > > Because on x86_64 storage and RAM is measured in Gigabytes so saving a > > few hundred kilobytes by removing the "all hardware just works with a > > single image" feature is NOT a worthy tradeoff. > > Partially true, partially untrue. Saving a few hundred kilobytes isn't > worthwhile. Shrinking the kernel by 35% and userspace by 20% though IS > worthwhile. > > Notably I'm making use of Xen. The Xen devices don't try to look like > normal hardware. As a result the Xen block devices don't depend on the > SCSI subsystem. Then you completely disable all emulated graphics > devices (simulated serial consoles work fine) and things have shrunk > drastically. [...] And combining these two statements, you're in a catch-22 dilemma... If you optimize the kernel configuration for Xen-only, it will no longer boot on qemu-kvm, hyper-v, virtualbox, vmware. Once you resurrect support for all of those, your high-density virtualization goals go out of the window - and the gap to support for real hardware becomes negligible, especially once you add in support for IOMMU/ DMAR based PCI pass-through support (which was already mentioned to pass through wireless cards). > I'm concerned at the large number of things enabled in the kernel > configurations. Traditionally OpenWRT has used f2fs, yet x86 also has > ext4. With the percentage of systems using SSDs, would seem advantageous > to stick with that flash-friendly choice. [...] f2fs && ext4 is a bad example here, on the one hand for the reasons Daniel Golle has already raised (the selection between f2fs and ext4 being based on the overlay size at firstboot time), on the other hand because we are only talking about a few KB in this case (and f2fs is a horrible filesystem, huge overhead (way more than half of those 100 MB given as deciding factor), bad fsck options, bad (online-)resize behaviour, so killing f2fs with fire would be the more sensible approach - not forgetting that dropping ext4 support would kill the ext4 based images, which are very popular among x86 and ARM SBC (RPi, sunxi, rockchip) users). > Many desktops can use a serial port as console (universal on servers). > Hypervisors generally provide some flavor of serial port-like device > (often they misbehave by doing rather more than 115.2kbps). Serial console ports (in the sense of rs-232c) on consumer desktops became extinct around sandy-bridge times, consumer notebooks haven't had them for over two decades by now. Yes, in some cases you will find a non-standard onboard header for them, but even that isn't a given. Yes, I'm aware that business computers are more likely to sport serial consoles (even today) and that dedicated x86_64 routing platforms and rack servers are very likely to have them, but those aren't the only (very common-) x86 system. None of your consumer (desktop-) mainboards/ system will, none of your notebooks will either - and it takes two to tango (admitted, the client side may go with USB2serial adapters, but the host side won't be able to). There may be optimization potential for 32 bit x86, in the sense of covering generic, geode and legacy in one image - as all of these are obsolete hardware, with little gains by different ISA optimizations. There is definitively potential to merge UEFI and legacy-CSM images into one for x86_64, but I don't really see any reason to drop hardware support for x86_64/generic. If you really wanted to provide high-density demands, you'd end up with at least five (kvm, Xen, hyper-v, virtualbox, vmware, parallels, maybe more) new images next to x86_64/generic, which I don't think anyone really wants or needs (those who do, will want even more fine-tuned images, and x32 may be part of those considerations). And no, I'm not advocating for this, at all. Regards Stefan Lippers-Hollmann pgpXuyOJF1aW7.pgp Description: Digitale Signatur von OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/9] (mostly) x86 kernel configuration adjustments
Hi On 2023-04-26, Elliott Mitchell wrote: > On Thu, Apr 27, 2023 at 01:11:13AM +0200, Stefan Lippers-Hollmann wrote: > > On 2023-04-26, Elliott Mitchell wrote: > > [...] > > > > > > Looks like little of ISA remained on "64", yet some DMA support remained > > > due to the generic configuration. Remove the ISA and ISA DMA support > > > from the top-level configuration. Geode and Legacy though almost > > > certainly still need ISA support. > > > > You might find that while ISA went away as an addon slot quite quickly, > > it still survived rather long for low performance onboard devices (e.g. > > sensors). > > I know, I was unsure of when it 100% disappeared. Do you expect anything > besides "legacy" to be used for this type of system though? [...] Ignoring industrial PCs (where you may still encounter ISA today), you'd have to venture into the pre-LPC days (and AMD, VIA, nVidia might have gone with ISA beyond that) - which might get you into the 2005-2009 time frame (anything with an onboard floppy controller might be worth looking at - and those were still around into the LGA755/ core2 (x86_64) days - in that particular case probably LPC based though). Regards Stefan Lippers-Hollmann pgptGI7NfSgkh.pgp Description: Digitale Signatur von OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/9] (mostly) x86 kernel configuration adjustments
On 2023-04-26, Elliott Mitchell wrote: [...] > > Looks like little of ISA remained on "64", yet some DMA support remained > due to the generic configuration. Remove the ISA and ISA DMA support > from the top-level configuration. Geode and Legacy though almost > certainly still need ISA support. You might find that while ISA went away as an addon slot quite quickly, it still survived rather long for low performance onboard devices (e.g. sensors). > In case someone doesn't know, "AGP" is short for "Accelerated Graphics > Port". This was an interim standard when graphics cards in the late > 1990s were overwhelming PCI, but PCI-Express wasn't yet available. Since > OpenWRT is a router distribution, this doesn't seem like a good fit. If > you've got such an Intel board, this will reduce graphics performance, > but will release ~.5MB extra memory for better uses. While *I personally* wouldn't consider systems of this vintage for 24/7 operations (power consumption alone), AGP has been in use for quite a while longer than that (mid 2000s). I do still have (fully functional) Pentium 4 and AMD64 systems with AGP graphics. I have responded to DRM and x86_x32 individually, but while I understand these proposals from a virtualization-only point of view, they are not very useful on real x86/ x86_64 hardware - up to the point of being actively harmful in breaking support for existing hardware. (It's pointless to enable x32, unless you can demonstrate that OpenWrt's buildsystem can successfully build for it, with a 32 bit userland and 64 bit kernels). Regards Stefan Lippers-Hollmann pgpI7VuI7p1FI.pgp Description: Digitale Signatur von OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 9/9] kernel/x86: remove DRM support
Hi
On 2023-04-19, Elliott Mitchell wrote:
> Direct Rendering Manager is mainly for running X (possibly Wayland
> too). As OpenWRT is meant for networking devices, there is no need
> for the support to be present.
That is only partially true, the Linux kernel is making a strong push
away from deprecated (FB_*) graphics drivers to DRM based ones, with
kernel based mode setting this is getting more (any) attention for
console support as well. Even without getting anywhere near X/ Wayland,
there is more than just a 80x25 tty on real hardware (and even VMs).
Regards
Stefan Lippers-Hollmann
pgp63BeoHYHk5.pgp
Description: Digitale Signatur von OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 6/9] kernel/x86: enable x32 support for amd64
Hi On 2023-03-30, Elliott Mitchell wrote: > Full amd64 support isn't really appropriate for most situations > OpenWRT is deployed. Whereas x86-x32 seems extremely appropriate for > these situations. As such enable x86-x32 support. > > CONFIG_ARCH_MMAP_RND_COMPAT_BITS is required to follow along, > otherwise the kernel build breaks. > > Signed-off-by: Elliott Mitchell > --- > I suggest OpenWRT should be placing quite a bit of effort towards > x86-x32. x86-x32 seems a rather superior generic target for OpenWRT. > Only issue is it could be valuable to have at least minimal amd64 > userland support alongside the x86-x32 version. x86_32 is pretty much dead in the water, with almost zero deployment by general purpose distributions - apart from VM data centre environments doing their own thing (least amount of RAM usage possible, everything else being secondary at best). At least Debian did raise security concerns about the x86_32 ISA in the past. While I might understand (understand, not support) a desire for this as a dedicated subtarget (to appease the virtualization crowd), although I still don't see a reason or sufficient uptake in more conventional Linux environments. I would not be happy (at all) to lose 'normal' x86_64 support (on real hardware) for this exotic fringe hybrid. I can imagine that actually building for this environment (with a 32 bit userland) might lead to 'funny' results as well (as in major toolchain changes necessary to get it working as expected). Regards Stefan Lippers-Hollmann pgpOhkC04JJfF.pgp Description: Digitale Signatur von OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 22.03.3 for mvebu (Turris Omnia)
Hi
On 2023-02-03, Sebastian Moeller wrote:
> MVEBU devices are not supported in kernel 5.10 based OpenWrt22.03.3 due to a
> bug.
> The fix is already in 5.15, but seems to intrusive to backport.
> Current snapshot builds are on kernel 5.15 already and the issue does not
> exist anymore.
> So the easy ways forward are:
> 1) stick to 22.03.2
[...]
Just to be clear and explicit about it, 22.03.0, 22.03.1 and 22.03.2
are affected just the same as 22.03.3 would have been, so the decision
should be more about going back to 21.02.x or going forward to
(master-) snapshots, until the next kernel v5.15 based major stable
release arrives (23.xy.0) or until 22.03.x gets fixed eventually
(which doesn't appear to be very likely at the moment).
Regards
Stefan Lippers-Hollmann
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64
Hi On 2023-01-06, Christian Marangi wrote: > On Thu, Jan 05, 2023 at 02:03:24PM -0800, Brian Norris wrote: > > On Thu, Jan 5, 2023 at 11:59 AM Brian Norris [...] > > Do I need to create some intermediate/stub package just to express the > > dependency, or is there some better way? > > > > In theory there is [1] coreutils-base64 as a separate package but I > think we have to move that to core packages as it's part of the feeds > package. There would be another alternative for base64 functionality, openssl... While not the lightest package, it's already available in main and with DEVICE_PACKAGES a relatively low-maintenance alternative. openssl enc -base64 -in foo -out foo.base64 openssl enc -d -base64 -in foo.base64 -out foo With root/ overlay on eMMC, this shouldn't be too heavy for this kind of hardware. Disclaimer: I did not check wolfssl/ mbedtls for potential alternatives. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] hostapd: update to 2022-05-08
Hi On 2022-06-12, Stefan Lippers-Hollmann wrote: > On 2022-06-07, David Bauer wrote: > > Update hostapd to Git HEAD from 2022-05-08. This allows us to take > > advantage of background radar-detection ad well as BSS color collision. > > I'm noticing a build failure for wpad-full-openssl since this patch > series went in, Debian/ unstable build host (x86_64), x86_64 build > target: Looking into this further suggests OPENSSL_NO_DEPRECATED=y being the cause of this build failure [...] > ../src/crypto/crypto_openssl.c: In function 'crypto_rsa_oaep_sha256_encrypt': > ../src/crypto/crypto_openssl.c:4003:13: warning: implicit declaration of > function 'EVP_PKEY_CTX_set_rsa_padding'; did you mean > 'EVP_PKEY_CTX_set_dh_pad'? [-Wimplicit-function-declaration] > 4003 | EVP_PKEY_CTX_set_rsa_padding(pkctx, > RSA_PKCS1_OAEP_PADDING) <= 0 || > | ^~~~ > | EVP_PKEY_CTX_set_dh_pad > ../src/crypto/crypto_openssl.c:4003:49: error: 'RSA_PKCS1_OAEP_PADDING' > undeclared (first use in this function) > 4003 | EVP_PKEY_CTX_set_rsa_padding(pkctx, > RSA_PKCS1_OAEP_PADDING) <= 0 || > | ^~ > ../src/crypto/crypto_openssl.c:4003:49: note: each undeclared identifier is > reported only once for each function it appears in > ../src/crypto/crypto_openssl.c:4004:13: warning: implicit declaration of > function 'EVP_PKEY_CTX_set_rsa_oaep_md'; did you mean > 'EVP_PKEY_CTX_set_dh_kdf_md'? [-Wimplicit-function-declaration] > 4004 | EVP_PKEY_CTX_set_rsa_oaep_md(pkctx, EVP_sha256()) <= 0 || > | ^~~~ > | EVP_PKEY_CTX_set_dh_kdf_md > ../src/crypto/crypto_openssl.c: In function 'crypto_rsa_oaep_sha256_decrypt': > ../src/crypto/crypto_openssl.c:4040:49: error: 'RSA_PKCS1_OAEP_PADDING' > undeclared (first use in this function) > 4040 | EVP_PKEY_CTX_set_rsa_padding(pkctx, > RSA_PKCS1_OAEP_PADDING) <= 0 || > | ^~ > make[4]: *** [../src/build.rules:86: > /tmp/pkg/openwrt/build_dir/target-x86_64_musl/hostapd-wpad-full-openssl/hostapd-2022-05-08-b859b9bc/build/hostapd/src/crypto/crypto_openssl.o] > Error 1 [...] > CONFIG_OPENSSL_NO_DEPRECATED=y > # CONFIG_OPENSSL_WITH_DEPRECATED is not set and indeed, setting CONFIG_OPENSSL_WITH_DEPRECATED=y # CONFIG_OPENSSL_NO_DEPRECATED is not set instead avoids the build failure. Sorry for the noise. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] hostapd: update to 2022-05-08
NFIG_PACKAGE_librrd1=m CONFIG_PACKAGE_libsensors=y CONFIG_PACKAGE_libstdcpp=y CONFIG_PACKAGE_libsysfs=y CONFIG_PACKAGE_libubus-lua=m CONFIG_PACKAGE_libuci-lua=m CONFIG_PACKAGE_libudev-zero=y CONFIG_PACKAGE_libusb-1.0=y CONFIG_PACKAGE_libustream-openssl=m CONFIG_PACKAGE_libustream-wolfssl=m CONFIG_PACKAGE_libwolfssl=m CONFIG_PACKAGE_libxtables=m CONFIG_PACKAGE_lm-sensors=y CONFIG_PACKAGE_lsblk=y CONFIG_PACKAGE_lua=m CONFIG_PACKAGE_luci=m CONFIG_PACKAGE_luci-app-adblock=m CONFIG_PACKAGE_luci-app-ddns=m CONFIG_PACKAGE_luci-app-firewall=m CONFIG_PACKAGE_luci-app-nlbwmon=m CONFIG_PACKAGE_luci-app-opkg=m CONFIG_PACKAGE_luci-app-p910nd=m CONFIG_PACKAGE_luci-app-sqm=m CONFIG_PACKAGE_luci-app-statistics=m CONFIG_PACKAGE_luci-app-uhttpd=m CONFIG_PACKAGE_luci-app-wireguard=m CONFIG_PACKAGE_luci-app-wol=m CONFIG_PACKAGE_luci-base=m CONFIG_PACKAGE_luci-compat=m CONFIG_PACKAGE_luci-i18n-adblock-de=m CONFIG_PACKAGE_luci-i18n-adblock-en=m CONFIG_PACKAGE_luci-i18n-base-de=m CONFIG_PACKAGE_luci-i18n-base-en=m CONFIG_PACKAGE_luci-i18n-ddns-de=m CONFIG_PACKAGE_luci-i18n-ddns-en=m CONFIG_PACKAGE_luci-i18n-firewall-de=m CONFIG_PACKAGE_luci-i18n-firewall-en=m CONFIG_PACKAGE_luci-i18n-nlbwmon-de=m CONFIG_PACKAGE_luci-i18n-nlbwmon-en=m CONFIG_PACKAGE_luci-i18n-opkg-de=m CONFIG_PACKAGE_luci-i18n-opkg-en=m CONFIG_PACKAGE_luci-i18n-p910nd-de=m CONFIG_PACKAGE_luci-i18n-p910nd-en=m CONFIG_PACKAGE_luci-i18n-sqm-de=m CONFIG_PACKAGE_luci-i18n-sqm-en=m CONFIG_PACKAGE_luci-i18n-statistics-de=m CONFIG_PACKAGE_luci-i18n-statistics-en=m CONFIG_PACKAGE_luci-i18n-uhttpd-de=m CONFIG_PACKAGE_luci-i18n-uhttpd-en=m CONFIG_PACKAGE_luci-i18n-wireguard-de=m CONFIG_PACKAGE_luci-i18n-wireguard-en=m CONFIG_PACKAGE_luci-i18n-wol-de=m CONFIG_PACKAGE_luci-i18n-wol-en=m CONFIG_PACKAGE_luci-lib-base=m CONFIG_PACKAGE_luci-lib-ip=m CONFIG_PACKAGE_luci-lib-ipkg=m CONFIG_PACKAGE_luci-lib-jsonc=m CONFIG_PACKAGE_luci-lib-nixio=m CONFIG_PACKAGE_luci-mod-admin-full=m CONFIG_PACKAGE_luci-mod-network=m CONFIG_PACKAGE_luci-mod-status=m CONFIG_PACKAGE_luci-mod-system=m CONFIG_PACKAGE_luci-proto-ipv6=m CONFIG_PACKAGE_luci-proto-ppp=m CONFIG_PACKAGE_luci-proto-wireguard=m CONFIG_PACKAGE_luci-ssl-openssl=m CONFIG_PACKAGE_luci-theme-bootstrap=m CONFIG_PACKAGE_luci-theme-openwrt-2020=m CONFIG_PACKAGE_netifd-netinfo=m CONFIG_PACKAGE_netperf=y CONFIG_PACKAGE_nlbwmon=m CONFIG_PACKAGE_ntfs-3g=m CONFIG_PACKAGE_ntfs-3g-utils=m CONFIG_PACKAGE_openssl-util=m # CONFIG_PACKAGE_openwrt-keyring is not set CONFIG_PACKAGE_opkg=m CONFIG_PACKAGE_p910nd=m CONFIG_PACKAGE_parted=y CONFIG_PACKAGE_pciids=y CONFIG_PACKAGE_pciutils=y CONFIG_PACKAGE_qrencode=m CONFIG_PACKAGE_resize2fs=y CONFIG_PACKAGE_roen-misc-meta=m CONFIG_PACKAGE_rpcd=m CONFIG_PACKAGE_rpcd-mod-file=m CONFIG_PACKAGE_rpcd-mod-iwinfo=m CONFIG_PACKAGE_rpcd-mod-luci=m CONFIG_PACKAGE_rpcd-mod-rrdns=m CONFIG_PACKAGE_rrdtool1=m CONFIG_PACKAGE_rt2800-pci-firmware=y CONFIG_PACKAGE_rt2800-usb-firmware=y CONFIG_PACKAGE_slh-misc-16m=m CONFIG_PACKAGE_slh-misc-32m=m CONFIG_PACKAGE_slh-misc-8m=m CONFIG_PACKAGE_slh-misc-luci-statistics=m CONFIG_PACKAGE_slh-misc-qos=m CONFIG_PACKAGE_speedtest-netperf=y CONFIG_PACKAGE_sqm-scripts=m CONFIG_PACKAGE_sqm-scripts-extra=m CONFIG_PACKAGE_sysfsutils=y CONFIG_PACKAGE_tc-tiny=m CONFIG_PACKAGE_tcpdump-mini=m CONFIG_PACKAGE_terminfo=y CONFIG_PACKAGE_tftp-hpa=m CONFIG_PACKAGE_tftpd-hpa=m CONFIG_PACKAGE_uboot-envtools=m CONFIG_PACKAGE_uhttpd=m CONFIG_PACKAGE_uhttpd-mod-ubus=m CONFIG_PACKAGE_umdns=m CONFIG_PACKAGE_usbutils=y # CONFIG_PACKAGE_usign is not set CONFIG_PACKAGE_wireguard-tools=m CONFIG_PACKAGE_wireless-regdb=y CONFIG_PACKAGE_wpa-cli=m CONFIG_PACKAGE_wpad=m CONFIG_PACKAGE_wpad-basic=m CONFIG_PACKAGE_wpad-basic-wolfssl=m CONFIG_PACKAGE_wpad-mini=m CONFIG_PACKAGE_wpad-openssl=m CONFIG_PACKAGE_wpad-wolfssl=m CONFIG_PACKAGE_xtables-nft=m CONFIG_PACKAGE_zlib=y CONFIG_PARTED_READLINE=y CONFIG_PCRE_JIT_ENABLED=y CONFIG_PREINITOPT=y # CONFIG_SIGNATURE_CHECK is not set # CONFIG_SIGNED_PACKAGES is not set CONFIG_TARGET_KERNEL_PARTSIZE=32 CONFIG_TARGET_PREINIT_TIMEOUT=5 CONFIG_TARGET_ROOTFS_PARTSIZE=920 CONFIG_WPA_MSG_MIN_PRIORITY=3 CONFIG_WPA_RFKILL_SUPPORT=y CONFIG_WPA_WOLFSSL=y CONFIG_ZLIB_OPTIMIZE_SPEED=y CONFIG_OPENSSL_NO_DEPRECATED=y # CONFIG_OPENSSL_WITH_DEPRECATED is not set Reverting the last four patches to hostapd fixes the issue again: b72c7db2293cf728851696e6370806cc3e0fa305 hostapd: fix missing HS20 support for hostapd-full 6ee4383350bc5b1920f81095f2ecd05b14e3bff6 hostapd: ubus: add bss-color to get_status 6c152ce5b0c003099dc1d9076fc3c38d061c1137 hostapd: randomize default BSS color c35ff1affe8f347b60a7539648a90b45ad43ffef hostapd: update to 2022-05-08 Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/3] Move mvswitch 88E6060 driver to the ath25
Hi On 2021-12-18, Sergey Ryazanov wrote: > On Sat, Dec 18, 2021 at 2:25 PM Bjørn Mork wrote: > > Sergey Ryazanov writes: > >> ath25 can not be switched to the DSA implementation due to lack of the > >> DTS support. > > > > I fully understand and accept that this isn't made a priority. But the > > explanation is misleading. It's definitely *possible* to use a DSA > > driver without DTS. There are examples in mainline. So "cannot" is > > wrong. > > Yep, I know that in general a DSA switch can be configured via the > platform data as any other device. But in this particular case, the > particular 88E6060 switch support can not be switched to the DSA > implementation because the DSA implementation does not support > configuration via the platform data. > > I checked the kernel code and the OpenWrt patches and found the only > board with the 88E6060 switch and this board utilizes DTS for its > configuration: NET_DSA_MV88E6060 has already been used for this device (tl-wr941nd v2/ v3) in ar71xx, using platform data https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr941nd.c;hb=refs/heads/openwrt-19.07 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/config-4.14;h=9a524fae4316caa10431bd6b3b4dadbe8660f14c;hb=refs/heads/openwrt-19.07#l433 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/base-files/etc/board.d/02_network;h=44fce970c0fd8b4811242fac0b53764a09244a2f;hb=refs/heads/openwrt-19.07#l324 so it should be possible for ath25 as well, although the effort might not be worth it, considering the age and specifications of the target devices. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Best VSDL modem-router to target?
Hi On 2021-12-03, Andrew Punch wrote: > Spoke too soon Fritzbox 7490 has been discontinued. Might be able to > get one from the US if I use the freight forwarder but I don't like my > chances. The Fritz!Box 7490 is rather special, two SOCs on one board (lantiq base, with an ath79 board dealing with the wireless on top and special VLANs between them), while there has been progress to get this working, it has never been merged (or submitted for potential merging) to OpenWrt. (It's pretty complex, you'd need to build two image, one lantiq, and a specially crafted initramfs image for ath79, using a special configuration conduit between them, to initialize and run the wireless on the ath79 SOC). Additionally DECT and FXS of the AVM devices is not supported by OpenWrt (DECT isn't at all, for FXS uses a different approach than other lantiq devices). Look at the https://openwrt.org/toh/bt/homehub_v5a - that's still pretty much the best modem-router combination you can get (be aware of the performance limits of lantiq vr9 and the supported profiles, vectoring, but not super-vectoring) and find a different solution for your phone requirements (ATA, VoIP-DECT base, etc.). The forum has quite a lot of information about these devices and may be better suited to guide you on your search. Regards Stefan Lippers-Hollmann pgpydzY80VKJN.pgp Description: Digitale Signatur von OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mac address issue of tp-link wdr3600 and archer c7-v2
Hi On 2021-11-15, e9hack wrote: > I'm using two tp-link routers. Both are using the same mac address for one > eth and one wlan interface: > > archer c7-v2: > uboot 60:xx:xx:xx:xx:E6 > eth0 60:xx:xx:xx:xx:E7 > eth1 60:xx:xx:xx:xx:E6 > wlan0 60:xx:xx:xx:xx:E4 5G > wlan1 60:xx:xx:xx:xx:E6 2.4G > > wdr3600: > uboot C0:xx:xx:xx:xx:60 > eth0 C0:xx:xx:xx:xx:60 > wlan0 C0:xx:xx:xx:xx:5F 2.4G > wlan1 C0:xx:xx:xx:xx:60 5G > > It looks like if an address decrement is missing for one wlan interface. I > don't know if this can trigger a problem. The rule is to follow the MAC assignments of the OEM firmware, not to invent new MAC addresses (which then can overlap in practice and create real problems). It's quite possible that the OEM firmware shared the same MAC address for one wired, and one wireless interface that generally won't cause too much trouble. The documented behaviour for the tl-wdr3600 would be: LAN label WAN label + 1 5G label 2G label - 1 according to https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=a4260eaab7744c8e3f1f7a62a61aab5e3b562342 Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
Hi On 2021-10-14, Sergey Ryazanov wrote: > On Mon, Oct 11, 2021 at 12:12 AM Hauke Mehrtens wrote: > > On 10/10/21 2:44 AM, Sergey Ryazanov wrote: > >> On Fri, Oct 8, 2021 at 4:40 PM Rui Salvaterra > >> wrote: > >>> On Fri, 8 Oct 2021 at 11:09, Rui Salvaterra wrote: [...] > > Does it make sense to directly convert this board to the upstream DSA > > driver for the Marvell 88E6060 switch: > > https://elixir.bootlin.com/linux/v5.10.72/source/drivers/net/dsa/mv88e6060.c > > It looks like our swconfig driver creates a bridge over all ports and > > the DSA driver only allows communication between the individual port and > > the CPU port. > > > > I do not know how much effort this is and if you have the device for > > testing. > > I do not think that migration to DSA without DT support will be a > practical step. Let's keep it as is until we are able to run new > kernels with it. If I'm not mistaken, CONFIG_NET_DSA_MV88E6060 has been used (for the tl-wr941nd v2/ v3) successfully on ar71xx already, not just ath79(-tiny). https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/config-4.14;h=9a524fae4316caa10431bd6b3b4dadbe8660f14c;hb=d5ae5658730a82312a20e68220f92f611b11d094#l433 and https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr941nd.c;h=1ddeec730eab47f2e5c9e4610603f9dc04cf8746;hb=d5ae5658730a82312a20e68220f92f611b11d094#l79 Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
Hi On 2021-10-10, Hauke Mehrtens wrote: > On 10/10/21 2:44 AM, Sergey Ryazanov wrote: > > On Fri, Oct 8, 2021 at 4:40 PM Rui Salvaterra wrote: > >> On Fri, 8 Oct 2021 at 11:09, Rui Salvaterra wrote: [...] > > I am in the process of migrating ath25 to the 5.10 kernel. Initial > > build was trivial. But I need to restore the Marvel swconfig driver > > that was lost during the initial 5.10 kernel introduction, and > > carefully run-time test it. > > Hi, > > Does it make sense to directly convert this board to the upstream DSA > driver for the Marvell 88E6060 switch: > https://elixir.bootlin.com/linux/v5.10.72/source/drivers/net/dsa/mv88e6060.c > It looks like our swconfig driver creates a bridge over all ports and > the DSA driver only allows communication between the individual port and > the CPU port. mv88e6060 has already been used by the tl-wr941nd v2/ v3 (very early ath79/ tiny) for many years, this might help for reference. https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/dts/ar9132_tplink_tl-wr941-v2.dts;h=58586eb03615b3ef959631824fcead21e077e12b;hb=HEAD#l64 Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Build issues gcc10
r--r-- 1 5892574 13. Sep 00:17 openwrt-ipq806x-generic-tplink_vr2600v-initramfs-uImage -rw-r--r-- 1 6554407 13. Sep 00:17 openwrt-ipq806x-generic-tplink_vr2600v-squashfs-sysupgrade.bin -rw-r--r-- 1 6047224 13. Sep 00:17 openwrt-ipq806x-generic-ubnt_unifi-ac-hd-initramfs-fit-uImage.itb -rw-r--r-- 1 6751016 13. Sep 00:17 openwrt-ipq806x-generic-ubnt_unifi-ac-hd-squashfs-sysupgrade.bin -rw-r--r-- 1 8388608 13. Sep 00:17 openwrt-ipq806x-generic-zyxel_nbg6817-initramfs-uImage -rw-r--r-- 1 25696256 13. Sep 00:17 openwrt-ipq806x-generic-zyxel_nbg6817-squashfs-factory.bin -rw-r--r-- 1 8336162 13. Sep 00:17 openwrt-ipq806x-generic-zyxel_nbg6817-squashfs-sysupgrade.bin drwxr-xr-x 281920 13. Sep 00:17 packages -rw-r--r-- 117816 13. Sep 00:17 profiles.json -rw-r--r-- 1 8391 13. Sep 00:17 sha256sums -rw-r--r-- 1 18 13. Sep 00:11 version.buildinfo $ ls -1 bin/targets/ipq806x/generic/packages/kmod-* | cut -d_ -f2 | sort -u 5.10.63-1 5.10.63+1.11-ipq806x-1 5.10.63-2 5.10.63+2020-12-07-1e9689c8-1 5.10.63+2021-06-03-b44cd7b2-5 5.10.63+2021-06-24-9b3a8197-1 5.10.63+2021-07-15-bbebea7d-4 5.10.63-3 5.10.63+5.10.42-1-1 accel accel-i2c accel-spi I can only assume that you're missing some build dependencies. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
Hi On 2021-09-07, Ansuel Smith wrote: > I am writing this to ask for some help/direction on what path we > should follow for > the qca8k driver. I currently have a pr open [1] to migrate ipq806x to > dsa driver > (qca8k) but some other devs reported that the same switch is also used by > other > targets. (ath79, bcm53xx) > It was suggested to move the entire patchset for qca8k to generic > patch dir and start > and adding the required patch to make qca8k work on the other target. [...] I'm not really in a position to give advice, but -imho- unless those other targets have at least proof-of-concept code for using qca8k on their devices /working/ and an intention to migrate to DSA for these devices within reasonable time frame, I personally wouldn't overthink this (yet). There is no problem with adding these patches for ipq806x first, and then moving the patches from ipq806x to generic later, when there is something tangible for ath79 or bcm53xx (as part of their PRs/ patch series to migrate from swconfig to qca8k). Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Clarification about dsa and ipq806x
Hi [Disclaimer: I'm not an OpenWrt developer] On 2021-03-01, Ansuel Smith wrote: [...] > The idea is to switch this target to dsa but there is a problem... > Since kernel 5.10 is a testing kernel how should I change the base [...] > Do we have some way in openwrt to know if the system use dsa driver or > swconfig driver? I could come up with these strategies: - if swconfig is still working in v5.10 with reasonable efforts, the easy way out could be to stick with swconfig for the TESTING_KERNEL introduction - and switch over to DSA as soon as it is acceptable to get rid of kernel v5.4. - adding kernel version based conditionals to - target/linux/ipq806x/base-files/etc/board.d/02_network - target/linux/ipq806x/base-files/etc/board.d/05_compat-version (new) - target/linux/ipq806x/image/Makefile (checking for TESTING_KERNEL) and toggling DEVICE_COMPAT_VERSION between them as needed. This does require (and enforces via DEVICE_COMPAT_VERSION) nuking the existing configuration between v5.4 and v5.10 based builds, but would allow building either from the same source. - if DSA is mostly working on kernel v5.4 (or could be retrofitted *easily*), switching kernel v5.4 in master over to DSA might be another option. "the dsa driver still lacks vlan support in kernel 5.4" suggests that this wouldn't be a reasonable option though. Just two questions of my own. I think to remember that introducing DSA based drivers is slightly at odds with devices storing the MAC address in ASCII representation (uboot-env) rather than binary at a fixed offset, is that an issue here? This affects linksys,ea7500-v1, linksys,ea8500 and zyxel,nbg6817 Is setting tx-fifo-depth still necessary/ useful? http://lists.infradead.org/pipermail/openwrt-devel/2020-September/031417.html Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] realtek: Add generic zyxel_gs1900 image definition
Hi On 2021-02-24, Hauke Mehrtens wrote: > Add a new common device definition for the Zyxel GS1900 line of > switches. [...] > -define Device/zyxel_gs1900-10hp > +define Device/zyxel_gs1900 >SOC := rtl8380 >IMAGE_SIZE := 6976k >DEVICE_VENDOR := ZyXEL >DEVICE_MODEL := GS1900-10HP >UIMAGE_MAGIC := 0x8380 > + KERNEL_INITRAMFS := kernel-bin | append-dtb | gzip | zyxel-vers AAHI | > uImage gzip > +endef I'm wondering if this attempt to deal the gs1900 switch family really improves the situation for these devices. While IMAGE_SIZE and UIMAGE_MAGIC might indeed by rather generic to most (all?) members of the gs1900 family, SOC might not be (GS1900-24, GS1900-24E, GS1900-24HP are RTL8382M, GS1900-48 and GS1900-48HP are RTL8393 - admittedly, I do not know how different the resulting DTS would need to be, as these devices are not supported yet) and zyxel-vers is different for every single model (aside from GS1900-8HPv1 && GS1900-8HPv2): GS1900-8: AAHH GS1900-8HPv1: AAHI GS1900-8HPv2: AAHI GS1900-10HP:AAZI GS1900-16: AAHJ GS1900-24: AAHL GS1900-24E: AAHK GS1900-24EP:ABTO GS1900-24HP:AAHM GS1900-24HPv2: ABTP GS1900-48: AAHN GS1900-48HP:AAHO GS1900-48HPv2: ABTQ Most of these should be supportable by OpenWrt. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: state of the DSA
Hi
On 2021-02-02, Paul Spooren wrote:
> Hi all,
>
> could you please update me on this matter? What's missing and what
> blocking for a release?
>
> The LuCI PR is still open: https://github.com/openwrt/luci/pull/4307
My initial testing of that PR on a ZyXEL GS1900-8 (RTL8382M) has been
pretty positive so far. I haven't really stressed it too much, but the
simple cases I needed are working nicely.
Regards
Stefan Lippers-Hollmann
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: state of the DSA
Hi On 2020-11-19, Paul Spooren wrote: [...] > The following targets seem use `swconfig`, should/can they be ported? > Please post states and links to work in progress migrations: [...] > * ath79 [...] > * ipq40xx > * ipq806x [...] > * lantiq/xrx200 [...] [ ipq807x is questionable at the moment, considering the discussions around adding ethernet/ switch support for the ax3600. ] At least these targets have- or are in the process (lantiq) of getting DSA drivers, but that doesn't mean all of the supported devices do (e.g. ath79 comes with a variety of different switch hardware, especially the older devices) or that the DSA drivers would be good enough to take over right now (e.g. ASCII encoded MAC addresses for ipq806x --> ea8500/ nbg6817 with qca8k or the current state of lantiq's DSA drivers, which are still under active development). > All other targets can be considered as DSA targets? If you're working or > testing around that, please comment and share the status. Assuming that 20.xx is supposed to be branched off 'soon' (and defining "soon" to be within the next couple of months), it's probably not feasible to migrate additional targets over to DSA right now, even for the devices where drivers exist, as this would invalidate all testing on these devices. IMHO this would be more of a todo item for immediately after 20.xy.0 gets released. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
Hi On 2020-11-19, TheWerthFam wrote: > Given that the first login via LuCI, on a fresh install, is not with a > password anyway. What if setting the initial password sets up > letsencrypt also. Then when letsencrypt's first successful cert install, > https gets enabled as the default and then requests the user reboot to > complete the setup and will force their next session to https. [...] This won't be possible in most cases. First of all you have a chicken an egg problem, as you'd have to set a password over a different management channel (e.g. ssh) - this is more of a media-breach, than accepting a self-signed certificate. Then there are a lot of cases where setting up internet access in an automated fashion simply isn't possible, at all, be it PPPoE (xDSL), having to use VLAN tagging, WAN over wireless or LTE connections, before even thinking about internal infrastructure. Users behind cgNAT (and that *very* common for cable, fibre or 4g/ 5g mobile users) simply don't have public IPv4 connectivity either (and often no IPv6 connectivity either). The next problem would be that this requires a public domain, which costs money and probably won't be easy to get sorted by many users. Yes, OpenWrt 'could' fill this gap, by handing out subdomains to the users, but this would require a lot of additional costly infrastructure and legal advice (what happens if a user doesn't behave and uses this for illegal activity, OpenWrt would be on the hook, at least first). Before even considering purely functional decisions, such as how to ensure unique DNS entries (no, as much as we'd like to, MAC addresses aren't always reliably unique, even if you ignore intentionally spoofed MACs) and stable over a factor reset. Without a quite advanced service backend (similar to dDNS providers, which OpenWrt is unlikely to become), you'd also end up with rather cryptic hostnames, which opens another can of worms (remembering it, introducing ant raising the risk of phishing attacks, etc.). Let's encrypt sounds like a great service, and it is for its intended use cases, but it utterly fails for mostly stateless embedded systems like routers, even more so for semi-internal (router behind a router, cgNAT, ...). I can't imagine any setup facilitating its features that would cover a significant portion of OpenWrt's most common use cases, without introducing serious problems and side-effects for a significant number of OpenWrt users - and/or would require heavy investments into OpenWrt's infrastructure (technical and legal). Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: The status of intel ax200 support (iwlwifi)
Hi On 2020-10-13, Alexander Pyattaev wrote: > I am trying to figure out if any version of openWRT can in principle > support the Intel's AX200 chips. I am quite willing to build a kernel > from source, but I have absolutely no idea whether I actually need to do > so. Some info on the internet points to there existing a backported > version of the driver, but I can not find it anywhere. If it does not > indeed exist, any pointers towards making it work would be nice, I'd be > happy to contribute a patch. iwlwifi should support ax200 just fine, but its firmware won't allow AP mode in the 5 GHz band at all (maybe using 25 mW on the short range band (ETSI EN 300 440-1), if you're lucky). That is an intentional choice from Intel to restrict (all of-) their WLAN cards and not fixable. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
Hi
On 2020-10-04, abnoeh wrote:
> Few months ago there was some debate for how we handle certificate for
> luci page: make user to click though certificate warning is not that
> great for security so here is a proposal for autometically assign a
> worldwide unique subdomain and how to make valid certificate for it, and
> make sure we and connect to the device he is expecting.
[…]
The elephant in the room remains, how do you propose to deal with
firstboot conditions? Not every internet connection can be
auto-detected, the most common examples would include having to
configure VLAN tagging on WAN or adding PPPoE credentials. For these,
the user will have to accept a self-signed certificate at least once
for doing the initial configuration - at which point they can just
stick to the already accepted self-signed certificate as well.
Regards
Stefan Lippers-Hollmann
--
I'm ignoring the usage profiles for offline networking infrastructure
(e.g. the recent addition of the rtl838x subtarget for managed
switches), what happens if you take an old device from the shelve
(existing certificate expired) and want to reconfigure/ start using it
again or the significant costs (in hardware, manpower and certification)
to operate a CA here.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: add ar5523 driver
Hi On 2020-08-11, Daniel Golle wrote: > Hi Mohammad, > > On Tue, Aug 11, 2020 at 03:41:29PM +0300, mohammad rasim wrote: > > The driver currently only support managed and monitor mode [...] > > +define KernelPackage/ar5523 > > + $(call KernelPackage/mac80211/Default) > > + TITLE:=Driver for Atheros AR5523 USB sticks > > + DEPENDS:=@USB_SUPPORT +kmod-mac80211 +kmod-ath +kmod-usb-core > > +kmod-input-core +@DRIVER_11N_SUPPORT > > ^^ > From what I understood ar5523 are 802.11a/b/g and hence do NOT support > 11N. Correct me if I'm wrong... Correct, ar5523 is basically just a mips 4000 SOC with AR2112 (AR5005UG) or AR5112 (AR5005UX) wireless, it's a 802.11 a/b/g solution (technically Atheros Super-G/ Super-AG with up to 108 MBit/s) and doesn't support 802.11n, so +@DRIVER_11N_SUPPORT should be dropped. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re:
Hi
On 2020-08-02, SAn via openwrt-devel wrote:
> The LibreRouter uses a dual-boot scheme that relies on the bootloader
> configuring the kernel cmdline. At ar71xx 18.06 it was possible to
> select per device if the cmdline from the bootloader has to be honored
> (using patch-cmdline).
> AFAIK there is no such possibility on ath79.
Perhaps take a look at mvebu (Linksys WRT1200AC/ WRT1900AC/ WRT1900ACS/
WRT3200ACM/ WRT32x), ipq40xx (Linksys EA6350v3/ EA8300, ZyXEL NBG6617)
or ipq806x (ZyXEL NBG6817) for inspiration (append-rootblock[0]).
Taking the bootloader cmdline as-is is probably not going to work, as
quite a lot of ath79 devices depend on a different kernel/ rootfs
split for the flash partitioning.
Regards
Stefan Lippers-Hollmann
--
[0]
target/linux/ipq806x/patches-5.4/0067-generic-Mangle-bootloader-s-kernel-arguments.patch
target/linux/mvebu/patches-4.19/006-mvebu-Mangle-bootloader-s-kernel-arguments.patch
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 20.XX
Hi [Disclaimer: I'm not an OpenWrt developer] On 2020-07-31, bapti...@bitsofnetworks.org wrote: [...] > Possibly missing goals are: > > 1) major feature: 802.11ax and ath11k support? > >I don't know the current state of this. I don't think this is going to happen for a 20.xy.0 release, basically there are only two platforms for this on the horizon at the moment: - QCA ipq807x/ ath11k: so far ath11k is exclusively available for the ipq807x SOC family (dedicated PCIe/ m.2 cards have just appeared on the market, PCIe support for ath11k is not completely merged upstream yet), but while basic -incomplete- target support already exists in master, not a single device is supported at this point (missing parts, PCIe, ethernet, ath11k technically also isn't available in master so far). While there is quite some interest and activity around this target, predominantly around the Xiaomi AX3600, I don't think this will make it soon (enough) for a 20.xy.0 stable release - not ruling it out completely, but a lot would have to happen in short time. - Mediatek mt7915e 802.11ax wireless The first devices of this kind appear to favour the older mips based mt7621a SOC, so support for these could appear quite quickly - depending on the current state of mt7615e support in the mt76 driver (it's still very new/ under development, no idea how far that has been developed at this point), but so far none of these routers/ APs is support by OpenWrt yet (and I'm not aware of any pending pull requests adding support for these either). A more natural (faster) combination would be the mt7622 ARMv8 SOC, but this is also a rather new target with few supported devices whose practical support is also just shaping up (none of those come with mt7915e WLAN at this moment either). So far I haven't seen any mt7622a+mt7915e on the market (nor any announcements) yet. Both 802.11ax contenders will probably have to wait for a 21.xy.0, even though ipq807x might be close. [...] > 3) organisational: switch to gitlab? > >While there was a vote about it, I don't know if this is planned >for 20.XX. I think it makes sense: we could start using gitlab to >track 20.XX bug reports, and possibly drop 18.06 bug reports from >flyspray. But if it is not ready, it should probably not block the >20.XX release. This has imho no direct relation to the release, it's mostly invisible behind the curtain for the ordinary user - their interaction with the git repositories is close to zero, bugs are only filed at bugs.openwrt.org anyways, the binary repos pushed from downloads.openwrt.org and the canonical location of the git repos is git.openwrt.org (github is just a mirror and the package feeds are a different question alltogether). This migration to gitlab can happen at any point and doesn't need to be tied to a release. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Simplified LuCI interface project: dashboard, quick setup, configuration
Hi On 2020-07-31, bapti...@bitsofnetworks.org wrote: > On 31-07-20, Henrique de Moraes Holschuh wrote: > > > As there has been no negative feedback about this, we will move to > > > configure the same SSID for 2.4 GHz and 5 GHz in the quick setup. > > > This will simplify the user experience. > > > > We have never tested it, but we did notice vendors nowadays, as well as the > > *large* ISPs witht their own CPEs and firmware, append _2G and _5G (or do > > something to that effect) to the default SSID. > > I noticed that too. Do you know why they do this? Personally my observation, especially with higher priced devices, is to the contrary. In my experience modern (highend 802.11ac/ 802.11ax) devices typically push[0] a single SSID/ network covering both bands, often with band-steering enabled; especially for devices touting the "mesh" mantra. Semi-modern mobile devices (e.g. android[1]) are also quite good at choosing the best band/ channel for their current needs, sticky clients should be less of a problem these days. The only potential reason to separate both networks for the common user would be broken-by-design IoT devices, which sometimes do fall over this (it's totally beyond imagination why these would care about the SSID of a 5 GHz network they don't even use/ see, but it happens). Obviously the option to configure this as needed must be available, but imho not necessarily for the simplified/ easy setup assistant (as long as full luci is easily available - and considering that the easy overview doesn't get confused by this). Regards Stefan Lippers-Hollmann [0] push := default and strongly suggested by the OEM firmware, but usually (not always) still offering both. [1] at least android 7 or newer ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: bump 5.4 to 5.4.53
Hi On 2020-07-25, Kevin Darbyshire-Bryant wrote: > Refresh patches. > > Remove upstreamed patches: > > bcm63xx/patches-5.4/022-v5.8-mtd-rawnand-brcmnand-correctly-verify-erased-pages.patch > bcm63xx/patches-5.4/024-v5.8-mtd-rawnand-brcmnand-fix-CS0-layout.patch > > Drop the cake hack as upstream have backported the changes themselves, > but in a slightly different way. > > generic/hack-5.4/641-sch_cake-fix-IP-protocol-handling-in-the-presence-of.patch > > Signed-off-by: Kevin Darbyshire-Bryant [...] Runtime tested on: Tested-by: Stefan Lippers-Hollmann [ath79/tl-wdr3600; ipq806x/nbg6817; ipq40xx/map-ac2200] Build tested on: - ath79 - ath79-tiny - ipq40xx - ipq806x - lantiq Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4
Hi On 2020-07-05, David Bauer wrote: > Hi all, > > On 4/2/20 9:53 PM, David Bauer wrote: > > As the reported major bugs are ironed out, switch to the new kernel to > > begin testing with a broader audience. > > As the DSP exception is now sorted out we should be good to go here. > > Any objections on applying this patch left? It's now working fine on my devices (not tested the tl-wr941nd v2 though, which has/ had(?) problems with NET_DSA_MV88E6060 in v4.19, FS#2524): Runtime tested with kernel v5.4.50 on: - TP-Link TL-WR1043NDv1/ AR9103 - Buffalo WZR-HP-AG300H/ AR7161 - TP-Link TL-WDR3600/ AR9344 - TP-Link TL-WDR4300/ AR9344 Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: Fix ath79 DSP exception at bootup
Hi
On 2020-07-03, Hauke Mehrtens wrote:
> This resolves a hazard between a mtc0 and a mfc0 instruction after
> activating the DSP support. Without this fix the CPU could use the old
> value again and the DSP support would not be active.
>
> Fixes: FS#2928
> Signed-off-by: Hauke Mehrtens
[...]
I can confirm that this works on the TP-Link TL-WDR3600 and TL-WDR4300,
tested on top of r13676-g9858a8c582 with kernel 5.4.50 and this patch.
Thanks a lot for looking into this.
Tested-by: Stefan Lippers-Hollmann [ath79/tl-wdr3600;
ath79/tl-wdr4300]
Regards
Stefan Lippers-Hollmann
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4
Hi On 2020-06-24, m...@adrianschmutzler.de wrote: > > On 4/11/20 5:13 PM, David Bauer wrote: > > > On 4/3/20 10:58 PM, Paul Blazejowski wrote: [...] > > Hi, > > > > I also get this problem with mainline kernel. > > > > See here for some more details: > > https://bugs.openwrt.org/index.php?do=details&task_id=2928 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94506 > > What's the status on this issue? Is it still there, and do we still have a > blocker for 5.4 on ath79? This issue is still open as of yesterday's master/ r13611-3f27a6e640, tested on both tl-wdr3600 and tl-wdr4300 with kernel v5.4.48. The device bootloops very early and in close succession, requiring tftp recovery[0]. Regards Stefan Lippers-Hollmann -- [0] early hardware revisions before h/w rev. 1.5 didn't ship with push-button tftp recovery enabled (this was only added in the last few OEM firmware updates for these devices), if the user never updated to a more recent OEM firmware containing an updated OEM u-boot (not all OEM updates contain the bootloader update), they'll end up with a brick requiring serial access. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] hostapd: update to latest Git hostap_2_9-1113-gc54a5e96b505
Hi
On 2020-05-04, Petr Štetiar wrote:
> Bump package to latest upstream Git HEAD which is commit c54a5e96b505
> ("Randomize GAS dialog token"). Since last update there was 1113
> commits done in the upstream tree with 537 files changed,
> 37874 insertions, 14159 deletions.
I've been testing this and Hauke's mac80211-5.6 branch
(1c5b2569dd3e6465a53d8c112517496cef5fa294) on top of r13208-426fb8cf84.
On both ipq806x (nbg6817/ QCA9984/ ath10k, WDS-AP/ WPA2PSK/ CCMP + WPA3SAE
mixed) and ipq40xx (map-ac2200/ ipq4019/ ath10k, WDS-client/ WPA3SAE only),
I'm getting a constant (every 3s) stream of
daemon.warn hostapd: nl80211: Not enough room for all AKM suites (num_suites=5
> NL80211_MAX_NR_AKM_SUITES)
warnings (WPA_ENABLE_WEP disabled).
ath10k_pci :01:00.0: qca9984/qca9994 hw1.0 target 0x0100 chip_id
0x sub 168c:cafe
ath10k_pci :01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
ath10k_pci :01:00.0: firmware ver 10.4-3.10-00047 api 5 features
no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 19ca6df2
ath10k_pci :01:00.0: board_file api 2 bmi_id 0:1 crc32 85498734
ath10k_pci :01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta
512 raw 0 hwcrypto 1
ath10k_ahb a00.wifi: qca4019 hw1.0 target 0x0100 chip_id 0x003b00ff sub
:
ath10k_ahb a00.wifi: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
ath10k_ahb a00.wifi: firmware ver 10.4-3.6-00140 api 5 features
no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 ba79b746
ath10k_ahb a00.wifi: board_file api 2 bmi_id 0:20 crc32 e2dfaa91
ath10k_ahb a00.wifi: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta
512 raw 0 hwcrypto 1
Same results using ath10k-ct/ ct-htt firmware:
ath10k 5.1 driver, optimized for CT firmware, probing pci device: 0x46.
ath10k_pci 0001:01:00.0: enabling device (0140 -> 0142)
ath10k_pci 0001:01:00.0: enabling bus mastering
ath10k_pci 0001:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
ath10k_pci 0001:01:00.0: qca9984/qca9994 hw1.0 target 0x0100 chip_id
0x sub 168c:cafe
ath10k_pci 0001:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
ath10k_pci 0001:01:00.0: firmware ver 10.4b-ct-9984-tH-013-d81f62d97 api 5
features
mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,htt-mgt-CT,set-special-CT,no-bmiss-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT
crc32 7d7b454d
ath10k_pci 0001:01:00.0: board_file api 2 bmi_id 0:2 crc32 85498734
ath10k_pci 0001:01:00.0: unsupported HTC service id: 1536
ath10k_pci 0001:01:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96
ath10k_pci 0001:01:00.0: msdu-desc: 2500 skid: 32
ath10k_pci 0001:01:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 msdu-desc:
2500 sw-crypt: 0 ct-sta: 0'
ath10k_pci 0001:01:00.0: wmi print 'free: 128704 iram: 15288 sram: 44212'
ath10k_pci 0001:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta
32 raw 0 hwcrypto 1
ath10k_ahb a00.wifi: qca4019 hw1.0 target 0x0100 chip_id 0x003b00ff sub
:
ath10k_ahb a00.wifi: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
ath10k_ahb a00.wifi: firmware ver 10.4b-ct-4019-tH-013-d81f62d97 api 5
features
mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,htt-mgt-CT,set-special-CT,no-bmiss-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT
crc32 a9217843
ath10k_ahb a00.wifi: board_file api 2 bmi_id 0:20 crc32 e2dfaa91
ath10k_ahb a00.wifi: unsupported HTC service id: 1536
ath10k_ahb a00.wifi: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96
ath10k_ahb a00.wifi: msdu-desc: 2500 skid: 32
ath10k_ahb a00.wifi: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 msdu-desc:
2500 sw-crypt: 0 ct-sta: 0'
ath10k_ahb a00.wifi: wmi print 'free: 88800 iram: 14696 sram: 47540'
ath10k_ahb a00.wifi: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta
32 raw 0 hwcrypto 1
Reverting just these two hostapd patches, but keeping the mac80211 bump,
the warnings vanish immediately.
Regards
Stefan Lippers-Hollmann
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] ipq806x: remove support for kernel 4.14
Hi
On 2020-04-02, Adrian Schmutzler wrote:
> This target has been on kernel 4.19 for several months [1] and
> already uses kernel 5.4 as testing kernel. Therefore, it should
> not be necessary to keep support for kernel 4.14 as well.
>
> [1] 2a82e0e1ca0f ("ipq806x: switch to 4.19 kernel version")
>
> Signed-off-by: Adrian Schmutzler
[...]
Acked-by: Stefan Lippers-Hollmann [ipq8065/nbg6817]
Thanks a lot for looking into this, given the rather good feedback
for kernel 5.4 testing on ipq806x (at least r7500v2, r7800 and nbg6817
are covered with good results so far), it might soon be time to switch
the default for ipq806x over to v5.4 as well.
Regards
Stefan Lippers-Hollmann
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] RFT: Add support for kernel 5.4
Hi On 2020-03-09, Adrian Schmutzler wrote: > > -Original Message- > > From: Stefan Lippers-Hollmann [mailto:s@gmx.de] [...] > > On 2020-02-28, John Crispin wrote: > > > On 28.02.20 21:30, Stefan Lippers-Hollmann wrote: > > > > On 2020-02-28, m...@adrianschmutzler.de wrote: > > > >>> On 2020-02-28, Koen Vandeputte wrote: > > [...] > > > > ath79 with kernel 4.14 has already been (mostly) broken by "ath79: add > > > > new ar934x spi driver" (ebf0d8dadeca443121f4f597c51bf6591e341caf), which > > > > does break the (shared between all kernel versions) DTS definitions for > > > > NAND based ath79 devices (breaking compilation with kernel 4.14). > > > > > > > > Because of "FS#2524 - ath79-tiny: TP-Link TL-WR941ND v2.4: Marvel > > > > MV88E6060 regression between kernel v4.14 and v4.19" > > > > https://bugs.openwrt.org/index.php?do=details&task_id=2524 I still do > > > > regularly build ath79 with kernel 4.14, but in order to finish the build > > > > I do need to comment out the affected devices: > > [...] > > > > > > > > Admittedly, the affected TL-WR941ND v2 (4/32) is barely worth the effort > > > > anymore. [...] > > Neither, nor. It's merely a report that kernel 4.14 support (albeit > > technically present in source) for ath79 isn't functional anymore (and > > hasn't been for a few weeks) anyways, regardless of the introduction of > > kernel 5.4 and its changes to ag71xx. Kind of answering Adrian's previous > > question "By moving ag71xx to files-4.19 on ath79, I suspect 4.14 is broken > > now on this target." [...] > thanks for you detailed explanation. > > Is there a specific reason why you build based on master and do not use the > 19.07 stable branch with working 4.14 support? [...] As mentioned previously, the device in question isn't really in active use anymore, I mostly do semi-regular regression testing with it. Therefore my pain threshold for it is limited, - enough to patch it back into the generic subtarget and build it (thanks to TARGET_MULTI_PROFILE && TARGET_PER_DEVICE_ROOTFS) as part of the build for actually useful devices, - enough to rebase the patchset to bring it back into generic, - enough to fix the build if the image got oversized again, - enough to spend some efforts on debugging new issues, but I probably wouldn't start a dedicated build just for this particular device (as part of dedicated debugging, sure, but not regularly). If it can't keep up with master builds, it's fate will be entertaining the dust bunnies, before finally meeting its maker. If this regression with ag71xx and Marvell MV88E6060 can't be fixed, it would be better to stop generating images for this particular device, as it's hard to recover. Therefore I'd suggest to add either of these patches to master: https://github.com/pkgadd/openwrt/commits/tl-wr941ndv2-deactivate -- From 3aacb4b374ee76bf2b0d2e43fc450a6bab50ffd9 Mon Sep 17 00:00:00 2001 From: Stefan Lippers-Hollmann Date: Mon, 9 Mar 2020 23:56:34 +0100 Subject: [PATCH] ath79-tiny: disable image generation for the tl-wr941nd v2/ v3 Since kernel v4.19 support for the Marvell MV88E6060 switch used in this devices has been broken, leading to an inaccesible device without an enduser compatible recovery method (no push-button tftp recovery, requiring serial console access and adding quite tiny 0-ohm SMD resistors to fix the cut serial rx traces). Disable image generation for this device until this gets fixed. Signed-off-by: Stefan Lippers-Hollmann --- target/linux/ath79/image/tiny-tp-link.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ath79/image/tiny-tp-link.mk b/target/linux/ath79/image/tiny-tp-link.mk index 29fdfec1e58..f0eaefbee41 100644 --- a/target/linux/ath79/image/tiny-tp-link.mk +++ b/target/linux/ath79/image/tiny-tp-link.mk @@ -338,7 +338,7 @@ define Device/tplink_tl-wr941-v2 TPLINK_HWID := 0x09410002 TPLINK_HWREV := 2 endef -TARGET_DEVICES += tplink_tl-wr941-v2 +#TARGET_DEVICES += tplink_tl-wr941-v2 define Device/tplink_tl-wr941-v4 $(Device/tplink-4m) -- or https://github.com/pkgadd/openwrt/commits/tl-wr941ndv2-nuke -- From 8dbdd50dc732d429e4650d375b56fc72587c5f42 Mon Sep 17 00:00:00 2001 From: Stefan Lippers-Hollmann Date: Tue, 10 Mar 2020 00:05:16 +0100 Subject: [PATCH] ath79-tiny: drop support for the tl-wr941nd v2/ v3 Since kernel v4.19 support for the Marvell MV88E6060 switch used in this devices has been broken, leading to an inaccesible device without an enduser compatible recovery method (no push-button tftp recovery, requiring serial console access and adding quite ti
Re: [OpenWrt-Devel] [PATCH] exfat-nofuse: fix kernel 5.4 compilation issue
Hi On 2020-03-06, Rosen Penev wrote: > On Fri, Mar 6, 2020 at 11:38 AM Paul Blazejowski > wrote: [...] > > - DEPENDS:=+kmod-nls-base > > + DEPENDS:=+kmod-nls-base @(LINUX_4_14||LINUX_4_19) > I prefer @!LINUX_5_4 Using @!LINUX_5_4 would break, once the next kernel after 5.4 comes around (be it in semi-private testing or officially with the next LTS kernel), while it's safe to assume that no older kernels will be merged back into master. It's usually a better strategy to test for known old kernels/ features, than to consider the new approach as an exception. > I also want an exfat package for 5.4. As it stands even though it is > in the staging directory, I don't think a package is available. https://github.com/openwrt/openwrt/pull/2807 [...] Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] RFT: Add support for kernel 5.4
Hi On 2020-02-28, John Crispin wrote: > On 28.02.20 21:30, Stefan Lippers-Hollmann wrote: > > On 2020-02-28, m...@adrianschmutzler.de wrote: > >>> On 2020-02-28, Koen Vandeputte wrote: [...] > > ath79 with kernel 4.14 has already been (mostly) broken by "ath79: add > > new ar934x spi driver" (ebf0d8dadeca443121f4f597c51bf6591e341caf), which > > does break the (shared between all kernel versions) DTS definitions for > > NAND based ath79 devices (breaking compilation with kernel 4.14). > > > > Because of "FS#2524 - ath79-tiny: TP-Link TL-WR941ND v2.4: Marvel > > MV88E6060 regression between kernel v4.14 and v4.19" > > https://bugs.openwrt.org/index.php?do=details&task_id=2524 I still do > > regularly build ath79 with kernel 4.14, but in order to finish the build > > I do need to comment out the affected devices: [...] > > > > Admittedly, the affected TL-WR941ND v2 (4/32) is barely worth the effort > > anymore. [...] > sorry for being dense here. what are you trying to tell us ? is there a > bug for which you propose a patch or is this a report or just a rant ? > honestly cant figure it out Neither, nor. It's merely a report that kernel 4.14 support (albeit technically present in source) for ath79 isn't functional anymore (and hasn't been for a few weeks) anyways, regardless of the introduction of kernel 5.4 and its changes to ag71xx. Kind of answering Adrian's previous question "By moving ag71xx to files-4.19 on ath79, I suspect 4.14 is broken now on this target." Beyond that, I'm merely explaining why I'm still regularly looking at ath79 with kernel 4.14 (because of the aforementioned regression in MV88E6060 on top of kernel 4.19). While I still regularly build for this device and sometimes boot it up/ flash a fresh (kernel 4.14 based) build, I'm well aware that this device is far beyond its prime (4/32, buggy draft-n AR9103 wireless) and don't actively use it anymore. Therefore I consider this flyspray bug more as a heads-up (while ath79 with MV88E6060 is rare, the underlying cause for this regression might have further impact), than in any way, shape or form 'important' - and I'd consider commenting out "tplink_tl-wr941-v2" (or removing its support altogether) a valid 'solution' (just retaining images for it in its current state in master is problematic, as they are broken and because the device requires serial access for recovering; no push-button tftp recovery provided by the OEM bootloader). Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] RFT: Add support for kernel 5.4
On 2020-02-28, Stefan Lippers-Hollmann wrote:
[...]
> does break the (shared between all kernel versions) DTS definitions for
> NAND based ath79 devices (breaking compilation with kernel 4.14).
Obviously this not meant to read NAND, but the more modern SOCs using
this new SPI driver (only applied to patches-4.19/ config-4.19) and its
different DTS definitions.
Sorry about the misleading typo.
Regards
Stefan Lippers-Hollmann
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] RFT: Add support for kernel 5.4
Hi On 2020-02-28, m...@adrianschmutzler.de wrote: > Hi, > > > On 2020-02-28, Koen Vandeputte wrote: [...] > > All supported targets have been provided with kernel 5.4 as the "Testing > > kernel". > > This means you can enable 5.4 by selecting "Global --> use the testing > > kernel > > version" within menuconfig. > > Thanks for your work. > > By moving ag71xx to files-4.19 on ath79, I suspect 4.14 is broken now on > this target. > So, we should either copy that to files-4.14 as well or remove the > remaining 4.14 files there as well (where I'd prefer the latter). ath79 with kernel 4.14 has already been (mostly) broken by "ath79: add new ar934x spi driver" (ebf0d8dadeca443121f4f597c51bf6591e341caf), which does break the (shared between all kernel versions) DTS definitions for NAND based ath79 devices (breaking compilation with kernel 4.14). Because of "FS#2524 - ath79-tiny: TP-Link TL-WR941ND v2.4: Marvel MV88E6060 regression between kernel v4.14 and v4.19" https://bugs.openwrt.org/index.php?do=details&task_id=2524 I still do regularly build ath79 with kernel 4.14, but in order to finish the build I do need to comment out the affected devices: $ grep \# ath79-k414.diff +#TARGET_DEVICES += tplink_cpe210-v1 +#TARGET_DEVICES += tplink_cpe220-v2 +#TARGET_DEVICES += tplink_cpe510-v1 +#TARGET_DEVICES += tplink_cpe510-v2 +#TARGET_DEVICES += tplink_cpe510-v3 +#TARGET_DEVICES += tplink_cpe610-v1 +#TARGET_DEVICES += tplink_tl-wdr3500-v1 +#TARGET_DEVICES += tplink_tl-wdr3600-v1 +#TARGET_DEVICES += tplink_tl-wdr4300-v1 +#TARGET_DEVICES += tplink_tl-wdr4300-v1-il +#TARGET_DEVICES += tplink_tl-wr842n-v2 +#TARGET_DEVICES += tplink_wbs210-v2 +#TARGET_DEVICES += tplink_wbs510-v1 +#TARGET_DEVICES += tplink_wbs510-v2 +#TARGET_DEVICES += ubnt_bullet-m-xw +#TARGET_DEVICES += ubnt_lap-120 +#TARGET_DEVICES += ubnt_litebeam-ac-gen2 +#TARGET_DEVICES += ubnt_nanobeam-ac +#TARGET_DEVICES += ubnt_nanostation-ac +#TARGET_DEVICES += ubnt_nanostation-ac-loco +#TARGET_DEVICES += ubnt_nanostation-loco-m-xw +#TARGET_DEVICES += ubnt_nanostation-m-xw +#TARGET_DEVICES += comfast_cf-e120a-v3 +#TARGET_DEVICES += dlink_dir-825-c1 +#TARGET_DEVICES += dlink_dir-835-a1 +#TARGET_DEVICES += iodata_etg3-r +#TARGET_DEVICES += iodata_wn-ag300dgr +#TARGET_DEVICES += ocedo_raccoon +#TARGET_DEVICES += pcs_cap324 +#TARGET_DEVICES += pcs_cr3000 +#TARGET_DEVICES += pcs_cr5000 +#TARGET_DEVICES += pisen_wmb001n +#TARGET_DEVICES += qihoo_c301 +#TARGET_DEVICES += sitecom_wlr-7100 +#TARGET_DEVICES += teltonika_rut955 +#TARGET_DEVICES += wd_mynet-n750 +#TARGET_DEVICES += wd_mynet-wifi-rangeextender +#TARGET_DEVICES += winchannel_wb2000 +#TARGET_DEVICES += zbtlink_zbt-wd323 Admittedly, the affected TL-WR941ND v2 (4/32) is barely worth the effort anymore. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/4] scripts/gen_image_generic.sh: use /bin/sh
Hi
On 2019-12-29, Rosen Penev wrote:
> This has nothing bash specific.
[...]
> +++ b/scripts/gen_image_generic.sh
> @@ -1,4 +1,4 @@
> -#!/usr/bin/env bash
> +#!/bin/bash
I assume this was supposed to become #!/bin/sh instead?
Regards
Stefan Lippers-Hollmann
--
Thanks for looking into this, unecessary bashisms have bothered me quite
a bit as well.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] mac80211: Adapt to changes to skb_get_hash_perturb()
From: Hauke Mehrtens
The skb_get_hash_perturb() function now takes a siphash_key_t instead of
an u32. This was changed in commit 55667441c84f ("net/flow_dissector:
switch to siphash"). Use the correct type in the fq header file
depending on the kernel version.
Signed-off-by: Hauke Mehrtens
Signed-off-by: Stefan Lippers-Hollmann
---
...t-to-changes-to-skb_get_hash_perturb.patch | 68 +++
1 file changed, 68 insertions(+)
create mode 100644
package/kernel/mac80211/patches/build/102-backports-Adapt-to-changes-to-skb_get_hash_perturb.patch
The second hunk was missing from include/net/fq_impl.h, which resulted
in a build error on 4.19.84:
Building backport-include/backport/autoconf.h ... done.
CC [M]
/tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/net/mac80211/tx.o
In file included from
/tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/net/mac80211/tx.c:28:
/tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/include/net/fq_impl.h:
In function 'fq_init':
/tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/include/net/fq_impl.h:319:19:
error: incompatible types when assigning to type 'siphash_key_t' {aka 'struct
'} from type 'u32' {aka 'unsigned int'}
fq->perturbation = prandom_u32();
^
make[9]: *** [scripts/Makefile.build:304:
/tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/net/mac80211/tx.o]
Error 1
This v2 version has been tested in ipq806x/ kernel v4.19.84
build-tested (master):
- ath79/ kernel v4.19.84
- ath79/ kernel v4.14.154
- ipq806x/ kernel v4.19.84
- lantiq/ kernel v4.19.84
runtime tested:
- ath79/ kernel v4.19.84 (only short testing)
- ath79/ kernel v4.14.154 (only short testing)
- ipq806x/ kernel v4.19.84 (running fine for the last 4 hours)
I have not tested old/ unaffected kernels (v4.19.82, ...) so far.
diff --git
a/package/kernel/mac80211/patches/build/102-backports-Adapt-to-changes-to-skb_get_hash_perturb.patch
b/package/kernel/mac80211/patches/build/102-backports-Adapt-to-changes-to-skb_get_hash_perturb.patch
new file mode 100644
index 00..7e40180b93
--- /dev/null
+++
b/package/kernel/mac80211/patches/build/102-backports-Adapt-to-changes-to-skb_get_hash_perturb.patch
@@ -0,0 +1,68 @@
+From e3c57dd949835419cee8d3b45db38de58bf6ebd5 Mon Sep 17 00:00:00 2001
+From: Hauke Mehrtens
+Date: Mon, 18 Nov 2019 01:13:37 +0100
+Subject: [PATCH] backports: Adapt to changes to skb_get_hash_perturb()
+
+The skb_get_hash_perturb() function now takes a siphash_key_t instead of
+an u32. This was changed in commit 55667441c84f ("net/flow_dissector:
+switch to siphash"). Use the correct type in the fq header file
+depending on the kernel version.
+
+Signed-off-by: Hauke Mehrtens
+---
+ include/net/fq.h | 8
+ include/net/fq_impl.h | 8
+ 2 files changed, 16 insertions(+)
+
+--- a/include/net/fq.h
b/include/net/fq.h
+@@ -69,7 +69,15 @@ struct fq {
+ struct list_head backlogs;
+ spinlock_t lock;
+ u32 flows_cnt;
++#if LINUX_VERSION_IS_GEQ(5,3,10) || \
++LINUX_VERSION_IN_RANGE(4,19,83, 4,20,0) || \
++LINUX_VERSION_IN_RANGE(4,14,153, 4,15,0) || \
++LINUX_VERSION_IN_RANGE(4,9,200, 4,10,0) || \
++LINUX_VERSION_IN_RANGE(4,4,200, 4,5,0)
++ siphash_key_t perturbation;
++#else
+ u32 perturbation;
++#endif
+ u32 limit;
+ u32 memory_limit;
+ u32 memory_usage;
+--- a/include/net/fq_impl.h
b/include/net/fq_impl.h
+@@ -108,7 +108,15 @@ begin:
+
+ static u32 fq_flow_idx(struct fq *fq, struct sk_buff *skb)
+ {
++#if LINUX_VERSION_IS_GEQ(5,3,10) || \
++LINUX_VERSION_IN_RANGE(4,19,83, 4,20,0) || \
++LINUX_VERSION_IN_RANGE(4,14,153, 4,15,0) || \
++LINUX_VERSION_IN_RANGE(4,9,200, 4,10,0) || \
++LINUX_VERSION_IN_RANGE(4,4,200, 4,5,0)
++ u32 hash = skb_get_hash_perturb(skb, &fq->perturbation);
++#else
+ u32 hash = skb_get_hash_perturb(skb, fq->perturbation);
++#endif
+
+ return reciprocal_scale(hash, fq->flows_cnt);
+ }
+@@ -308,7 +316,15 @@ static int fq_init(struct fq *fq, int fl
+ INIT_LIST_HEAD(&fq->backlogs);
+ spin_lock_init(&fq->lock);
+ fq->flows_cnt = max_t(u32, flows_cnt, 1);
++#if LINUX_VERSION_IS_GEQ(5,3,10) || \
++LINUX_VERSION_IN_RANGE(4,19,83, 4,20,0) || \
++LINUX_VERSION_IN_RANGE(4,14,153, 4,15,0) || \
++LINUX_VERSION_IN_RANGE(4,9,200, 4,10,0) || \
++LINUX_VERSION_IN_RANGE(4,4,200, 4,5,0)
++ get_random_bytes(&fq->perturbation, sizeof(fq->perturbation));
++#else
+ fq->perturbation = prandom_u32();
++#endif
Re: [OpenWrt-Devel] v5.4 as next kernel
Hi
On 2019-10-30, Adrian Schmutzler wrote:
> 1. We currently have work-in-progress 4.19 support PRs for ramips,
> ipq806x and bcm63xx, still with considerable work to do at least for
> the first two (IIRC).
Kernel 4.19 has been working fine on ipq806x (nbg6817) for me so far,
I've been using it a for couple of months now and the pending pull
request[0] is functional. Yes, there might be further optimization steps
possible, but none of that is necessary to switch ipq806x from v4.14 to
v4.19 now'ish (routing throughput is already significantly better in
v4.19, jumbo frames no longer crash stmmac, so I do consider the current
state of the v4.19 patches for ipq806x to be an improvement over v4.14).
Regards
Stefan Lippers-Hollmann
[0] https://github.com/openwrt/openwrt/pull/2472
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/6] hostapd: update to version 2.8
Hi Successfully build-tested on: - ath79 - ipq806x - lantiq Succeffully runtime tested on: - ipq806x On 2019-05-04, Hauke Mehrtens wrote: > This also syncs the configuration files with the default configuration > files, but no extra options are activated or deactivated. > > The mesh patches were partially merged into hostapd 2.8, the remaining > patches were extracted from patchwork and are now applied by OpenWrt. > The patches still have open questions which are not fixed by the author. > They were taken from this page: > https://patchwork.ozlabs.org/project/hostap/list/?series=62725&state=* > > Signed-off-by: Hauke Mehrtens Tested-by: Stefan Lippers-Hollmann [...] > --- a/package/network/services/hostapd/Makefile > +++ b/package/network/services/hostapd/Makefile > @@ -11,9 +11,9 @@ PKG_RELEASE:=6 > > PKG_SOURCE_URL:=http://w1.fi/hostap.git > PKG_SOURCE_PROTO:=git > -PKG_SOURCE_DATE:=2018-12-02 [...] > +PKG_SOURCE_DATE:=2.8 [...] The version number goes backwards here, I'd suggest sticking to the date here (2019-04-21) otherwise opkg would like to install the older snapshot again: # opkg update [...] # opkg list-upgradable hostapd-utils - 2.8-63962824-6 - 2018-12-02-c2c6c01b-6 wpad-openssl - 2.8-63962824-6 - 2018-12-02-c2c6c01b-6 wpa-cli - 2.8-63962824-6 - 2018-12-02-c2c6c01b-6 hostapd-common - 2.8-63962824-6 - 2018-12-02-c2c6c01b-6 You might also want to reset PKG_RELEASE to 1: --- a/package/network/services/hostapd/Makefile +++ b/package/network/services/hostapd/Makefile @@ -7,11 +7,11 @@ include $(TOPDIR)/rules.mk PKG_NAME:=hostapd -PKG_RELEASE:=6 +PKG_RELEASE:=1 PKG_SOURCE_URL:=http://w1.fi/hostap.git PKG_SOURCE_PROTO:=git -PKG_SOURCE_DATE:=2.8 +PKG_SOURCE_DATE:=2019-04-21 PKG_SOURCE_VERSION:=63962824309bb428e5f73d9caae08fcb949fbe36 PKG_MIRROR_HASH:=c3d789b822428c92bd47b3c85d9dc36cced38f7affe885cc2bb15e54248a4566 -- Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Bumping ar71xx to 4.14
Hi On 2018-10-05, Koen Vandeputte wrote: > Hi All, > > Regarding bumping ar71xx to 4.14, from my point of view all known issues > seem to be fixed. > Therefore, I'm planning to actually make 4.14 the default for this > target mid next week. > > If you still have issues which would not allow this, please let me know > asap. (and provide a log of the issue please) It's been a while since I last tested it (migrated to ath79 with all my devices meanwhile), but I successfully tested the initial port with these devices: - TP-Link TL-WR941ND v2 (AR9132) - TP-Link TL-WR1043ND v1 (AR9132) - TP-Link TL-WDR3600 (AR9344) - TP-Link TL-WDR4300 (AR9344) The size increase of kernel 4.14 will be very hard for all 4 MB flash devices though, especially for release images with luci preinstalled; not that this would be avoidable or fixable. Given the quite good state of ath79, it might be useful to lift the source-only flag for it soon. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LEDE > OpenWrt > TP-Link TL-WDR4900 1.0
Hi
On 2018-10-01, blu.italia--- via openwrt-devel wrote:
> One Question:
> Is there a way to delete the old radios 0 and 1?
Just remove them from /etc/config/wireless, using any text editor
(e.g. vi), this usually is a result of the device path changing between
different (kernel/ backports) versions - which shouldn't happen, but
in practice does occassionally.
Regards
Stefan Lippers-Hollmann
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.01 plans
Hi
On 2018-09-29, Torbjorn Jansson wrote:
> checkbox for hw offloading shows up for a fraction of a second when page is
> loaded but then it disappears.
> so i take it luci removes it dynamically or something at page load.
flow-offloading has only beenbackported to kernel 4.14, if your target
is still on an older kernel (e.g. ar71xx is still on kernel 4.9), it
isn't available.
Regards
Stefan Lippers-Hollmann
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] build: add mkrasimage
Hi On 2018-08-21, David Bauer wrote: > On 8/21/18 8:31 AM, Stefan Lippers-Hollmann wrote: > > While this passes the version check, the appended git hash does break > > later on in the flashing process - so at the moment only the numerical > > revision (of DISTRIB_REVISION='r7890-40eb9bda44') seems to be safe: > > > > RAS_VERSION := "V1.99(OWRT.$$(shell echo $(REVISION) | sed -e s/^r// -e > > s/\\-.*//))C0" > > Does the version string contained in the RAS-header get exposed to a > user in any way? If not, i would go for using a static (high enough so > it probably never get's used by ZyXEL) version string and call it a day > before we are over-complicating things here. [...] The OEM firmware doesn't expose any information about the other partition set, OpenWrt could make use of it via luci-app-advanced-reboot (but hasn't been doing that so far, as OpenWrt installs and sysupgrades don't update the header partition so far). But hardcoding RAS_VERSION := "V1.99(OWRT.)C0 should be fine for the forseeable future as well. Regards Stefan Lippers-Hollmann pgp5Pz6xkxtHD.pgp Description: Digitale Signatur von OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] build: add mkrasimage
Hi On 2018-08-21, Jo-Philipp Wich wrote: > Hi, > > > RAS_VERSION := "V1.99(OWRT.$$(shell echo $(REVISION) | sed s/^r//))C0" While this passes the version check, the appended git hash does break later on in the flashing process - so at the moment only the numerical revision (of DISTRIB_REVISION='r7890-40eb9bda44') seems to be safe: RAS_VERSION := "V1.99(OWRT.$$(shell echo $(REVISION) | sed -e s/^r// -e s/\\-.*//))C0" # hexdump -C /dev/mmcblk0p6 00 00 b4 bc 01 47 18 00 56 31 2e 39 39 28 4f 57 |.G..V1.99(OW| 0010 52 54 2e 37 38 39 30 29 43 30 00 ff ff ff ff ff |RT.7890)C0..| 0020 ff ff ff ff ff ff ff ff 00 00 d4 1d 4e 42 47 36 |NBG6| 0030 38 31 37 00 ff ff ff ff ff ff ff ff ff ff ff ff |817.| 0040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || * 0060 ff ff ff ff ff ff ff ff ff ff ff ff 00 00 98 e5 || 0070 00 40 00 00 ff ff ff ff ff ff ff ff ff ff ff ff |.@..| 0080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || * 0001 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0010 > make that RAS_VERSION := "V1.99(OWRT.$(patsubst r%,%,$(REVISION)))C0" > to avoid spawning a shell + sed process. I'll have a look at improving this tonight, thanks. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] build: add mkrasimage
On 2018-08-21, Stefan Lippers-Hollmann wrote: > Hi > > On 2018-08-21, Stefan Lippers-Hollmann wrote: > > On 2018-08-20, David Bauer wrote: > [...] > > For now, I've supplied a valid/ future firmware version for testing > > > > RAS_VERSION := "V1.00(ABCS.9)C0" > > While perhaps not ideal yet, this is accepted by the OEM webinterface > and should be safe to use for the time being. > > RAS_VERSION := "V1.99(OWRT.7890)C0" Sorry, this was meant to read: RAS_VERSION := "V1.99(OWRT.$$(shell echo $(REVISION) | sed s/^r//))C0" # hexdump -C /dev/mmcblk0p3 00 00 c4 38 01 47 18 00 56 31 2e 39 39 28 4f 57 |...8.G..V1.99(OW| 0010 52 54 2e 37 38 39 30 2d 34 30 65 62 39 62 64 61 |RT.7890-40eb9bda| 0020 34 34 29 43 30 00 ff ff 00 00 cb 60 4e 42 47 36 |44)C0..`NBG6| 0030 38 31 37 00 ff ff ff ff ff ff ff ff ff ff ff ff |817.| 0040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || * 0060 ff ff ff ff ff ff ff ff ff ff ff ff 00 00 98 e5 || 0070 00 40 00 00 ff ff ff ff ff ff ff ff ff ff ff ff |.@..| 0080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || * 0001 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0010 Regards Stefan Lippers-Hollmann pgpUy1INt3ylP.pgp Description: Digitale Signatur von OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] build: add mkrasimage
Hi On 2018-08-21, Stefan Lippers-Hollmann wrote: > On 2018-08-20, David Bauer wrote: [...] > For now, I've supplied a valid/ future firmware version for testing > > RAS_VERSION := "V1.00(ABCS.9)C0" While perhaps not ideal yet, this is accepted by the OEM webinterface and should be safe to use for the time being. RAS_VERSION := "V1.99(OWRT.7890)C0" # hexdump -C /dev/mmcblk0p6 00 00 b8 49 01 47 18 00 56 31 2e 39 39 28 4f 57 |...I.G..V1.99(OW| 0010 52 54 2e 37 38 39 30 29 43 30 00 ff ff ff ff ff |RT.7890)C0..| 0020 ff ff ff ff ff ff ff ff 00 00 d3 3f 4e 42 47 36 |...?NBG6| 0030 38 31 37 00 ff ff ff ff ff ff ff ff ff ff ff ff |817.| 0040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || * 0060 ff ff ff ff ff ff ff ff ff ff ff ff 00 00 98 e5 || 0070 00 40 00 00 ff ff ff ff ff ff ff ff ff ff ff ff |.@..| 0080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || * 0001 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |....| * 0010 Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] build: add mkrasimage
Hi On 2018-08-20, David Bauer wrote: > The current make-ras.sh image generation script for the ZyXEL NBG6617 > has portability issues with bash. Because of this, factory images are > currently not built correctly by the OpenWRT buildbots. > > This commit replaces the make-ras.sh by C-written mkrasimage. The old > script is still kept but can be deleted in the future. > > The new mkrasimage is also compatible with other ZyXEL devices using > the ras image-format. This is not tested with a OpenWRT build but > it correctly builds the header for ZyXEL factory images for all devices > it is added to. > > Signed-off-by: David Bauer with the caveat explained below: Tested-by: Stefan Lippers-Hollmann > v2 changes: > - Rework image-generation code > - Add factory image for NBG6616 > - Add factory image for NBG6817 Thanks a lot for looking into this! I've given this a test on my ZyXEL NBG6817 and it's basically working, ZyXEL just decided to prevent downgrades from the firmware upgrade functionality of their webinterface, which means it parses the RAS_VERSION and rejects the currently chosen version number. Flashing this image from a tftpd avoids the strict version requirements and can flash the image as-is (press WPS key while power-on, have the factory image renamed to "ras.bin" available from a tftpd at 192.168.1.99). [...] > diff --git a/target/linux/ipq806x/image/Makefile > b/target/linux/ipq806x/image/Makefile > index 2902af3231..cbb03272fb 100644 > --- a/target/linux/ipq806x/image/Makefile > +++ b/target/linux/ipq806x/image/Makefile [...] > @@ -245,6 +246,9 @@ define Device/zyxel_nbg6817 > KERNEL_SIZE := 4096k > BLOCKSIZE := 64k > BOARD_NAME := nbg6817 > + RAS_BOARD := NBG6817 > + RAS_ROOTFS_SIZE := 20934k > + RAS_VERSION := "$(VERSION_DIST) $(REVISION)" [...] For now, I've supplied a valid/ future firmware version for testing RAS_VERSION := "V1.00(ABCS.9)C0" and it flashes nicely from the webinterface (until ZyXEL actually releases this version, which is next in line). I'll have a look if I can track down the version check and supply something that's both a bit closer to OpenWrt and more future safe, but I'd suggest to go with "V1.00(ABCS.9)C0" for now, as that has been confirmed to work for the next couple of weeks. Flashed OpenWrt master image via web-interface, with a fake ZyXEL version number: # hexdump -C /dev/mmcblk0p6 | head -n6 00 00 7a 9f 01 47 18 00 56 31 2e 30 30 28 41 42 |..z..G..V1.00(AB| 0010 43 53 2e 39 29 43 30 00 ff ff ff ff ff ff ff ff |CS.9)C0.| 0020 ff ff ff ff ff ff ff ff 00 00 d5 73 4e 42 47 36 |...sNBG6| 0030 38 31 37 00 ff ff ff ff ff ff ff ff ff ff ff ff |817.| 0040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || * Flashed via tftpd, using OpenWrt's preliminary version info: # hexdump -C /dev/mmcblk0p3 | head -n6 00 00 7a 9f 01 47 18 00 4f 70 65 6e 57 72 74 20 |..z..G..OpenWrt | 0010 72 37 38 38 33 2d 66 63 39 63 62 66 33 62 63 30 |r7883-fc9cbf3bc0| 0020 00 ff ff ff ff ff ff ff 00 00 d0 e0 4e 42 47 36 |NBG6| 0030 38 31 37 00 ff ff ff ff ff ff ff ff ff ff ff ff |817.| 0040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || * Regards, thank you very much! Stefan Lippers-Hollmann pgpF8_kF_K18G.pgp Description: Digitale Signatur von OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] build: add mkrasimage
Hi
On 2018-08-17, Christian Lamparter wrote:
> On Thursday, August 16, 2018 12:31:38 PM CEST David Bauer wrote:
> > On 8/16/18 3:12 AM, Karl Palsson wrote:
[...]
> [...] (And there is at least
> one more device that can make use of ras: the NBG6817).
Adding support for a factory image for the NBG6817 by using make-ras is
on my radar, but as that router is in use as my main router with a rather
complex vlan and 4addr setup, it might take a while until I find an
opportunity to look into it.
Regards
Stefan Lippers-Hollmann
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH v2] ipq806x: add kernel 4.14 support
r rudimentary build config. The kernel size is a bit below 2.3 MB. In order not to add to the confusion, I'm not formally filing this branch as a pull request. Regards Stefan Lippers-Hollmann pgp6FW4NvIpCz.pgp Description: Digitale Signatur von OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
Re: [LEDE-DEV] [PATCH v2] ipq806x: add kernel 4.14 support
Hi On 2018-05-17, John Crispin wrote: > On 17/05/18 13:47, Ram Chandra Jangir wrote: > > Thanks Michael for confirming this, > > > > Can you please help to update the kernel partition size to 4MB for R7800 > > and send it as patch to community (lede-...@lists.infradead.org)? > > This will help to enable kernel v4.14 for all ipq806x based boards. > > hang on, that would break sysupgrade or not ? At least for the NAND based devices with a 2 MB kernel partition: - Netgear Nighthawk X4 D7800 - Netgear Nighthawk X4 R7500 - Netgear Nighthawk X4 R7500v2 - Netgear Nighthawk X4S R7800 SPI-NOR based devices should migrate transparently: - TP-Link Archer C2600 - TP-Link Archer VR2600v Not affected: - Compex WPQ864 (merged ubi on NAND) - Linksys EA8500 (kernel partition 3 MB on NAND) - Qualcomm IPQ8064/DB149 (merged firmware partition, SPI-NOR) - ZyXEL NBG6817 (kernel partition 4 MB on eMMC/ GPT partitions) Unknown, probably not affected: - Qualcomm IPQ8064/AP148 (NAND, partitioning derived from qcom-smem) The Netgear/ NAND devices will need installing the differently partitioned image via tftp, therefore it might make sense to migrate ipq806x to qca8k/ dsa around the same time, given that the existing configs can't be kept over the upgrade anyways. https://github.com/dissent1/openwrt/commit/5c17ab1f8673d6fb69163052ac7e3f71bf385405 Devices successfully tested with this patch/ kernel 4.14: - Netgear Nighthawk X4S R7800 tftp 'recovery' needed to apply the new partitioning, patches for DTS and image code needed tested by: Michael Yartys Message-ID: - TP-Link Archer C2600 smooth transition, patches for DTS and tplink-safeloader needed tested by: Joris de Vries Message-Id: - ZyXEL NBG6817 smooth sysupgrade, no patches or other changes needed tested by: Stefan Lippers-Hollmann Message-ID: <20180504214003.61bbd2be@mir> I've been running my nbg6817 successfully on kernel 4.14 for a bit over two weeks now, no issues at all. It is still possible to drop the kernel size to 2'097'152 byte by - https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=commitdiff;h=9e6c25f6940dbb294a7ba8cf8c72b659ec444ebf - CONFIG_OPTIMIZE_INLINING=y - CONFIG_CC_OPTIMIZE_FOR_SIZE=y But that's exactly on the limit for 2 MB, so it will overflow sooner than later, probably at the most inconvenient time. While [PATCH] ipq806x: cleanup kernel config Message-Id: <1526561729-32032-1-git-send-email-rjan...@codeaurora.org> should extend the headroom a bit more, extending the size of the kernel partition for the affected Netgear devices will be needed in the future either way, probably with the next minor kernel bump at the latest. Regards Stefan Lippers-Hollmann pgpz2Efxuw57S.pgp Description: Digitale Signatur von OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH v2 2/4] base-files: add sysupgrade -u to skip unchanged files
Hi On 2018-04-04, Luiz Angelo Daros de Luca wrote: > With '-u', for a file /aaa/bbb/ccc enlisted for backup, > it will only get into backup if /rom/aaa/bbb/ccc does not > exist or /aaa/bbb/ccc is different from /rom/aaa/bbb/ccc. > > It also works with '-c', but only effective for files touched > but not modified. [...] This patch series works very nicely for me on ar71xx, brcm47xx, ipq806x and lantiq, -u unclutters the overlay contents quite significantly and makes spotting (manual) changes a lot easier. Thanks Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [openwrt-realtek] Is it possible to add support for rtl8676?
Hi
On 2017-04-21, Pavel Sayekat wrote:
> Dear team,
> My device is a rtl8676 (may be it has become old :( ) and I like to use
> openwrt firmwire on it if its possible :).
[ Disclaimer: I can't speak for the OpenWrt developers ]
RTL8676 is based on Realtek's own lexra architecture, a reduced mips
ISA, neither the upstream kernel nor OpenWrt have any kind of support
for this (sub-)architecture (and forward porting arch support from their
last kernel 2.6.30 based code drop won't be particularly easy). Another
rather obvious problem for many devices of this architecture would be
insufficient hardware ressources (16 MB RAM); OpenWrt has dropped
support for devices with less than 32 MB RAM with Attitude Adjustment
in 2012 and even 32 MB RAM (the most seen in any known RTL8676 device)
would be very limiting for OpenWrt trunk and close to the end of its
life cycle.
Adding support for lexra and RTL8676 to OpenWrt would require
significant efforts (and arch upstreaming), which -given the age (and
relative rarity) of these lexra designs and the very limited system
ressources of most devices- is extremely unlikely to happen[1]. It most
likely would require you personally (as I can't really imagine (m)any
others to share your motivation) to spend massive efforts on upstream
kernel- and toolchain support, before even thinking about OpenWrt
specifics.
Regards
Stefan Lippers-Hollmann
[1] lexra as an architecture used by Realtek in networking devices
exists since ~2004, RTL8676 specifically probably since ~2013,
given that nothing has happened for this architecture within
the last ~12 years, it's rather safe to assume that nothing
will happen in the forseeable future either.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH trunk/r47894] hostapd: fix post v2.4 security issues
- WPS: Fix HTTP chunked transfer encoding parser (CVE-2015-4141) - EAP-pwd peer: Fix payload length validation for Commit and Confirm (CVE-2015-4143) - EAP-pwd server: Fix payload length validation for Commit and Confirm (CVE-2015-4143) - EAP-pwd peer: Fix Total-Length parsing for fragment reassembly (CVE-2015-4144, CVE-2015-4145) - EAP-pwd server: Fix Total-Length parsing for fragment reassembly (CVE-2015-4144, CVE-2015-4145) - EAP-pwd peer: Fix asymmetric fragmentation behavior (CVE-2015-4146) - NFC: Fix payload length validation in NDEF record parser (CVE-2015-8041) - WNM: Ignore Key Data in WNM Sleep Mode Response frame if no PMF in use (CVE-2015-5310) - EAP-pwd peer: Fix last fragment length validation (CVE-2015-5315) - EAP-pwd server: Fix last fragment length validation (CVE-2015-5314) - EAP-pwd peer: Fix error path for unexpected Confirm message (CVE-2015-5316) Signed-off-by: Stefan Lippers-Hollmann --- I have kept the upstream patches as untouched as possible (except for the necessary backporting), so this introduces trailing whitespace in several places. ...Fix-HTTP-chunked-transfer-encoding-parser.patch | 49 +++ ...r-Fix-payload-length-validation-for-Commi.patch | 73 ++ ...ver-Fix-payload-length-validation-for-Com.patch | 66 +++ ...r-Fix-Total-Length-parsing-for-fragment-r.patch | 52 +++ ...ver-Fix-Total-Length-parsing-for-fragment.patch | 50 +++ ...eer-Fix-asymmetric-fragmentation-behavior.patch | 32 ++ ...load-length-validation-in-NDEF-record-par.patch | 61 ++ ...Key-Data-in-WNM-Sleep-Mode-Response-frame.patch | 32 ++ ...-peer-Fix-last-fragment-length-validation.patch | 54 ...erver-Fix-last-fragment-length-validation.patch | 51 +++ ...r-Fix-error-path-for-unexpected-Confirm-m.patch | 34 ++ 11 files changed, 554 insertions(+) create mode 100644 package/network/services/hostapd/patches/003-WPS-Fix-HTTP-chunked-transfer-encoding-parser.patch create mode 100644 package/network/services/hostapd/patches/004-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch create mode 100644 package/network/services/hostapd/patches/005-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch create mode 100644 package/network/services/hostapd/patches/006-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch create mode 100644 package/network/services/hostapd/patches/007-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch create mode 100644 package/network/services/hostapd/patches/008-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch create mode 100644 package/network/services/hostapd/patches/009-NFC-Fix-payload-length-validation-in-NDEF-record-par.patch create mode 100644 package/network/services/hostapd/patches/010-WNM-Ignore-Key-Data-in-WNM-Sleep-Mode-Response-frame.patch create mode 100644 package/network/services/hostapd/patches/011-EAP-pwd-peer-Fix-last-fragment-length-validation.patch create mode 100644 package/network/services/hostapd/patches/012-EAP-pwd-server-Fix-last-fragment-length-validation.patch create mode 100644 package/network/services/hostapd/patches/013-EAP-pwd-peer-Fix-error-path-for-unexpected-Confirm-m.patch diff --git a/package/network/services/hostapd/patches/003-WPS-Fix-HTTP-chunked-transfer-encoding-parser.patch b/package/network/services/hostapd/patches/003-WPS-Fix-HTTP-chunked-transfer-encoding-parser.patch new file mode 100644 index 000..36b4ca2 --- /dev/null +++ b/package/network/services/hostapd/patches/003-WPS-Fix-HTTP-chunked-transfer-encoding-parser.patch @@ -0,0 +1,49 @@ +From 5acd23f4581da58683f3cf5e36cb71bbe4070bd7 Mon Sep 17 00:00:00 2001 +From: Jouni Malinen +Date: Tue, 28 Apr 2015 17:08:33 +0300 +Subject: [PATCH] WPS: Fix HTTP chunked transfer encoding parser + +strtoul() return value may end up overflowing the int h->chunk_size and +resulting in a negative value to be stored as the chunk_size. This could +result in the following memcpy operation using a very large length +argument which would result in a buffer overflow and segmentation fault. + +This could have been used to cause a denial service by any device that +has been authorized for network access (either wireless or wired). This +would affect both the WPS UPnP functionality in a WPS AP (hostapd with +upnp_iface parameter set in the configuration) and WPS ER +(wpa_supplicant with WPS_ER_START control interface command used). + +Validate the parsed chunk length value to avoid this. In addition to +rejecting negative values, we can also reject chunk size that would be +larger than the maximum configured body length. + +Thanks to Kostya Kortchinsky of Google security team for discovering and +reporting this issue. + +Signed-off-by: Jouni Malinen +--- + src/wps/httpread.c | 7 +++ + 1 file changed, 7 insertions(+) + +diff --git a/src/wps/httpread.c b/src/wps/httpread.c +index 2f08f37..d285
Re: [OpenWrt-Devel] Recommended settings ip6 DNS server / dnsmasq
Hi On 2015-08-17, Jean-Michel Pouré - GOOZE wrote: > Dear Steven, > > Thanks for this kind response. > > > " addr inet6: 2a01:e35:87d8:::953/128 Scope:Global" > > OK, I cannot find the lease in Luci, but here is /tmp/hosts/odhcpd LuCI should show it on Status/ Overview, quite to the bottom under "DHCPv6 Leases". > # br-lan 0004901071a15f278795aa0dd83bde8b 49874f74 - 1439881026 953 > 128 2a01:e35:87d8:::953/128 > > Is my duid 0004901071a15f278795aa0dd83bde8b? Yes, but you need to restart odhcpd(IPv6) (and dnsmasq(IPv4) after changing /etc/config/dhcp, doing that clears /tmp/hosts/odhcpd as a side effect. [...] > > At some point using the mac-address (option mac) should work here > > as well but it might be broken currently. I will put it on my todo. This is basically a question I was planning to ask, right now (as in trunk r46589 on a TP-Link TL-WDR4300) it seems that specifying the duid is necessary. For my personal situation (virtual machines (kvm) for testing differing stateless systems, I give each of the VM definitions a static MAC/ IPv4 mapping and DNS entry - but I can't guess the duid for different OS images in advance), it would be great if it were possible to omit the duid and use the MAC address exclusively. [...] > I used: > config host > option name 'sony-vaio' > option ip '' > option mac '54:42:49:87:xx:xx' > > config host > option duid '0004901071a15f278795aa0dd83bde8b' > option hostid '3' What works for me, is this config host option name 'foobar' option mac 'BC:5F:F4:XX:XX:XX' option ip '10.10.7.0' option duid '0002ab119da6fe0c' option hostid '100700' option dns '1' The dns option should be optional, but is very convenient for me; I make quite heavy use of local (forward- and reverse) local DNS entries for physical and virtual systems. > and it does not work. The assigned address is still > 2a01:e35:87d8:::953 Most likely because you didn't restart odhcpd - or eventually because you split it into two config sections (I'm not sure if that's valid). Regards Stefan Lippers-Hollmann pgpIOYpwu1vkq.pgp Description: Digitale Signatur von OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
Hi On Saturday 19 July 2014, David Lang wrote: > On Fri, 18 Jul 2014 10:21:56 -0700, Bill wrote: > > Gert Doering wrote: > > > > On Thu, Jul 17, 2014 at 10:20:09AM +0200, Steven Barth wrote: [...] > > P.S. No, my printer is not v6-ready, either, but let's assume there > > are some that are... If you're looking for real world examples, consider a 2009 vintage "OKI B430dn" black&white laser printer (which was targetted relatively cheaply (<160 EUR) between advanced desktop tasks and small workgroups), something I would call quite representative for embedded devices. - it comes with an embedded printserver - supports IPv4 and IPv6 - it defaults to using DHCP for IPv4. - the IPv6 implementation is enabled and uses SLAAC by default. - it does not support DHCPv6, but does support fully manual configuration (in a very, very limited way and not beyond the limits depicted for the SLAAC case below). - via SLAAC, it binds to the globally routable IPv6 address (and to its link local address (fe80::/10)), it does not support ULA prefixes, privacy extensions or anything more advanced. Within these constraints, IPv6 support works surprisingly well (and reliably). - this printer does have rather advanced user access controls for an embedded device, including a local static user/ password store and 802.1X (EAP). but, like pretty much any embedded device, it ships without any of this this enabled --> fully open for printing, default username and password for administration and everything else. - it does offer a plethora of protocols (SNMP, telnet, ftp, NetBEUI, Ethertalk, (LPR, Port9100, IPP, NetWare PServer/ RPrinter, etc.)), with at least the common ones (IPP, LPR, Webinterface, SNMP) enabled by default. - there are no intrusion detection methods, nothing stops you from painstakingly brute forcing your way into it (if the default username/ password don't happen to work and if you really don't find a simpler way in). On paper, the access controls are pretty advanced (if you bother to configure them), but would I trust its security if exposed to the open internet? Of course not. To the best of my knowledge there hasn't been any security problem published, but at the same time there has never been a firmware update either, nor would I expect any after 2, or 5, years - even leaving alone the likelyness that an enduser (or the resident (network-) admin for a small to medium office or company) would find one, if it existed, or risk flashing it. > that's a real example that has been exploited in the past, especially > with the very expensive, high-end printer/copiers sold to businesses. > Again from companies that "should know better" [...] Like David Lang mentioned, there are tons of network enabled devices, increasingly with some kind of IPv6 support. Why, because supporting it essentially comes for free (especially if you base your firmware on linux, one of the BSDs, etc.) and allows the manufacturer to tick a few more bullet points in their product description. Security is usually being an afterthought at best, you can be happy if IPv6 support actually works in the first place (see the limited configuration options for the printer mentioned above). While probably not printers, many of these will need a globally routable address for outgoing services (think NAS and downloading functions), but fewer need to provide incoming services to the internet at large (while you may want to connect to them via a VPN) - and very few can be expected to be (and remain-) secure over their whole effective life time (which can easily be 5-10 years or longer for printers, wireless security cameras, simple NAS boxes and other embedded devices). This even ignoring that pretty much all networked appliances (including OpenWrt itself) default to open access (with weak default passwords at best) after firstboot, because that and binding to all available network addresses is the only way to configure them in the first place. With IPv6, you naturally get end-to-end connections, but this (imho) shouldn't imply unfiltered, incoming connections by default. Unlike with IPv4 and NAT, you do have all the options to allow incoming connections easily, for all your devices, without having to fight with managing portforwardings within the acceptable range of your service. If you're in an ISP-like position, you certainly need to provide unfiltered access to your clients, but CPE devices (which OpenWrt certainly is) better error on the side of caution and provide the ingrained expectation of having a secure local net. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH/RFC v2] add hardware id for TL-WDR4300v1 (IL)
Hi On Sunday 10 March 2013, Daniel Golle wrote: > On 03/10/2013 05:37 PM, Bastian Bittorf wrote: > > * Daniel Golle [10.03.2013 16:24]: […] I'm not going to comment upon what's the correct approach in this case and certainly agree that the local regulatory requirements should be enforced by default. > Simply speaking: If I buy a TP-LINK router in germany and flash it with > OpenWrt, > it will come with ETSI 0x68 regdomain (or similar) set in the "art" partition, […] If only this were true… Over the years, I've bought 4 TP-Link routers (TL-WR941ND, two TL-WR1043ND and TL-WDR4300) through regular (and different) retail channels (online and brick & mortar stores). Every single one has an EEPROM/ ART locked to the 'US' regdomain (the official vendor firmware, including localized variants, ignores the ART content and makes the user to select the country freely). Likewise I own more than 10 Atheros based wlan cards (most built by TP-Link), including ath5k, ath9k, ar5523, ar9170 and ath9k_htc based ones, all but a single one (which shipped as part of a netbook, set to 0x37 ETSI1_WORLD) are locked to CN (APL1_WORLD). While this is somewhat acceptable in the 2.4 GHz band, intersecting US, DE and CN in the 5 GHz band is not… Unfortunately the stock regdomain settings on Atheros hardware (TP-Link in particular) are typically wrong and the official drivers circumvent them all the time. It would be so much easier if the EEPROM/ ART wouldn't contain country code (group), but an explicit list of (calibrated) allowed frequency/ txpower mappings - and not to allow bypassing them with any driver at all (as that would force vendors to program either correct country codes or offer the whole range with further limits applied purely in software, rather than enforcing an always wrong country code in hardware and ignoring the setting in their own firmware). Answering your follow up mail one below, why is it often needed to override the EEPROM/ ART settings: - enable channel 12, 13 (the official TP-Link vendor firmware allows this after selecting germany[1]) - restricting transmit power to allowed values in DE (further restrictions can be applied easily, so no problem) - most importantly, to get a reasonable selecting of 5 GHz channels, as the intersection of US (FCC), DE (ETSI) and CN (APL) is particularly bad --> empty list (the official TP-Link vendor firmware allows this after selecting germany[1]). - to make sure that transmitted IEEE 802.11d country IEs don't create even more havoc. Regards Stefan Lippers-Hollmann [1] http://www.tp-link.com/resources/simulator/TL-WDR4300/index.htm Wireless 2.4GHz --> Wireless Settings --> Region/ Channel Wireless 2GHz --> Wireless Settings --> Region/ Channel yes, this reflects the actual firmware and the country setting can be toggled freely, including different settings for 2.4 GHz and 5 GHz… ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] support for TP-Link TL-WDR3500. Was: Re: [RFC] ar71xx: add support for the TP-Link TL-WDR4310 v1.0
Hi On Saturday 22 December 2012, Stefan Lippers-Hollmann wrote: > On Thursday 20 December 2012, Nicolás Echániz wrote: > > TP-Link WDR3600 is supported since r33219. It has the same hardware as > > the WDR4300 with one less chain/antenna. > > > > However the model WDR3500, which is similar to WDR3600 is not yet > > supported. Outstanding differences in relation to WDR3600 are: > > For the TL-WDR3600, the situation was easy (once TL-WDR4300 was > supported), because it's essentially the same device, with only minor > differences for the 2.4 GHz radio (but still supported by the same > driver, ath9k). Without knowing any details, I fear this might be > slightly different with the TL-WDR3500. > > > - no gigabit ethernet > > Yes, and this means there is a big chance that the switch chipset might > be different. In contrast to wlan support, where you might be able to > just risk it, missing ethernet/ switch support would have much bigger > consequences. Given that The Atheros DB120 reference architecture, from > which these TP-Link routers are closely derived, is quite well > integrated and is specified with an Atheros AR8327N GBit/s switch, > there is a significant chance that a different switch chipset might be > used here - or eventually some completely different base board. O.k., after looking at the FCC pictures, which are not detailed enough to read all of the chips, it becomes clear that they're using a similar, but significantly different PCB for the TL-WDR3500 - so you really should make high resolution pictures and check bootlog/ GPL tarball before risking anything. While there still is a small chance that the differences are small enough that OpenWrt might "just work" for this device as well, it does look like there is a different solution in place for the networking switch, so it's more likely that some more involved source changes might be needed. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] support for TP-Link TL-WDR3500. Was: Re: [RFC] ar71xx: add support for the TP-Link TL-WDR4310 v1.0
Hi On Thursday 20 December 2012, Nicolás Echániz wrote: > TP-Link WDR3600 is supported since r33219. It has the same hardware as > the WDR4300 with one less chain/antenna. > > However the model WDR3500, which is similar to WDR3600 is not yet > supported. Outstanding differences in relation to WDR3600 are: For the TL-WDR3600, the situation was easy (once TL-WDR4300 was supported), because it's essentially the same device, with only minor differences for the 2.4 GHz radio (but still supported by the same driver, ath9k). Without knowing any details, I fear this might be slightly different with the TL-WDR3500. > - no gigabit ethernet Yes, and this means there is a big chance that the switch chipset might be different. In contrast to wlan support, where you might be able to just risk it, missing ethernet/ switch support would have much bigger consequences. Given that The Atheros DB120 reference architecture, from which these TP-Link routers are closely derived, is quite well integrated and is specified with an Atheros AR8327N GBit/s switch, there is a significant chance that a different switch chipset might be used here - or eventually some completely different base board. > - one USB port instead of two This should not have any impact on firmware support, but there may of course also be other differences which may require new hardware support (e.g. flash chipset, etc.). > Here in the QuintanaLibre network we have been testing WDR3600 with much > success as a cheap multi-band router. WDR3500 is even cheaper and we > would very much like to test it. If you'd only need a single, or a handful of devices, I wouldn't risk it - especially because the price difference is pretty small, but I think you might need a few more… However if you really do, make sure to check the abilities of the network switch before ordering a larger quantity. > What would it involve to have the WDR3500 supported? […] First, you should try to find (or make) high resolution pictures of the PCB used in this TL-WDR3500, ideally also try to find (or make) a bootlog of the original vendor firmware; you could also try to compare the GPL firmware tarballs for TL-WDR3600 and TL-WDR3500 for important differences. Like mentioned above, the most interesting aspects, once you can confirm that this TL-WDR3500 really is a close derivative to the other members of this new router class, are network switch and flash types. Of course, you may also just risk it and adapt the (binary-) firmware header to the needs of your device and pray that everything else "just works™" - while there is a certain chance for this, you should at least have a serial console prepared (and once you considering this, do check the original bootlog and make high resolution pictures of the PCB before trying your luck) - as you would need it to recover from a bricked device. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] ar71xx: add support for the TP-Link TL-WDR4310 v1.0
The hardware for TP-Link TL-WDR4300 v1.1 and TL-WDR4310 v1.0 is identical, but requires different firmware headers: TL-WDR4300: 0040 43 00 00 01 00 00 00 01 00 00 00 00 76 fb 83 40 |C...v..@| TL-WDR4310: 0040 43 10 00 01 00 00 00 01 00 00 00 00 38 2b 50 6c |C...8+Pl| Signed-off-by: Stefan Lippers-Hollmann Cc: Gabor Juhos --- UNTESTED, please don't apply until anyone with TL-WDR4310 hardware can confirm this to be functional. Update: According to http://wiki.openwrt.org/toh/tp-link/tl-wdr4310, these changes seem to be sufficient. linux/ar71xx/base-files/lib/ar71xx.sh|2 +- linux/ar71xx/generic/profiles/tp-link.mk |2 +- linux/ar71xx/image/Makefile |1 + 3 files changed, 3 insertions(+), 2 deletions(-) Index: target/linux/ar71xx/base-files/lib/ar71xx.sh === --- target/linux/ar71xx/base-files/lib/ar71xx.sh(revision 32499) +++ target/linux/ar71xx/base-files/lib/ar71xx.sh(working copy) @@ -123,7 +123,7 @@ "342000"*) model="TP-Link TL-MR3420" ;; - "43"*) + "43"*|"431000"*) model="TP-Link TL-WDR4300" ;; *) Index: target/linux/ar71xx/generic/profiles/tp-link.mk === --- target/linux/ar71xx/generic/profiles/tp-link.mk (revision 32499) +++ target/linux/ar71xx/generic/profiles/tp-link.mk (working copy) @@ -95,7 +95,7 @@ define Profile/TLWDR4300 - NAME:=TP-LINK TL-WDR4300 + NAME:=TP-LINK TL-WDR4300/ TL-WDR4310 PACKAGES:=kmod-usb-core kmod-usb2 kmod-ledtrig-usbdev endef Index: target/linux/ar71xx/image/Makefile === --- target/linux/ar71xx/image/Makefile (revision 32499) +++ target/linux/ar71xx/image/Makefile (working copy) @@ -977,6 +977,7 @@ tlwdr4300_cmdline=board=TL-WDR4300 console=ttyS0,115200 define Image/Build/Profile/TLWDR4300 $(call Image/Build/Template/$(fs_64kraw)/$(1),TPLINK-LZMA,tl-wdr4300-v1,$(tlwdr4300_cmdline),0x4301,1,8Mlzma) + $(call Image/Build/Template/$(fs_64kraw)/$(1),TPLINK-LZMA,tl-wdr4310-v1,$(tlwdr4300_cmdline),0x4311,1,8Mlzma) endef wndr3700_cmdline=board=WNDR3700 console=ttyS0,115200 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
