**** BEGIN LOGGING AT Wed Jul 10 03:01:22 2019 Jul 10 06:27:59 blogic: ping - any suggestions about this? https://github.com/981213/openwrt/commit/fcb6b3cc528c52bd56420bff25d0bf0ff4ebba41 Jul 10 06:29:01 gch981213: lets have a look Jul 10 06:31:02 gch981213: looks good, please also send it to the linux-mips list Jul 10 06:31:47 oh and feel free to push it, you can do that yourself nowdays :) Jul 10 06:32:52 blogic: Thanks. I'll send it to linux-mips after the cpu clock patchset is applied. Jul 10 06:58:36 gch981213: please copy your nice description from commit message to the patch body Jul 10 06:58:48 gch981213: so it's easy to understand that patch later if needed Jul 10 06:59:46 gch981213: otherwise I'd just replace "m" with "M" or "Mi", but it's cosmetical and just me being nerdy Jul 10 07:13:46 gch981213: Great to see that you are working on mt7621 stuff again. I saw also your clock patches. Jul 10 07:15:24 gch981213: also intressed in mt7621 NAND driver development? Jul 10 07:28:23 <_abc_> Hello, to add usb support to any of the tiny ar71xx/ath79 targets which have usb hw, does one need to recompile the kernel or not? In 14.01 times the kernel had to be rebuilt for this. Has this changed? Tia. Jul 10 08:01:57 rmilecki: Thanks. will do so. Jul 10 08:03:20 Rene__: There are a lot for me to learn before I could do anything for that nand driver :P Jul 10 08:06:42 <_abc_> I assume this is what I need to follow, correct? https://openwrt.org/docs/guide-user/additional-software/extroot_configuration Jul 10 08:07:05 <_abc_> There are several rather conflicting howtos some are in the forums. I assume what I linked is the "right" one? Jul 10 08:08:47 _abc_: You don't need to rebuild the kernel, you just need to install usb driver and filesystem support. But I doubt if it's even possible to fit all these stuff into a 4M flash. Jul 10 08:09:06 <_abc_> One will renounce some other unused packages and edit the image for that gch981213 Jul 10 08:09:12 <_abc_> s/one/I/ Jul 10 08:13:20 <_abc_> In 14.07 the usb subsystem had to be enabled in the build to work since vanilla ar71xx/ath79 images ommitted this completely, to save maybe 1 kbyte or so. I.e. the stubs layer in the kernel which interacts with usb Jul 10 08:13:51 <_abc_> The latter being loaded as modules in such tight devices. So one does have to recompile afaik gch981213 Jul 10 08:16:25 <_abc_> Is still have a hw modded tl-wr741n where someone nicely built a custom 14.07 image way back when and put it in the forums years ago. That is a good example for this kind of work. Jul 10 08:18:23 <_abc_> Perhaps his rebuild was needed because of the hw mod, the oem router has no usb, it involves soldering wires inside. Jul 10 08:27:51 gch981213: blocktrron: FYI I've just bumped your user status on bugs.opewrt.org, could you please check? Jul 10 08:40:20 ynezz: Got it. Thanks. Jul 10 08:45:03 gch981213: ok :) Jul 10 09:35:21 ynezz:thanks, will check later Jul 10 10:26:56 gch981213: those cpu clock patches 1/2 and 2/5 should probably have proper author set, Author: Weijie Gao Jul 10 10:28:27 now it just looks, that you've authored them, Signed-off-by: Weijie Gao is probably not enough (I didn't diffed the files, but looking quickly at those patches it seems like mostly hackpascal's work) Jul 10 10:30:28 gch981213: "Is it correct to send the entire patchset to lists of all involved subsystems", I think yes, otherwise they're going to scream at you, I usually stick to what get_maintainer.pl returns, have following setup https://www.marcusfolkesson.se/blog/get_maintainers-and-git-send-email Jul 10 10:51:54 ldir: thank you for the kmod-sched* fix, "worksforme" Jul 10 11:49:24 Hi. I just read through the minutes and sounds like a very interesting meeting. If there any interest or need, I would like to help out with firewall4 Jul 10 11:54:54 kristrev: you had tha unilec mt7623 board right ? Jul 10 11:54:59 *that Jul 10 11:55:08 blogic: Yup, it is here somewhere Jul 10 11:55:23 ok, I have an update to v4.19 for the target Jul 10 11:55:34 once its in my staging, could you test it on mt7623 ? Jul 10 11:55:41 Great, I can take it for a spin Jul 10 11:55:42 i only have mt7622 and mt7629 here right now Jul 10 11:55:45 Yes, sure, just let me know Jul 10 11:55:52 cool, i'll shot you an email when its done Jul 10 11:55:58 Oh, interesting, mt7622 is the one that is getting a lot of attention upstream now? Jul 10 11:56:29 right Jul 10 11:56:58 Seems like a nice replacement for mt7621 Jul 10 11:57:37 http://www.banana-pi.org/r64.html Jul 10 11:57:45 Perhaps it is soon time to expand my Mediatek-horizon Jul 10 11:57:47 Thanks! Jul 10 11:57:49 there is a R2 of this with the new switch silicon mt7531 Jul 10 11:58:08 fedex should deliver the R2 prototype tomorrow Jul 10 11:58:16 I have the tree ready incl the new switch driver Jul 10 11:58:28 cool Jul 10 11:58:32 and while at it, i'll bump to v4.19 ;) Jul 10 11:59:15 I am curios if Mediatek has updated their USB-controlles. The one on 7621/7623 only has 16 endpoints (or something like), making connecting multiple LTE-modems a bit of a challenge ... Jul 10 11:59:46 yeah Jul 10 12:00:00 i think mt7622 has the one used in the androids Jul 10 12:00:06 so its a new one Jul 10 12:00:18 I will order the board and try, I guess that is the easiest way :) Jul 10 12:00:43 kristrev: dont Jul 10 12:00:48 that is the one with RTL switch Jul 10 12:01:02 we dont have a driver, wait a month and get the R2 version when it is online Jul 10 12:01:25 Do you know if 4.19 supports the OTG port on 7623? I see that there has been some activity upstream related to OTG and Mediatek, but I havent been able to figure out if the work will also benefit mt7623 Jul 10 12:01:32 I am getting one of the first verification production batch, so if all goes well it should be in mass production and online really soon Jul 10 12:01:41 no idea, sorry Jul 10 12:01:50 Ok, then I will try and see Jul 10 12:01:55 kristrev: the plan for firewall4 is to have an executable which parses the current /etc/config/firewall uci (sans the iptables specific "option exta" stuff) and generates nft for it Jul 10 12:02:12 Or try to boot linux-next or something and see how it goes Jul 10 12:02:25 blogic: Thanks, I will wait then Jul 10 12:02:29 kristrev: preferably in C. Not sure if it is as simple as "just" copying firewall3.git and replace xtables backend ops with printfs or we need to revise the ruile architecture Jul 10 12:02:58 didn't look into nft at all yet, all I know is that it uses curly braces Jul 10 12:03:31 :-) Jul 10 12:04:19 jow: Thanks for letting me know. If I remember correctly, the netfiler-devs have spent lots of time implementing a translator from iptables-rules to nftables Jul 10 12:04:38 yeah but that'd be a transitional solution at best Jul 10 12:05:02 Perhaps "just" translating todays rules to nftables could be the first step, and then start adding proper support Jul 10 12:05:05 Agree Jul 10 12:06:27 I took a look at nftables + firewall3 some time ago, just for fun, and played around with concept of having a backend variable that would either be "iptables" or "nftables". I got something working, but the code looks like a car-wreck and I have forgot most of the details Jul 10 12:06:37 transitional workarounds have a nasty habit of becoming permanent IMHO Jul 10 12:07:01 Unless anyone beats me to it, I can try to create a minimal nftables backend Jul 10 12:07:07 that'd be great Jul 10 12:07:09 Indeed, permanent hacks :) Jul 10 12:07:23 and don't bother putting it into fw3 / keeping it compatible Jul 10 12:07:28 simpyl fork and do what needs to be done Jul 10 12:07:46 I'd start with a simple nft stdout backend which produces stuff suitable to be piped to nft Jul 10 12:07:57 ynezz: That's hackpascal's work indeed. I only did some code style fixes. I asked him if I could send the patches as what I've done so far, but neither of us thought about the authorship problem :P Jul 10 12:08:12 later we can examine the nft cli and see what needs to be done to invoke the internal parser Jul 10 12:10:03 also I think I've read somewhere that nft more or less integrates ipsets by default Jul 10 12:10:27 so maybe we can also get rid of dynamic rules (nat reflection, interface and subnet selection rules) and replace those with placeholder ipsets Jul 10 12:10:44 so we have one static ruleset describing the zone structure and zone policies Jul 10 12:11:08 and only have to care about populating the per-zone ipsets identifying incoming/outgoing interfaces, subnets etc. Jul 10 12:11:19 but that'd be a step 2 optimization imo Jul 10 12:12:19 once we do have such a more or less static ruleset we can further think about turing that into an editable template Jul 10 12:12:35 ... instead of hardcoded rules in some C executable Jul 10 12:12:56 that'd be step 3 then, I guess Jul 10 12:16:39 sounds good Jul 10 12:17:29 My plan would be something like: 1) Mirror what we have today with nftables, starting with just getting the "default" rules correct 2) Look into the cool stuff offered by nftables and optimize Jul 10 12:17:40 right, I agree Jul 10 12:18:07 is there some way to take the current iptables-save output, translate that into nft using some magic util, thne cleanup and decompose the generated nft ruleset? Jul 10 12:18:56 jow: i think there was a way to do so Jul 10 12:19:05 however you dont get optimal nft code that way Jul 10 12:19:19 https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables Jul 10 12:19:24 right, thats what I was suspecting Jul 10 12:19:29 kristrev: just seen that page as well Jul 10 12:19:33 hehe Jul 10 12:19:43 they have example of save + translate Jul 10 12:19:51 jow: i cant recall the details but nft offers new features that you want to leverage and converting old->new want do that Jul 10 12:20:10 blogic: yes, I know - but need to get a feeling for the overwall structure first Jul 10 12:20:16 sure Jul 10 12:20:24 in that case it makes sense to go that route Jul 10 12:20:28 the fundamental zone model with source-bound policies will remain even with nft Jul 10 12:20:33 correct Jul 10 12:20:45 2017 i wrote that Jul 10 12:20:51 2009 Jul 10 12:20:52 sorry Jul 10 12:21:06 one of the first things i did for FON ;) Jul 10 12:21:18 centos' firewalld works quite similar which is somewhat reassuring Jul 10 12:21:34 or redhats firewalld rather Jul 10 12:22:59 one big optimization potential I see with nft is the ability to factor out all variable bits of the ruleset (-i, -o, -s, -d in iptables terms) Jul 10 12:23:10 yep Jul 10 12:23:11 factor out in the form of ipsets Jul 10 12:23:55 which makes the effort to classify a stream into a zone O(1) in contrast to the O(n_interfaces) we have right now Jul 10 12:24:36 one could do that with iptables right now as well (when we start to require ipset) but why bother when nft is around the corner anyway Jul 10 12:24:37 I see how you can add s/d to an ipset, but I guess i/o might be hard Jul 10 12:24:56 Unless nftables sets has some extract features, which they might very well do :) Jul 10 12:25:02 kristrev: why? iirc netdev ipsets are supported since a while Jul 10 12:25:45 for my own education, how big does n_interfaces really get? I mean, I understand ipsets when you have huge lists of ips you want to white/black/grey list, but for interfaces? Jul 10 12:26:24 karlp: in the worst case at least as big as the amount of zones Jul 10 12:26:30 Indeed, mine vote for nft too for the future plan :) Jul 10 12:26:40 jow: Indeed, I had missed the hash:net,iface type Jul 10 12:27:23 But it seems we still need to attach a net to an iface. Or, at least last time I tried, 0.0.0.0/0 was not allowed in hash net types Jul 10 12:27:50 okay, I wasn't aware of that Jul 10 12:29:26 Looking at the source, it seems that 0.0.0.0/0 is allowed for net,iface. I at least can't find the check that is in for example hash:net Jul 10 12:29:29 Which makes sense, I guess Jul 10 12:30:10 it seems to work in practise as well: https://pastebin.com/7zALLwHi Jul 10 12:30:15 Ok. So Step 1: Get what we have today working, Step 2: Make use of sets for variables, Step 3: Other cool stuff Jul 10 12:30:34 nice Jul 10 12:31:54 kristrev: actually the worst-case effort is O(n_zones * n_interfaces) and it can be optimized to O(n_zones) Jul 10 12:31:58 sorry, karlp ^ Jul 10 12:32:41 you still need some if match-set-1 goto lan, if match-set-2 goto wan, if match-set-3 goto guest etc. Jul 10 12:33:17 what's a common figure for zones? Jul 10 12:33:30 like 10s? or 1000s? Jul 10 12:33:36 I think 10s Jul 10 12:34:25 the optimization is not about the matching effort alone though, the other advantage of sets is that you do not need to frequently rebuild/patch/update the ruleset with each ifup/ifdown anymore Jul 10 12:34:43 indeed, taht sounds like a bigger gain. Jul 10 12:35:53 and we can probably inline a few rules and reduce the amount of chains required Jul 10 12:36:03 e.g. the delegate_* chains would probably go away Jul 10 12:36:13 I remember that my main motivation for trying nftables last time was that could can do multiple things with one statement. So it is possible to set a mark and then ACCEPT, for example. No need for two rules Jul 10 12:36:52 or the zone_XXX_{src,dest}_{ACCEPT,REJECT,DROP} chains could be inlined into single rules using set matches Jul 10 12:38:12 It probably won't affect firewall4 much, but one of my favorite things about nftables is that you can write rules that affect IPv4 and IPv6 at the same time, which significantly reduces the number of rules on my homebrew Linux router. Jul 10 12:39:04 mamarley: I think it could affect fw4 a lot since it now essentially duplicates the ruleset (minus postrouting rules - these are restricted to ipv4) Jul 10 12:39:34 Oh, cool! Jul 10 12:39:54 In broad general I have got the feeling too that nft eases things up in many ways.. ofcourse helluva diffirent thing to make it sit on openwrt code nicely :D Jul 10 12:40:10 I've been using ferm for dual-stack firewalls. it already does the "rules that affect both families" thing Jul 10 12:40:37 Dagger: so does fw3, by translating the same abstract rules into iptables and ip6tabgles equivalents Jul 10 12:40:55 with nft these would be single rules again (as long as no addresses of a particular family are involved) Jul 10 12:41:01 (not sure about multiple targets) Jul 10 12:41:39 I was about to say that this already works on openwrt, for pile of years... because jow and many others has done the hard work :P Jul 10 12:42:22 mixed address families works in ferm Jul 10 12:43:16 they do work in fw3 as well Jul 10 12:43:32 list src_ip 1.2.3.4; list src_ip fdca::123 Jul 10 12:43:40 one rule ends up in ipt, one in ip6t Jul 10 12:48:09 in ferm it's something like "saddr (1.2.3.4 fdca::123) proto (tcp udp) port 53 accept;" (which would expand to 4 rules; one per proto for each IP, in either iptables/ip6tables as appropriate) Jul 10 12:50:59 its the sme in fw3 (just in more verbose uci syntax) Jul 10 13:14:40 whats this? https://openwrt.io/ Jul 10 13:16:18 looks like a blog of some sort Jul 10 13:24:03 aparcar[m]: A hobbist making random development guides, I guess? Jul 10 13:26:05 DonkeyHotei: gch981213 thanks Jul 10 14:31:53 hi Jul 10 14:33:20 stumbled upon unusual register in qca code: (0xcffc10u) Jul 10 14:33:55 anyone has an idea what does this u stand for? Jul 10 14:34:12 psyborg: unsigned Jul 10 14:35:59 psyborg: That's just the way of declaring a unsigned integer literal in C Jul 10 14:37:52 ok, thanks for confirmation. i thought it might be unsigned, just never seen it declared that way Jul 10 15:59:36 Posting following here .. in case somebody with more brains has an idea :) (mac80211 splats) Jul 10 15:59:37 https://pastebin.com/raw/NgG1SHK4 Jul 10 15:59:55 these have been around for a few years already .. Jul 10 18:27:13 gch981213: https://github.com/openwrt/openwrt/pull/2220 what does this do? Jul 10 19:43:30 I'm still thinking about the ssb bus of my BCM53312. For some reason the bus scan isn't working, so the only idea I have is to map the cores statically. Any better ideas? Jul 10 19:44:07 The static core map ideas comes from this source code https://github.com/fvollmer/ecos-2.0-GS108Tv2/blob/master/packages/hal/mips/bcm953710/v2_0/src/sbutils.c (from netgear) Jul 10 19:48:53 ugh Jul 10 19:52:40 The strange thing is that SSB_IDHIGH always returns 0, but I can read the SSB_CHIPCO_CHIPID (https://elixir.bootlin.com/linux/v5.2/source/drivers/bcma/scan.c) Jul 10 19:53:35 I officially hate OpenWrt tarballs Jul 10 19:54:12 So matching with the ecos sources there is a Chipcommon, but I can't read the ids. Jul 10 20:44:30 @magix: #2220 probes the size of the DDR memory installed on the board by checking at which point a test-pattern repeats Jul 10 20:45:34 this would allow for removing that information from device-tree and no longer create separate images for devices having variants with different DRAM size Jul 10 20:48:32 ah ok. it made it sound like a bug fix for 512MB units Jul 10 20:50:51 I'm trying to understand the ssb bus better and found this page: https://bcm-v4.sipsolutions.net/Backplane/index.html#BAS0. It states the cores start at 0x18000000. For some reason the linux kernel appears to use the offset of 0xb8000000. Where does this come from? Jul 10 20:51:36 I actually tried readl(0x18000000 + 0x0FFC), but it just crashes, so there appears to be a valid reason for the 0xb8000000 offset Jul 10 20:55:14 someoner: it's a mips thing, 0x8000000~0x9ffffffff and 0xa0000000~0xbfffffff (both virtual addresses) are fixed mappings to the physical addresses 0x00000000~0x1fffffff Jul 10 20:55:26 the former cached, the latter uncached Jul 10 20:56:23 thanks! Jul 10 20:57:44 I've just compiled snapshot with luci and flashed and I get "TypeError: Cannot read property 'url' of undefined" in the web interface, cannot log in. is this a bug or something i configured wrong? Jul 10 20:58:34 I had it working at some point, but I had to recompile again because I forgot firmware, and I can't get it back working again Jul 10 21:03:14 Oh I think I found the problem. I must have updated the feed because I see a commit last night around when I was playing with it Jul 10 22:23:24 someoner: i don't think static list of core will get you anywhere Jul 10 22:23:33 someoner: AFAIR your SSB_CHIPCO_CHIPID value seemed fishy Jul 10 22:23:47 and some other important registers were 0 Jul 10 22:23:53 I think there is some missing bus setup Jul 10 22:24:22 I think you could be right. I did some more testing: Jul 10 22:26:20 I thought I try to access the statically defined cores from the ecos sources. e.g. printk("core id low: 0x%x", readl(0xa0000000 + 0x18005000 + 0x0FF8)); (should be the "mips" core). Jul 10 22:27:04 This just lead to an exception (BusErrD) Jul 10 22:30:21 someoner: that sbutils.c looks interesting I give you that Jul 10 22:30:47 I'm currently still trying to understand the initialization at the ecos sources. At the moment it looks like it starts here: https://github.com/fvollmer/ecos-2.0-GS108Tv2/blob/master/packages/hal/mips/bcm953710/v2_0/src/plf_misc.c#L106 and then the next interesting thing is here: https://github.com/fvollmer/ecos-2.0-GS108Tv2/blob/master/packages/ha Jul 10 22:30:47 l/mips/bcm947xx/v2_0/src/sbmips.c#L457 Jul 10 22:32:27 ups, the last link with the initialization should be this: https://github.com/fvollmer/ecos-2.0-GS108Tv2/blob/master/packages/hal/mips/bcm953710/v2_0/src/sbmips.c#L385 Jul 10 22:33:53 there are some suspicious looking lines with different indentation (ag"/* Chip specific initialization */"). Maybe I should take a closer look at those. Jul 10 22:34:53 hal_platform_init() seems like an init point for Broadcom's board Jul 10 22:44:06 yep, that is what I thought, but there has to be some initialization somewhere else. sb_mips_init mentiones: "SB and NVRAM access must be initialized prior to calling." Jul 10 22:50:51 I should probably checkout the bcm47xx hal package. It looks like netgear used the bcm47xx hal and bcm953710 hal package together (https://github.com/fvollmer/ecos-2.0-GS108Tv2/blob/master/mips_raptor_netgear.ecc#L56) Jul 10 22:52:12 nevermind the bcm47xx hal package is nearly empty Jul 10 23:34:21 Is 'Matthias Schiffer' here? Jul 10 23:47:22 i just soft-bricked a device due to a missing wget exit code check in sysupgrade :/ Jul 10 23:47:52 potential fix: https://pb.nanl.de/show.php?id=44738 Jul 11 00:38:34 dumb question… my env/kernel-config contains a CONFIG_FOOBAR=m but that's not turning up in my generated linux-4.1.19/.config … what are the steps to figure out why? (i.e. missing dependencies, etc?) is this documented anywhere? Jul 11 00:43:18 is your env activated? **** ENDING LOGGING AT Thu Jul 11 03:01:20 2019