**** BEGIN LOGGING AT Sun Jan 20 02:59:57 2019
Jan 20 08:32:57 <Borromini> _lore_: ping
Jan 20 09:32:07 <_lore_> Borromini: pong
Jan 20 09:34:20 <Borromini> _lore_: hi. i cloned the mt76 repo and am on the openwrt-18.06 branch but it doesn't seem to match what nbd committed
Jan 20 09:35:42 <Borromini> to openwrt i mean. grepping the mt76 git log for the last commits on the openwrt 18.06 branch doesn't return them
Jan 20 09:37:50 <_lore_> what do you mean? were you using openwrt 28.06 before?
Jan 20 09:37:59 <Borromini> yeah i'm on 18.06 head
Jan 20 09:40:53 <Borromini> https://paste.debian.net/1061476/ < this is mt76 18.O6 branch
Jan 20 09:41:34 <Borromini> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=f34ad1a8f0d1ee4a3e4b966d58c8f3b8a523a417 < the commit log in openwrt 18.06 doesn't match that
Jan 20 09:42:39 <Borromini> is there a way to show which branch a commit is part of?
Jan 20 09:42:56 <Borromini> git show $hash shows me the commit but i can't see what branch it was applied to.
Jan 20 09:43:43 <Borromini> it seems like stuff was pulled from mt76 master for this openwrt 18.06 push
Jan 20 09:44:09 <_lore_> awfk for a while, brb
Jan 20 09:44:25 <Borromini> np.
Jan 20 09:55:56 <KanjiMonster> Borromini: git branch --contains $hash
Jan 20 10:03:16 <Borromini> KanjiMonster: thanks.
Jan 20 10:09:40 <Borromini> all master stuff, it turns out.
Jan 20 10:25:32 <KanjiMonster> Borromini: the switch to master happened in https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=514ad059ef40b747c93c363403cb49b45dd86e41 and was intentional it seems
Jan 20 10:28:46 <Borromini> KanjiMonster: good catch, thanks. will have to look there
Jan 20 10:29:00 <Borromini> just the latest mt76 bump on 18.06 that broke it
Jan 20 10:36:05 <ldir> Borromini: don't know if this helps " git log package/kernel/mt76" will show you every commit that touches a directory/file
Jan 20 10:40:43 <\x> hey guys
Jan 20 10:40:55 <\x> any good usb adapters i can put on my AP ?
Jan 20 10:41:08 <\x> like another AC 5ghz channel on it?
Jan 20 10:41:40 <\x> i think 1x1 AC will fit as its 433Mbps, usb2 is 480 Mbps aight?
Jan 20 10:43:06 <Borromini> ldir: thanks, but i know which bump caused it
Jan 20 10:43:10 <\x> Borromini: what mt76 device do you own?
Jan 20 10:43:39 <Borromini> as in: which openwrt bump. the thing is, which upstream mt76 commit is causing my issues
Jan 20 10:43:50 <Borromini> \x: dir-860l
Jan 20 10:44:32 <\x> oh
Jan 20 10:44:41 <\x> that form factor is interesting
Jan 20 10:45:41 <Borromini> very happy with it but only using the 5 GHz radio
Jan 20 10:45:49 <\x> Borromini: love the dual core aye?
Jan 20 10:45:54 <Borromini> only b1 is supported (and mt7621 probably)
Jan 20 10:46:10 <Borromini> yeah, but it's still MIPS if you're looking for a powerful CPU
Jan 20 10:46:12 <\x> i have this
Jan 20 10:46:13 <\x> https://openwrt.org/toh/hwdata/youhua/youhua_wr1200js
Jan 20 10:46:22 <\x> we are about the same
Jan 20 10:46:34 <\x> minus the usb 3.0 which might be a curse on 2.4ghz
Jan 20 11:00:59 <ldir> Borromini: ahh I see - consider CONFIG_SRC_TREE_OVERRIDE and point your mt76 package at a local mt76 git repo, then you can bisect within that mt76 repo (building & booting your test image each time) to find which mt76 commit introduced the issue.
Jan 20 11:01:44 <Borromini> ldir: thanks for the tip. i will be building the single mt76 package, it would be a bit madness to compile a new firmware for that every time
Jan 20 11:02:23 <_lore_> Borromini: I am back
Jan 20 11:03:15 <Borromini> _lore_: KanjiMonster pointed me to an openwrt 18.06 commit switching it to master mt76 upstream
Jan 20 11:03:19 <Borromini> so i'll start from there
Jan 20 11:03:54 <ldir> Borromini: yeah I guess you should be able to just rebuild the module and do that.
Jan 20 11:04:39 <ldir> Borromini: I'm not very good with the 'just update the package' thing.... I tend to just flash whole images.... like nuking from orbit, it's the only way to be sure :-)
Jan 20 11:04:44 <Borromini> ;)
Jan 20 11:06:46 <ldir> if you use SRC_TREE_OVERRIDE you don't have to mess about with updating Makefiles with souce commits, though I recommend make package/foo/clean ; make package/foo/compile V=s
Jan 20 11:07:19 <_lore_> Borromini: ok, thx for testing
Jan 20 11:11:45 <Borromini> ldir: good point. i'm totally new to bisecting, so...
Jan 20 11:12:40 <_lore_> Borromini: please skip mt7603 commits
Jan 20 11:12:52 <_lore_> just mt76/mt76x2
Jan 20 11:14:45 <Borromini> _lore_: gotcha
Jan 20 11:25:35 <rmilecki> jow: did you say ThreadX? that's what Broadcom uses as well I think
Jan 20 11:30:51 <jow> rmilecki: well I'm still watching that marvell firmware vulnerability story to unfold
Jan 20 11:31:01 <rmilecki> me too
Jan 20 11:31:13 <jow> so no idea if there's anything in common apart form the name
Jan 20 11:31:17 <rmilecki> I also don't expect Broadcom to release any fix (assuming its affected) in next months
Jan 20 11:42:52 <Tapper> jow didn't  marvell  lay off a load of people just a month or 2 ago?
Jan 20 11:43:24 <Tapper> That mite meen we will wate even longer!
Jan 20 11:44:55 <Tapper> In the last weeks the github for that marvell  driver has bin quiet.
Jan 20 11:45:54 <\x> kek
Jan 20 11:45:57 <\x> nice vuln
Jan 20 11:46:36 <\x> is this everything on mwlwifi?
Jan 20 11:53:04 <Borromini> ?
Jan 20 11:54:21 <\x> i mean the exploit on that mrvell firmware
Jan 20 11:54:32 <\x> im just reading it now, looks like mostly consoles
Jan 20 11:56:14 <Tapper> We don't know about mwlwifi? because thay use a closed fermwair blob
Jan 20 11:58:06 <KanjiMonster> from the slides: "Vendor notified – 02 May 2018" ... " ZeroNights conference – 21 November 2018" ... "Still fixing"
Jan 20 11:59:31 <KanjiMonster> jow: rmilecki: the slides also says they looked at other firmware files, e.g. pci 88w8997, where the bugs are still present
Jan 20 12:01:59 <KanjiMonster> but different chips have different memory layouts, so (AFAICT) will require uniquely crafted exploits
Jan 20 12:03:59 <\x> still a very nasty exploit
Jan 20 12:04:03 <\x> It doesn’t require any user interaction.
Jan 20 12:04:03 <\x> It can be triggered every 5 minutes in case of GNU/Linux operating system.
Jan 20 12:04:03 <\x> It doesn’t require the knowledge of a Wi-Fi network name or passphrase/key.
Jan 20 12:04:03 <\x> It can be triggered even when a device isn’t connected to any Wi-Fi network, just powered on.
Jan 20 12:04:06 <\x> lmao
Jan 20 12:07:39 <Borromini> ldir: once i enable the source tree override, how do i go about pointing the mt76 makefile to the local repo?
Jan 20 12:09:08 <Borromini> just adjust the PKG_SOURCE_URL I presume
Jan 20 12:15:46 <KanjiMonster> Borromini: add a symlink in the package dir called git-src pointing to the .git directory of the repo
Jan 20 12:15:52 <KanjiMonster> (IIRC)
Jan 20 12:18:48 <KanjiMonster> yep, that was it
Jan 20 12:21:19 <Borromini> already did that. no Makefile modificatin then? :)
Jan 20 12:21:26 <KanjiMonster> corret
Jan 20 12:21:28 <KanjiMonster> *correct
Jan 20 12:21:37 <Borromini> neat.
Jan 20 12:22:53 <KanjiMonster> it will then checkout the current HEAD of the repo pointed to, not copy the contents - so any uncommitted modifications are ignored
Jan 20 12:23:51 <Borromini> ok that's nice
Jan 20 12:24:36 <KanjiMonster> unless you try to fix something and wonder why your recent modifications don't do anything because you forgot to commit them ;)
Jan 20 12:25:54 <Borromini> hehe
Jan 20 12:26:01 <Borromini> git bisect here i come!
Jan 20 12:27:13 <KanjiMonster> mtfbwy
Jan 20 12:30:23 <Borromini> :)
Jan 20 12:33:21 <jow> I tried to start some kind of package policy document here: https://openwrt.org/docs/guide-developer/package-policies
Jan 20 12:34:45 <jow> the scope is not to explain how to package in each detail (will eventually end up elsewhere) but aims to document the informal packagaing requirements that exist today
Jan 20 12:36:47 <Borromini> _lore_: given there have been 109 commits since the last one that's in 18.06, doesn't it make more sense to try the mt76 master head? or should i stick with 6745830 as my head (which is the last commit included in the 18.06 mt76 bump)
Jan 20 12:37:29 <karlp> TIL that src dirs are automatically copied to the destt
Jan 20 12:39:36 <karlp> jow: looks good, perhaps in versioning explain _why_ the data+hash are done? (to make version compare work for updates)instead just "do this"
Jan 20 12:40:14 <karlp> in pkg_revision, you mix up revision and release.
Jan 20 12:41:36 <karlp> nice examples of "things you mightt need to do"
Jan 20 13:06:04 <jow> will fix
Jan 20 14:40:17 <_lore_> Borromini: it is interesting to understand what is the offending commit
Jan 20 14:41:05 <_lore_> have you considered just mt76/mt76x2 commit? you can skip mt7603 ones
Jan 20 14:46:27 <Borromini> _lore_: i won't forget about skipping mt7603 (2,4 GHz right)
Jan 20 14:46:52 <Borromini> but i haven't found how to save the git bisect results (so that it's reflected in the git commit log)
Jan 20 15:02:19 <_lore_> Borromini: what do you mean with 'save'?
Jan 20 15:04:57 <Borromini> well i can point the openwrt buildroot to the git tree but it will only build what's committed, not what's pending
Jan 20 15:05:21 <Borromini> and from what i can see git bisect doesn't commit anything?
Jan 20 15:13:27 <_lore_> I suggest just to update the mt76 pkg with the commits listed in the upgrade, skipping 7603 ones
Jan 20 15:14:19 <Borromini> makes sense, thanks.
Jan 20 15:21:35 <KanjiMonster> Borromini: git bisect points the HEAD to the commit to test, so you only need to rebuild the package
Jan 20 15:22:04 <Borromini> oh. sorry, very new to git bisect.
Jan 20 15:23:02 <KanjiMonster> no worries
Jan 20 15:24:29 <KanjiMonster> basic workflow is to start the bisect, then rebuilt and test the package, then tell git bisect if it works or not (with "git bisect good" or "git bisect bad"), and reiterate until git bisect says this is the offending commit
Jan 20 15:25:52 <KanjiMonster> skipping unrelated commits can be done, but doesn't really significantly reduce test/build time (might be even slower since then you first need to look at the commit to test and decide wether to skip it or not, instead of just rebuilding and testing)
Jan 20 15:29:21 <Borromini> ok
Jan 20 15:46:35 <swalker> jow: find package/feeds/packages/*/patches -type f -not -name "*.patch" | wc -l -> 17
Jan 20 17:10:12 <nbd> Borromini: what issue are you trying to bisect?
Jan 20 17:12:14 <_lore_> nbd: the one related to mcu msg timeout, I guess it is the same reported by stanislaw
Jan 20 17:12:39 <_lore_> on minipcie card
Jan 20 17:14:55 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
**** ENDING LOGGING AT Mon Jan 21 02:59:56 2019