Re: ipv6 quirk openwrt 21.02.1
Understood - thank you. So DF provokes the detection of the weakest link for MTU discovery. So a bit of digging and development is necessary if I wish to have that option available in the luci GUI. Complex? The weird thing in this setup is that the IPv4 PMTU is 1480 all the way. It's only at IPv6 layer the PMTU is reduced. possibly something similar occuring at IPv6. Is it possible something unusual is happening in 6in4 or lower? On 2021-11-04 23:04, Nathan Lutchansky wrote: On 11/4/21 11:52 AM, Paul D wrote: Having a bit of IPv6 6in4 problem. I set a static MTU to 1480 locally and remotely (HE tunnel). As I interpret the RFC [1] as referenced by overarching RFC [2], it notes: > When using the static tunnel MTU, the Don't Fragment bit MUST NOT be > set in the encapsulating IPv4 header. As a result, the encapsulator > should not receive any ICMPv4 "packet too big" messages as a result > of the packets it has encapsulated. But pcaps clearly show in the IPv4 packet: > Flags: 0x40, Don't fragment > 0... = Reserved bit: Not set > .1.. = Don't fragment: Set > ..0. = More fragments: Not set Is this considered normal IPv6 tunneling behaviour? Or is this broken? This is normal for Linux. Since forcing routers to perform fragmentation mid-path is a huge performance hit, Linux uses path MTU discovery to determine the real MTU of the tunnel, and then generates fragmentation-needed errors at the tunnel ingress if the outer packet would be too large for the path. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: awk problem on pistachio (24kc+24kf)
On Tue, Nov 02, 2021 at 11:49:02PM +0100, Hauke Mehrtens wrote:
> Hi,
>
> On pistachio sysupgrade in master fails and I got down to a problem with
> awk. This command returns different results on pistachio compared to other
> targets:
>echo "mtd2: 2000 1000 \"uEnv\"" | awk -F: '{print $1}'
>
> When I execute this on an lantiq/xrx200 or mt7622 device I get this:
>mtd2
>
> When I execute this command on pistachio in master I get this:
>mtd2: 2000 1000 "uEnv"
So the separator doesn't match. Maybe another integer bitwidth issue,
ie. comparing char aka. uint8 with uint16 or uint32 having their upper
bits not zero'd because only the first 8 bit of the register were
loaded, leaving old value in the remaining 8 or 24 bits?
Another interesting thing would be to try moving the position of the
':' as any variation in the result would be a clear hint towards
MIPS unaligned access being the problem...
There are also hints on kernel mailing lists that Ingenic
implementation of MIPS interAptiv somehow differs in how cpu cache has
to be dealt with in combination with some memory access instructions
(I didn't get into the details and can't find it again atm)
Does this also happen when using `cut -d: -f1` instead of the `awk`
call (not that this would solve anything, but if it happens also when
using `cut` it would be easier to debug as `cut` is much less complex
than `awk`, both are busybox applets).
>
> This is part of the find_mtd_index() function used for sysupgrade.
>
> The pistachio target is MIPS 32 little Endian with hardware floating point
> activated. This target is not much used, nobody complained that it did not
> boot for multiple months, but I am interested why it fails.
Unfortunately my pistachio board got stolen from my car 2 years ago
(among with tons of other equipment I had boxed up there).
> I also see this problem with OpenWrt master from August 2020 which was still
> on the board.
So at least this is not due to recent GCC or musl updates...
(that doesn't make it better though)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] uboot-lantiq: danube: fix hanging lzma kernel uncompression
At least since gcc 7.3.0 (OpenWrt 18.06) lwr/lwl are used in the assembly of LzmaProps_Decode. While the decission made by the compiler looks perfect fine, it triggers some obscure hang on lantiq danube-s v1.5 with MX29LV640EB NOR flash chips. Only if the offset 1 is used, the hang can be observed. Using any other offset works fine: lwl s0,0(a1) - s0 == 0x6d80 lwl s0,1(a1) - hangs lwl s0,2(a1) - s0 == 0x0080 lwl s0,3(a1) - s0 == 0x80xx It isn't clear whether it is a limitation of the flash chip, the EBU or something else. Force 8bit reads to prevent gcc optimizing the read with lwr/lwl instructions. Signed-off-by: Mathias Kresin --- Changes in v2: - add more details to the commit message about what can be observed - mention the affected hardware combination - use readb() to force 8 bit reads .../patches/0030-lzma-force-8bit-reads.patch | 48 +++ 1 file changed, 48 insertions(+) create mode 100644 package/boot/uboot-lantiq/patches/0030-lzma-force-8bit-reads.patch diff --git a/package/boot/uboot-lantiq/patches/0030-lzma-force-8bit-reads.patch b/package/boot/uboot-lantiq/patches/0030-lzma-force-8bit-reads.patch new file mode 100644 index 00..dc7d9ed7ee --- /dev/null +++ b/package/boot/uboot-lantiq/patches/0030-lzma-force-8bit-reads.patch @@ -0,0 +1,48 @@ +From a40a6e16ed76e5e26a0f60226b64c311d4a62c9f Mon Sep 17 00:00:00 2001 +From: Mathias Kresin +Date: Sun, 31 Oct 2021 23:04:54 +0100 +Subject: [PATCH] lzma: force 8bit reads + +At least since gcc 7.3.0 (OpenWrt 18.06) lwr/lwl are used in the +assembly of LzmaProps_Decode. While the decission made by the compiler +looks perfect fine, it triggers some obscure hang on lantiq danube-s +v1.5 with MX29LV640EB NOR flash chips. + +Only if the offset 1 is used, the hang can be observed. Using any other +offset works fine: + + lwl s0,0(a1) - s0 == 0x6d80 + lwl s0,1(a1) - hangs + lwl s0,2(a1) - s0 == 0x0080 + lwl s0,3(a1) - s0 == 0x80xx + +It isn't clear whether it is a limitation of the flash chip, the EBU or +something else. + +Force 8bit reads to prevent gcc optimizing the read with lwr/lwl +instructions. + +Signed-off-by: Mathias Kresin +--- + lib/lzma/LzmaDec.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/lib/lzma/LzmaDec.c b/lib/lzma/LzmaDec.c +@@ -7,6 +7,7 @@ + #include "LzmaDec.h" + + #include ++#include + + #define kNumTopBits 24 + #define kTopValue ((UInt32)1 << kNumTopBits) +@@ -929,7 +930,7 @@ SRes LzmaProps_Decode(CLzmaProps *p, con + if (size < LZMA_PROPS_SIZE) + return SZ_ERROR_UNSUPPORTED; + else +-dicSize = data[1] | ((UInt32)data[2] << 8) | ((UInt32)data[3] << 16) | ((UInt32)data[4] << 24); ++dicSize = readb([1]) | ((UInt32)readb([2]) << 8) | ((UInt32)readb([3]) << 16) | ((UInt32)readb([4]) << 24); + + if (dicSize < LZMA_DIC_MIN) + dicSize = LZMA_DIC_MIN; -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
wget: limit downloaded bytes problem
With OpenWRT master and busybox v1.34.1 (musl-1.2.2), but also with older busybox v1.26.2 (musl-1.1.16), I see these issues with wget: # on server: dd if=/dev/urandom of=/var/www/random.bin bs=513 count=1 # on OpenWRT/client: limit downloaded bytes: wget -O - http://intercity-vpn.de/random.bin | head -c 10 >/tmp/part (hangs/connection times out) ^ The interesting things are: 1) sometimes it works 2) no problem with files =< 512 bytes i tried it with different architectures: OK: mipsel_24kc / ramips (Archer C6U) problem: x86_64 (qemu) problem: mips_24kc (TP-Link 4300) problem: ppc/powerpc_8540 (TP-Link 4900) problem: arm_arm1176jzf-s_vfp = bcm2708/armv6l/RaspPiZero using GCC8 or GCC11 makes no difference. using 'curl' instead of wget works without issues. A selfcompiled static musl-busybox + qemu x86_64 has no issues. Can somebody confirm this? Has somebody an idea why i can see this only on OpenWRT? bye, Bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
