[00:05] <ejat> https://cxsecurity.com/issue/WLB-2016050014
[08:02] <apw> ejat, that one is known indeed, and the fix ought to be out in -security already
[08:03] <ejat> apw: ok thanks
[13:02] <caribou> Who is the resident expert on wireless kernel modules ?
[13:03] <rtg> caribou, sforshee
[13:03] <caribou> rtg: thanks
[13:04] <caribou> I've been hunting a nasty wifi bug on my desktop @home (Trusty & Xenial) and the only fix I found is to get some module source on github & install it with dkms
[13:04] <caribou> same problem on realtek & ralink chips
[13:05] <caribou> so I'm curious to understand why such fix is not in the distro
[13:05] <caribou> sforshee: ^^
[13:06] <JanC> did you report a bug?
[13:09] <caribou> JanC: I've seen a few while investigating the issue
[13:10] <caribou> JanC: none actually brought a solution; I thought that upgrading to Xenial would help but it didn't
[13:11] <caribou> JanC: installing https://github.com/pvaret/rtl8192cu-fixes does nail it down, now I'm about to look at what has changed
[13:16] <sforshee> caribou: what's in the distro kernel is generally just what's in upstream linux. I can't say why any fixes there aren't making their way upstream.
[13:17] <caribou> sforshee: looking at the git repo, it looks like work that has never been submitted upstream
[13:17] <sforshee> sometimes "fixes" for some hardware break other hardware though, and that's generally not considered acceptible
[13:18] <caribou> sforshee: true, that would explain why it is kept outside
[13:18] <JanC> it's a driver from Realtek that according to README only works on one specific chip and wasn't ported to recent kernels
[13:20] <sforshee> I don't really recommend people use realtek or ralink because neither does a great job of making things work well upstream
[13:20] <JanC> looks like driver that was written for a specific device really
[13:21] <caribou> JanC: then it explains why it's kept there
[13:21] <JanC> as e.g. it doesn't support multiple antennas properly & such?
[13:22] <JanC> it might still be useful for somebody wanting to improve the drivers in upstream linux, dunno
[13:22] <caribou> sforshee: well, it's the builtin chip so not much choice
[13:22] <caribou> one thing though, it used to work fine for a long time (even during Trusty's early days)
[13:22] <JanC> caribou: it's not on PCIE?
[13:23] <caribou> JanC: ralink is a wifi dongle that I used to diagnose further; realtek is native on the desktop
[13:25] <caribou> or the other way around, I'd have to check
[13:26] <caribou> well, your clarifications pretty much explains why I had to chase it down
[13:27] <caribou> my only solution to identify the problem would be to identify a working kernel then bisect
[13:28] <caribou> JanC: sforshee: thanks for the clarifications btw
[13:29] <JanC> there seem to be several more drivers like that on github  :-/
[13:29] <JanC> for other Realtek chips etc.
[17:55] <jdstrand> jsalisbury: fyi, the upstream kernel still had the bug :\
[17:56] <jdstrand> jsalisbury: in trying it I noticed that I couldn't use sbuild since overlayfs wasn't in the kernel. I thought the upstream kernels had overlayfs available. would it be possible to adjust the kernel config for the upstream kernels to include overlayfs?
[18:51] <jsalisbury> jdstrand, I can look into it.  I'm not sure off hand though.  Maybe apw has an idea?
[18:52] <jsalisbury> jdstrand, thanks for testing the latest mainline.  I'll build the next kernel for the bisect.
[18:53] <apw> jdstrand, i'd expect overlayfs to be included, _but_ you might find you are using old format overlayfs which only ubuntu lkernles support
[18:53] <apw> as in using overlayfs not overlay
[18:53]  * jdstrand is just using sbuild
[18:54] <jdstrand> I don't recall changing anything, but its been a while
[18:54] <apw> yeah sbuild i thnk support both, and it would remember which you first used
[18:54] <jdstrand> union-type=overlayfs
[18:54] <apw> now how did you tell, erm, in the overlay directory it stores a flag
[18:54] <apw> so thats V1 support with the old whiteouts, so a mainline kernel cannot mount it
[18:55] <apw> you can make that overlay and it ought to work with both
[18:55] <apw> obviously persistant ones get broken, but ephemerals for sbuild should just be ok
[18:59] <jdstrand> interesting
[19:00] <jdstrand> apw: ok, thanks!