Re: OpenWrt IKEv2 NAT traversal (or similar) problem
On 5/31/23 21:08, Yousong Zhou wrote: Not that I got any clue, but this looks very suspicious that you saw the supposed-to-go-through-tunnel packet at an intermediate router (the openwrt device). I don't know exactly what happened here, but I didn't see it again. In any case, it turns out that enabling the xfrm module resolved the problem - hopefully this saves someone else some grief. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt IKEv2 NAT traversal (or similar) problem
On 5/31/23 10:20, Peter Naulls wrote: On 5/30/23 21:09, Yousong Zhou wrote: On Wed, 31 May 2023 at 06:38, Peter Naulls wrote: Thanks for you patience, more: I ran the connection instead over a wired WAN connection instead of the cell WWAN link, and the problem is the same. This points the finger rather squarely at packet processing/forwarding or similar on OpenWrt. I did find some reference to some similarish problems - in almost all the searches I've done, the VPN is initiated on the Linux router, however - but there's some suggestion that MTU/MSS is implicated - I've rather severely limited MTU on all the interfaces in OpenWrt as well as the physical and VPN interfaces in Windows to no avail. The fetch can be done in Windows to http://www.yahoo.com (instead of https), which of course normally results in an HTTP redirect - this makes the transaction a bit smaller, since no attempt at TLS. In this case, curl does send the HTTP headers, but there's no response, and the issues with the "missing" packet that I described earlier is still ultimately seen on the VPN interface. I realize that since it's UDP, that duplicated and missing packets are entirely possible, but could it be that this happens in a 100% repeatable fashion in some cases? That would be strange, certainly. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt IKEv2 NAT traversal (or similar) problem
On 5/30/23 21:09, Yousong Zhou wrote: On Wed, 31 May 2023 at 06:38, Peter Naulls wrote: Is it that your dns traffic is not going through the tunnel? curl -vvv should reveal the IP address it tries to connect. One possibility is that maybe the resolv result does not work. Yes, a DNS was an early check, I don't think this is the problem though. When I said no data comes back from curl, this wasn't 100% correct - here's the output (https://www.yahoo.com/ which is another problem site): % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 74.6.231.21:443... * Connected to www.yahoo.com (74.6.231.21) port 443 (#0) * ALPN: offers h2 * ALPN: offers http/1.1 * CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt * CApath: none } [5 bytes data] * [CONN-0-0][CF-SSL] TLSv1.3 (OUT), TLS handshake, Client hello (1): } [512 bytes data] 0 00 00 0 0 0 --:--:-- 0:00:04 --:--:-- 0 In Wireshark on the VPN interface, I can see that after the TLSv1 Client Hello and then ACK, after that I get two errors: "TCP Previous segment not captured" (port 443) and "Dup ACK". The latter might just be a side effect of VPN retries or something. Looking at the interface itself, during the stream of ESP packets, we get a TCP re transmission packet from the VPN host to the LAN IP, which seems wrong. This is a match for this tcpdump from br-lan on OpenWrt: 14:14:45.368484 IP (tos 0x0, ttl 255, id 64433, offset 0, flags [none], proto UDP (17), length 128) 192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap: ESP(spi=0xce938746,seq=0x52), length 100 14:14:47.919812 IP (tos 0x68, ttl 60, id 18554, offset 0, flags [none], proto TCP (6), length 342) 20.25.241.18.443 > 192.168.113.102.62792: Flags [P.], cksum 0x12c7 (correct), seq 0:302, ack 1, win 172, length 302 14:14:50.120142 IP (tos 0x0, ttl 255, id 64434, offset 0, flags [none], proto UDP (17), length 112) 192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap: ESP(spi=0xce938746,seq=0x53), length 84 Which I think is already a clue - the response is coming back via TCP 443 not over the VPN UDP 4500. Thanks again. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt IKEv2 NAT traversal (or similar) problem
On 5/30/23 18:16, Yousong Zhou wrote: On Wednesday, 31 May 2023, Peter Naulls wrote: ] I am afraid the above is still single direction traffic. Sorry, quite so. I finished this email in the middle of something else. There is return traffic: To Google, which works. 16:57:11.936911 IP (tos 0x0, ttl 128, id 43279, offset 0, flags [none], proto UDP (17), length 29) 192.168.113.102.4500 > 89.187.170.130.4500: [udp sum ok] isakmp-nat-keep-alive 16:57:16.597085 IP (tos 0x0, ttl 255, id 43280, offset 0, flags [none], proto UDP (17), length 128) 192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap: ESP(spi=0xc4a096e5,seq=0x31b), length 100 16:57:16.597085 IP (tos 0x0, ttl 255, id 43281, offset 0, flags [none], proto UDP (17), length 128) 192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap: ESP(spi=0xc4a096e5,seq=0x31c), length 100 16:57:16.629104 IP (tos 0x0, ttl 128, id 43983, offset 0, flags [none], proto UDP (17), length 60) 192.168.113.102.63724 > 192.168.113.3.53: [udp sum ok] 56044+ ? www.google.com. (32) 16:57:16.629104 IP (tos 0x0, ttl 128, id 43982, offset 0, flags [none], proto UDP (17), length 60) 192.168.113.102.54875 > 192.168.113.3.53: [udp sum ok] 4736+ A? www.google.com. (32) 16:57:16.630048 IP (tos 0x0, ttl 255, id 43282, offset 0, flags [none], proto UDP (17), length 128) 192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap: ESP(spi=0xc4a096e5,seq=0x31d), length 100 16:57:16.630050 IP (tos 0x0, ttl 255, id 43283, offset 0, flags [none], proto UDP (17), length 128) 192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap: ESP(spi=0xc4a096e5,seq=0x31e), length 100 16:57:16.634072 IP (tos 0x0, ttl 64, id 12085, offset 0, flags [DF], proto UDP (17), length 88) 192.168.113.3.53 > 192.168.113.102.63724: [bad udp cksum 0x6410 -> 0x70cf!] 56044 q: ? www.google.com. 1/0/0 www.google.com. [1m52s] 2607:f8b0:4006:81d::2004 (60) 16:57:16.639834 IP (tos 0x0, ttl 64, id 12086, offset 0, flags [DF], proto UDP (17), length 76) 192.168.113.3.53 > 192.168.113.102.54875: [bad udp cksum 0x6404 -> 0x3314!] 4736 q: A? www.google.com. 1/0/0 www.google.com. [4m19s] A 142.251.32.100 (48) 16:57:16.654048 IP (tos 0x68, ttl 50, id 41090, offset 0, flags [none], proto UDP (17), length 224) 89.187.170.130.4500 > 192.168.113.102.4500: [no cksum] UDP-encap: ESP(spi=0x0a11bcfe,seq=0x26d), length 196 16:57:16.665933 IP (tos 0x68, ttl 50, id 41091, offset 0, flags [none], proto UDP (17), length 240) 89.187.170.130.4500 > 192.168.113.102.4500: [no cksum] UDP-encap: ESP(spi=0x0a11bcfe,seq=0x26e), length 212 16:57:16.668916 IP (tos 0x0, ttl 255, id 43284, offset 0, flags [none], proto UDP (17), length 128) 192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap: ESP(spi=0xc4a096e5,seq=0x31f), length 100 16:57:16.711776 IP (tos 0x68, ttl 50, id 41104, offset 0, flags [none], proto UDP (17), length 160) 89.187.170.130.4500 > 192.168.113.102.4500: [no cksum] UDP-encap: ESP(spi=0x0a11bcfe,seq=0x26f), length 132 To another site, which doesn't: 17:02:12.192380 IP (tos 0x0, ttl 255, id 43526, offset 0, flags [none], proto UDP (17), length 144) 192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap: ESP(spi=0xc4a096e5,seq=0x415), length 116 17:02:12.219548 IP (tos 0x0, ttl 255, id 43527, offset 0, flags [none], proto UDP (17), length 144) 192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap: ESP(spi=0xc4a096e5,seq=0x416), length 116 17:02:12.374062 IP (tos 0x68, ttl 50, id 6571, offset 0, flags [none], proto UDP (17), length 208) 89.187.170.130.4500 > 192.168.113.102.4500: [no cksum] UDP-encap: ESP(spi=0x0a11bcfe,seq=0x33b), length 180 17:02:12.382227 IP (tos 0x0, ttl 255, id 43528, offset 0, flags [none], proto UDP (17), length 128) 192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap: ESP(spi=0xc4a096e5,seq=0x417), length 100 17:02:12.523997 IP (tos 0x68, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), length 128) 89.187.170.130.4500 > 192.168.113.102.4500: [no cksum] UDP-encap: ESP(spi=0x0a11bcfe,seq=0x33c), length 100 17:02:12.525249 IP (tos 0x0, ttl 255, id 43529, offset 0, flags [none], proto UDP (17), length 112) 192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap: ESP(spi=0xc4a096e5,seq=0x418), length 84 17:02:12.538861 IP (tos 0x68, ttl 50, id 6599, offset 0, flags [none], proto UDP (17), length 208) 89.187.170.130.4500 > 192.168.113.102.4500: [no cksum] UDP-encap: ESP(spi=0x0a11bcfe,seq=0x33d), length 180 17:02:12.625718 IP (tos 0x0, ttl 255, id 43530, offset 0, flags [none], proto UDP (17), length 624) 192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap: ESP(spi=0xc4a096e5,seq=0x419), length 596 17:02:12.855180 IP (tos 0x68, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), length 368)
OpenWrt IKEv2 NAT traversal (or similar) problem
I'm trying to track down a problem whereby using Windows VPN, some websites are accessible and some aren't. The problem is 100% OpenWrt, since it works over my regular WiFi router. Here's what I know (or think I know): All the VPN traffic uses UDP port 4500. This is (or should be) a pretty typical 22.03 NAT setup. The setup I'm testing against is with privatevpn.com, although the actual setup is something else, but the problem is the same. Using curl under Windows to try and isolate the problem and tcpdump under OpenWrt, mostly looking at br-lan. The upstream is a wwan0 AT connection. Looking at a fetch to https://www.google.com/ for example I can see there's traffic in both directions, the NAT seems to be working as expected and all works. However, if I try and fetch certain sites, and one in particular is https://gov.visuallabsinc.com/ then there's still traffic in both directions, but whatever is happening, it's not reaching the HTTP layer in curl and nothing appears there - just a hang. Here's some example traffic: 17:02:12.192380 IP (tos 0x0, ttl 255, id 43526, offset 0, flags [none], proto UDP (17), length 144) 192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap: ESP(spi=0xc4a096e5,seq=0x415), length 116 17:02:12.219548 IP (tos 0x0, ttl 255, id 43527, offset 0, flags [none], proto UDP (17), length 144) 192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap: ESP(spi=0xc4a096e5,seq=0x416), length 116 I have tried messing with the usual suspects - MTU, MSS, even put a forward rule in the firewall for UDP 4500, but I guess I'm missing something. Any suggestions on what else to look at or to try? Let me know if you need further details or better traces, etc. Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt vs Defense positions
On 5/7/23 13:19, Hauke Mehrtens wrote: I check from time to time which companies in the US are looking for OpenWrt experts [0] to get an overview who is using it. About 10% to 30% of these job offers require clearance. It looks like the US military and US intelligence community is using OpenWrt. Once I saw a job offer where someone was looking for a person who has experience in writing exploits for OpenWrt and DD-WRT in the Washington, D.C. area, this scared me a bit, normally I do not have the NSA in my thread model. Someone from BAE Systems (largest defence contractor in Europe) was also contacting us at OpenWrt some years ago with questions about the license. I hope that these companies use OpenWrt mostly to provide Internet access for their soldiers and it is not part of any real weapon system. As OpenWrt is now used by many vendors I think the intelligence agencies around the world are interested in exploits fro OpenWrt. I'm now getting at least two queries a week from recruiters regarding (non-OpenWrt) but embedded Linux positions building weapons systems. My usual reply is that "firing missiles at people doesn't improve the world". That's hippy idealism of course, but it's still my stance. (My current involvement in OpenWrt is providing cell/internet access to first responders; my knowledge of military internet or whatever is zero apart from the the obvious history). I heard a rumor some years ago that one of the biggest OpenWrt installation was at the fence between the US and Mexico, but I have no prove that this is true. Yes, and regarding security as we usually mean in the software stance, and whether the rumor is true or not, OpenWrt is widely deployed. It doesn't take very much paranoia at all to think that there are government departments in various countries keeping track of issues with embedded Linux in general and OpenWrt in particular. It also doesn't take much of a stretch to image they have at least some info on major OpenWrt contributors such as yourself or people who have long expressed interest in embedded Linux security, although certainly in my case, it would be short and boring. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt vs Defense positions
On 5/2/23 09:31, Enrico Mioso wrote: On Tue, May 02, 2023 at 09:24:52AM -0400, Peter Naulls wrote: On 5/2/23 07:26, Enrico Mioso wrote: Another impression I have, is that the OpenWrt project is very important for many yet under-resourced. There are some important tasks that would help with the long-term maintenance (e.g. merging of the mtk_nand for mt7621 and the upstrema one, if at all possible), which require time and highly motivated person to carry on. I was that person, but at this point, the upstream m7621 NAND driver works correctly, *except* when the MMC is also enabled. The mtk_nand driver is very old and I did get it to run correctly for reads under current kernel, but it didn't seem to have any further value here, and many obvious faults - see my discussion on this a few months back. If there's specific work you know of here, I'd be very interested. Thanks for your reply. No, I don't know wether work is ongoing on that at the moment, sorry. Yes, but there must have been some issue that caused this comment - is there some backstory here? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt vs Defense positions
On 5/2/23 07:26, Enrico Mioso wrote: On Mon, May 01, 2023 at 04:56:36PM -0400, Peter Naulls wrote: On 5/1/23 16:42, Dave Taht wrote: one of the constraints OpenWrt has been placed under, historically, is the need to fit in small flash memoris, so fitting some libraries and infrastructure maybe a little bit of a stretch here. Furthermore, OpenWrt has been tought to be a platform, not a "finished" solution: this is not meant bo be an "excluse", just to note that some particular problems, and their solutions, have not been integrated in the core. In some cases, like for ModemManager, the problems where related to size and complexity, I think. Yes, although that's more historic; one of the reasons we did in fact go to NAND below is due to size constraints; and indeed with ModemManager. It took us a long time to get ModemManager working how we liked it, since it's not a 100% solution all by itself, and our needs are very specific. Another impression I have, is that the OpenWrt project is very important for many yet under-resourced. There are some important tasks that would help with the long-term maintenance (e.g. merging of the mtk_nand for mt7621 and the upstrema one, if at all possible), which require time and highly motivated person to carry on. I was that person, but at this point, the upstream m7621 NAND driver works correctly, *except* when the MMC is also enabled. The mtk_nand driver is very old and I did get it to run correctly for reads under current kernel, but it didn't seem to have any further value here, and many obvious faults - see my discussion on this a few months back. If there's specific work you know of here, I'd be very interested. As for what will happen with OpenWrt when it will become used in some important places, I don't have an answer of course. Does anyone know how much contributions come from people working for companies in OpenWrt? Who knows. I will say that OpenWrt has formed a large part of my career. As measured by patches (which frankly, is something of a time-consuming hurdle), my contributions are very very small, but all my OpenWrt work has been under companies. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt vs Defense positions
On 5/1/23 16:42, Dave Taht wrote: How a ragtag bunch of unincorporated (mostly?) peacenik hippie types can co-exist with devices being built by militaries out of this stuff I have few ideas. I prefer to shrink the world, and produce stable, secure, software, for everyone that wants it, but I look at the contentious places where it also goes (like space, or spacex) and wonder how it will all end up, and who will maintain it, improve it, or attempt to subvert it. Yes, and on a parallel note about security (not "Security" aka Defense), OpenWrt is good, but not excellent. This has been a long term interest of mine, largely due to career need rather than enthusiasm per se - the product I'm working on now has been through multiple security reviews - much of it without question is theater. See a discussion I started on this some months ago - there's been a bit of a historic lack of appetite for this topic, partly because some of the theater is certainly high-class nonsense, and partly because of lack of resources - OpenWrt doesn't really have a dedicated security effort (if I missed something in recent months than I apologize), and some of the suggestions I've made have gone into the ether. Still, I think there's a growing recognition of its use - certainly many home routers and no little number of special-user routers run it as well as commercial applications and of course the original topic I raised. OpenWrt now has vastly more clout in the world than superficial visibility would suggest. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt vs Defense positions
For those of you who track the small but very real OpenWrt job market, you may have seen there's a creep into Defense/Clearance jobs. Here's but one example: https://careers-bluehalo.icims.com/jobs/3844/job As a self-declared pacifist (and anyway, dual citizen which would limit my ability to get clearance), this is most certainly not for me, but I thought it should be something you guys might want to be aware of. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: MT7621 NAND vs MMC (was: MT7621 NAND OOB misdetect)
On 2/21/23 11:02, Peter Naulls wrote: On 2/15/23 10:17, Chuanhong Guo wrote: Hi! What to try next, thanks! It looks like the detected spare size and ECC strength matches between the two drivers, according to the u-boot message and kernel log. Maybe you can try dumping the nand controller setup registers and compare the register values between the two drivers? I don't have any other easier ideas now :( After some marathon debug, I have an answer to this. It seems that once the MT7621 MMC driver gets loaded, then the NAND driver's busy flag becomes stuck on forever. This was loaded as a module, so the first few flash lookups (such as MAC addresses) would work, and then failure after. Why this might be, I don't know, and I don't have the appetite to look into the MMC driver - I disabled it in my build. I'm sure someone has some insight into this. I was able to get both the legacy driver and the current kernel driver working - but the former is rife with problems, so there's no cause to use it. Thanks again to Chuanhong. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] mt7621: move uboot-envtools to DEFAULT_PACKAGES
On 2/28/23 09:07, Felix Baumann wrote: one issue I see here is that there are MT7621 devices like the Asus RT-AX53U that don't save their environment to their u-boot-env partition by default. You still need to execute saveenv while connected via serial. Note: the device doesn't have a u-boot-env partition in stock rom. The environment is saved to the second half of the original u-boot partition. We added uboot-envtools support by splitting the u-boot partition in half. What problem are you trying to solve here? Are you relying upon the u-boot values for MAC address or something? On one of my boards, so I do fix up the u-boot values, just so it's correct, but the actual MAC values are stored elsewhere in both binary and ASCII values. If you just care about reading the values, it's not required to use u-boot-env tools - you can parse yourself or use the OpenWrt functions, which are basically a "strings" operation. But I think the bottom line here is mt7621 is a very diverse platform, and there's no one-size-fits-all with package selection or anything. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] mt7621: move uboot-envtools to DEFAULT_PACKAGES
On 2/28/23 06:46, Bjørn Mork wrote: Peter Naulls writes: On 2/27/23 17:23, Hauke Mehrtens wrote: This will add uboot-envtools to all devices. uboot-envtools is not included in all DEVICE_PACKAGES now, should we explicitly remove it from device definitions which do not had it before? The Device/adslr_g7 for example does not add uboot-envtools in its DEVICE_PACKAGES. Same comment for NAND support. Only 1/3rd or so of the mt7621 systems use the nand feature. This is a difficult problem for any feature which is required by one or more device during boot or upgrade. Using a shared rootfs per target means that all such features must be included on all devices. The alternatives are AFAICS 1) splitting targets by feature sets 2) always use a per-device rootfs I believe 2) is non-trivial. 1) might be easier and could make some sense for huge targets like mt7621? Well, I certainly agree. I have this situation. I have a separate build system, which setups an overlay per device (3x mt7621 boards) in files and then also does some post-processing to the rootfs via a change I put in the end of the OpenWrt scripts. But one solution here might be per-target package selection - I can imagine this getting messy though. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] mt7621: move uboot-envtools to DEFAULT_PACKAGES
On 2/27/23 17:23, Hauke Mehrtens wrote: Build firmware images for Ralink MT7621 based boards. This will add uboot-envtools to all devices. uboot-envtools is not included in all DEVICE_PACKAGES now, should we explicitly remove it from device definitions which do not had it before? The Device/adslr_g7 for example does not add uboot-envtools in its DEVICE_PACKAGES. Same comment for NAND support. Only 1/3rd or so of the mt7621 systems use the nand feature. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: m7621 i2c read failure
On 2/20/23 09:48, Peter Naulls wrote: On 2/16/23 17:17, Alexander Papazoglou wrote: My first guess would be that your microcontroller code doesn't handle repeated starts properly. All of the i2ctransfer commands you've shown involve at least one repeated start with the new driver but perhaps not with the old one. To verify, you can break them up in such a way that no repeated starts are issued. Since you control the microcontroller, you can add diagnostic code (printfs?) to see what I2C reads/writes are being issued by the MT7621. I've now spent some time with this, and I think your theory is correct based upon what little debug I can get out of the MCU - inconsistent use of break points, incomplete variable display etc. Sometimes I see it get into loops from which it doesn't recover. I did spend a while looking at the two versions of the driver, but I wasn't sure entirely how to break it up to not do the repeated starts - I'm sure it's obvious, but I guess you gotta know. My colleague pointed out that we have an almost identical setup on a prior board - same CPU, same kernel - the difference there is a different MCU. Sometimes that setup returns top-bit set and bogus values from its (probably more sophisticated I2c setup, but it's sufficiently infrequent that we can work around it). In any case, there probably isn't any fundamental problem with the Linux setup - the old driver just happened to be naive and lucky enough to mostly work most of the time. The Sinomcu code is copyright them, but freely available for download from their website, and I wasn't subject to any NDAs or anything regarding this: https://www-sinomcu-com.translate.goog/product/detail?id=80&_x_tr_sl=zh-CN&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=sc I could probably paste the relevant short function here (i2c_master_write_slave), but because this is an OSS project, I'd rather err on the side of caution and not do that - I'll email it to anyone who asks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Override MAC address for interface?
On 2/23/23 01:43, Rafał Miłecki wrote: On 22.02.2023 21:02, Peter Naulls wrote: config device option 'lan1' This line is clearly wrong. See how you specify device name in above section. Perhaps it is "clear" but there's much in OpenWrt that isn't obvious up front, until you know, and then it is. But thanks for the correction. However, what I really want to do is this: config interface 'wan' option auto '0' option proto 'dhcp' #option device 'wan' option name 'wan' option metric '0' config device 'wan' option name 'wan' option macaddr '34:BA:9A:CC:DD:BB' But uci doesn't allow this. I guess I'll have to rename the wan device in the DTS to wan0 or something. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Override MAC address for interface?
On 2/22/23 15:34, Robert Marko wrote: option 'lan1' option macaddr 34:BA:9A:CC:DD:EE This should work as long as its in single quotes. I corrected the quotes, but no joy. Also, cant you fixup the MAC in 02_networking or in preinit? Yes, I have a preinit script, but it seems that the MAC address doesn't get retained. Probably cleared by netifd, which would be entirely expected. The plan of course is to have the preinit script do the config setting. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Override MAC address for interface?
Due to some missing flash values, I need to do a later user space lookup for possible missing values stored "elsewhere" to fix up the MAC address. According to: https://openwrt.org/docs/guide-user/base-system/basic-networking Something like this should work: config device option name 'br-lan' option type 'bridge' list ports 'lan1' list ports 'lan2' list ports 'lan3' list ports 'lan4' config device option 'lan1' option macaddr 34:BA:9A:CC:DD:EE But it doesn't get applied in my testing. As far as I know, there's no option to override the MAC in current luci. I am using ifconfig at boot to set the MAC, but that's transient and doesn't remain set. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: MT7621 NAND OOB misdetect
On 2/15/23 10:17, Chuanhong Guo wrote: Hi! What to try next, thanks! It looks like the detected spare size and ECC strength matches between the two drivers, according to the u-boot message and kernel log. Maybe you can try dumping the nand controller setup registers and compare the register values between the two drivers? I don't have any other easier ideas now :( Yes, right. Well, I did do this with all the "obvious" values, and everything matches up. After some considerable effort and some intrusive changes, I did get the legacy driver working on the current kernel. It correctly detects things, but the data it's reading with nanddump is clearly coming from "somewhere else" (looks like a procd memory buffer), and not the actual NAND contents. Could this be fixed? Perhaps, although this is all new to me, and it's old and now hacked up code, so I'm not sure it's worth it except perhaps as a baseline, and learning how things work. I do see there are perhaps some DTS hints about NAND layout, so that might be relevant too, to making the current driver work. Here's the old driver on the current 5.10.x kernel, just in case - a fair bit of this debug is my own. [ 16.338256] # MTK NAND # : Use HW ECC [ 16.345553] Device not found, ID: c2f1 [ 16.353016] Not Support this Device! [ 16.360479] chip_mode=000A [ 16.366548] NAND: chipsize: 134217728 page_shift: 11 pagemask: 65535 phys_erase_shift: 17 chip_shift: 27 [ 16.385434] eccbytes: 96 sparesize: 128 [ 16.385442] Support this Device in MTK table! c2f1 [ 16.402956] NAND: DMA disabled [ 16.402980] [NAND]select ecc bit:12, sparesize :112 spare_per_sector=28 [ 16.422280] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1 [ 16.434932] nand: Macronix NAND 128MiB 3,3V 8-bit [ 16.444307] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 32 [ 16.459383] NAND: chipsize: 134217728 page_shift: 11 pagemask: 65535 phys_erase_shift: 17 chip_shift: 27 [ 16.478265] Block protection check failed [ 16.486255] Scanning device for bad blocks [ 16.762369] NAND: Erase disabled ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: m7621 i2c read failure
On 2/16/23 17:17, Alexander Papazoglou wrote: My first guess would be that your microcontroller code doesn't handle repeated starts properly. All of the i2ctransfer commands you've shown involve at least one repeated start with the new driver but perhaps not with the old one. To verify, you can break them up in such a way that no repeated starts are issued. Since you control the microcontroller, you can add diagnostic code (printfs?) to see what I2C reads/writes are being issued by the MT7621. Yes, understood and thank you. Unfortunately, due to present time constraints, I need to leave this as working "well enough" with the older driver. I strongly suspect I'll be returning to this, but it will be some weeks away. In the meantime, in case someone else stumbles across this, I will add some remaining information that I should have filled in. The MCU is an ARM-based Sinomcu part, which is a clone of some kind. I'm using the Keil SDK and whatever libraries that is pulling in/using. I do have an MCU development board with its own serial port, but in practice on the real hardware, I think the only real debug is going to be i2c itself. I think it is possible to set breakpoints of the debugger (STLink), but not single step for whatever reason. If there's a way to get debug strings of of the STLink, then I haven't discovered it. Thanks again. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: m7621 i2c read failure
On 2/16/23 13:59, Jan Breuer wrote: On 16. 2. 2023 16:21, Peter Naulls wrote: On 2/15/23 13:31, Peter Naulls wrote: I'm trying to track yet another vendor vs current OpenWrt driver mishandling. x00 Can you please provide info about the exact SoC and hardware you are using? Hi Jan, thanks for responding. I probably cut too much of the original message, but it's an mt7621 board, made by Atel. Presumably heavily based upon the original reference board, but I couldn't say for sure. I don't believe it's hugely different to any of the other mt7621 systems; certainly the dts only varies in things like GPIO location and flash layout etc. I'm a little bit lost here. It seems to me, that also the vendor driver does not work all the time for you and you must "reset" something, but maybe I just misunderstood this. I think the "reset" was a red herring due to a daemon I had running which also queried the i2c bus (wrongly). The i2c code on the MCU does seem a bit fragile, but in any case appears to be now working as expected with the vendor/old kernel driver. The vendor driver appears to be also be the driver from OpenWrt 18.02ish which is from before your changes. I suspect it doesn't have any changes from the vendor, but I would have to do some careful checking to make entirely sure. Can you please describe the exact protocol you would like to implement in terms of I2C and what device is on the other side? The other end is an MCU with a software setup i2c protocol - it's pretty simple, but here's for example some queries to get the firmware version etc that I had posted originally: Writes work correctly. This for example sets LEDs via i2c (handled by the MCU and its GPIOs - I control this code too): # i2ctransfer -y 0 w1@0x50 0x43 w3 3 2 1 Wed Feb 15 18:23:01 2023 kern.debug kernel: [ 307.979880] i2c i2c-0: ioctl, cmd=0x705, arg=0x7fb736f0 Wed Feb 15 18:23:01 2023 kern.debug kernel: [ 307.979927] i2c i2c-0: ioctl, cmd=0x703, arg=0x50 Wed Feb 15 18:23:01 2023 kern.debug kernel: [ 307.979954] i2c i2c-0: ioctl, cmd=0x707, arg=0x7fb736f0 # i2ctransfer -y 0 w1@0x50 1 r1 Wed Feb 15 18:23:04 2023 kern.debug kernel: [ 310.921389] i2c i2c-0: ioctl, cmd=0x705, arg=0x7febfd60 Wed Feb 15 18:23:04 2023 kern.debug kernel: [ 310.921437] i2c i2c-0: ioctl, cmd=0x703, arg=0x50 Wed Feb 15 18:23:04 2023 kern.debug kernel: [ 310.921463] i2c i2c-0: ioctl, cmd=0x707, arg=0x7febfd60 0x03 # i2ctransfer -y 0 w1@0x50 1 r1 Wed Feb 15 18:23:06 2023 kern.debug kernel: [ 312.714856] i2c i2c-0: ioctl, cmd=0x705, arg=0x7feaf3e0 Wed Feb 15 18:23:06 2023 kern.debug kernel: [ 312.714903] i2c i2c-0: ioctl, cmd=0x703, arg=0x50 Wed Feb 15 18:23:06 2023 kern.debug kernel: [ 312.714928] i2c i2c-0: ioctl, cmd=0x707, arg=0x7feaf3e0 0x00 In particular, for the first read attempt, the value is always the first value sent as part of the last write. i.e, 3 in this case. After, that, it's always 0 (the correct answer ought to be 0xf). The original post is here: http://lists.openwrt.org/pipermail/openwrt-devel/2023-February/040509.html Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: m7621 i2c read failure
On 2/15/23 13:31, Peter Naulls wrote: I'm trying to track yet another vendor vs current OpenWrt driver mishandling. x00 In particular, for the first read attempt, the value is always the first value sent as part of the last write. i.e, 3 in this case. After, that, it's always 0 (the correct answer ought to be 0xf). (CCed Jan Breuer, as credited with the most recent changes) So I pulled out the old vendor-supplied driver and dropped it in the current kernel, where it compiled with no changes. It works for reads, after a fashion. It will read the correct value a few times, and then 0 after. The state can be "reset" by doing a write, and then it works again. Pursing getting the current driver working here seems most prudent - clearly the most recent changes were made for a reason, but I'm not sure what to do next. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
m7621 i2c read failure
I'm trying to track yet another vendor vs current OpenWrt driver mishandling. In my vendor kernel: [2.243263] i2c-mt7621 1e000900.i2c: clock 100KHz, re-start not support Which is this driver: * drivers/i2c/busses/i2c-mt7621.c * * Copyright (C) 2013 Steven Liu * Copyright (C) 2016 Michael Lee * * Improve driver for i2cdetect from i2c-tools to detect i2c devices on the bus. * (C) 2014 Sittisak This is kernel 4.14.131 Which of course works fine. In 5.10 and 5.15 current OpenWrt kernels: [2.917685] i2c-mt7621 1e000900.i2c: clock 100 kHz Writes work correctly. This for example sets LEDs via i2c (handled by the MCU and its GPIOs - I control this code too): # i2ctransfer -y 0 w1@0x50 0x43 w3 3 2 1 Wed Feb 15 18:23:01 2023 kern.debug kernel: [ 307.979880] i2c i2c-0: ioctl, cmd=0x705, arg=0x7fb736f0 Wed Feb 15 18:23:01 2023 kern.debug kernel: [ 307.979927] i2c i2c-0: ioctl, cmd=0x703, arg=0x50 Wed Feb 15 18:23:01 2023 kern.debug kernel: [ 307.979954] i2c i2c-0: ioctl, cmd=0x707, arg=0x7fb736f0 # i2ctransfer -y 0 w1@0x50 1 r1 Wed Feb 15 18:23:04 2023 kern.debug kernel: [ 310.921389] i2c i2c-0: ioctl, cmd=0x705, arg=0x7febfd60 Wed Feb 15 18:23:04 2023 kern.debug kernel: [ 310.921437] i2c i2c-0: ioctl, cmd=0x703, arg=0x50 Wed Feb 15 18:23:04 2023 kern.debug kernel: [ 310.921463] i2c i2c-0: ioctl, cmd=0x707, arg=0x7febfd60 0x03 # i2ctransfer -y 0 w1@0x50 1 r1 Wed Feb 15 18:23:06 2023 kern.debug kernel: [ 312.714856] i2c i2c-0: ioctl, cmd=0x705, arg=0x7feaf3e0 Wed Feb 15 18:23:06 2023 kern.debug kernel: [ 312.714903] i2c i2c-0: ioctl, cmd=0x703, arg=0x50 Wed Feb 15 18:23:06 2023 kern.debug kernel: [ 312.714928] i2c i2c-0: ioctl, cmd=0x707, arg=0x7feaf3e0 0x00 In particular, for the first read attempt, the value is always the first value sent as part of the last write. i.e, 3 in this case. After, that, it's always 0 (the correct answer ought to be 0xf). Clues where to look please? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: MT7621 NAND OOB misdetect
On 2/13/23 15:01, Peter Naulls wrote: ich might be the misreporting. In our driver, it comes out as: [ 16.091826] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128 [ 16.107083] mt7621-nand 1e003000.nand: ECC strength adjusted to 12 bits I tried adjusting in nand_onfi.c ecc_bits = 12 and spare_bytes_per_page to 112, to no avail. I set that back, and then in mt7621_nfc_calc_ecc_strength tried setting the strength to 1, with no obvious difference. I found this: https://forum.openwrt.org/t/fritz-repeater-3000-ubirmvol/119513/26?page=2 And the Fritz!Box 7520 V2 uses the exact same part. I haven't yet tried to track down any patches, etc for this. https://boxmatrix.info/wiki/FRITZ!Box_7520_v2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: MT7621 NAND OOB misdetect
On 2/11/23 08:10, Chuanhong Guo wrote: Hi! # nanddump -a /dev/mtd2 ECC failed: 8 ECC corrected: 0 Number of bad blocks: 0 Number of bbt blocks: 0 Block size 131072, page size 2048, OOB size 128 Dumping data starting at 0x and ending at 0x0004... libmtd: error!: MEMGETBADBLOCK ioctl failed for eraseblock 0 (mtd2) error 77 (Bad message) nanddump: error!: libmtd: mtd_is_bad I haven't been able to find anything on what this error means in practice. You could try printing the spare size and ecc strength used in the old driver, replacing the calculation in the new driver with hard-coded values and see if that works. If it works, you can implement the ecc strength override in our driver. Thanks. I'm not real familiar with this, so it's slow going. I'm sure the answer is simple. Here's some more info from u-boot: # MTK NAND # : Use HW ECC NAND ID [C2 F1 80 91 03] Device found in MTK table, ID: c2f1, EXT_ID: 809103 Support this Device in MTK table! c2f1 select_chip [NAND]select ecc bit:12, sparesize :112 spare_per_sector=28 Signature matched and data read! load_fact_bbt success 1023 load fact bbt success [mtk_nand] probe successfully! mtd->writesize=2048 mtd->oobsize=112, mtd->erasesize=131072 devinfo.iowidth=8 From the vendor mtk_nand2 driver: nand_chip->ecc.mode = hw->nand_ecc_mode;/* enable ECC */ nand_chip->ecc.strength = 1; [9.398860] [NAND]select ecc bit:12, sparesize :112 spare_per_sector=28 Also note: mtd->oobsize = devinfo.sparesize; Which might be the misreporting. In our driver, it comes out as: [ 16.091826] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128 [ 16.107083] mt7621-nand 1e003000.nand: ECC strength adjusted to 12 bits I tried adjusting in nand_onfi.c ecc_bits = 12 and spare_bytes_per_page to 112, to no avail. I set that back, and then in mt7621_nfc_calc_ecc_strength tried setting the strength to 1, with no obvious difference. What to try next, thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: MT7621 NAND OOB misdetect
On 2/10/23 22:41, Chuanhong Guo wrote: Hi! 16.163318] 8 fixed-partitions partitions found on MTD device mt7621-nand From the datasheet here: https://www.mxic.com.tw/Lists/Datasheet/Attachments/8858/MX30LF1G28AD,%203V,%201Gb,%20v1.3.pdf The MX30LF1G28AD actually have 2K+128 flash layout, so it's the old driver which is incorrectly detecting OOB size. Suffice to that accessing the device (nanddump) does not go well. Could you describe what exactly goes wrong? Thanks for your reply. Sorry, yes, I should have included that output. In particular, this fails: [ 28.070690] mt76x2e :02:00.0: reading EEPROM from mtd factory failed: -77 [ 28.717408] mt76x2e :02:00.0: Invalid MAC address, using random address 02:73:0b:95:75:d9 I have verified that the correct MAC address does in fact exist in flash at the same location as it did on the NOR under the legacy kernel. And then also at the end of boot (mtd6 is rootfs): [ 33.335299] blk_update_request: I/O error, dev mtdblock6, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 [ 33.359479] blk_update_request: I/O error, dev mtdblock6, sector 8 op 0x0:(READ) flags 0x80700 phys_seg 3 prio class 0 [ 33.383345] blk_update_request: I/O error, dev mtdblock6, sector 16 op 0x0:(READ) flags 0x80700 phys_seg 2 prio class 0 [ 33.407643] blk_update_request: I/O error, dev mtdblock6, sector 24 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [ 33.431898] blk_update_request: I/O error, dev mtdblock6, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 [ 33.452624] Buffer I/O error on dev mtdblock6, logical block 0, async page read [ 33.476059] blk_update_request: I/O error, dev mtdblock6, sector 36736 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [ 33.501107] blk_update_request: I/O error, dev mtdblock6, sector 36736 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 [ 33.522557] Buffer I/O error on dev mtdblock6, logical block 4592, async page read And then for example: # nanddump -a /dev/mtd2 ECC failed: 8 ECC corrected: 0 Number of bad blocks: 0 Number of bbt blocks: 0 Block size 131072, page size 2048, OOB size 128 Dumping data starting at 0x and ending at 0x0004... libmtd: error!: MEMGETBADBLOCK ioctl failed for eraseblock 0 (mtd2) error 77 (Bad message) nanddump: error!: libmtd: mtd_is_bad I haven't been able to find anything on what this error means in practice. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
MT7621 NAND OOB misdetect
This is the boot on the vendor legacy code - OpenWrt 18.06ish, with kernel 4.14.131, with probably a bunch of their customizations, but: [9.398860] [NAND]select ecc bit:12, sparesize :112 spare_per_sector=28 [9.412077] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1 [9.424719] nand: Macronix NAND 128MiB 3,3V 8-bit [9.434084] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 32 But under 5.10 on 22.03 (I also tried 5.15 with current development, but that has unrelated issues): [ 16.071380] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1 [ 16.084185] nand: Macronix MX30LF1G28AD [ 16.091826] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128 [ 16.107083] mt7621-nand 1e003000.nand: ECC strength adjusted to 12 bits [ 16.163318] 8 fixed-partitions partitions found on MTD device mt7621-nand Suffice to that accessing the device (nanddump) does not go well. I did look around the code, and in particular at the nand_onfi.c code, where the OOB is set based upon various metrics. I tried hard wiring here to 32, but this caused other problems with ECC determination. It turns out the legacy code actually uses a whole other driver: /** * mtk_nand2.c - MTK NAND Flash Device Driver * * Copyright 2009-2012 MediaTek Co.,Ltd. Suffice to say it does not build under current kernels, even with some attempts in this direction. What should I be looking at here - I can put some debug/queries under the legacy code if need be, but clearly the current code needs to be updated to support this. I haven't looked at the datasheet yet for this part, but probably I should do. Many thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Using prebuilt binaries in SDK builds
On 2/7/23 18:35, Eric Montellese wrote: Hello all, As I'm sure those on this list are aware, OpenWrt is used extensively in the commercial router world. That would be an understatement, we do for one. At NETGEAR, I am working to find a satisfactory solution to an annoying little corporate problem -- but I think the solution to that problem may be of value to the greater open-source community. The situation is this: When building a particular source package using the SDK, I need to rebuild any dependent packages from source as w Perhaps an easy solution is to have a clean target variant that also recursively cleans all the dependencies? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mt7621: Initial Atel platform support
I'm expecting this to need to be tidied up based upon feedback, but here's the
first try of support for the two mt7621 atel platforms I've been working on.
I have a number of smaller changes to go with this, but these are the top level
pieces to get started that I want to get right first.
Signed-off-by: Peter Naulls
diff --git a/target/linux/ramips/dts/mt7621_atel-ei.dts b/target/linux/ramips/dts/mt7621_atel-ei.dts
new file mode 100755
index 00..2dcbd7b932
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_atel-ei.dts
@@ -0,0 +1,177 @@
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include
+#include
+#include
+
+
+/ {
+ compatible = "atel,ei", "atel,aw12", "mediatek,mt7621-soc";
+ model = "ATEL-EI";
+
+ aliases {
+ led-boot = _status;
+ led-failsafe = _status;
+ led-running = _status;
+ led-upgrade = _status;
+ label-mac-device =
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,57600";
+ };
+
+ keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <20>;
+
+ reset {
+ label = "reset";
+ gpios = < 15 GPIO_ACTIVE_HIGH>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ led_status: green {
+ label = "green";
+ gpios = < 5 GPIO_ACTIVE_HIGH>;
+default-state = "off";
+ };
+ blue {
+ label = "blue";
+ gpios = < 6 GPIO_ACTIVE_HIGH>;
+default-state = "on";
+ };
+ red {
+ label = "red";
+gpios = < 7 GPIO_ACTIVE_HIGH>;
+default-state = "off";
+ };
+ };
+
+ gpio-export {
+ compatible = "gpio-export";
+ #size-cells = <0>;
+
+ mcu-reset {
+ gpio-export,name = "mcu-reset";
+ gpio-export,output = <0>;
+ gpios = < 0 GPIO_ACTIVE_HIGH>;
+ };
+
+ aw12-power {
+ gpio-export,name = "aw12-power";
+ gpio-export,output = <1>;
+ gpios = < 8 GPIO_ACTIVE_HIGH>;
+ };
+
+mcu-download {
+ gpio-export,name = "mcu-download";
+ gpio-export,output = <0>;
+ gpios = < 28 GPIO_ACTIVE_HIGH>;
+ };
+
+ mcu-watchdog {
+gpio-export,name = "mcu-watchdog";
+ gpio-export,output = <0>;
+ gpios = < 32 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ m25p80@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <1000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+label = "u-boot";
+reg = <0x0 0x3>;
+read-only;
+ };
+
+ partition@3 {
+label = "u-boot-env";
+reg = <0x3 0x1>;
+ };
+
+ factory: partition@4 {
+label = "factory";
+reg = <0x4 0x1>;
+read-only;
+ };
+
+ firmware: partition@5 {
+compatible = "openwrt,uimage", "denx,uimage";
+reg = <0x5 0x1fa>;
+label = "firmware";
+ };
+
+ manufacture: partition@0x1ff {
+reg = <0x1ff 0x1>;
+label = "manufacture";
+read-only;
+ };
+ };
+ };
+};
+
+
+ {
+ pinctrl-0 = <_pins>, <_pins>;
+};
+
+ {
+ nvmem-cells = <_factory_0028>;
+ nvmem-cell-names = "mac-address";
+};
+
+ {
+ ports {
+ port@0 {
+ status = "okay";
+ label = "lan1";
+ };
+ };
+};
+
+ {
+ compatible = "nvmem-cells";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ macaddr_factory_0028: macaddr@0028 {
+ reg = <0x0028 0x6>;
+ };
+};
+
+_default {
+ gpio {
+ groups = "wdt", "jtag", "rgmii2";
+ function = "gpio";
+ };
+};
+
+
+
+
diff --git a/target/linux/ramips/dts/mt7621_atel-fi.dts b/target/linux/ramips/dts/mt7621_atel-fi.dts
new file mode 100755
index 00..b49cb727ed
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_atel-fi.dts
@@ -0,0 +1,423 @@
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include
+#include
+#include
+
+
+/ {
+ compatible = "atel,fi", "mediatek,mt7621-soc";
+ model = "ATEL-FI";
+
+ aliases {
+ led-boot = _status;
+ led-failsafe = _status;
+ led-running = _status;
+ led-upgrade = _status;
+ label-mac-device =
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,57600";
+ };
+
+ keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <20>;
+
+ reset {
+ label = "reset";
+ gpios = < 15 GPIO_ACTIVE_HIGH>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_status: green {
+ label = "
elfutils build failure
This is elfutils-0.188 in master. No doubt I'm using a bad toolchain combo - I brought the config over from my 22.03 build: CONFIG_GCC_VERSION="11.3.0" CONFIG_BINUTILS_VERSION_2_38=y configure:3994: mipsel-openwrt-linux-musl-gcc -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts -msoft-float -mips16 -minterlink-mips16 -fmacro-prefix-map=/home/peter/awc/openwrt-master/build_dir/target-mipsel_24kc_musl/elfutils-0.188=elfutils-0.188 -Wformat -Werror=format-security -DPIC -fpic -fstack-protector-strong -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -D_GNU_SOURCE -Wno-unused-result -Wno-format-nonliteral -Wno-error=use-after-free -I/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/usr/include -I/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/include/fortify -I/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/include -L/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/usr/lib -L/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/lib -DPIC -fpic -specs=/home/peter/awc/openwrt-master/include/hardened-ld-pie.specs -znow -zrelroconftest.c >&5 cc1: error: '-Wno-error=use-after-free': no option '-Wuse-after-free' ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release Goals 23.x?
On 1/24/23 14:48, Nick wrote: Hey, We have testing-support for 5.15 in almost all targets, so we may be able to release it shortly [0]? WIP 6.1 support is already underway in OpenWrt [1]. We are using GCC 12 as our default compiler version[2]. Binutils has been updated to version 2.40. Could we fill out the Release Goals page [3]? It would be great to see a new release. I guess an actual release here is a few months off, and I don't know anything about the state of 23.x, but I have 2 mt7621 platforms that I should try and get included sooner rather than later, and probably a 3rd in a few months. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] odhcpd: Reduce error messages
When there's no network cable connected to LAN, then odhcpd does this: Tue Jan 24 18:32:04 2023 daemon.err odhcpd[2017]: Failed to send to ff02::1%lan@br-lan (Address not available) Tue Jan 24 18:32:20 2023 daemon.err odhcpd[2017]: Failed to send to ff02::1%lan@br-lan (Address not available) Tue Jan 24 18:32:36 2023 daemon.err odhcpd[2017]: Failed to send to ff02::1%lan@br-lan (Address not available) Tue Jan 24 18:32:52 2023 daemon.err odhcpd[2017]: Failed to send to ff02::1%lan@br-lan (Address not available) Accurate, but not very interesting. I think this would be better served as debug. Signed-off-by: Peter Naulls --- --- a/src/odhcpd.c 2023-01-24 13:29:56.080616097 -0500 +++ b/src/odhcpd.c 2023-01-24 13:30:19.284692423 -0500 @@ -207,7 +207,7 @@ ssize_t sent = sendmsg(socket, , MSG_DONTWAIT); if (sent < 0) - syslog(LOG_ERR, "Failed to send to %s%%%s@%s (%m)", + syslog(LOG_DEBUG, "Failed to send to %s%%%s@%s (%m)", ipbuf, iface->name, iface->ifname); else syslog(LOG_DEBUG, "Sent %zd bytes to %s%%%s@%s", ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
On 1/22/23 13:58, Daniel Santos wrote: [snip] Thanks Daniel and all the others (to many to mention). Yes, I should have read the datasheet much earlier, so in the end I really have only myself to blame. The fix was simply to add back in the "rgmii2" group back into the gpio group. I believe I previously removed this in order to try and figure out the handling of the ethernet switch in the newer kernel - another poorly documented and very confusing change that got made that took me a while to figure out (clue, swconfig is deprecated and no longer works on mt7621). As a very long time embedded developer, but only occasional kernel hacker, this stuff is hard to keep track of. I understand that OpenWrt is highly volunteer driven with limited resources, and to some extent we're subject to the vagaries of mainstream kernel hacking, but this clearly could have been better documented - again, I don't think that's anyone's fault, but it's still frustrating. I agree with the sentiment that OpenWrt could be more hacker friendly. I don't particularly need to dynamic pin grouping, but it might have been nice to know about in kernel reporting or libgpiod output, etc. I would kindly suggest that major subsystem changes in the future be updated in the wiki. Even if it's just a link to relevant kernel development. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
mt7621 GPIO mapping mystery
I posted previously on GPIOs, which caused some debate; this may or may not be relevant, but I'd be remiss to not mention it: http://lists.openwrt.org/pipermail/openwrt-devel/2022-October/039593.html I've been chasing an issue with GPIO mapping in for an mt7621 on the OpenWrt 5.10.161 etc kernels. In short, GPIOS up to at least 17 work, but 22 and beyond do not - 5-17 and 22-24 are LEDs, so their operation should be immediately obvious. The are all active high and are all wired as you'd expect. This all works as expected on a previous 4.14 kernel. To say that there have been significant changes in drivers, GPIO handling and device tree since that kernel would be an understatement. I have tried exporting the GPIOS as LEDs, named GPIOs, direct manipulation in /sys/class/gpio and libgpiod, but something is amiss. The actual value of the GPIO as seen in software can manipulated in all cases, but the physical value does not change. Suspiciously, MDIO/MDC are at GPIOs 20 and 21, so I don't know if these are upsetting the physical mapping. I've also turned off as much as possible in the device tree, and built the kernel without switch and ethernet drivers, etc. I'm tearing my hair out here, so any clues at all would be appreciated. Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Secure cookie handling upon https to http downgrade
On 12/30/22 15:42, Jo-Philipp Wich wrote: Hi, [...] I renamed the new cookies to "http-sysauth" and "https-sysauth", to work around this and it seems to do the right thing. But there is still a fault here. Already fixed with https://github.com/jow-/lucihttp/commit/6e68a1065f3ed1889e5fa053b206bd3aa108bd5f Right, thanks Jow, and everyone involved in OpenWrt. For some reason this was an update that I had missed in my setup. More generally, and regard to the earlier suggestion, I would still suggest splitting the http vs https cookie names in any ongoing luci rework in order to avoid this situation. I know that HTTPS on a local system is security theater, but it's where we find ourselves. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Secure cookie handling upon https to http downgrade
On 12/22/22 15:56, Peter Naulls wrote:
On 12/22/22 13:50, Oscar Hjelm wrote:
I’m not familiar with the luci interface, but to help you get started:
- One workaround would be to use a different cookie name on the new secure
cookies (or a new name on the older cookies, if that is preferred). The two
cookies could co-exist.
Yes, thank you. I was able to rename the cookie to "sysauth-http" in the old
code. This requires fixups in in 8 or so places to work properly, but seems to
do the right thing.
To follow up on this, it didn't work properly. It looks to me that when there's
multiple cookies set for a site, the http.getcookie, which uses:
return lhttp.header_attribute("cookie; " .. (self:getenv("HTTP_COOKIE") or
""), name)
Will sometimes return the wrong cookie. I didn't dig into the exact problem
further, but it would return the original "sysauth" cookie not the new "sysauth-
https". Perhaps due to alphabetical sorting, or a prefix match or something.
I renamed the new cookies to "http-sysauth" and "https-sysauth", to work around
this and it seems to do the right thing. But there is still a fault here.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ui.waitReconnect() may load over HTTP instead of HTTPS
I see this warning in Firefox (OpenWrt 22.03):
Loading mixed (insecure) display content
“http://192.168.113.1/luci-static/resources/icons/loading.gif?0.046104145623280135”
on a secure page
This happens when the sysupgrade dialog is processing on an https luci. It
doesn't cause any real harm, but it would be good to fix.
The problem is that pingDevice falls back to http only when no protocol
is specified:
pingDevice: function(proto, ipaddr) {
var target = '%s://%s%s?%s'.format(proto || 'http', ipaddr ||
window.location.host, L.resource('icons/loading.gif'), Math.random());
For some of the calls to ui.awaitReconnect, window.location.protocol could be
prefixed, but I think pingDevice is the correct place for a fix.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Secure cookie handling upon https to http downgrade
On 12/22/22 13:50, Oscar Hjelm wrote: I’m not familiar with the luci interface, but to help you get started: - One workaround would be to use a different cookie name on the new secure cookies (or a new name on the older cookies, if that is preferred). The two cookies could co-exist. Yes, thank you. I was able to rename the cookie to "sysauth-http" in the old code. This requires fixups in in 8 or so places to work properly, but seems to do the right thing. Setting the Secure flag is considered best-practice. However, if the end user deployment relies on self-signed certificates, then the security offered is low. A user is unfortunately likely to approve a certificate error and proceed anyway, leaking the session token to a potential attacker. There's no question that a lot of the security measures I'm taking are theater (see my previous posts), but the hoops have to be jumped through. And I think they'll help out others in the future. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Secure cookie handling upon https to http downgrade
Some background. I have two versions of OpenWrt code:
One is legacy version based upon a mismash of versions, but is approximately
luci code from mid-2021. The webserver is http only. I'm able to change this
code for bug fixes, but don't want to pull in anything too large.
The other is based upon very current 22.03 code, and https is set.
The problem is that for some purposes, we may need to downgrade. If the login
is done on the https setup, then the sysauth cookie is set, with the "secure"
flag set on the cookie. All fine.
However, if we go back to the older code, then it's not possible to login in
luci. I've been through dispatcher.lua and what I think is happening is that
the cookie isn't being updated:
http.header("Set-Cookie", 'sysauth=%s; path=%s; SameSite=Strict; HttpOnly%s' %{
sid, build_url(), http.getenv("HTTPS") == "on" and ";
secure" or ""
})
Now that would be justified, since you wouldn't want a website to update a
cookie from an HTTP page with one already set from an HTTPS page. So what
happens is that the authentication "works" but there is another check in
dispatcher.lua for the session ID vs cookie, and this fails, and so no login
can be made until the cookie is cleared from the browser (or the cookie
is manually modified in the browser to be not secure). Or in practice,
flushing the cache for the page.
I know also there have been significant changes in the dispatcher code between
the legacy OpenWrt code I'm using and the 22.03 code, but it's not clear that
this has been addressed.
Looking for suggestions on work arounds - maintaining the integrity of the
security of my latest code is important, but if I have to weaken things in the
legacy code, that's probably OK.
Thanks!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RFC - Encrypted overlay and help with boot ordering
I've been experimenting with making the overlay encrypted as part of our
security requirements.
There are a couple of things needed to make this work - first, cryptsetup and
other kernel modules need to be brought in. This also needs the upstream kernel
patch to block2mtd that I posted last week that allows for a custom label.
Finally, in the OpenWrt kernel patch to the partition split logic, I renamed
"rootfs_data" to "rootfs_image.
Then I added the following file as /lib/preinit/80_mount_prepare. Note that this
is carefully named so it appears after 80_lvm2 and before 80_mount_root.
Running the steps manually after boot (I shut down as much as possible), the
process is OK, but during boot, things are not quite right:
[ 21.397406] mount_root: Could not open mtd device: /dev/mtd8
[ 21.408913] mount_root: reading rootfs_data failed
[ 21.420865] mount_root: Could not open mtd device: /dev/mtd5
[ 21.432353] mount_root: reading rootfs failed
[ 21.441237] mount_root: mounting /dev/root
It appears that the device nodes are not ready at this point. In my setup, mtd5
is the old "rootfs_image" and mtd8 is the mtd created by block2mtd.
In any case, feedback on this whole setup and what's going on here welcome.
This is obviously very experimental in nature.
do_prepare_rootfs() {
echo " Preparing rootfs"
encrypt_name=rootfs_image
data_name=rootfs_data
mtd=$(cat /proc/mtd | grep ${encrypt_name} | cut -d : -f 1)
if [ -z "${mtd}" ] ; then
echo "${encrypt_name} not found" 1>&2
exit 1
fi
block=$(echo $mtd | sed s#mtd#mtdblock#)
pass=test
echo "Trying to open partition /dev/{$block} as is"
if ! echo -n "${pass}" | cryptsetup luksOpen /dev/${block} rootfs
2>/dev/null; then
echo "Formatting parititon /dev/${block}"
echo -n "${pass}" | cryptsetup -q luksFormat /dev/${block}
echo "Complete, opening again"
echo -n "${pass}" | cryptsetup luksOpen /dev/${block} rootfs
fi
insmod block2mtd block2mtd=/dev/mapper/rootfs,32KiB,${data_name}
data=$(cat /proc/mtd | grep ${data_name} | cut -d : -f 1)
if [ -z "${data}" ] ; then
echo "${data_name} not found"
exit 1
fi
# Now rely upon mount_root to check partition and setup for jffs2
}
[ "$INITRAMFS" = "1" ] || boot_hook_add preinit_main do_prepare_rootfs
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] px5g-mbedtls error check
In 22.03, px5-mbedtls isn't bothering to check if the output was opened:
--- a/package/utils/px5g-mbedtls/px5g-mbedtls.c
+++ b/package/utils/px5g-mbedtls/px5g-mbedtls.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -70,6 +71,11 @@ static void write_file(const char *path, int len, bool pem)
if (path)
f = fopen(path, "w");
+if (!f) {
+ fprintf(stderr, "Failed to open output '%s': %s\n", path,
strerror(errno));
+ exit(1);
+}
+
fwrite(buf_start, 1, len, f);
fclose(f);
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] linux: add in labels for block2mtd
On 11/29/22 12:37, Daniel Golle wrote: I thought you are on a device with actual block storage. For your case I also can't come up with anything better which works out-of-the-box for NOR flash. Supporting fscrypt in JFFS2 would be more elegant, but that's a bit more demanding than just using what is already there and works... Well, my big concern here is performance on a small device. I haven't done much testing yet, but some operations seem quite slow; I won't really know until I get it all going. The format of the ~17MB roofs_data takes 3-4 minutes, but that's a one-time operation after sysupgrade. In my colleague's case, he used AES and was able to make use of the hardware acceleration. I imagine that fscrypt in JFFS2 would avoid a lot of overhead too. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] linux: add in labels for block2mtd
On 11/29/22 11:50, Daniel Golle wrote: There is nothing wrong with that use-case, and it can even be interesting for other downstream users. Encrypted rootfs_data is generally a good idea, especially when rootfs_data is used to store private key material (think: VPN keys) or other kind of credentials. I was more wondering why you are using JFFS2 on a block device, instead of e.g. using F2FS or EXT4 which are intended for block devices. Our flash is NOR. We will probably move to NAND in the next iteration of hardware, but this is what we have for now. I'm open to other ways to make it work, but this is the arrangement that I was able to make work in my research and testing, and that a colleague used successfully on a non-OpenWrt system. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] linux: add in labels for block2mtd
On 11/29/22 10:32, Daniel Golle wrote: On Tue, Nov 29, 2022 at 10:23:48AM -0500, Peter Naulls wrote: This backports the upstream label feature in block2mtd to the 5.10.x kernel in 22.03: https://github.com/torvalds/linux/blob/master/drivers/mtd/devices/block2mtd.c Where are we using block2mtd and why? I should have added more context. I don't think there's really a "we" here, this is something I needed, and it's more for discussion than anything. I don't think it has a general use in OpenWrt at present, and given the release status of 22.03 you could even argue it shouldn't go in. My application is for encrypting the rootfs_data partition to meet security audit requirements (rootfs too, but that's a different step). I know there hasn't been much appetite for this in the past, and I'm painfully aware of the OSS nature here vs encryption, but here we are. This is a requirement for our product, whether I get pushback or not. In any case, block2mtd allows me to present devices from cryptsetup to jffs2. I'm working on some additional patches to make this all work with 'mount_root' and sysupgrade, so we'll see - it will be experimental in nature for sure, and may not ultimately be the best way to do things. That's OK. As for the patch, it'll come to OpenWrt eventually, but my preference is to stick with some sense of stability with 22.03. Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] linux: add in labels for block2mtd
This backports the upstream label feature in block2mtd to the 5.10.x kernel in
22.03:
https://github.com/torvalds/linux/blob/master/drivers/mtd/devices/block2mtd.c
--- a/drivers/mtd/devices/block2mtd.c 2022-11-29 07:35:32.382695321 -0500
+++ b/drivers/mtd/devices/block2mtd.c 2022-11-29 08:04:27.406754981 -0500
@@ -31,6 +31,9 @@
#include
#include
+/* Maximum number of comma-separated items in the 'block2mtd=' parameter */
+#define BLOCK2MTD_PARAM_MAX_COUNT 3
+
/* Info for the block device */
struct block2mtd_dev {
struct list_head list;
@@ -214,7 +217,7 @@
static struct block2mtd_dev *add_device(char *devname, int erase_size,
- int timeout)
+ char *label, int timeout)
{
#ifndef MODULE
int i;
@@ -278,7 +281,10 @@
/* Setup the MTD structure */
/* make the name contain the block device in */
- name = kasprintf(GFP_KERNEL, "block2mtd: %s", devname);
+ if (!label)
+ name = kasprintf(GFP_KERNEL, "block2mtd: %s", devname);
+ else
+ name = kstrdup(label, GFP_KERNEL);
if (!name)
goto err_destroy_mutex;
@@ -305,7 +311,7 @@
list_add(>list, _device_list);
pr_info("mtd%d: [%s] erase_size = %dKiB [%d]\n",
dev->mtd.index,
- dev->mtd.name + strlen("block2mtd: "),
+ label ? label : dev->mtd.name + strlen("block2mtd: "),
dev->mtd.erasesize >> 10, dev->mtd.erasesize);
return dev;
@@ -381,8 +387,9 @@
/* 80 for device, 12 for erase size, 80 for name, 8 for timeout */
char buf[80 + 12 + 80 + 8];
char *str = buf;
- char *token[2];
+ char *token[BLOCK2MTD_PARAM_MAX_COUNT];
char *name;
+ char *label = NULL;
size_t erase_size = PAGE_SIZE;
unsigned long timeout = MTD_DEFAULT_TIMEOUT;
int i, ret;
@@ -395,7 +402,7 @@
strcpy(str, val);
kill_final_newline(str);
- for (i = 0; i < 2; i++)
+ for (i = 0; i < BLOCK2MTD_PARAM_MAX_COUNT; i++)
token[i] = strsep(, ",");
if (str) {
@@ -414,7 +421,8 @@
return 0;
}
- if (token[1]) {
+ /* Optional argument when custom label is used */
+ if (token[1] && strlen(token[1])) {
ret = parse_num(_size, token[1]);
if (ret) {
pr_err("illegal erase size\n");
@@ -422,7 +430,12 @@
}
}
- add_device(name, erase_size, timeout);
+ if (token[2]) {
+ label = token[2];
+ pr_info("Using custom MTD label '%s' for dev %s\n", label, name);
+ }
+
+ add_device(name, erase_size, label, timeout);
return 0;
}
@@ -448,7 +461,7 @@
the device (even kmalloc() fails). Deter that work to
block2mtd_setup2(). */
- strlcpy(block2mtd_paramline, val, sizeof(block2mtd_paramline));
+ strscpy(block2mtd_paramline, val, sizeof(block2mtd_paramline));
return 0;
#endif
@@ -456,7 +469,7 @@
module_param_call(block2mtd, block2mtd_setup, NULL, NULL, 0200);
-MODULE_PARM_DESC(block2mtd, "Device to use. \"block2mtd=[,]\"");
+MODULE_PARM_DESC(block2mtd, "Device to use. \"block2mtd=[,[][,]]\"");
static int __init block2mtd_init(void)
{
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
mt7621 - validate mt7603/mt762e calibration
Our vendor has put calibration data into flash for the onboard WiFi. They've made some changes which I have to their supplied 4.14.131 driver to read from the "factory" flash partition to read calibration data. As per my previous post on u-boot, getting exact details out of them has proved tricky due to language challenges and whatnot. This is kernel 5.10.154. The driver code here in question is substantially different. [ 22.298838] pci :00:00.0: enabling device (0004 -> 0007) [ 22.310143] mt7603e :01:00.0: enabling device ( -> 0002) [ 22.322339] mt7603e :01:00.0: ASIC revision: 76030010 [ 23.511774] mt7603e :01:00.0: Firmware Version: ap_pcie [ 23.522944] mt7603e :01:00.0: Build Time: 20160107100755 [ 23.570908] mt7603e :01:00.0: firmware init done [ 23.770019] mt7621-pci 1e14.pcie: bus=2 slot=1 irq=24 [ 23.780950] pci :00:01.0: enabling device (0004 -> 0007) [ 23.792240] mt76x2e :02:00.0: enabling device ( -> 0002) [ 23.804437] mt76x2e :02:00.0: ASIC revision: 76120044 [ 24.471734] mt76x2e :02:00.0: ROM patch build: 20141115060606a [ 24.488470] mt76x2e :02:00.0: Firmware Version: 0.0.00 [ 24.499444] mt76x2e :02:00.0: Build: 1 [ 24.507607] mt76x2e :02:00.0: Build Time: 201607111443 [ 24.540896] mt76x2e :02:00.0: Firmware running! On modern kernels, the location of the data is determined by the DTB of course, and this all appears to be in order, and having looked in some detail at the code, everything seems to be there for calibration to happen with no additional effort, but I don't see any debug one way or another. My question is, how to verify the calibration data has been correctly set, both on the driver level and in practical testing? I'm not an RF engineer, so by all means educate me here. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Add swig/host build dependency [Was: Re: [PATCH] uboot-mediatek: clean up build dependencies]
On 11/17/22 14:33, Petr Štetiar wrote: Daniel Golle [2022-11-17 17:01:43]: Hi, Add swig/host to build dependencies. this doesn't looks like a cleanup as commit subject suggests, but rather contrary :-) Thanks all in any case for looking at this. We have a possible need to modify our vendor (or vendor's vendor, hard to be sure) U-Boot. On our MT7621 boards we have vendor versions 2.0.0 aka Ralink version 2.0.0 and 1.1.3 aka Ralink version 4.3.0.0. And I have the Mediatek SDK with source for what claims to be version 5.0.0.0. Attempts to clarify with the vendor what's going on or get exact sources or history have proven challenging due to timezones and language barriers, and I think they simply may not know. Obviously using the OpenWrt version is going to be probably more satisfactory, although there may well be vendor changes to support MCU etc. It's been many many years since I did u-boot work, but is there some magic to load u-boot image into RAM on mt7621 and run it to try it out before flashing? I know there are configuration options for DDR and CPU frequency, etc, but tftping the u-boot binaries variously and using 'go' result in an apparently stopped system. This is the only meaningful documentation I have found. https://u-boot.readthedocs.io/en/latest/board/mediatek/mt7621.html Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
uboot-mediatek maybe needs swig
I needed to add this in my build: diff --git a/package/boot/uboot-mediatek/Makefile b/package/boot/uboot-mediatek/Makefile index 9d823ec698..ac8e5dd0f3 100644 --- a/package/boot/uboot-mediatek/Makefile +++ b/package/boot/uboot-mediatek/Makefile @@ -3,7 +3,7 @@ include $(INCLUDE_DIR)/kernel.mk PKG_VERSION:=2022.10 PKG_HASH:=50b4482a505bc281ba8470c399a3c26e145e29b23500bc35c50debd7fa46bdf8 -PKG_BUILD_DEPENDS:=arm-trusted-firmware-tools/host +PKG_BUILD_DEPENDS:=arm-trusted-firmware-tools/host swig/host include $(INCLUDE_DIR)/u-boot.mk include $(INCLUDE_DIR)/package.mk I do see that some of the other versions of u-boot have patches to avoid using it, (e.g, rockchip), so I don't know if it's really needed. Also, I'm building for mt7621 only (ramips), and this build brings in a lot of ARM stuff too; perhaps the dependencies need to be split up some. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 22.03 expat - CVE-2022-43680/CVE-2022-40674
The 2.4.9 version of expat in OpenWrt 22.03 contains the following CVEs: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-43680 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-40674 Suggest either update to 2.5.0 (as per master) or application of the upstream patches, etc: https://github.com/libexpat/libexpat/pull/616 https://github.com/libexpat/libexpat/pull/650 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] px5g-mbedtls (Was: px5g return value checking)
On 11/3/22 14:49, Peter Naulls wrote:
Another one from our security scan:
File: /usr/sbin/px5g
Issue: RET NOT ASSIGNED in function 'FUN_000281b0' at address 0x281c0 while
calling 'mbedtls_rsa_check_pub_priv'
Issue: RET NOT ASSIGNED in function 'FUN_000285e8' at address 0x285f8 while
calling 'mbedtls_ecp_check_pub_priv'
The problem is in fact with px5g-mbedtls util, not the library:
--- a/px5g-mbedtls.c
+++ b/px5g-mbedtls.c
@@ -113,13 +113,13 @@ static void gen_key(mbedtls_pk_context *key, bool rsa, int
ksize, int exp,
mbedtls_pk_init(key);
if (rsa) {
fprintf(stderr, "Generating RSA private key, %i bit long
modulus\n", ksize);
- mbedtls_pk_setup(key,
mbedtls_pk_info_from_type(MBEDTLS_PK_RSA));
- if (!mbedtls_rsa_gen_key(mbedtls_pk_rsa(*key), _urandom, NULL,
ksize, exp))
+ if (!mbedtls_pk_setup(key,
mbedtls_pk_info_from_type(MBEDTLS_PK_RSA)) &&
+ !mbedtls_rsa_gen_key(mbedtls_pk_rsa(*key), _urandom,
NULL, ksize, exp))
return;
} else {
fprintf(stderr, "Generating EC private key\n");
- mbedtls_pk_setup(key,
mbedtls_pk_info_from_type(MBEDTLS_PK_ECKEY));
- if (!mbedtls_ecp_gen_key(curve, mbedtls_pk_ec(*key), _urandom,
NULL))
+ if (!mbedtls_pk_setup(key,
mbedtls_pk_info_from_type(MBEDTLS_PK_ECKEY)) &&
+ !mbedtls_ecp_gen_key(curve, mbedtls_pk_ec(*key),
_urandom, NULL))
return;
}
fprintf(stderr, "error: key generation failed\n");
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] libtasn1: CVE-2021-46848
On 11/3/22 12:01, Etienne Champetier wrote: Hi Peter, Can you resend this as a proper patch ready to be applied ? Or as a PR on Github if this is easier for you ? Sorry, retry. I wasn't 100% sure of the filename setup for submitted patches. I've got a couple more to come. As per: https://nvd.nist.gov/vuln/detail/CVE-2021-46848 --- a/lib/int.h 2022-11-03 10:15:01.065656767 -0400 +++ b/lib/int.h 2022-11-03 10:15:39.333658083 -0400 @@ -97,7 +97,7 @@ #define ETYPE_TAG(etype) (_asn1_tags[etype].tag) #define ETYPE_CLASS(etype) (_asn1_tags[etype].class) #define ETYPE_OK(etype) (((etype) != ASN1_ETYPE_INVALID && \ - (etype) <= _asn1_tags_size && \ + (etype) < _asn1_tags_size && \ _asn1_tags[(etype)].desc != NULL)?1:0) #define ETYPE_IS_STRING(etype) ((etype == ASN1_ETYPE_GENERALSTRING || \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
px5g return value checking
Another one from our security scan: File: /usr/sbin/px5g Issue: RET NOT ASSIGNED in function 'FUN_000281b0' at address 0x281c0 while calling 'mbedtls_rsa_check_pub_priv' Issue: RET NOT ASSIGNED in function 'FUN_000285e8' at address 0x285f8 while calling 'mbedtls_ecp_check_pub_priv' I'm not familiar with this code, and looking I can't see anything obvious. I do note that the function "rsa_check_pair_wrap" is used as a function pointer, which might be upsetting scans. This is mbedtls-2.28.1. Can someone verify this or see if it's a false positive? Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
CVE-2020-15888 - libtasn1
https://nvd.nist.gov/vuln/detail/CVE-2021-46848 Against openwrt-22.03 --- /dev/null +++ b/libs/libtasn1/patches/099-CVE-2020-15888.patch @@ -0,0 +1,11 @@ +--- a/lib/int.h2022-11-03 10:15:01.065656767 -0400 b/lib/int.h2022-11-03 10:15:39.333658083 -0400 +@@ -97,7 +97,7 @@ + #define ETYPE_TAG(etype) (_asn1_tags[etype].tag) + #define ETYPE_CLASS(etype) (_asn1_tags[etype].class) + #define ETYPE_OK(etype) (((etype) != ASN1_ETYPE_INVALID && \ +- (etype) <= _asn1_tags_size && \ ++ (etype) < _asn1_tags_size && \ + _asn1_tags[(etype)].desc != NULL)?1:0) + + #define ETYPE_IS_STRING(etype) ((etype == ASN1_ETYPE_GENERALSTRING || \ Regards. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 18:20, openwrt-devel-requ...@lists.openwrt.org wrote: From: Nathan Lutchansky My hands are tied, we gotta do the dance. I mean this as gently as possible, but I think what a lot of us are missing is the benefit to the OpenWrt project to carry an increased maintenance burden in response to your internal requirements, which you openly state add no value. Maybe your time is better spent fixing your organization's processes, rather than trying to make volunteers responsive to what we all agree are pointless requirements?? -Nathan Apologies, due to volume, I had put this list on digest and am missing some of the responses not CCed to me and am going to be breaking the threading here. Thanks to everyone for taking the time. My company is small, there's little disagreement on what I've mentioned to date about these issues internally. These audits are done by much (much) larger partner companies - e.g, MS/Intel that I mentioned recently, so there's no chance there to change process. The best response in many cases is well reasoned arguments, but sometimes not. I'm not asking anyone here to do anything; but if my comments serve as useful reference in future to someone who is going through the same process, then I'll consider it time well spent. And if the commentary turns into practical measures, then I'll contribute back what I can. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: lua 5.1.5 CVEs / lua 5.3 with luci
On 10/25/22 20:45, Reuben Dowle wrote: My opinion is that openwrt should try and move to a newer version of lua. This old 5.1.5 version appears to be unmaintained, and there does not seem to be the resources within the openwrt community to change that. So I naively adjusted the lua5.3 package to add PROVIDES for lua and liblua and symlinked the /usr/bin/lua5.3 binary to /usr/bin/lua. In some very superficial testing, skimming through pages, luci almost works correctly. What I do see on all pages, is this: RPCError: RPC call to luci/getFeatures failed with error -32000: Object not found at handleCallReply (http://192.168.113.1/luci-static/resources/rpc.js?v=unknown:82:7) at promise callback*parseCallReply (http://192.168.113.1/luci-static/resources/rpc.js?v=unknown:66:5) at promise callback*call (http://192.168.113.1/luci-static/resources/rpc.js?v=unknown:41:6) at declare/(http://192.168.113.1/luci-static/resources/rpc.js?v=unknown:342:9) at declare/< (http://192.168.113.1/luci-static/resources/rpc.js?v=unknown:302:11) at probeSystemFeatures (http://192.168.113.1/luci-static/resources/luci.js?v=unknown:2588:7) at setupDOM (http://192.168.113.1/luci-static/resources/luci.js?v=unknown:2737:10) at promise callback*__init__ (http://192.168.113.1/luci-static/resources/luci.js?v=unknown:2254:7) at ClassConstructor (http://192.168.113.1/luci-static/resources/luci.js?v=unknown:104:20) Just bear in mind that although this is 22.03, I have some heavyish changes to customize luci too. I don't know this particular code, but I can't imagine it being hard to fix. There's some additional similar errors on other pages. Switch config: RPCError: RPC call to luci/getSwconfigFeatures failed with error -32000: Object not found Firewall: RPCError: RPC call to luci/getConntrackHelpers failed with error -32000: Object not found The system log tabs also report: "Unable to load log data: Not Found". Wireguard: RPC call to luci.wireguard/getWgInstances failed with error -32000: Object not found Suggested fixes? In any case, this seems like it would be a major internal change in OpenWrt. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
lua 5.1.5 CVEs
Lua 5.1.5 would appear to have CVEs below against it. The patches to this in OpenWrt are significant, but dated, with the last bug fix seeming to be from 2019, so it's hard to say if these are addressed: https://github.com/openwrt/openwrt/tree/openwrt-22.03/package/utils/lua/patches https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15888 https://github.com/lua/lua/commit/6298903e35217ab69c279056f925fb72900ce0b7 https://github.com/lua/lua/commit/eb41999461b6f428186c55abd95f4ce1a76217d5 I can't see that these have been applied - correct me here please. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43519 This appears to be the fix: https://github.com/lua/lua/commit/6298903e35217ab69c279056f925fb72900ce0b7 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15945 Fix here: https://github.com/lua/lua/commit/a2195644d89812e5b157ce7bac35543e06db05e3 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5461 This is ancient, and may have long since been fixed, although I can't find the exact patch. This would be a good example where if the CVE patches had been applied, naming them well would help. The "better" fix would arguably to move to lua 5.3 or even 5.4, but as I mentioned in an earlier post, I'm not sure if this is possible or what it might break in luci. Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 17:45, Michael Richardson wrote: So, it needs to bound to *all* the IPv6 "LAN" IPs. That means: a) the ULA that is created. b) the LL-IPv6 that are always present c) the GUA IPv6 that is delegated Sorry, I badly paraphrased. The requested change was for IPv4 only. I don't anticipate any IPv6 changes here. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 17:25, Reuben Dowle wrote: I have myself gone through the process of getting an openwrt based product through a security audit. The issue of HTTP listening on all interfaces also came up in my audit, but the auditors were happy with the explanation that the firewall prevented any access through the WAN interface. If the people auditing your system are only interested in security 'theatre', then that is really a poor quality/incompetent audit process. Well, I agree. For clarity, years ago I had been through reviews with both Microsoft and Intel, with some combination of Ubuntu/OpenWrt, so had some expectation here. Those reviews turned up their share of nonsense, but things have changed I guess. My hands are tied, we gotta do the dance. That said, I think that limiting the listening ports of uhttpd is a good idea. I hardly see any downside to it, apart from maybe adding some complexity. I think adding complexity here is a pretty good argument against this. Certainly. But failing an official fix, I'm left to a workaround of my own devising, which is unlikely to be robust in the short term, but will have to do - unless someone has other suggestions. To be clear to everyone here - I appreciate the feedback, and likely agree with everything that's been said - I've been doing this as long as you guys, so I know the ins and outs, but I think the conversation is still worth having. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 16:40, Karl Palsson wrote: Peter Naulls wrote: If they see what they want to see, then why should anyone else get involved in their wish fulfilment? Security review is fine, security should not be entertained, and certainly foisted on other people? Karl, not sure where you're going with this. You haven't named anything practical here, apart from suggesting ignoring it. OpenWrt is widely used nowadays, probably more than most people expect, security reviews like this are likely to become more common. I think everyone bothering to read this understands the theatre aspects of all this that I called out in my original post. Whether things should actually be fixed (or "fixed") is certainly an open question, but if I can save someone some future grief, or at least have the discussion, then I might save myself or someone else some time. That said, I think that limiting the listening ports of uhttpd is a good idea. I hardly see any downside to it, apart from maybe adding some complexity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 14:53, Luiz Angelo Daros de Luca wrote: is much easier to let the firewall zones deal with that. As aside, they don't see the iptables tool in the system, and don't understand that that's been deprecated (although I since did add it for some unrelated legacy usage), and think there's no firewall at all. 22.03? Did you read the release notes? nftables. Luiz, I think you might have missed the context of my post - perhaps you missed my earlier ones. I'm well aware that nftables is in use, but this is in a security review, and they see what they want to see. It would be better to improve the uhttpd startup script, allowing it to bind to a list of openwrt interfaces. It is always better to reference an existing config than to duplicate it. Or leave the original bind address. I agree that's a better solution. I don't think I've advocated duplicating config though. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Security changes - restricting uhttpd addresses
The default uhttpd configuration has this: # HTTP listen addresses, multiple allowed list listen_http0.0.0.0:80 list listen_http[::]:80 Now, I know there's lots of practical reasons for this to be the case, and I know also that the firewall setup in OpenWrt is robust and isn't going to allow WAN-side access. Nevertheless, the security people are looking at this config statically, and not seeing that it's bound to the LAN interface IP only. As aside, they don't see the iptables tool in the system, and don't understand that that's been deprecated (although I since did add it for some unrelated legacy usage), and think there's no firewall at all. For my use, I've changed the default binding to the LAN IP, and also added another init.d script to check the current LAN address, and update the uhttpd config if need be and then restart it (and add a config hook to the network config). Obviously this isn't very satisfactory, open to better suggestions here. It might also be better if uhttpd could be configured to bind to a specific interface rather than knowing its IP upfront, but that might be impractical. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CVEs in OpenWrt 22.03
On 10/24/22 18:21, Hauke Mehrtens wrote: Hauke, thanks for replying! I also prefer if the CVE number is named in the patch. If this is missing somewhere you could send a patch or pull request to rename the patch. I'm afraid I don't have any explicit examples, but I'll let you know if find any. There are some concerns with the older lua I mentioned below, but I'll need to come back to those. In any case, a suggestion for future CVE patches. The OpenWrt project does not have enough resources to maintain security patches for the kernel on our own. OpenWrt relays on the LTS kernel maintenance and we update to the most recent LTS version every few days or weeks in the maintained branches. If some security patches are missing in the LTS kernel versions used by OpenWrt it is probably best to approach the Linux stable team directly. See this blog post from Greg Kroah-Hartman, especially the "Keeping a secure system" section: http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/ Yes, sure. And whether you or I agree with this or not is to some degree irrelevant, since what matters to the security people is that they see the bug fixed. In 90% of the cases I was able to dismiss CVEs since the subsystems in question are not in use by us (or most of OpenWrt for that matter. e.g, frame buffers), but some tricky ones remain. That said, there's a very large number of patches to the kernel in OpenWrt; mostly for new device function, pending fixes or whatnot; I guess few of these are actual security fixes. So, to user space: dnsmasq 2.86 - my pointing out that CVE-2021-45957 et al are false didn't go over particularly well, even though they have been properly dismissed by the Simon Kelley and others. See my mail on the dnsmasq mailing list: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q1/016161.html Yes, and was referred to and well understood by myself at least. Still, the objection is that Mitre have this as "disputed", which is rather unhelpful, and that is what is being focused upon. Obviously I cannot fix something that isn't broken and has no fix, so there's no satisfactory answer here to a security review beyond getting the CVEs dismissed from Mitre. tcpdump 4.9.3 - CVE-2018-16303 This CVE is not for tcpdump, but PDF-XChange Editor: https://nvd.nist.gov/vuln/detail/CVE-2018-16303 Sorry, trying to juggle lots of items here. https://nvd.nist.gov/vuln/detail/CVE-2018-16301 Long since in OpenWrt patches. e2fsprogs 1.46.5 - CVE-2022-1304 This is pretty hard to attack. You could provide a patch. This was the patch I provided here: I brought in this patch: diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c index b324c7b0..1a206a16 100644 Yes, very large files on OpenWrt are unlikely without external media. If would be simply easier on the optics if I was able to ditch 5.1.5 in the build and just use 5.3 - is this possible; I'm sure there's been much discussion on this before, so please point me at that - will it break luci? An update to Lua 5.4 would be good, but I do not know which impact it has. Understood. I'm going to come back to this later in another post. There's much more, but that's quite enough for now. OpenWrt is a mostly volunteer run project. Especially (security) maintenance does not get paid by companies. If you have some fixes tested patches would be really helpful. Yes, I know, and to say my reliance upon OpenWrt over the years is considerable would be an understatement, but my time is limited as well, and my focus must be on addressing specifics to the security review. Still, I felt it better to at least have a partial discussion here, and do what little I can. I don't necessarily have time to roll patches in a format suitable for OpenWrt upstreaming; sometimes I think it's more constructive to simply point out what can be done, and have the maintainers do it. Maybe not ideal, but it's something. Look for some more posts on specific topics in the near future. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Removing writable permissions in squashfs images vs overlayfs
On 10/23/22 23:35, Phillip Lougher wrote: On Thu, Oct 20, 2022 at 6:01 PM Peter Naulls wrote: What you probably want is the following % mksquashfs test test.sqsh -action "chmod(ugo-w)@perm(/ugo+w)" It is, fantastic, thank you. I added to include/image.mk: --- a/include/image.mk +++ b/include/image.mk @@ -76,6 +76,7 @@ SQUASHFS_BLOCKSIZE := $(CONFIG_TARGET_SQUASHFS_BLOCK_SIZE)k SQUASHFSOPT := -b $(SQUASHFS_BLOCKSIZE) SQUASHFSOPT += -p '/dev d 755 0 0' -p '/dev/console c 600 0 0 5 1' SQUASHFSOPT += $(if $(CONFIG_SELINUX),-xattrs,-no-xattrs) +SQUASHFSOPT += -action 'chmod(ugo-w)@perm(/ugo+w)' SQUASHFSCOMP := gzip LZMA_XZ_OPTIONS := -Xpreset 9 -Xe -Xlc 0 -Xlp 2 -Xpb 2 ifeq ($(CONFIG_SQUASHFS_XZ),y) It sure seems like this could easily be an config option in OpenWrt, either allowing specific commands here, or some easy presets, or perhaps platform overrides. Again, I know this is theater and overlayfs rules here, but it's still important for my use. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Build strings in libstdc++
I don't know if this is intentional, or some side effect of my build setup, but the OpenWrt 22.03 libstdc++ library has some build strings in it. $ strings build_dir/target-mipsel_24kc_musl/root-ramips/usr/lib/libstdc++.so.6.0.29 | grep home ... /gcc-11.2.0/libstdc++-v3/src/c++11/debug.cc ... /gcc-11.2.0/libstdc++-v3/src/c++17/ryu/f2s_intrinsics.h Etc, which was flagged as a security concern, especially since it contains /home references. C++ is no longer used in my setup in any case, so I removed it from the build. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Expired certificates from ca-certificates
This is of course from ca-certificates 20211016 $ openssl x509 -enddate -noout -in build_dir/target-mipsel_24kc_musl/root-ramips/etc/ssl/certs/Cybertrust_Global_Root.crt notAfter=Dec 15 08:00:00 2021 GMT $ openssl x509 -enddate -noout -in build_dir/target-mipsel_24kc_musl/root-ramips/etc/ssl/certs/GlobalSign_Root_CA_-_R2.crt notAfter=Dec 15 08:00:00 2021 GMT Suggest these are removed from the package. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
CVEs in OpenWrt 22.03
Apologies for the obtuseness of the previous email about the squashfs
permissions - that's related to the following, but a different topic. I can now
say that we're undergoing a security review for our system which is very much
based upon OpenWrt 22.03.
If you have ever done this, you'll probably know what's in such things, lots
of picky items, much that is to be polite, spurious and many other things
which are of little relevance, but are security theater and therefore
important to people who make such reports. Nevertheless, I do have to
provide answers and "proof" for everything.
The following is partly for my own benefit, but it might benefit anyone
else who is settling upon 22.03 for a stable version and will be doing
the same in the near future.
First a request on patch naming in OpenWrt - if it's a specific CVE patch, then
it would help that it was named that. I know that often isn't possible, since
often they get rolled up into other upstream patches, pulled out of git, etc,
etc, but it would help.
For the kernel, a great many of the CVEs in my report relate to the 5.15
kernel series. The dumb assumption here is a that the 5.10 series
kernel is "older", and therefore these must apply to. The reality is that
in most cases, these are issues introduced in that series for new features,
or they've been backported by either the 5.10 maintainers or the OpenWrt
maintainers, both of who I know are on top of such things.
For other remaining CVEs, sometimes it's very hard to know, unless you
can (a) rule out for sure the driver/subsystem isn't in use, or failing
that (b) close code examination and hand-waving that the patch isn't
relevant, sans intimate knowledge of the codebase.
CVE-2022-500 and CVE-2021-4150 are examples here.
For CVE-2022-39188, CVE-2021-3669, it seems like they might get 5.10 series
patches, if they are relevant, so I will wait on a kernel bump on those.
So, to user space:
dnsmasq 2.86 - my pointing out that CVE-2021-45957 et al are false didn't go
over particularly well, even though they have been properly dismissed by
the Simon Kelley and others.
However, there is CVE-20220-0934.
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=03345ecefeb0d82e3c3a4c28f27c3554f0611b39
Which can easily be patched, or update to dnsmasq 2.87.
busybox 1.35.0 - CVE-2022-30065
I brought in patches from here:
https://bugs.busybox.net/show_bug.cgi?id=14781
tcpdump 4.9.3 - CVE-2018-16303
Long since in OpenWrt patches.
e2fsprogs 1.46.5 - CVE-2022-1304
I brought in this patch:
diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c
index b324c7b0..1a206a16 100644
--- a/lib/ext2fs/extent.c
+++ b/lib/ext2fs/extent.c
@@ -495,6 +495,10 @@ retry:
ext2fs_le16_to_cpu(eh->eh_entries);
newpath->max_entries = ext2fs_le16_to_cpu(eh->eh_max);
+ /* Make sure there is at least one extent present */
+ if (newpath->left <= 0)
+ return EXT2_ET_EXTENT_NO_DOWN;
+
if (path->left > 0) {
ix++;
newpath->end_blk = ext2fs_le32_to_cpu(ix->ei_block);
@@ -1630,6 +1634,10 @@ errcode_t ext2fs_extent_delete(ext2_extent_handle_t
handle, int flags)
cp = path->curr;
+ /* Sanity check before memmove() */
+ if (path->left < 0)
+ return EXT2_ET_EXTENT_LEAF_BAD;
+
if (path->left) {
memmove(cp, cp + sizeof(struct ext3_extent_idx),
path->left * sizeof(struct ext3_extent_idx));
lua 5.1.5 and lua 5.3.
CVE-2014-5461 and others. lua 5.1.5 has been heavily patched in OpenWrt,
and I suspect these have all long since been fixed.
If would be simply easier on the optics if I was able to ditch 5.1.5 in the
build and just use 5.3 - is this possible; I'm sure there's been much
discussion on this before, so please point me at that - will it break luci?
There's much more, but that's quite enough for now.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Removing writable permissions in squashfs images vs overlayfs
Yes, I know. Bear with me. Laugh if you must. # ls -l /rom/ ... drwxr-xr-x4 root root98 Oct 20 13:53 www I'd like to remove the writable bits from the squashfs image - /www is particular concern because of security paranoia. Now I realize that: 1. This is contrary to the design and operation of overlayfs - it doesn't matter what you set the permissions to, overlayfs will make a copy and let you "write" anyway (correct me if I'm wrong here) and besides there's only root. 2. This is 100% security theater, but the optics have become important here. I don't see that mksquashfs has any options for removing these attributes. It is possible to set the permissions on files that end up in the rootfs before the image generation, but then you tend to run into permissions problems on the host build system when you do it again and it needs to clean things out. Open to suggestions. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio fiddling from userspace [Was: Re: gpio-mt7621 offset fix for 5.10 kernel series]
On 10/19/22 05:51, Lukas Zeller wrote: Hi, Lukas, thanks for this. I've read through everything and I agree with your concerns. I'll note also that Linus W's commentary is from 2018. On 19 Oct 2022, at 08:55, Petr Štetiar wrote: IMO there should be `ugpiod` daemon available over ubus, probably written in ucode using libgpiod bindings. It should provide ubus events for GPIO inputs and should be able to control GPIO outputs using ubus calls. What would that mean for performance, compared to more direct call chains as when using legacy /sys/class/gpio and current libgpiod? I suspect it would be much slower via an extra daemon. Regarding performance, this is a practical concern. In one case using a GPIO- driven 3-color LED, using explicit user-space tools (albeit a clunky vendor program), to blink, there was a enough of a delay between the blinks to give a disconcerting display when trying to blink white. I'm sure there's a better way to do this, but changing the code to direct file access to the GPIOs produced a more satisfactory result. And I still haven't seen a rationale for the "non-fixed" base - I understand there's probably a desire for abstraction somewhere, but figuring out offsets becomes a hassle. I get that some boards have some wacky GPIO assignments due to chip design, but this is surely a DTS concern. I'm sure also it's trivial to extend the legacy GPIO export function to export named GPIOs too (if it doesn't already, I haven't looked). So for the moment, there doesn't seem to be general-purpose solution in OpenWrt, especially for script use. I'll gladly migrate to that if there is one in future, but I think for now I need to stick to my patch and named GPIO exports in the DTS. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio-mt7621 offset fix for 5.10 kernel series
On 10/18/22 17:10, Lukas Zeller wrote: . Just not any more - the mt7621 had this too. I currently patch it back into 22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3] I can follow the rationale to get rid of legacy GPIOs, but in the context of experimenting platforms, where GPIOs are a thing to work with in user space, there's just no real replacement yet (see details in [1],[2]). Yes, I see. I have a mix of C and scripted GPIO access in my setup, and certainly I can move to libgpiod for that - or just just access them as files with named GPIOs as setup per the DTS. I do see the GPIO shell examples in the OpenWrt wiki, but the code needs more work to deal with multiple banks, and it just makes figuring out the GPIO number to use more clunky without any good cause. Now, the numbered GPIOs really are just for debug in my system, the actual code will use the named ones, but still. Is the long-term intent for shell scripting to instead use the libgpiod tools? https://openwrt.org/docs/techref/hardware/port.gpio ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio-mt7621 offset fix for 5.10 kernel series
On 10/18/22 15:55, Martin Blumenstingl wrote: Hello Peter, On Tue, Oct 18, 2022 at 9:34 PM Peter Naulls wrote: Looks like there was some code loss when the driver came from an earlier kernel series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that number, I don't know): You should also explain the problem with this behavior (if there's any). Upstream kernel doc [0] mentions: * @base: identifies the first GPIO number handled by this chip; * or, if negative during registration, requests dynamic ID allocation. * DEPRECATION: providing anything non-negative and nailing the base * offset of GPIO chips is deprecated. Please pass -1 as base to * let gpiolib select the chip base in all possible cases. We want to * get rid of the static GPIO number space in the long run. I never used it but my understanding is that the recommended way for accessing GPIOs from userspace (in case that's what you need) should be done through libgpiod. Thanks for pointing me at this. Of course, I don't keep tabs on all the kernel development. I will say the following though: It looks a bit odd - the 416 is arbitrary at best, but I'm sure it comes from some calculation. All/most of the other ramips use the ramips GPIO driver instead, which does specify the base, although that's in the the DTS; there's no facility for that in the mt7621 setup at present. I ended up using named GPIO mappings set up in the DTS, which appears to be OK. I was chasing some additional GPIO issues vs what I had working on an earlier kernel series - it didn't immediately help, but it was an obvious inconsistency. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
gpio-mt7621 offset fix for 5.10 kernel series
Looks like there was some code loss when the driver came from an earlier kernel series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that number, I don't know): --- a/drivers/gpio/gpio-mt7621.c2022-10-18 15:03:42.596454871 -0400 +++ b/drivers/gpio/gpio-mt7621.c2022-10-18 13:51:23.628305673 -0400 @@ -234,6 +234,7 @@ return ret; } +rg->chip.base = rg->bank * MTK_BANK_WIDTH; rg->chip.of_gpio_n_cells = 2; rg->chip.of_xlate = mediatek_gpio_xlate; rg->chip.label = devm_kasprintf(dev, GFP_KERNEL, "%s-bank%d", I'm using 5.10 in the current OpenWrt 22.03. Before # ls -l /sys/class/gpio/gpiochip4* lrwxrwxrwx1 root root 0 Jan 1 1970 /sys/class/gpio/gpiochip416 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio6 lrwxrwxrwx1 root root 0 Jan 1 1970 /sys/class/gpio/gpiochip448 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio8 lrwxrwxrwx1 root root 0 Jan 1 1970 /sys/class/gpio/gpiochip480 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio0 After: # ls -l /sys/class/gpio/ --w---1 root root 4096 Jan 1 1970 export lrwxrwxrwx1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio/gpiochip0 lrwxrwxrwx1 root root 0 Jan 1 1970 gpiochip32 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio/gpiochip32 lrwxrwxrwx1 root root 0 Jan 1 1970 gpiochip64 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio/gpiochip64 --w---1 root root 4096 Jan 1 1970 unexport Which is consistent with what I had in 4.14 series. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] udev/libudev update
On 02/11/2013 12:04 PM, Aleksander Morgado wrote: Hey, I'm trying to prepare an update of udev/libudev to latest upstream. As you may already know, udev/libudev sources are now within systemd. I'm not fully sure how to handle this issue; so I'm hoping to get some advice here. Comments welcome! One option is to build systemd completely (e.g. without enabling any special feature, just the bare minimum), and then package in the udev/libudev packages only what we are interested for. This option would require to have libcap and dbus as build dependencies; but these are not For what it's worth - and my requirements are often tangential to the OpenWrt developers ;-) I think this approach makes the most sense. There will almost certainly be someone sometime who wants the other bits, and building optional parts is best. I'd also like to see an update to udev, since there have been various bugs I've fought in older versions, so will take what I can get. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Looking for fulltime OpenWrt/Embedded Developer
This is not strictly on topic for this list, so I'll keep this pretty short. I'm after a developer to work in the Bay Area on OpenWrt stuff. You should be a junior/mid level developer willing to learn new skills but who knows the basics of embedded development. We do lots of other stuff, but that can all be easily taught. So I'm looking for someone based upon the merits of the skills they do have rather than anything else specific. This is a chance to work and learn under one of the most experienced embedded guys I know (me ;-) We have several new boards to bring up with OpenWrt and all likelihood, you'd be interacting heavily with OpenWrt devs (i.e, IRC/this list) to add and improve existing platforms and other OSS technologies. Email me your resume. And to make this real clear, I'm not asking to be contacted by recruiters. Thanks! (Peter, deploying OpenWrt in the real world) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WMAC LED Problems
On 08/01/2012 09:03 PM, LEO Airwarosu Yoichi Shinoda wrote:
On 2012/08/01, at 22:39, Peter Naulls wrote:
The problem here is that the LED handling is done in the wrong
order. I submitted a fix/patch(?) for this months ago, but
it seems to have been ignored or lost. I can dig it out
again - the fix is pretty simple.
I would definitely would like to take a look at it.
Ah yes:
Index: base-files/files/etc/init.d/led
===
--- base-files/files/etc/init.d/led (revision 31054)
+++ base-files/files/etc/init.d/led (working copy)
@@ -1,7 +1,7 @@
#!/bin/sh /etc/rc.common
# (C) 2008 openwrt.org
-START=96
+START=94
load_led() {
local name
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WMAC LED Problems
On 07/31/2012 11:45 PM, LEO Airwarosu Yoichi Shinoda wrote: The problem of wmac based leds on WZR-HP-AG300H stimulated some research on status of led support on other buffalo units with wmac based leds. The following results and observations are based on the trunk revision r32910. COMMON - Wmac based leds do not appear in the /sys/class/leds directory until the corresponding phy is recognized and initialized, which happens during regular init. This suggest that we can not use wmac based leds to indicate the boot/init progress. WZR-HP-G300NH2 - Current /etc/diag.sh uses buffalo:red:diag for indicating boot/init progress. This led is connected to the platform's gpio, so it works. However, the problem is that it REMAINS LIT when the boot/init completes. VERY mis-leading. The problem here is that the LED handling is done in the wrong order. I submitted a fix/patch(?) for this months ago, but it seems to have been ignored or lost. I can dig it out again - the fix is pretty simple. But yes, the requirement to enable WLAN first is a bit annoying. In many of our deployments, we don't even use that - we use G300NH, G300NH2 and AG300H. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WZR-HP-AG300H led support
On 07/30/2012 09:51 PM, LEO Airwarosu Yoichi Shinoda wrote: Peter and folks, I believe Peter meant WZR-HP-AG300H. Last night, I did some research on behaviors of leds on WZR-HP-AG300H, and located controls for all remaining leds on wmacs. Awesome, seems to work fine. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Buffalo WLAE-AG300N wireless led support
On 07/27/2012 07:35 PM, LEO Airwarosu Yoichi Shinoda wrote: On 2012/07/28, at 8:04, Peter Naulls wrote: On 07/27/2012 04:00 PM, LEO Airwarosu Yoichi Shinoda wrote: Folks, Please ignore this particular (additional) patch. I've started to learn how uci-defaults work. Also, and unless I've missed some very recent patch, we're still sans full support of all the LEDs on the AG300N. Anyone want to have a go? Do you mean full support by something similar to those provided by the factory firmware (e.g. http://www.cellularforless.com/resources/userguides/buffalo_Manual.pdf pp.8-9)? No, this is different, but possibly, quite similar hardware internally - the WZR-AG300N - I thought I had seen mention of that in this thread too, but perhaps not. I mention it for completeness. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Buffalo WLAE-AG300N wireless led support
On 07/27/2012 04:00 PM, LEO Airwarosu Yoichi Shinoda wrote: Folks, Please ignore this particular (additional) patch. I've started to learn how uci-defaults work. Also, and unless I've missed some very recent patch, we're still sans full support of all the LEDs on the AG300N. Anyone want to have a go? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] eglibc 2.12 fails to build
On 04/19/2012 05:41 AM, Mirko Vogt wrote: I also noticed complains about glibc - however every time I ask people why in particular they chose glibc over eglibc I didn't get any meaningful response. glibc is de facto unmaintained in OpenWrt and I'd actually like to purge it out - still I'm afraid to affront people using it for a reason. The answer is quite involved, and I don't have time here to repeat stuff that I've detailed elsewhere (sorry). However: - with my current project when I started the uclibc version at the time (about a year ago), had some serious threading bugs. I'm pretty sure those are now fixed, but I switched to glibc 2.13. - uclibc was significantly slower for the PHP/sqlite stuff I was doing over eglibc/glibc (2:1, see benchmarks I made). - I switched to eglibc 2.13 (no other version has built in recent history) because it was slightly smaller. In practice, I had to turn many of the subfeatures back on, since there's poor dependency handling. - We've long since frozen what we do, and we have 3rd party stuff compiled against the toolchain I made, so we're going to be using eglibc for a long time, and am not in a hurry to go to 2.14 etc unless there's some urgent bug that pops up. As for the patches I made, the code base has moved on a bit, but there's stuff there definitely still needed. I don't have time to update them, sorry. But I believe they are all very very obvious. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] eglibc 2.12 fails to build
On 04/17/2012 11:15 AM, Mirko Vogt wrote: Hey Emmanuel, I levelled up all versions of eglibc to i's latest revisions of its respective branches ( https://dev.openwrt.org/changeset/31300 ) and therewith I guess broke eglibc version 2.12 which I'd like to purge out anyway. Is there any reason for you to stay on 2.12 instead of 2.13? If it id because it doesn't/didn't work please give it another try and let me know. Unless something has changed very recently, 2.12 and 2.14 builds have been broken for as long as I've been looking at them, which is the best part of a year. Only 2.13 builds, and even then you still need some additional e/glibc patches for the rest of the system to work correctly. https://dev.openwrt.org/ticket/9483 So, again. Old versions of both eglibc and glibc need to be purged, since they (a) are ancient (b) don't build (c) cause repeat questions of exactly this type on this list. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] sysupgrade: try harder during an error
On 02/25/2012 07:13 AM, Bastian Bittorf wrote:
Remembering the old days, where we had floppy-drives?
Now we have MTD. sad but true, in case of any error during
sysupgrade regarding mtd, there are no further checks
and we are f*cked:
###
Performing system upgrade...
Unlocking linux ...
Writing fromstdin to linux ... [e]MTD do_erase_oneblock():
software
timeout
This has frustrated me too. I don't know what the root
cause is, but what I have seen is that the mtd utility
needs to retry sometimes, and that [e] condition
is a temporary Out of memory error. At least, on ar71xx.
Here's what I did:
Index: src/mtd.c
===
--- src/mtd.c (revision 30710)
+++ src/mtd.c (working copy)
@@ -462,16 +462,21 @@
if (!quiet)
fprintf(stderr, \b\b\b[w]);
- if ((result = write(fd, buf + offset, buflen)) buflen) {
- if (result 0) {
- fprintf(stderr, Error writing image.\n);
- exit(1);
- } else {
- fprintf(stderr, Insufficient space.\n);
- exit(1);
- }
- }
- w += buflen;
+int try;
+for (try = 0; try 3; try++) {
+ if ((result = write(fd, buf + offset, buflen)) buflen) {
+if (result 0) {
+ fprintf(stderr, Error writing image: %s (try %d of 3).\n,
strerror(errno), try + 1);
+ if (try 2) continue;
+ exit(1);
+} else {
+ fprintf(stderr, Insufficient space.\n);
+ exit(1);
+}
+ }
+ w += buflen;
+ break;
+}
I have seen this fail once, twice, and then still succeed. But this
doesn't solve the root cause, and I think I'm still seeing complete
failures here on occasion. This just significantly mitigates it.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] sysupgrade: try harder during an error
On 02/25/2012 10:15 AM, Bastian Bittorf wrote: cause is, but what I have seen is that the mtd utility needs to retry sometimes, and that [e] condition is a temporary Out of memory error. At least, on ar71xx. out of memory doesnt satisfy me. And? I'm telling you what the error is at this level; I'm the only one who's reported this; I've not claimed the resolution is satisfactory. You are free to dig further and find the underlying cause, which is probably kernel related. I'd for one would be grateful. My machine too has significant free memory, but I suspect the memory relates to some kernel memory issues, rather than megabytes of free user space memory. Chill. And I recommend use of your shift key ;-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] WIP: Bulogics Smart Grid Home Controller
Hi guys, I mention in case anyone is interested. I've started work on an OpenWrt port to the Bulogics gateway. I've documented here: http://wiki.openwrt.org/toh/bulogics/smartgrid I'm actually a bit beyond that, have found serial port, etc, etc. I think the software/kernel itself is pretty straightforward, and should be more or less stock. The practical problem is getting access to the device and being in a position to flash. I still need to check a couple of things. If anyone has one of these and is willing to help out, let me know. Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Low level boot on MIPS CPUs
On 02/06/2012 08:52 AM, jonsm...@gmail.com wrote: Most ARM CPUs have boot ROMs for getting the initial image out of flash. I'm referring to the boot loader that loads uboot, not uboot. The ARM CPUs I've worked with search for a signature in flash, if they can't find a valid signature they load from UART instead. Or you can use a jumper to force loading from UART. This allows you to recover from being bricked or initially load the flash without needing a special programmer. Do the MIPS based router CPUs have this ability? What does the on MIPS CPU ROM do if the image in flash is invalid? MIPS systems varies as much as ARM ones do. The short answer, is it depends upon the hardware. For systems which lack serial/ROM level recovery, you'll need to use JTAG. Some systems I work with lack even that. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!
On 01/25/2012 02:50 PM, Philip Prindeville wrote: I'm told that my patches languish because they are for 2.6.39.4 (or whatever) and I'm encouraged to go to a newer kernel... but I can't because all of the churn with the ath9k goes untested and tends to be extremely destabilizing to the ath5k drivers. Hence I'm *forced* to use the 2.6.39.x if I want a machine that even boots. Ironically, my patches are being held back because they're not sufficiently 'vetted', but the reason they aren't vetted is because I can't even get a box to boot with other people's insufficiently vetted ath-common changes! Right, this sounds familiar, except it's with e/glibc stuff. No one much has tested it because it's not in SVN, etc. Moreover, it doesn't affect most users, and without them, e/glibc doesn't work at all. I'm more than willing to take responsibility for this stuff. Exactly how that gets done doesn't bother me very much, since every project is different anyway, only that is a defined path for it getting in at some point. By comparison, I've had Mozilla patches languish for several *years*. Other than that, I'm going a great deal of work testing/using ar71xx, although it's small stuff all over the place. Some of this certainly isn't suitable for mainstream code (much of it I've posted as patches anyway), but I think it likely people would be interested anyway. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] More on G300HN LEDs
On the G300NH (v1), the router LED is turned on at boot completion to indicate it's running. Or at least, that's the intent of the done script. But the led script which sets up the mappings has START=96, but the done script is 95. So it never gets turned on. I fixed that in my setup by moving the led script to 94. For reference, on the G300NH2, the router LED isn't available until the WiFi drivers are loaded, due to the connection via PCI, so the diag light is used instead. Locally, in my rc.local, I turn that off after boot and then turn on the wireless LED. This is definitely a work around. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] FTDI additional serial IDs
Add support for the Rainforest Automation Zigbee dongle.
This is against 2.6.39 only, however Linux 3.2 does not have this
ID either.
Signed-of-by: Peter Naulls pe...@chocky.org
Index: target/linux/generic/patches-2.6.39/823-usb_serial_ftdi_add_more_devices.patch
===
--- target/linux/generic/patches-2.6.39/823-usb_serial_ftdi_add_more_devices.patch (revision 0)
+++ target/linux/generic/patches-2.6.39/823-usb_serial_ftdi_add_more_devices.patch (revision 0)
@@ -0,0 +1,22 @@
+--- a/drivers/usb/serial/ftdi_sio_ids.h.orig 2012-01-16 15:05:19.479187251 -0800
b/drivers/usb/serial/ftdi_sio_ids.h 2012-01-16 15:09:36.059187291 -0800
+@@ -1159,4 +1159,8 @@
+ /* USB-Nano-485*/
+ #define FTDI_CTI_NANO_PID 0xF60B
+
+-
++/*
++ * Rainforest Automation
++ */
++/* ZigBee controller */
++#define FTDI_RF_R106 0x8A28
+--- a/drivers/usb/serial/ftdi_sio.c.orig 2012-01-16 15:05:27.727187253 -0800
b/drivers/usb/serial/ftdi_sio.c 2012-01-16 15:10:37.695187302 -0800
+@@ -828,6 +828,7 @@
+ .driver_info = (kernel_ulong_t)ftdi_jtag_quirk },
+ { USB_DEVICE(ST_VID, ST_STMCLT1030_PID),
+ .driver_info = (kernel_ulong_t)ftdi_stmclite_quirk },
++ { USB_DEVICE(FTDI_VID, FTDI_RF_R106) },
+ { }, /* Optional parameter entry */
+ { } /* Terminating entry */
+ };
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] glibc won't build on ARM
On 01/16/2012 01:49 PM, jonsm...@gmail.com wrote: I can't get any of the glibc versions to build on ARM. I wanted to use glibc as a way of eliminating ulibc as the source of the bug. They all fail with various compile errors. Less than 2.7 complains about binutils. cue weekly response 2.7 is ancient and broken. Patches here: https://dev.openwrt.org/ticket/9483 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Ethernet breakage in latest trunk on WZR-HP-300HN
I'm seeing this: Realtek RTL8366S ethernet switch driver version 0.2.2 [1.01] rtl8366s rtl8366s: using GPIO pins 19 (SDA) and 20 (SCK) [1.01] rtl8366s rtl8366s: unknown chip id () [1.02] rtl8366s rtl8366s: chip detection failed, err=-19 [1.03] eth0: Atheros AG71xx at 0xb900, irq 4 [1.34] eth0: unable to find MII bus on device 'rtl8366s' [1.36] eth0: Atheros AG71xx at 0xba00, irq 5 [1.66] eth0: unable to find MII bus on device 'rtl8366s' I rolled back to before this change in just generic/files/drivers/net/phy: r29677 | juhosg | 2012-01-07 11:36:30 -0800 (Sat, 07 Jan 2012) | 5 lines Changed paths: M /trunk/target/linux/generic/files/drivers/net/phy/rtl8366_smi.c M /trunk/target/linux/generic/files/drivers/net/phy/rtl8366_smi.h M /trunk/target/linux/generic/files/drivers/net/phy/rtl8366rb.c M /trunk/target/linux/generic/files/drivers/net/phy/rtl8366s.c generic: rtl8366: preparing for RTL8367 support * make clock delay configurable * make read,write commands configurable * use u16 for member and untag fields And now it works again: [1.00] Realtek RTL8366RB ethernet switch driver version 0.2.3 [1.01] rtl8366rb rtl8366rb: using GPIO pins 19 (SDA) and 20 (SCK) [1.02] rtl8366rb rtl8366rb: RTL5937 ver. 3 chip found [1.12] rtl8366rb: probed [1.13] eth0: Atheros AG71xx at 0xb900, irq 4 [1.44] eth1: Atheros AG71xx at 0xba00, irq 5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] WZR-HP-G300NH ar71xx u-boot
On 01/11/2012 07:16 PM, Mark Deneen wrote: Quick question, since I don't know the full story here.. but the buffalo gpl source for u-boot for the G300NH is available. The NH2 u-boot source is MIA, though. http://opensource.buffalo.jp/gpl_wireless.html It's in the G300NH tarball. The source from the other buffalo models may be of use to you as well. This helped a little, but I wasn't able to produce a binary which kexec liked with this (funky ld flags, perhaps). Is anyone interested in this? I was able to get the flash setup right, and started on the ethernet, but I don't actually need that, so I left it. It needs support for its switch type. You could take that from the sources above or mods from Linux kernel, etc. I also tried to make a version against latest u-boot trunk (ftp site is down), but that was having malloc errors, so I gave up on that for now. As for NH2, I still need to do that, and have support for its flash. It might not be possible to produce a u-boot that does both, since u-boot isn't quite as flexible as the Linux platform setup. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx preemptive kernel
On 01/12/2012 02:26 AM, Florian Fainelli wrote: Hello Peter, The system seemed otherwise ok, but I didn't test beyond this. Can you describe how you run into this error? Just so that we can reproduce and fix the problem. Should have provided more details. I had to rebuild the kernel to get on with other stuff, and this was just the bit I saved. This error is immediately after the kernel boot, so whatever's being run with swconfig during boot. This is latest trunk using glibc. If there's something else you'd like me to try, I can do that later. The option I turned on in the kernel is for desktop preemption. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Circular locking dependency
I think this is the same kernel I've been using a long time on
WZR-HP-G300NH, (that is, not the preemptive options I
mentioned yesterday), but I did recently turn on debugging.
I think this may help explain some occasional flash failures
we've been seeing (this is the only one with a serial port).
During sysupgrade:
[ 66.54]
[ 66.54] ===
[ 66.54] [ INFO: possible circular locking dependency detected ]
[ 66.54] 2.6.39.4 #6
[ 66.54] ---
[ 66.54] find/1417 is trying to acquire lock:
[ 66.54] (mm-mmap_sem){++}, at: [800cf728] might_fault+0x38/0x90
[ 66.54]
[ 66.54] but task is already holding lock:
[ 66.54] (f-sem){+.+.+.}, at: [8013e630] jffs2_readdir+0x10c/0x1cc
[ 66.54]
[ 66.54] which lock already depends on the new lock.
[ 66.54]
[ 66.54]
[ 66.54] the existing dependency chain (in reverse order) is:
[ 66.54]
[ 66.54] - #1 (f-sem){+.+.+.}:
[ 66.54][800a5e18] lock_acquire+0x60/0x88
[ 66.54][8027f8a4] mutex_lock_nested+0x54/0x30c
[ 66.54][8013ede0] jffs2_readpage+0x2c/0x6c
[ 66.54][800c0fa4] __do_page_cache_readahead+0x214/0x27c
[ 66.54][800c1300] ra_submit+0x28/0x34
[ 66.54][800b9ff0] filemap_fault+0x1bc/0x414
[ 66.54][800cfab8] __do_fault+0x70/0x44c
[ 66.54][800d2e1c] handle_pte_fault+0x380/0x78c
[ 66.54][800d32dc] handle_mm_fault+0xb4/0xe0
[ 66.54][8006c000] do_page_fault+0x100/0x2f0
[ 66.54][80062880] ret_from_exception+0x0/0xc
[ 66.54]
[ 66.54] - #0 (mm-mmap_sem){++}:
[ 66.54][800a51b0] __lock_acquire+0x10d0/0x1818
[ 66.54][800a5e18] lock_acquire+0x60/0x88
[ 66.54][800cf750] might_fault+0x60/0x90
[ 66.54][800f8038] filldir64+0xe8/0x158
[ 66.54][8013e68c] jffs2_readdir+0x168/0x1cc
[ 66.54][800f8364] vfs_readdir+0x88/0xd8
[ 66.54][800f8588] sys_getdents64+0x74/0xdc
[ 66.54][8006a178] stack_done+0x20/0x40
[ 66.54]
[ 66.54] other info that might help us debug this:
[ 66.54]
[ 66.54] 2 locks held by find/1417:
[ 66.54] #0: (sb-s_type-i_mutex_key#7){+.+.+.}, at: [800f8334]
vfs_readdir+0x58/0xd8
[ 66.54] #1: (f-sem){+.+.+.}, at: [8013e630]
jffs2_readdir+0x10c/0x1cc
[ 66.54]
[ 66.54] stack backtrace:
[ 66.54] Call Trace:
[ 66.54] [8027dd14] dump_stack+0x8/0x34
[ 66.54] [800a2b6c] print_circular_bug+0xd4/0xf8
[ 66.54] [800a51b0] __lock_acquire+0x10d0/0x1818
[ 66.54] [800a5e18] lock_acquire+0x60/0x88
[ 66.54] [800cf750] might_fault+0x60/0x90
[ 66.54] [800f8038] filldir64+0xe8/0x158
[ 66.54] [8013e68c] jffs2_readdir+0x168/0x1cc
[ 66.54] [800f8364] vfs_readdir+0x88/0xd8
[ 66.54] [800f8588] sys_getdents64+0x74/0xdc
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ar71xx preemptive kernel
For comedy value, I enabled preemption in my G300NH build:
124.49] BUG: scheduling while atomic: swconfig/811/0x0002
[ 124.50] 2 locks held by swconfig/811:
[ 124.50] #0: (genl_mutex){+.+...}, at: [8021cd20] genl_rcv+0x14/0x34
[ 124.51] #1: ((dev-lock)-rlock){+.+...}, at: [801d5e48]
swconfig_get_dev.clone.7+0x7c/0xa0
[ 124.52] Modules linked in: nf_nat_irc nf_conntrack_irc nf_nat_ftp
nf_conntrack_ftp ipt_MASQUERADE iptable_nat nf_nat xt_conntrack xt_CT xt_NOTRACK
iptable_raw xt_state nf_conntrack_ipv4 ne
[ 124.57] Call Trace:
[ 124.58] [80287b68] dump_stack+0x8/0x34
[ 124.58] [8028811c] schedule+0x84/0x50c
[ 124.58] [80288b08] schedule_timeout+0x184/0x1bc
[ 124.59] [800839b0] msleep+0x20/0x30
[ 124.59] [801deec4] rtl8366rb_reset_chip+0x2c/0x90
[ 124.60] [801df1c4] rtl8366rb_sw_reset_switch+0x18/0x74
[ 124.61] [801d6274] swconfig_set_attr+0x1f4/0x23c
[ 124.61] [8021cee8] genl_rcv_msg+0x1a8/0x1f4
[ 124.62] [8021c204] netlink_rcv_skb+0x6c/0xe8
[ 124.62] [8021cd30] genl_rcv+0x24/0x34
[ 124.62] [8021ba5c] netlink_unicast+0x26c/0x350
[ 124.63] [8021bde4] netlink_sendmsg+0x2a4/0x334
[ 124.63] [801e93cc] sock_sendmsg+0x84/0x9c
[ 124.64] [801ebecc] sys_s
The system seemed otherwise ok, but I didn't test beyond this.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] kexec failure on G300NH
On 01/07/2012 03:25 AM, Florian Fainelli wrote: Le samedi 07 janvier 2012 00:32:31, Peter Naulls a écrit : On 01/06/2012 08:10 AM, Peter Naulls wrote: As an alternative, I'm looking at first jumping to an ar71xx version of u-boot (as per OpenWrt build), all I should need to add to that is flash support for the G300NH(2). Perhaps that puts the system in more consistent state before starting Linux. I was able to make this work. I built the ar71xx u-boot, and was able to add support for the G300NH flash. So, I kexec into u-boot, then am able to reboot back into Linux (loaded from flash). This suggests that u-boot is resetting something that either kexec or the Linux kernel upon boot does not. Anyway, I'll pursue this option right now, but I'm open ideas for fixing kexec directly to new kernel. What about you leaving the watchdog enabled with a timeout sufficiently small that it does not cover the time for loading the kernel to kexec + the time for the kexec'd kernel to start up? It's unclear what you're getting at here. If the watchdog is not disabled, then it''ll reboot during the kexec steps. Anyway, the problem still remains of the kexec kernel without u-boot helping not being in a good state. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] kexec failure on G300NH
On 01/06/2012 07:06 AM, Paolo Pisati wrote: On 01/06/2012 11:48 AM, Florian Fainelli wrote: Then this might be an entirely different issue. Try to run the kexec'd kernel uncached and see if that helps (there is a MIPS-specific Kconfig option to do that). but is kexec working at all on MIPS cpus? on arm, at least, it was badly broken and there are fixes queued for the 3.3 window. Not all. It does appear to work fine, above issues notwithstanding. However, I need it to also work on ramips, where it has issues. I'll be looking at that in detail once I fix this. As an alternative, I'm looking at first jumping to an ar71xx version of u-boot (as per OpenWrt build), all I should need to add to that is flash support for the G300NH(2). Perhaps that puts the system in more consistent state before starting Linux. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] kexec failure on G300NH
On 01/06/2012 02:48 AM, Florian Fainelli wrote: Then this might be an entirely different issue. Try to run the kexec'd kernel uncached and see if that helps (there is a MIPS-specific Kconfig option to do that). CONFIG_MIPS_L1_CACHE_SHIFT=5 ? There's other related stuff in arch/mips/Kconfig but I don't see an explicit disable. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] kexec failure on G300NH
On 01/06/2012 08:10 AM, Peter Naulls wrote: As an alternative, I'm looking at first jumping to an ar71xx version of u-boot (as per OpenWrt build), all I should need to add to that is flash support for the G300NH(2). Perhaps that puts the system in more consistent state before starting Linux. I was able to make this work. I built the ar71xx u-boot, and was able to add support for the G300NH flash. So, I kexec into u-boot, then am able to reboot back into Linux (loaded from flash). This suggests that u-boot is resetting something that either kexec or the Linux kernel upon boot does not. Anyway, I'll pursue this option right now, but I'm open ideas for fixing kexec directly to new kernel. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] kexec failure on G300NH
I'm trying to use kexec as a fallback/flash mechanism. But something is going wrong: http://pastebin.com/0uvNnMQd So the device halts after/during the serial port setup, and returns to boot loader. Anyone want to suggest what might be going wrong, or where to start looking? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] kexec failure on G300NH
On 01/05/2012 09:43 AM, Florian Fainelli wrote: Hello, You should enable kernel debugging in your kexec'd kernel and see whether the serial port is being left with IRQs disabled from the original kernel. I turned on kernel debug, but I'm unsure what exactly I'm looking at. It may be that the serial port is flooding the kernel with IRQs not handled which in turn causes a reboot. Otherwise, just dump the serial port register contents before leaving the original kernel, and at driver initialization of the kexec'd kernel to see if there are any differences. Sure, but which registers am I looking at - 8250, or something arxx specific? I went as far as to set: CONFIG_SERIAL_8250_NR_UARTS=0 CONFIG_SERIAL_8250_RUNTIME_UARTS=0 But this might not be enough by itself. It still reboots at that same point. I also tried disabling early printk. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Toolchain fails to compile on trunk with glibc 2.7
On 01/04/2012 08:55 AM, Jo-Philipp Wich wrote: Hi. Error: bad register name `%sil' You probably need a patch similar to this: http://old-list-archives.xen.org/archives/html/xen-devel/2009-05/binBCldaQtw31.bin Apart from that, there are still a number of pending patches required for e/glibc to work: https://dev.openwrt.org/ticket/9483 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
