**** BEGIN LOGGING AT Mon Apr 19 02:59:56 2021 Apr 19 08:38:02 blocktrron: I have no idea why the at803x patch broke. I saw the changes and they looked fishy, but they were completely automated. I trusted quilt had done the right thing… :/ Apr 19 08:42:55 hmm armvirt 32-bit has a too capable setup Apr 19 08:43:01 wonder if it's easy to change Apr 19 08:44:14 https://github.com/openwrt/openwrt/blob/master/target/linux/armvirt/32/config-5.10#L48 what a typo Apr 19 08:50:02 mangix: Typo? Apr 19 08:50:41 CONFIG_HZ=100 looks correct… Apr 19 08:50:55 oh I can't read Apr 19 08:51:30 Well, I just woke up and had no coffee yet, so it could be me, for sure. :P Apr 19 09:08:21 mangix: Speaking of HZ, is there any reason for some targets to select HZ=250 instead of HZ=100, like most do? Apr 19 09:12:28 rsalvaterra: happenes Apr 19 09:46:27 rsalvaterra, o/ Apr 19 09:46:46 nitroshift: Hi, there! :) Apr 19 09:47:09 rsalvaterra, after you have your coffee can you pm me please? Apr 19 10:38:46 rsalvaterra: nobody has an answer honestly. Apr 19 10:41:30 mangix: Thought so… :) Apr 19 10:42:16 mangix: I'm getting this ready… https://github.com/rsalvaterra/openwrt/commit/ff692f55c7bc6dbd230a74489b33a5f7c593c5f8 Apr 19 10:47:54 how dare you slow my kernel down! Moar faster is better!!!! Apr 19 10:50:25 * ldir sets CONFIG_HZ to 100000000000000000000000000000 Apr 19 10:52:07 hey guys Apr 19 10:52:14 i need firewall / routing / NAT help Apr 19 10:52:33 i have 2 networks connected using wireguard Apr 19 10:52:44 only 1 network has public ip Apr 19 10:53:22 I want OpenWrt router in my network with public IP to port forward requests to another network client Apr 19 10:53:31 it doesn't work Apr 19 10:54:15 port forwarding to "lan" local device works of course Apr 19 10:54:34 port forwarding to "lan" device accessible over wireguard connection doesn't work Apr 19 10:54:38 can I fix that? Apr 19 10:56:12 * ldir doesn't know Apr 19 10:56:15 can DNAT redirect work for dest_ip being device in wireguard connected network? Apr 19 10:56:15 rsalvaterra: now history makes full-circle https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=3a761c90afc0af1a17a03241534508b52a235410 Apr 19 10:56:34 jow: my firewall & routing guru ^^ Apr 19 10:58:07 rmilecki: what I'd be doing is reading raw iptables -t nat -L -v -n output (and same for -t filter). That would show the counters for specific rules. DNAT should be there and you can see if it ever matched, and if it did you see all the options used and you can try e.g. pinging the host listed etc. Apr 19 11:06:38 -t nat https://pastebin.com/raw/qWgSyNRj Apr 19 11:06:44 -t filter https://pastebin.com/raw/LrDhTScF Apr 19 11:07:10 i'm trying to forward port 5821 TCP requests to the 192.168.22.145 Apr 19 11:07:45 192.168.99.1 is my main router (public IP) wg IP Apr 19 11:12:00 tmn505: Why the upstream default? 100 Hz ought to be enough for everybody™. :P Apr 19 11:12:53 rmilecki: were the command performed after at least one try to contact that port from the outside. Apr 19 11:12:56 ? Apr 19 11:13:01 yes Apr 19 11:13:10 i tried telnet few times Apr 19 11:14:05 tmn505: Oh, that's an old commit, I see now. Apr 19 11:14:14 Well as the idiot who committed that - personal view - stick with kernel defaults scratched my OCD/keep the defaults unless you really don't want them itch Apr 19 11:15:28 PaulFertser: oh, wait, I check that again Apr 19 11:15:45 PaulFertser: now every telnet try results in increasing pkts and bytes in the zone_wan_prerouting Apr 19 11:15:55 after 9 requests: Apr 19 11:15:57 9 540 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5821 /* !fw3: towg */ to:192.168.22.145:5821 Apr 19 11:16:34 personally again, I think all targets should use whatever the openwrt default is, unless there's a damn good technical reason why not (like it doesn't work/smoke comes out) Apr 19 11:17:45 rmilecki: rmilecki: I wonder if the counters in zone_lan_forward are changing too. Apr 19 11:17:52 no Apr 19 11:18:08 ldir: My reasoning for keeping everything at 100 Hz is twofold… first, it consolidates the definition in the generic kconfigs; second, the our scheduling frequency requirements aren't high (we're not running DAWs in OpenWrt, I think :P), so we might as well tune for server-like workloads. :) Apr 19 11:18:27 PaulFertser: -t nat updated https://pastebin.com/raw/s3tzm3Vm Apr 19 11:18:48 ah, wait, zone_lan_forward is not a part of -t nat Apr 19 11:21:34 PaulFertser: i checked -t filter and zone_lan_forward counters don't increate on telnet attempt Apr 19 11:22:43 rmilecki: hm, I think counters in zone_wan_forward should be increasing as the traffic is coming from wan in this case. Apr 19 11:24:19 rmilecki: and in your previous paste I see 2 packets in zone_wan_forward were recognised as cstate DNAT. Apr 19 11:25:12 PaulFertser: i guess it could be some other traffic (non 5821 port) Apr 19 11:25:35 uh, it's annoying Apr 19 11:27:05 rmilecki: you also have reflection enabled for that rule. Probably it adds to the confusion. Apr 19 11:27:47 PaulFertser: i believe fw3 does that by default Apr 19 11:27:55 rsalvaterra: like I said "I know nothing" and having a global default suits me fine even if that global default is different from upstream. Apr 19 11:28:03 rmilecki: it does, yes Apr 19 11:28:04 i didn't enable anytng like that in the "config redirect" UCI section Apr 19 11:28:07 ok Apr 19 11:35:10 rmilecki: https://openwrt.org/docs/guide-user/firewall/firewall_configuration - 'reflection' - maybe it helps you Apr 19 11:35:27 rmilecki: is your wg tunnel supposed to pass traffic from IPs outside the specific range you defined? Apr 19 11:35:47 rmilecki: or do you expect port forwarding to SNAT all packets to the router's address? Apr 19 11:36:40 PaulFertser: i don't think i understand that question Apr 19 11:36:54 PaulFertser: in routing on my main router (public IP) i have: Apr 19 11:36:55 192.168.22.0 * 255.255.255.0 U 0 0 0 wg0 Apr 19 11:37:16 192.168.22.0 is network of my other network (no public ip) Apr 19 11:37:43 rmilecki: so you have some packet coming from the internet, and it has source IP of some outside internet host. And you eventually want that packet to be received by some internal host that's accessible via the wireguard tunnel. Do you expect that packet to pass the wireguard tunnel while still having that external source ip address? Apr 19 11:39:12 PaulFertser: i don't need that, a simple DNAT is fine Apr 19 11:39:41 (i don't need replacing source IP) Apr 19 11:40:19 ah, i'm wondering if that is not aproblem Apr 19 11:40:48 it source IP doesn't get replaced, than my 192.168.22.145 my be sending reply directly Apr 19 11:40:55 not back thought the NAT Apr 19 11:41:22 You'd see it in tcpdump running on your 192.168.22.145 Apr 19 11:41:30 definitely Apr 19 11:41:31 good idea Apr 19 11:43:02 Not sure if it's indeed the problem but for cases like that https://unix.stackexchange.com/a/23345 looks like the best answer. Apr 19 11:44:33 rmilecki: when you get it working document it :-) I don't need to port forward across to my wireguard private subnet yet... but I might one day. Apr 19 11:45:10 Pretty please configure IPv6 routing instead. DNAT is just a hack and so has limitations and unexpected quirks. Apr 19 11:59:09 PaulFertser: i don't see any incoming traffic on 192.168.22.145 when running "tcpdump port 5821" Apr 19 12:00:06 I'd check on the router itself too Apr 19 12:00:08 (it I connect from my main router (public ip) lan network - i can see "tcpdump port 5921" output) Apr 19 12:01:36 PaulFertser: nothing on my other network router (no public ip) Apr 19 12:01:53 so my main router (public ip) doesn't seem to even forward that request over wireguard Apr 19 12:02:22 rmilecki: in cases like that I usually try to correlate the counters to see where the packet gets lost. Apr 19 12:02:46 And watching tcpdump on the device doing firewalling. Apr 19 12:03:27 PaulFertser: i just run tcpdump of device doing firewalling (main router with public ip) Apr 19 12:03:30 nothing Apr 19 12:03:44 i'm not sure if tcpdump is expected to show forwarded traffi Apr 19 12:03:59 If you use the interface where the traffic goes, yes. Apr 19 12:04:17 well, it does show TCP packets when I do "telnet" from local network device (no port forwarding from wan) Apr 19 12:05:14 So must be getting lost in firewall somehow. Some counter in -t filter should be increasing. Apr 19 12:11:48 tmn505: Any idea on how to answer these questions? https://github.com/openwrt/openwrt/pull/3886#issuecomment-788231115 Apr 19 12:12:14 tmn505: I just ported the patches, I don't know if they're relevant or not. Apr 19 12:22:45 Hauke: would it be possible to update mac80211 to the latest 4.19 kernel in OpenWrt 19.07? What is the preferred wokflow for you? I'd like to have this fix https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.19.y&id=e0ea994b77a32763138b33ac784ab91cfb91eefd in the stable release Apr 19 13:31:37 rsalvaterra: done. Apr 19 13:32:52 tmn505: Nice, thanks a lot! :) Apr 19 14:10:33 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 98.3% packages reproducible in our current test framework.) Apr 19 14:27:22 PaulFertser: I've got an issue you can probably help with... I have two zones here (192.168.{1,3}.0) and I'd like to be able to contact 192.168.3.1 from the 192.168.1.0 zone Apr 19 14:31:00 Spyro1248: then it should be a matter of adding a rule that would allow it. By default forwardirng between zones is prohibited. Apr 19 14:43:50 > Unfortunately, we will not be able to deliver the part 115-HF105-000 . Apr 19 14:44:02 sigh, no HiFive Unmatched for Europe Apr 19 14:44:10 stoopid regulations Apr 19 15:10:59 ok, after some uptime, something seems definitely wrong with octeon on 5.10 Apr 19 15:11:05 but that's why we have testing kernels right :) Apr 19 15:12:17 seems to be memleaking Apr 19 15:24:51 stintel, is there some info what the issue is - that board doesnt have wifi - is it some patent issue ? Apr 19 15:30:40 plntyk: no, I tweeted @sifive Apr 19 15:30:45 let's see if they respon Apr 19 16:43:14 EdgeRouter Lite + 5.10: [54157.508486] Kernel panic - not syncing: System is deadlocked on memory Apr 19 16:43:15 oops Apr 19 16:43:31 should we revert testing kernels on such bad issues? Apr 19 16:43:40 I'd say no because testing though Apr 19 16:46:08 stintel: Yikes, what happened? Apr 19 16:47:14 nothing Apr 19 16:47:32 simply 5.10 that seems really leaky Apr 19 16:52:30 plntyk: < SiFive> [c0->84] @stintel Hi @stintel, we'll check on this and let you know. Apr 19 16:53:27 at least they responded :) Apr 19 16:57:52 stintel: Were you the commenter on that thread RE: XAUI init? Apr 19 16:58:29 hurricos: yes Apr 19 16:58:35 it's the same nickname, no ? Apr 19 16:59:27 stintel: Actually, I'll comment on the forum. But I have to tell you just how excited I am that you are actually looking at this as well. I haven't had the time or encouragement to touch it for months. Apr 19 16:59:41 hurricos: alright works for me ;) Apr 19 16:59:57 Yes, I noticed. I only briefly recalled that I got an email from the forum telling me someone had replied, and I said "ugh" through my chocolate and sat back down to playing Moonlighter :'( Apr 19 17:00:06 hehehe Apr 19 17:00:21 I'm mostly a bit bummed that I have devices without NAND Apr 19 17:00:38 Well, it's not a huge issue since you almost certainly have to stick it into a motherboard anyways :^) Apr 19 17:01:06 Unless, of course, you've gotten some extra electrical hints about the heavy, power-looking 4-pin header at the top right corner. Apr 19 17:01:19 anyways, inline on forum i shall respond. Thank you very much for coming back to this! Apr 19 17:01:42 just before I go on the forum and probably forget to finish posting when I get called away due to work: If you are in North America I will happily send you cards Apr 19 17:02:08 Hopefully US, specifically. I have 50 of them with NAND Apr 19 17:02:13 well actually I had hoped to put 2 of them in 1 single 1U rackmount case, each separate power supply, and just put them in something like this: https://www.jarcomputers.com/Estillo-Riser-Card-6-Pin-PCI-E_prod_IESTILLORISERCARD6PIN.html?ref=prod Apr 19 17:02:23 hurricos: no I'm in Eastern Europe unfortunately Apr 19 17:02:27 Ah! Apr 19 17:02:30 which is why I never bothered asking you :) Apr 19 17:03:16 but a solution like that would a super fancy HA setup imo :) Apr 19 17:03:30 HA? hadoop? Apr 19 17:03:35 High-Available Apr 19 17:03:53 see https://stijn.tintel.eu/blog/2017/09/20/building-redundant-router-setup-open-source-software-part-1 if you want to know more about my setup :) Apr 19 17:04:28 zoinks! You've been doing this a while! Apr 19 17:04:52 yeah :) Apr 19 17:05:41 I think in 2007 I did my first setup like that at home Apr 19 17:05:53 stintel: Oh, the ER Lite is octeon. I'd be worried if it were MT7621, as it could possibly be my fault. Carry on, then. :P Apr 19 17:06:08 but even earlier I did some HA setup for the company of the father of one of my best friends Apr 19 17:06:28 my network now is ... you don't want to know :P Apr 19 17:08:09 I suspect the vsc848x driver is going to be have to rewritten some more though Apr 19 17:08:50 I managed to get it to compile, and I've added some printks, the driver is registering but it doesn't seem to the detect the phys Apr 19 17:09:49 but I'm somewhat excited that I managed to make it detect the SFPs in the slots Apr 19 17:10:16 so I'm hoping we're not too far off of network connectivity :) Apr 19 17:10:16 Yes, I was able to read the serial content of the device using i2c-detect Apr 19 17:10:27 But actually setting up the PHYs was past me Apr 19 17:11:42 well, disabling that reset to fix xaui probe seems to have worked, that means your debug patches are no longer needed I think Apr 19 17:13:27 stintel: Actually, you should probably write a blog post about your network setup. Who doesn't like some network porn? :) Apr 19 17:14:46 if we can manage to get those CN6640-SNIC10E to run standalone and I replace my APU2 (main) and ERL (backup) routers, then maybe I'll do just that :P Apr 19 17:15:22 stintel: you just tried it now? Apr 19 17:15:28 tried what ? Apr 19 17:15:51 Oh, OK. I'm all caught up on the chronology of what happened. The heisenbug you found, and then killed with Aaro's patch properly applied to CN66XX Apr 19 17:16:01 with XAUI init hanging the board Apr 19 17:16:57 Am I correct in saying that you have access and are using OpenWrt's buildsystem? Apr 19 17:17:04 Like, the internal one? The buildbots I should say Apr 19 17:17:22 scratch that, of course you do, you're pushing to the OpenWrt git. Never mind. Apr 19 17:18:24 Can we have a Gitlab project somewhere to track all this so I can get back to it? :^) Apr 19 17:19:13 I can offer you gitlab.laboratoryb.org, or we can use Gitlab for-real, or some other minor issue-tracking thing elsewhere. I'd like to find time to find and sync up my fiddly changes to the SDK's u-boot tree and then actually track them Apr 19 17:19:27 stintel: Apr 19 17:20:16 hurricos: I am pushing to my staging tree so not using the build infra. I just build manually here Apr 19 17:20:20 Ah ok. Apr 19 17:20:49 The other side of all of this is, just so you're aware, all of the hardware setup. I link that patchset multiple times, there's a lot that needs to be done to setup Cavium hardware queues, etc Apr 19 17:23:01 it's the SFP PHY setup, but then it's also the VSC848X PHY setup, and then the Cavium XAUI init, and after all that, all of the hardware queue stuff hinted at by Aaro's patchset Apr 19 17:24:25 yeah, I hope we can poke it hard enough so that it'll work :P Apr 19 17:31:54 as far as I know though, if you don't set up hardware queues you can get away with piss-poor performance Apr 19 17:31:59 something like 2Gbit/s Apr 19 17:32:25 ah but that's a good start Apr 19 17:32:44 so we don't need the hw queues for working ethernet? Apr 19 17:32:59 I'm gonna have another go at that vsc848x driver Apr 19 17:33:56 stintel: Can you upload your diffconfig somewhere? Apr 19 17:34:49 the other issue with nand is U-boot, sadly Apr 19 17:37:52 u-boot doesn't support the NAND? Apr 19 17:38:28 yes and no. I tripped over some bugs with a recompiled u-boot. Actually, it's mostly not knowing how to manage NAND without ubi Apr 19 17:38:48 Vaguely remember being able to nand load into RAM with the original copy of U-boot, not sure about the newer one. Apr 19 17:39:01 ah, but could do a "hybrid" setup like u-boot + kernel on NOR and use NAND only for rootfs/overlayu Apr 19 17:41:13 hurricos: diffconfig: https://gist.github.com/stintel/8f59e32b10f6aaae0a3fcb173f23f432 Apr 19 17:42:17 just updated it, even sensors is showing stuff about the SFP modules and the device Apr 19 17:43:58 stintel: if you can fit the kernel in NOR Apr 19 17:44:21 I suspect it should be possible Apr 19 17:44:36 stintel: you're running on a pcie card? Apr 19 17:45:07 Pepe: the mac80211 update is on my todo list Apr 19 17:45:08 lynxis: yes - https://forum.openwrt.org/t/wip-porting-openwrt-to-cavium-cn6640-snic10e-octeon-ii-nic/88461/29 Apr 19 17:45:15 lynxis: credits to hurricos Apr 19 17:45:35 Pepe: I think xback already backported some fixes amnually Apr 19 17:47:00 stintel: what can you do with it? Apr 19 17:47:54 lynxis: It's a standard 8-core MIPS64 processor with two XAUI ports and some hardware cores for AES etc which BSD is able to use Apr 19 17:48:01 lynxis: well it has 2x10GbE SFP+ Apr 19 17:48:39 sorry. two SFP+ ports, connected via two lanes of XAUI to an older XAUI-to-XGXS Apr 19 17:48:42 ... phy Apr 19 17:48:48 (the phy in question being VSC848X) Apr 19 17:48:49 so for me it would be extra nice because I would plug both ports into my switch' SFP+ slots so I win 4 wired ports again =) Apr 19 17:49:37 using DACs Apr 19 17:49:51 so how is the pcie connected? Apr 19 17:49:51 The standard driver is supposed to be liquidio in Linux, it's supposed to push a firmware to it which boots it. However, the firmware *doesn't work*, or the driver doesn't like what state it finds the firwmare in after booting it. Apr 19 17:50:22 Host with PCIe connector -> board, with a bootloader, NOR flash, and sometimes NAND flash on it, plus 2GB of soldered-on RAM Apr 19 17:50:33 s/connector/slot. Apr 19 17:58:02 lynxis: are you interested in having a few? I'm arranging shipping from US to BG Apr 19 17:58:12 can forward some to DE if you want Apr 19 17:58:32 stintel: soo many hardware is already lying around :P. I was just looking on ebay for one. Apr 19 17:58:41 I know the feeling :P Apr 19 17:59:06 * stintel looks at the WatchGuard Firebox M300 under his desk Apr 19 18:00:04 stintel: if you have enought, it would be great if you could send me one. Apr 19 18:00:27 stintel: interesting device too ;) Apr 19 18:01:11 yeah, absolutelt Apr 19 18:09:35 stintel I have one of these that just works https://www.ebay.co.uk/itm/Mellanox-MCX311A-XCAT-CX311A-ConnectX-3-EN-Network-Card-10GbE-SinglePort-SFP/132911356246 what switch are you working with? Apr 19 18:11:03 ephemer0l: Huawei S6720-32C-PWH-SI Apr 19 18:11:18 ephemer0l: but it works as a NIC or as a standalone device ? Apr 19 18:13:50 stintel I have 10g SR sfp's to an ex-4200 Apr 19 18:14:14 yes but can you run OpenWrt on the NIC? Apr 19 18:14:17 that's what I want to do ;) Apr 19 18:14:33 that I doubt ;-) Apr 19 18:18:00 OpenWrt on the NIC is interesting enough -- bolt the NIC atop any SFP+ VLAN-aware switch and add a serial voltage converter and a 12v power supply and you have a 46-port OpenWrt switch ;^) Apr 19 18:18:24 of course, of course, that's not actually how it works. Apr 19 18:18:45 :P Apr 19 18:21:31 oooh my DACs will arrive tomorrow Apr 19 18:23:13 so where I am still stuck: https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=blob;f=target/linux/octeon/patches-5.10/710-netdev-phy-Add-driver-for-Vitesse-vsc848x-single-dua.patch;h=456d94e4aab5188d649d64358dc12d147991d615;hb=fb55b3a5ef067ef8b17f142bcb4b04cdb7befb13#l705 Apr 19 18:23:28 struct phy_driver does not have a driver member anymore it seems Apr 19 18:23:54 and I couldn't figure out where I have to move that with its of_match_table member Apr 19 18:27:17 So my undersatnding is, the of_memory_accessor patch stuff was based on an understanding that there was no way in kernel 3.10 to map memory as was desired by Aaron Williams Apr 19 18:27:50 from a device that needed to be initialized by the kernel. Of course, since mapping devices into virtual memory so they can be trivially accessed is the point of device trees I don't know if thta understanding is solid. Apr 19 18:28:36 Frankly, I don't even know if my spoken / unspoken assertions / assumptions about the function of device trees / OpenFirmware is accurate Apr 19 18:29:11 since it's the kernel's memory, I think. I remember attempting to compile in the patches from https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=commitdiff;h=fb55b3a5ef067ef8b17f142bcb4b04cdb7befb13 and failing. Apr 19 18:29:25 well, I think I got that memory_accessor working, otherwise I wouldn't see the SFP type + SN I think? Apr 19 18:29:26 for exactly the reason you'd found, the hacks present in the kernel have since disappeared Apr 19 18:29:48 That's just i2c provided by your new dts from b44df9861a Apr 19 18:31:15 I do believe we had a similar issue for reading MAC addresses of wireless device Apr 19 18:31:26 if I'm not mistaken, and I probably am, but ... the issue was that the VSC PHY was not able to handle, as other PHYs were, the passthrough of ... well. Something to do with EEPROM. And even that part doesn't make sense, what EEPROM if not for that exposed already by i2c? Apr 19 18:31:51 and I believe the proposed solution was finalized and accepted Apr 19 18:31:52 And I'll even add: I set up sensors-detect on OpenWrt and did *not* get as far as you did, probably for lack of having b44df961a Apr 19 18:32:11 b44df961a ? Apr 19 18:32:16 what tree am I looking at :) Apr 19 18:32:19 https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=commitdiff;h=b44df9861ae175c77545a851317896cc126d79be Apr 19 18:32:30 "as far as" -> https://gist.githubusercontent.com/stintel/8f59e32b10f6aaae0a3fcb173f23f432/raw/d60b2e0a3df2221d3fbc36032120beaac8c61208/sensors Apr 19 18:32:36 ahh, b44df961a is ambiguous Apr 19 18:32:54 My sensors-detect on top of 5.4 did not catch any of this even if i2c-detect scanned and showed me some info. Apr 19 18:33:01 sensors-detect should not be needed Apr 19 18:33:18 The point is that sensors showed nothing, and adding sensors-detect to show more things did nothing. Apr 19 18:33:20 that's just to generate modprobe.conf or something Apr 19 18:33:34 So it could be user error, kernel 5.4 -> 5.10, *or* that commit Apr 19 18:33:56 I added kmod-hwmon-tmp421 (just enabled all kmod-hwmon-* then checked result) Apr 19 18:34:06 so that's how I found that tmp421 shows the octeon temp Apr 19 18:34:13 Oh, that would probably be it, then! Apr 19 18:34:19 and those SFP details come from adding that stuff to the DTS yes Apr 19 18:34:44 but I think the main issue now is the vsc848x driver Apr 19 18:35:26 stintel: Can you start spinning this into an issue tracker somewhere? I really want to work with you on this but really also must get back to work ;( Apr 19 18:37:03 ok. preference for gitlab github gitea or something else or doesn't matter ? Apr 19 18:37:46 If they're all equal choices, gitlab, and the main one. But if you have any preference, I've used all of them. Apr 19 18:38:27 s#the main one#https://gitlab.com# Apr 19 18:38:35 well I'm not a fan of gitlab because UI/UX is pretty poor imo but I don't mind Apr 19 18:38:50 No problem, Github works Apr 19 18:39:44 PM me a link and I'll get back to this when it's appropriate :^) Apr 19 18:39:49 alright Apr 19 18:40:28 It's been a few months but I think ... when I found that phy_driver stuff was missing, I walked through a chain of commits about at24-compatible EEPROM Apr 19 18:40:39 and how that had been moved to using the nvmem framework Apr 19 18:41:37 Specifically because I thought that the patch that creates the OF_MEMORY_ACCESSOR symbol -- this one: "https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=blob;f=target/linux/octeon/patches-5.10/800-of-Add-of_memory_accessor-to-map-device-tree-node-to.patch;h=b6fc10e7473780aac989e59d158bff183d0c0225;hb=fb55b3a5ef067ef8b17f142bcb4b04cdb7befb13" -- that patch was using some of that stuff Apr 19 18:41:39 and I wanted to see if I could get rid of it with newer kernel stuf Apr 19 18:41:50 a bad idea seeing as I don't know how to write kernel code. Apr 19 18:42:32 If you haven't already seen it, all of this is in the yocto apaliwal/octeon tree here: https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=apaliwal/octeon Apr 19 18:42:38 you probably did already see it but :shrug: Apr 19 18:43:23 ah yeah, reading through the forum post again I found that Apr 19 18:43:25 Looking at an issue tracker will straighten my brain and help shake out the details, specifically and importantly, whether I am thinking about phy_driver or something else that didn't compile. Apr 19 18:43:27 but it's all pretty old Apr 19 18:43:46 That's the only VSC848X code that exists that I've found :P Apr 19 18:43:59 other than Wind River Linux 5 stuff, which I wasn't able to clone down but did find references to Apr 19 18:44:45 That's where, notably, the aforementioned patches, also on git.laboratoryb.org/hurricos/snic10e*, came from Apr 19 18:44:57 Oh, hey! Apr 19 18:45:30 I found my compiler error log, I wasn't thinking about phy_driver, but about the memory_accessor stuff from https://paste.c-net.org/TippinStiffs Apr 19 18:46:43 yeah I managed to fix that, both the memory_accessor, hooking it into at24 and the vsc848x driver compile now Apr 19 18:46:49 Anyways, that's from a post in February, months ago. And oh yes, you've fixed it! :D Apr 19 18:46:58 See, this is why we need an issue tracker. :^) poke poke Apr 19 18:47:09 I forked openwrt in gitlab to my personal account and gave you dev access Apr 19 18:47:19 that should allow you to create and edit wiki pages, branches, etc Apr 19 18:47:38 Ah thank you stintel. If only you'd found the post months ago, you'd have saved me from a month of depression and nearly throwing away my entire CN6640 stockpile Apr 19 18:47:46 the only reason I still have it was because I've been too lazy to go to the dump. Apr 19 18:47:51 :D Apr 19 18:49:29 heh :) Apr 19 18:49:51 maybe I should have contacted you earlier, it's been a while since I found your post Apr 19 18:49:52 Thank you, I've put eyeballs on it in gitlab and can confirm. I'll be back on this in a few hours :^) Apr 19 18:50:13 No worries, it's not your job to save other people from drowning in useless hardware Apr 19 18:51:26 After all, the most empowering thing here is you can make something useful out of what I left unfinished. And that has made my day Apr 19 19:02:50 hurricos: started basic documentation on https://gitlab.com/stintel/openwrt/-/wikis/Cavium-SNIC10E Apr 19 20:13:34 We loose about 1-2% of routers "sysupgrade -n" that we do when we upgrade about 5k routers. Is there some recommendation of things to do before running a sysupgrade? Should I reboot, clear some cache, ram etc that might make things unstable? Apr 19 20:16:02 sysupgrade already stops most userspace apps and drops caches Apr 19 20:16:26 the problem is that you can't really see what goes wrong anymore, I had some idea to improve that but never got around to working on that :( Apr 19 20:20:40 :/, sounds like a hard one. I guess Ill try to add a reboot before running sysupgrade just in case. Or do you think thats just not going to help at all? Apr 19 20:21:38 it might, guess it depends on the actual cause Apr 19 20:22:02 Right now my recovery image is giving a webpage on 192.168.1.1 to upload a new image (made by the router manufacturer). Wouldn't that be possible to change so that when you enter recovery it would do DHCP on WAN, download the image from our webservers and flash directly? Apr 19 20:22:26 At least I would give the customers a way to recover without needing to send the router back to us **** BEGIN LOGGING AT Mon Apr 19 21:08:15 2021 Apr 19 21:24:58 stintel: ping Apr 19 21:28:12 stintel: for mdio_driver you need to put the compatibles in mdio_driver.mdiodrv.driver. It appears to be the same for phy_driver Apr 19 21:43:20 svanheule: my hero :) Apr 19 21:43:44 stintel: ^_^ Apr 19 21:45:18 plntyk: https://forums.sifive.com/t/update-on-hifive-unmatched-availability-in-eu-almost-there/4634 Apr 19 21:45:35 barhom: without more background about the exact setup that's hard to tell Apr 19 21:45:55 * stintel looks for phy_driver.phydrv Apr 19 21:46:13 svanheule: if that works I'm going to owe you even more beers :P Apr 19 21:46:37 stintel: whenever you have a chance to get back to BE ;-) Apr 19 21:47:08 October the latest. celebrated my birthday in Bulgaria 2 years in a row, now it's time for Belgium again :) Apr 19 22:07:52 svanheule: ow yeah, it compiled at least :P Apr 19 22:09:14 but something is terribly wrong Apr 19 22:09:15 hahaha Apr 19 22:11:48 https://gist.github.com/stintel/430a190d7e317e9c35fe34f1255b1432 Apr 19 22:13:02 now all those missing symbols don't really make sense ... maybe the build is just hosed Apr 19 22:18:55 yeah did a clean build and not seeing that anymore Apr 19 22:20:31 still doesn't seem to detect anything though Apr 19 22:24:54 stintel, can I flash the recovery partition from a running system or does it need to be completely reflashed? I know its a dangerous operation Apr 19 22:27:20 I don't have experience with recovery partitions really Apr 19 22:30:17 I meant the uboot partition, I guess it's the same thing Apr 19 22:33:49 oh, never touched that on any device Apr 19 22:39:34 I ought to enrich my English expletive vocabulary in order to adequately express the full extent of my hatred for my ISP's router. Apr 19 22:41:41 How, in any part of the know (or unknown) universe, would someone think it would be a good idea to enable UPnP by default… Apr 19 22:41:58 … without giving the user *any possibility at all* to disable it? Apr 19 22:46:02 Sure, power users just set the sodding thing to to bridged mode, and use a real router, but… sweet baby Jesus, why?! Apr 19 22:50:05 rsalvaterra, because 95% of the users like things to just work and ISPs want less phone calls to their customer support (even if it might be a security issue). But yes, the ability to not let you disable it is weird Apr 19 22:58:49 I have a file I crosscompile that includes openssl/sha.h, since we switched to wolfssl that file cannot be found obviously. I tried including wolfssl/sha.h instead but no go. Any ideas? Apr 20 02:53:36 need help with review: https://github.com/openwrt/openwrt/pull/4070 **** ENDING LOGGING AT Tue Apr 20 02:59:56 2021