**** BEGIN LOGGING AT Tue Aug 07 03:00:01 2018
Aug 07 03:36:13 <abenz> nbd: can this be applied to 18.06 as well?  https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=2601e34fad9e523b87c310386ba9b7bace4025e2
Aug 07 03:44:04 <abenz> oh its not applicable. I had the same error and thought it might be related
Aug 07 04:04:16 <russell--> nbd: fwiw, linkit 7688 (mt7603e) is still broken in station mode ... i saw someone claim it was working a few weeks ago, not so here. often can't even get dhcp resolution over the link.
Aug 07 04:04:33 <Monkeh> It.. does work
Aug 07 04:04:35 <Monkeh> Sometimes.
Aug 07 04:04:44 <Monkeh> Depending on the AP and a few other things.
Aug 07 04:04:56 <russell--> not here
Aug 07 04:05:31 <russell--> what AP does it work on?
Aug 07 04:05:47 <Monkeh> It works okay with my ath9k APs right up until WDS is used
Aug 07 04:05:59 <Monkeh> It's unusable with the mt7603e AP.
Aug 07 04:06:17 <russell--> most of my radios are ath9k, including the one that it just failed on
Aug 07 04:12:43 <russell--> iwinfo shows: "Tx-Power: 0 dBm"
Aug 07 04:12:49 <russell--> which seems wrong
Aug 07 04:12:59 <russell--> or, possibly explanatory
Aug 07 04:13:32 <russell--> same behavior, connecting to ath9k AP, either open or psk2
Aug 07 04:16:51 <russell--> hmm, proximity seems to help. <1.5m == good ; 5m == seriously flakey
Aug 07 04:17:29 <russell--> scratch "good", convert to "at least gets a dhcp lease"
Aug 07 04:21:36 <russell--> seems happier with a buffalo wzr600dhp, 1.5m away, no packet loss
Aug 07 04:21:51 <russell--> (wzr600dhp is ath9k)
Aug 07 04:24:06 <russell--> tplink wdr3600, no dhcp lease
Aug 07 04:27:04 <russell--> meraki mr24, no dhcp lease
Aug 07 04:29:21 <Monkeh> Mm, mine was working okay sans WDS issues last time I had it up
Aug 07 04:29:32 <Monkeh> Really must get a second one
Aug 07 04:30:45 <russell--> the wdr3600 and meraki mr24 were approximately the same distance as the wzr600dhp
Aug 07 04:31:24 <russell--> which ath9k routers did it work with?
Aug 07 04:31:32 <russell--> (for you)
Aug 07 04:31:39 <Monkeh> HH5As
Aug 07 04:32:08 <DonkeyHotei> i thought hh5a is ath10k
Aug 07 04:32:20 <Monkeh> Not at 2.4GHz it's not.
Aug 07 06:49:30 <Sagi> https://www.kb.cert.org/vuls/id/962459
Aug 07 06:49:50 <Sagi> this probably works on 17.01.5
Aug 07 06:50:17 <Sagi> or on 18.06.0 for that matter.
Aug 07 06:53:32 <SwedeMike> Sagi: 17.01.x doesn't run 4.9+ kernels, right?
Aug 07 06:53:33 <KanjiMonster> Sagi: 17.01 uses kernel 4.4, the page says 4.9+, so 17.01 should be unaffected. 18.06 uses 4.9 / 4.14 though
Aug 07 06:54:13 <Sagi> ah good point
Aug 07 06:55:03 <SwedeMike> Sagi: so we'd need to figure out when mainline fixed this to see if 18.06 is vulnerable
Aug 07 06:57:14 <Sagi> I think the linked commit made it into either the latest or latest-1 stable series.
Aug 07 07:02:49 <KanjiMonster> 4.9.116 and 4.14.59 contain the appropriate fixes, 18.06.0 uses .111 and .54, so it's vulnerable
Aug 07 08:47:19 <jow> morning
Aug 07 08:48:34 <jow> philipp64: need to look at the perl stuff in detail
Aug 07 08:49:47 <jow> philipp64: I see that perlmod.mk already declares PERL_VERSION:=5.28
Aug 07 08:50:27 <jow> philipp64: so my 1st try would be adding an PKG_VERSION:=$(PKG_VERSION)+perl$(PERL_VERSION) directly beneath
Aug 07 08:51:22 <jow> philipp64: then all extra perl packages using perlmod.mk should get a versioned filename like perl-cgi_4.38-1+perl5.28_mips_24kc.ipk
Aug 07 08:51:30 <jow> that would solve the opkg visibility problem
Aug 07 08:54:00 <jow> my 2nd measure would be attempting to set PKG_FILE_DEPENDS:=../perl/perlmod.mk
Aug 07 08:54:58 <jow> that should incroperate perlmod.mk's modtime into the .built target stamp calculation of the package so that e.g. a "touch perlmod.mk" would retrigger a build of every package including perlmod.mk
Aug 07 09:13:34 <f00b4r0> jow: re 'wifi': it seems people are still replying to the v1 of the patch. All these arguments are addressed in v2 which preserves the current "no argument" behaviour
Aug 07 09:14:17 <f00b4r0> s/these arguments/these points/
Aug 07 09:14:22 <jow> f00b4r0: partly, yes. Discussion goes beyond that though, mainly cicle around the fact that `/sbin/wifi` is not well defined
Aug 07 09:14:32 <f00b4r0> ah ok. Thats for sure ;P
Aug 07 09:14:41 <jow> it indeed performs more tasks than just applying wifi settings
Aug 07 09:14:47 <f00b4r0> but at least I'd very much like to get rid of the very nasty globall
Aug 07 09:15:03 <f00b4r0> last time I ran "wifi disable" it bit me in the ass
Aug 07 09:15:06 <jow> mainly the ubus call network reload could or could not cause unrelated network ifaces to get reconfigured, mainly if unapplied changes are present
Aug 07 09:15:14 <f00b4r0> yeah
Aug 07 09:15:25 <f00b4r0> it seems that's an "expected behavior" though
Aug 07 09:15:56 <jow> yeah, espacially considering that wifi is commonly bridged to something else
Aug 07 09:15:58 <f00b4r0> also the argument list is incoherent: 'wifi enable' but 'wifi down'. Should be 'enable/disable' or 'up/down' but not a mix, imo ;P
Aug 07 09:16:25 <jow> personally I would have no problem consolidating all that stuff in a better thought out "net" or "network" command
Aug 07 09:16:43 <f00b4r0> I'm sure some will complain about breaking assumptions ;P
Aug 07 09:16:46 <jow> ifup / ifdown, ifstatus, devstatus, wifi, ubus call network reload, swconfig etc.
Aug 07 09:18:26 <jow> e.g. "net if|iface|interface [name] up|down|enable|disable|status", "net dev|device [name] status", "net wifi|wireless|radio [radioX] up|down|enable|disable|status"
Aug 07 09:18:43 <f00b4r0> that'd be nice indeed
Aug 07 09:19:16 <jow> old stuff can then remain as wrapper for that
Aug 07 09:19:32 <jow> along with a deperecation warning
Aug 07 09:21:20 <jow> regarding the inconsistency
Aug 07 09:21:32 <jow> "down" indeed jsut deconfigures the radio but "enable" also alters uci iirc
Aug 07 09:21:47 <f00b4r0> ah
Aug 07 09:21:55 <hsp> What is Network/Hostnames on Luci? dns for the local network or what?
Aug 07 09:23:20 <jow> hsp: it adds "config host" sections to /etc/config/dhcp which ultimately get translated to --host-record for dnsmasq
Aug 07 09:25:39 <hsp> jow, can i add the IP and Hostname from my local Net (static IP)?
Aug 07 09:27:00 <jow> in the network hostnames page
Aug 07 09:28:36 <hsp> thx
Aug 07 09:30:28 <jow> DonkeyHotei: I simply reverted that change because a) I don't do kernel work and b) I do not want to add 18.06 specific commits. That branch sohuld receive cherry-picks / backports only and I assume that gsw driver change was cherry picked without a required, preceeding commit
Aug 07 09:48:46 <DonkeyHotei> the pastebin was the required, preceeding commit involved, but edited to apply cleanly to 18.06
Aug 07 09:49:49 <DonkeyHotei> however, it might've been more down the rabbit hole than optimal, so your action also was not a bad thing
Aug 07 09:52:09 <DonkeyHotei> it should be noted that the commit that broke the build was submitted in a pr without the offending line, but i looked at it and regression potential alarm bells went off in my mind
Aug 07 09:53:29 <DonkeyHotei> i suggested both the change and the application to 18.06, but in hindsight, i should've advised against the latter
Aug 07 10:00:05 <DonkeyHotei> [Mon 2018-08-06 11:25:44 AM PDT] <mkresin> DonkeyHotei: a fix for all the issues I found so far: https://gist.github.com/mkresin/7e5f0600a2fcdd19c456d4de0b7ded7f <----- i have received the report of the test of this as the latest entry in an off-list e-mail thread, so i'm disinclined to randomly add the ml to the middle of the thread, but i'd rather you see the report, at least.
Aug 07 10:03:49 <mkresin> DonkeyHotei: what? Can you switch to a form of communication that makes it easy for me to follow
Aug 07 10:04:45 <DonkeyHotei> the patch in the gist has a few problems
Aug 07 10:05:05 <mkresin> DonkeyHotei: guess my next question!
Aug 07 10:05:38 <Neighbor11111113> Moning all, I'm trying to get my head around autotools especially in regards to how OpenWRT works with it. I don't understand why there is a aclocals directory in the staging/target? Surely all autotools should be in the host directory as they are meant to be run on the build machine. Can anyone explain what is the purpose of staging_dir/target/host/share/aclocal and staging_dir/target/usr/share/aclocal? Thanks
Aug 07 10:06:27 <DonkeyHotei> you want to know what they are, of course. i'm offering to forward you the e-mailed report directly.
Aug 07 10:07:02 <DonkeyHotei> it's not the most transparent way to go about this, but idk what else to do atm
Aug 07 10:07:21 <mkresin> DonkeyHotei: please do so. Not unlikely I fat-fingered something
Aug 07 10:07:43 <john_> hello world!
Aug 07 10:08:24 <Guest28848> everybody here?
Aug 07 10:09:41 <Guest28848> people please tell me how to add the sim7600e-h module driver to the openwrt distribution?
Aug 07 10:10:49 <nitroshift> wigyori, o/
Aug 07 10:10:57 <nitroshift> stintel, o/
Aug 07 10:11:02 <stintel> nitroshift: o/
Aug 07 10:15:31 <DonkeyHotei> mkresin: sent
Aug 07 10:18:57 <mkresin> DonkeyHotei: puh, nothing critical so far
Aug 07 10:20:26 <mkresin> DonkeyHotei: I don't yet get the switch config
Aug 07 10:20:44 <mkresin> to which port of which switch is the wan port attached?
Aug 07 10:20:58 <DonkeyHotei> port 0 of switch1
Aug 07 10:21:30 <mkresin> okay, than it should be: ucidef_set_led_switch "wan" "wan" "$boardname:blue:wan" "switch1" "0x0"
Aug 07 10:22:06 <DonkeyHotei> and i wouldn't have characterized breaking sysupgrade as "nothing critical"
Aug 07 10:22:47 <mkresin> DonkeyHotei: breaking might a bit harsh. you need to do a forced updated due to the changed boardname
Aug 07 10:23:26 <mkresin> DonkeyHotei: but sure, we can blame each other. I forgot to mention it and you have done it wrong from the beginning
Aug 07 10:25:17 <mkresin> DonkeyHotei: the usb led issue is related to the missing kmod-usb-ledtrig-usbport. while looking at mt7620.mk, you might need to include kmod-usb2 and kmod-usb-ohci as well
Aug 07 10:53:08 <wigyori> nitroshift: \o
Aug 07 11:09:55 <jow> Neighbor11111114: staging_dir/target/host/share/aclocal is used by tools and package host builds
Aug 07 11:10:53 <jow> Neighbor11111114: some packages are first compiled for the host system, then for the target. Either because they require parts of themselves to cross compile (ncurses) or because we need them on the host as well (e.g. opkg and dependant libraries)
Aug 07 11:30:08 <Neighbor11111114> Hi jow, that makes sense. But if they're used by just tools and host builds then they should be in staging_dir/host not staging_dir/target?
Aug 07 11:53:30 <wigyori> df
Aug 07 11:54:58 <a__pi> the terminal tab is the other one
Aug 07 11:57:57 <wigyori> yep
Aug 07 13:47:56 <jwh> hm, broke sysupgrade generation
Aug 07 13:48:00 <jwh> what have I done
Aug 07 13:51:26 <jwh> does it depend on anything in particular? (target image types, packages?)
Aug 07 13:55:11 <jwh> um, hm, rootfs per device is tripping me up
Aug 07 16:28:29 <moonwatcher> .
Aug 07 16:28:49 <moonwatcher> so… i understand the MT7603EN is a dead end? This 2.4 radio will never be stable?
Aug 07 16:29:10 <moonwatcher> what is a recommended 2.4 chip with open source drivers and good support in openwrt?
Aug 07 16:29:38 <Borromini> moonwatcher: ath9k?
Aug 07 16:29:50 <moonwatcher> realy?
Aug 07 16:29:59 <moonwatcher> so all the mediatek stuff is out of the door?
Aug 07 16:30:24 <moonwatcher> i mean i have a tp-link C7 with ath9k and ath10k
Aug 07 16:30:29 <Borromini> erm i don't know of any 2,4 GHz Mediatek 2,4 GHz radios besides MT7603, but I might be mistaken.
Aug 07 16:30:38 <moonwatcher> the MT7603EN is shit
Aug 07 16:30:39 <Borromini> i am very happy with my 5 GHz MT7621
Aug 07 16:30:46 <moonwatcher> unusable
Aug 07 16:31:06 <moonwatcher> i have a pile of Xiaomi 3G with MT7612EN
Aug 07 16:31:10 <moonwatcher> 5GHz is solid
Aug 07 16:31:22 <moonwatcher> but the MT7603EN is crap
Aug 07 16:31:35 <moonwatcher> and sadly there are still small decvices that depend on a solid 2.4
Aug 07 16:32:06 <moonwatcher> is the MT7620A better?
Aug 07 16:32:24 <moonwatcher> or are you saying ath9k is the best 2.4 on openwrt at the moment?
Aug 07 16:32:33 <karlp> it's always been the best 2.4
Aug 07 16:32:46 <karlp> mt7620a is old ramips driver,
Aug 07 16:33:03 <karlp> mt7603 is new mt76 driver and will in theory continue to improve. (aiui)
Aug 07 16:33:45 <moonwatcher> well… i have a pile of stuff with MT7603EN but i need it basically only for some lifx bulbs, raspberry pi zeros and such
Aug 07 16:33:55 <moonwatcher> all of which are very unhappy with the stability
Aug 07 16:34:51 <Fishman> moonwatcher: ath9k is the epitome of open source support for wifi.  it's all downhill from there
Aug 07 16:34:57 <karlp> various mt76 builds over the last few months have been of rather variable stability
Aug 07 16:35:17 <karlp> I built again yesterday and it's been good, but a month ago was complete garbge, and two months ago ogod again, sort of thing.
Aug 07 16:35:29 <moonwatcher> i just built reboot-7729-gf960490fc8f9c347021868f6bd0ed1a078fc6da2
Aug 07 16:35:37 <moonwatcher> but i never even tried the 2.,4
Aug 07 16:35:43 <moonwatcher> ill try and enable it and see how it works
Aug 07 16:35:55 <moonwatcher> i fall back on an old apple time capsule for 2.4 for now
Aug 07 16:35:57 <karlp> you never even tried the 2.4, but you're complaining about the 2.4?
Aug 07 16:36:12 <moonwatcher> i tried it for months
Aug 07 16:36:21 <moonwatcher> and wracked havok on my marriage ;)
Aug 07 16:36:29 <moonwatcher> “Why is the internet acting up again???)
Aug 07 16:36:34 <f00b4r0> there's hope for mt7620a: https://bugzilla.kernel.org/show_bug.cgi?id=82751
Aug 07 16:37:13 <karlp> yes, I had weird behaviour on mt76 wifi too, sometimes it woudl be perfect ror days and days, then require 5 reboots a night. wife wass't impressed here either :)
Aug 07 16:37:25 <karlp> interestly, it would be fine for her all day, and as soon as I walked in the door, the wifi would crash.
Aug 07 16:37:32 <karlp> presumably it doesn't like my phone as a client?
Aug 07 16:41:17 <moonwatcher> yes
Aug 07 16:41:24 <moonwatcher> i noticed it drives iphones insane
Aug 07 16:41:34 <moonwatcher> and the lifx bulbs are really unhappy
Aug 07 16:41:59 <moonwatcher> kind of points to wifi power saving of some sort
Aug 07 16:42:17 <moonwatcher> but i mean, that is pretty much what i use 2.4 for
Aug 07 16:42:32 <moonwatcher> all the rest is on 5
Aug 07 16:43:56 * Borromini is curious about MT7615
Aug 07 16:48:10 <moonwatcher> so something with TP9343?
Aug 07 16:48:22 <moonwatcher> that uses ath9k right?
Aug 07 16:53:38 <rotanid> hm, the bugzilla link is about another driver, not mt76, am i right? rt2x00
Aug 07 16:53:53 <f00b4r0> rotanid: the link is about mt7620
Aug 07 16:53:57 <f00b4r0> 2.4
Aug 07 16:54:01 <rotanid> and that is rt2x00 driver, not mt76
Aug 07 16:54:05 <f00b4r0> indeed
Aug 07 16:54:16 <rotanid> but both drivers are actively worked on
Aug 07 16:54:17 <rotanid> afaik
Aug 07 16:54:34 <karlp> well, rt2x00 has that stansislaw guy, and that's about it.
Aug 07 16:54:35 <f00b4r0> i guess so. The last 3 patches on the bugzilla have fixed 2.4 for me
Aug 07 16:54:48 <rotanid> if someone knows a billionaire, additionaly funding would help as far as i know the guys
Aug 07 16:54:55 <rotanid> ;)
Aug 07 16:55:03 * karlp should try them on his quirky old broadcom+ralink box
Aug 07 16:55:32 <f00b4r0> i'm not sure funding is the main issue. More like lack of proper hw documentation, AIUI
Aug 07 16:55:59 <rotanid> i also just found "MT7610E is a very crappy chip and will very certainly never be supported"
Aug 07 16:56:18 <f00b4r0> heh
Aug 07 16:56:37 <moonwatcher> https://wiki.openwrt.org/toh/tp-link/tl-wa901nd with TP9343?
Aug 07 16:56:54 <moonwatcher> that seems like a cheap small unit with 2.4 only and a latest ath9k?
Aug 07 16:57:12 <moonwatcher> will that solve the “stable 2.4 for small irritating devices” problem?
Aug 07 16:57:39 <rotanid> f00b4r0: sure, documentation is always good, but as far as i know at least the mt76 main dev has good connectiosn to Mediatek, they just don't invest as much many in the open source driver as we would like, so more money from someone would help here
Aug 07 16:57:47 <f00b4r0> moonwatcher: QCA953x is ath9k and works well afaict. More recent chip.
Aug 07 16:57:54 <f00b4r0> so possibly more hw choices
Aug 07 16:58:21 <rotanid> s/much many/much/
Aug 07 16:58:26 <moonwatcher> f00b4r0: so which would be yuour prefered solution to this issue?
Aug 07 16:59:17 <f00b4r0> rotanid: i find the funding argument a bit specious in a FOSS world. A large chunk of linux drivers have been written without any kind of funding.
Aug 07 16:59:41 <f00b4r0> moonwatcher: i don't know, I don't have that issue :)
Aug 07 16:59:49 <rotanid> well, you can either wait for someone endlessly or pay someone who has to live from something
Aug 07 17:00:28 <f00b4r0> rotanid: sure. But in this particular case it's uncertain funding would help. As evidenced by the kickstarter referenced in the bugzilla which, AFAICT, didn't fix anything.
Aug 07 17:00:46 <rotanid> f00b4r0: and please have a look at kernel devs, there are maaaany whose work is paid for by some company
Aug 07 17:00:51 <f00b4r0> sure
Aug 07 17:01:07 <f00b4r0> i'm not saying funding doesn't help. I'm saying it doesn't _always_ help :)
Aug 07 17:01:26 <rotanid> ack
Aug 07 17:01:32 <f00b4r0> you can pay me a gazillon dollars, if there isn't enough info to write workable code, it's not going to change anything.
Aug 07 17:04:35 <karlp> f00b4r0: that kickstarter certainly made it better.
Aug 07 17:04:45 <karlp> mt7620 before and after that code was night and day
Aug 07 17:04:48 <karlp> there'
Aug 07 17:06:59 <f00b4r0> i'll take your word for it
Aug 07 17:15:24 <moonwatcher> ok, TL-WA901ND is like 35$ and even has PoE
Aug 07 17:16:19 <f00b4r0> 32MB RAM
Aug 07 17:16:25 <f00b4r0> 4MB flash
Aug 07 17:16:31 <Fishman> moonwatcher: here's the current link: https://openwrt.org/toh/tp-link/tl-wa901nd
Aug 07 17:16:32 <f00b4r0> sounds about as unusable as it gets
Aug 07 17:16:47 <moonwatcher> sounds like it will make me stop care about 2.4
Aug 07 17:17:06 <moonwatcher> it will cover the apartment, handle all the little irritating 2.4 crap
Aug 07 17:17:35 <moonwatcher> getting rid of 2.4 on the Xiaomis also eliminates the issues with usb3
Aug 07 17:18:27 <moonwatcher> i like that v5 has EMI shielding on everything
Aug 07 17:19:04 <Fishman> i personally wouldn't want to spend more than $15US on a 4/32 device
Aug 07 17:19:19 <f00b4r0> ^
Aug 07 17:19:37 <moonwatcher> well, i dont intend on buying a pile of them
Aug 07 17:19:39 <moonwatcher> only one
Aug 07 17:19:54 <moonwatcher> i suppose ebay will have 2nd hand if i am patient
Aug 07 17:21:57 <moonwatcher> lots of v 3.1 on ebay for 15~
Aug 07 17:23:42 <f00b4r0> the hAP mini and lite are available on amazon, afaict
Aug 07 17:23:46 <f00b4r0> they have 16MB of flash
Aug 07 17:24:01 <f00b4r0> 32MB RAM.
Aug 07 17:25:41 <moonwatcher> which is that?
Aug 07 17:25:53 <moonwatcher> do you have a link to the wiki?
Aug 07 17:26:39 <f00b4r0> https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb941-2nd
Aug 07 17:26:47 <f00b4r0> https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb931-2nd_hap_mini
Aug 07 17:30:04 <moonwatcher> i see
Aug 07 17:30:07 <moonwatcher> similar price
Aug 07 17:30:11 <moonwatcher> internal antennas
Aug 07 17:30:16 <moonwatcher> more ram
Aug 07 17:30:23 <moonwatcher> more flash
Aug 07 17:30:39 <moonwatcher> not sure how it all matters for my “small irritating 2.4 device network”
Aug 07 17:30:54 <moonwatcher> i figure coverage is more important that throughput
Aug 07 17:31:09 <moonwatcher> lifx bulbs dont need throughput…
Aug 07 17:31:17 <f00b4r0> if Luci matters to you, more flash matters.
Aug 07 17:31:40 <moonwatcher> luci does not
Aug 07 17:31:56 <moonwatcher> i spend 80% of my waking hors staring at a terminal
Aug 07 17:32:06 <moonwatcher> i write c++ code for biologists for a living...
Aug 07 17:32:26 <f00b4r0> cool.
Aug 07 17:32:39 <moonwatcher> this is purrely a single purpose device
Aug 07 17:32:45 <moonwatcher> poe actually sounds good
Aug 07 17:32:59 <moonwatcher> mkes it simpler to wall mount it in a good spot for coverage
Aug 07 17:33:47 <moonwatcher> TP-Link TL-WA901ND sounds like a winner… quastion is when did v5 come out? is the one on amazon v5?
Aug 07 17:33:57 <f00b4r0> clearly you've never heard of splitter cables :)
Aug 07 17:34:44 <moonwatcher> im in a small apartment in manhattan
Aug 07 17:35:06 <moonwatcher> we actually have 2 ethernet cables running from the main com closet to the other sides
Aug 07 17:35:15 <moonwatcher> makes deloying a decent wifi really easy
Aug 07 17:35:35 <moonwatcher> than again
Aug 07 17:35:46 <moonwatcher> about 60 SSIDs in range...
Aug 07 17:38:19 <moonwatcher> TP9343 is actuall 3x3:3
Aug 07 17:38:30 <moonwatcher> not that i have any chance of using multiple channels here
Aug 07 18:04:19 <andy2244> nbd: quick question regarding librpc, the host build seems to compile using host/defaults, yet only really installs headers? Are those headers generated/changed by the build?
Aug 07 18:33:08 <ntd> jow, ping
Aug 07 19:07:17 <jow> ntpong
Aug 07 19:07:23 <jow> ah, too late
Aug 07 19:13:15 <philipp64> jow: are you onboard with the +perl5.28.0 proposal?
Aug 07 19:14:20 <DonkeyHotei> PERL_VERSION vs. ABIVERSION
Aug 07 19:20:23 <philipp64> ABIVERSION.
Aug 07 19:38:11 <philipp64> so how do we go about changing the way that package naming happens?
Aug 07 19:41:54 <karlp> are you really trying to go down a path of having multiple supported perl versions in tree at the same time?
Aug 07 19:42:51 <philipp64> that's not the goal, no.  I'm trying to have version bumps in lang/perl/Makefile cause all of the packages to be rebuilt… alas that causes ambiguity for IB, etc.
Aug 07 19:43:36 <philipp64> but at least images built post-bump would once again be consistent with each other, which we don't have now.
Aug 07 19:45:36 <philipp64> if you have a better fix, I'm listening…
Aug 07 19:48:50 <karlp> not at all, sorry
Aug 07 19:49:07 <karlp> f00b4r0: where are you dropping these three patches for rt28xx?
Aug 07 19:55:06 <Hauke> philipp64: to rebuild a packet increase the PKG_RELEASE number
Aug 07 19:59:49 <DonkeyHotei> it's not feasible to automatically increase PKG_RELEASE on a long list of packages with zero changes every time
Aug 07 19:59:52 <jow> Hauke: the idea is to automate that part
Aug 07 20:00:00 <Hauke> ok
Aug 07 20:00:17 <jow> philipp64: sure, fine with me. Do you happen to have a link?
Aug 07 20:05:57 <philipp64> jow: I'm still trying to figure out where the package name gets constructed…
Aug 07 20:07:44 <karlp> f00b4r0: and are you suing any of the dangolle/psyborg patches that are in dangolle's staging as well as stansilaw's patches?
Aug 07 20:08:45 <jow> philipp64: did you try to just increase PKG_VERSION from perlmod.mk ?
Aug 07 20:08:50 <jow> or append, rather
Aug 07 20:10:13 <jwh> jow: i know im a pain in the ass.. but can you deal with my patch? :D
Aug 07 20:10:29 <jwh> pretty pls
Aug 07 20:10:46 <jow> which one?
Aug 07 20:13:26 <jwh> one that changes offload check to generic kmod check in fw3
Aug 07 20:17:02 <andy2244> jow: quick question, do i see this correct that the current librpc is kinda fixup and switching to a upstream maintained libtirpc would be preferred? Just looking into this and related packages atm.
Aug 07 20:18:09 <jow> andy2244: hm, quite likely
Aug 07 20:18:37 <jwh> jow: defaults: use a generic  check_kmod() function, 13th july
Aug 07 20:18:38 <philipp64> jow: looking at perlmod.mk but don't see where the change would happen… also, seems pointless to duplicate the setting of PERL_VERSION in both perlmod.mk and Makefile…
Aug 07 20:18:51 <jow> don't recall the exact librpc history, I think it was just a necessity to get stuff working on musl
Aug 07 20:19:27 <andy2244> oki will try some basic testing tomorrow and if all works out, try to submit a PR that removes librpc and replaces it with libtirpc
Aug 07 20:24:23 <andy2244> jow: btw i also had to-do some strange travis fixup here: https://github.com/openwrt/packages/pull/6706
Aug 07 20:24:23 <andy2244> Whats going on there?
Aug 07 20:26:05 <jow> no idea
Aug 07 20:26:21 <jow> however travis uses the SDK to build packages, not the complete buildroot
Aug 07 20:26:27 <jow> maybe the SDK simply lacks include/
Aug 07 20:26:35 <jow> iirc there's been a similar issue in the past
Aug 07 20:26:51 <andy2244> my docker test builder also uses the sdk/snapshot and could compile just fine
Aug 07 20:30:06 <andy2244> so do we fixup for travis in such a case or is there some travis only define and only fix if run by travis?
Aug 07 20:30:16 <Rene__> Yes, SFP port is finally talking on my ER-X-SFP.
Aug 07 20:31:24 <jow> andy2244: I have totally no idea. I've no experience with travis at all
Aug 07 20:31:38 <jow> andy2244: here's the things it does: https://github.com/openwrt/packages/blob/master/.travis_do.sh
Aug 07 20:32:25 <jow> could be pure luck that it works in your docker setup, maybe some package is built earlier, creating that missing inc dir
Aug 07 20:33:42 <andy2244> mhh so who is the person that maintains the travis stuff? I feel bad having code for "kinda" travis only?
Aug 07 20:35:53 <jow> the error you linked does not look like a travis specifc thing at all
Aug 07 20:36:16 <jow> it just happens to be triggered there because it tends to start with a clean, minimal env
Aug 07 20:37:51 <andy2244> mhh than why did the package not fail before the PR? The actual change is a minor configure change, which has no real impact on include dirs?
Aug 07 20:45:16 <jow> the packages uses autoconf and libtool, anything can happen
Aug 07 20:46:00 <jow> could be that ac_cv_lib_resolv___res_querydomain=yes triggers -lresolv which lets libtool do ... things
Aug 07 20:46:48 <jow> philipp64: the following seems to work on a first glance: https://pastebin.com/xT7QTkQ8
Aug 07 20:47:30 <jow> $ find bin/ -name 'perl-*.ipk'
Aug 07 20:47:30 <jow> bin/packages/mips_24kc/packages/perl-html-parser_3.72+perl5.28-1_mips_24kc.ipk
Aug 07 20:47:33 <jow> bin/packages/mips_24kc/packages/perl-html-tagset_3.20+perl5.28-3_mips_24kc.ipk
Aug 07 20:47:36 <jow> bin/packages/mips_24kc/packages/perl-cgi_4.38+perl5.28-1_mips_24kc.ipk
Aug 07 20:47:54 <ntd> jow: https://hashcat.net/forum/thread-7717-newpost.html
Aug 07 20:48:11 <jow> ntd: yes?
Aug 07 20:48:19 <ntd> can this be mitigated through sw/lede/owrt
Aug 07 20:48:52 <jow> it seemed to only be possible when fast roaming / 11r is enabled
Aug 07 20:48:57 <ntd> not the concept itself ofc
Aug 07 20:49:00 <ntd> right
Aug 07 20:49:09 <jow> but don't fall for the scare hype
Aug 07 20:49:22 <ntd> yeah, blogosphere has been kinda wild today
Aug 07 20:49:51 <jow> all this new attack vector does is to slightly simplify obtaining the pmk hash
Aug 07 20:50:17 <jow> which is'nt even a practical problem to begin with on busy networks
Aug 07 20:50:39 <ntd> no real speed benefit
Aug 07 20:51:12 <ntd> but useful if 11w, cosmic rays causing busted captures, etc
Aug 07 20:51:18 <jow> instead of waiting for a 4 way handshake (some client roams in) you can now - in some cases, on 11r enabled networks [as far as I understood it] - grab the hash from a fast roaming eapol frame
Aug 07 20:51:53 <jow> it does not simplify cracking the derived hash
Aug 07 20:52:00 <jow> it does not leak key bits
Aug 07 20:52:06 <jow> search space isn't reduced
Aug 07 20:52:29 <jow> its basically another in some cases slightly more convenient way to get the pmk hash to crack
Aug 07 20:53:19 <jow> I would guess that disabling 11r (or not enabling it to begin with) is as good as it gets wrt. software side mitigations
Aug 07 20:53:36 <jow> but take that statement with a huge grain of salt, I am no expert on this
Aug 07 20:56:50 <jow> andy2244: the problem traces down to  rules.mk:TARGET_CPPFLAGS:=-I$(STAGING_DIR)/usr/include -I$(STAGING_DIR)/include
Aug 07 20:57:10 <jow> andy2244: problem is that nothing in buildroot/sdk ensures that $(STAGING_DIR)/include actually exists
Aug 07 20:57:33 <andy2244> ah oki so i guess i keep the fix than
Aug 07 20:57:36 <jow> andy2244: which will cause some packages to fail due to -Werror in combination with -Wmissing-include-dirs
Aug 07 20:58:05 <andy2244> thanks for checking this
Aug 07 21:03:10 <jow> a slightly cleaner fix to your issue might be  TARGET_CPPFLAGS += -Wno-error=missing-include-dirs
Aug 07 21:03:33 <jow> you do not need to override the prepare recipe then
Aug 07 21:04:07 <andy2244> ah so the last or "no" takes priority?
Aug 07 21:05:00 <ntd> reading through the changelog of 1806. have there been any improvements re NCM 4g dongle handling? recent huawei firmwares have both 17.01 and older networkmanager stumped
Aug 07 21:05:32 <ntd> "huawei mobile connect" from 2013 still working fine. had to testpoint and fw downgrade sev modems
Aug 07 21:07:00 <jow> andy2244: yes
Aug 07 21:07:15 <jow> andy2244: latter options in the same cmdline will override former ones
Aug 07 21:08:00 <andy2244> thanks for the tip
Aug 07 21:27:53 <jwh> jow: <3
Aug 07 21:31:37 <andy2244> jow: bah -Wno-error=missing-include-dirs is added before -Werror=missing-include-dirs  and than it still fails....
Aug 07 22:45:10 <f00b4r0> karlp: no. I'm doing exactly what is detailed in the bugzilla: removing one patch from the openwrt quilt and applying the 3 extra on top of a fully extracted/patched backports
Aug 07 22:46:45 <f00b4r0> karlp: I'm not touching anything that's coming from psyborg with a 10ft pole. In fact I find the last commits in that staging tree rather worrying: the commits say they're "from mtk driver". I wonder if said "mtk driver" is GPL v2 licensed.
Aug 07 22:47:00 <f00b4r0> not to mention the lack of copyright assignment.
Aug 07 23:04:26 <DonkeyHotei> mtk did get it from ralink, which did license their drivers under gpl2
Aug 07 23:56:06 <DonkeyHotei> and if you're talking about PR 626, did dangole already wash his hands of it? it doesn't look like it from the comments
**** ENDING LOGGING AT Wed Aug 08 03:00:01 2018