Bug#985686: wpasupplicant: WPA supplicant tries to bring up wrong network device
Package: wpasupplicant Version: 2:2.7+git20190128+0c1e29f-6+deb10u2 Severity: important Dear Maintainer, * What led up to the situation? Regular wpasupplicant + backports kernel updates * What exactly did you do (or not do) that was effective (or ineffective)? Removing custom module parameters for iwlwifi module did not solve problem Configuring interface manually using the wlp36s0 device worked * What was the outcome of this action? Card was only able to associate with WLAN and connect successfully when enabled manually * What outcome did you expect instead? Connection to WLAN should have Just Worked as it has in the past -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wpasupplicant depends on: ii adduser 3.118 ii libc6 2.28-10 ii libdbus-1-3 1.12.20-0+deb10u1 ii libnl-3-200 3.4.0-1 ii libnl-genl-3-200 3.4.0-1 ii libnl-route-3-200 3.4.0-1 ii libpcsclite1 1.8.24-1 ii libreadline7 7.0-5 ii libssl1.1 1.1.1d-0+deb10u5 ii lsb-base 10.2019051400 wpasupplicant recommends no packages. Versions of packages wpasupplicant suggests: pn libengine-pkcs11-openssl pn wpagui -- no debconf information I'm not quite sure when it happened (it's been an age since the last reboot) but I recently discovered that the wireless network on one of my machines wouldn't come up at boot. To cut a long story short, it looks like wpasupplicant was throwing an error when bringing up the interface. Networking status pointed at a device that I don't recall seeing before, p2p-dev-wlp39s0. Because wpasupplicant threw an error, the rest of the networking steps were never performed (so I was left without a default gateway etc): /etc/init.d/networking status ● networking.service - Raise network interfaces Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sun 2021-03-21 22:18:34 GMT; 6min ago Docs: man:interfaces(5) Process: 22444 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE) Main PID: 22444 (code=exited, status=1/FAILURE) Mar 21 22:18:34 macduff wpa_supplicant[22472]: nl80211: Failed to open /proc/sys/net/ipv4/conf/p2p-dev-wlp36s0/drop_unicast_in_l2_multicast: No such file or directory Mar 21 22:18:34 macduff wpa_supplicant[22472]: nl80211: Failed to set IPv4 unicast in multicast filter Mar 21 22:18:34 macduff wpa_supplicant[22472]: nl80211: Failed to open /proc/sys/net/ipv4/conf/p2p-dev-wlp36s0/drop_unicast_in_l2_multicast: No such file or directory Mar 21 22:18:34 macduff wpa_supplicant[22472]: nl80211: Failed to set IPv4 unicast in multicast filter Mar 21 22:18:34 macduff wpa_supplicant[22472]: nl80211: deinit ifname=p2p-dev-wlp36s0 disabled_11b_rates=0 Mar 21 22:18:34 macduff wpa_supplicant[22472]: p2p-dev-wlp36s0: CTRL-EVENT-TERMINATING Mar 21 22:18:34 macduff wpa_supplicant[22472]: nl80211: deinit ifname=wlp36s0 disabled_11b_rates=0 Mar 21 22:18:34 macduff wpa_supplicant[22472]: wlp36s0: CTRL-EVENT-TERMINATING Mar 21 22:18:34 macduff systemd[1]: networking.service: Failed with result 'exit-code'. Mar 21 22:18:34 macduff systemd[1]: Failed to start Raise network interfaces. The same device showed up in /var/run/wpa_supplicant and wpa_cli (MACs and UIDs removed): wpa_cli status Selected interface 'p2p-dev-wlp36s0' wpa_state=DISCONNECTED p2p_device_address= address= uuid= According to the doc, wpasupplicant will try and bring up the first device it sees in /var/run/wpa_supplicant which appears to be the wrong one. Manually upping wlp36s0 with ifup worked but every attempt using the networking script/wpasupplicant failed and left me with an unconfigured network. Using the "correct" device name I'm able to connect successfully. wpa_cli status -i wlp36s0 bssid= freq=5500 ssid= id=0 mode=station pairwise_cipher=CCMP group_cipher=CCMP key_mgmt=WPA2-PSK wpa_state=COMPLETED ip_address= p2p_device_address= address= uuid= ieee80211ac=1 I was using some custom parameters for the iwlwifi and kernel boot but I disabled those for the purposes of debugging. The wireless card in question is an Intel 8265 using the v36 firmware. iw reports that this device supports P2P, whatever that means. From dmesg: [ 3.996170] iwlwifi :24:00.0: firmware: direct-loading firmware iwlwifi-8265-36.ucode [ 3.997288]
Bug#963002: udev: Keyboard mis-detected as Apple
On 2020-06-17 21:52, Michael Biebl wrote: Control: tags -1 + moreinfo Hi Salutations! Am 17.06.20 um 14:08 schrieb Vroomfondel: Package: udev Version: 241-7~deb10u4 Severity: normal Dear Maintainer, * What led up to the situation? New Varmilo keyboard * What was the outcome of this action? Fn keys not working correctly * What outcome did you expect instead? Fn key to work out of the box (as it does with my other Varmilo KB) * Futher elaboration: I've run in to an odd problem recently with a new keyboard, a Varmilo VA88M (essentially the UK-ISO version of the VA87M); a fairly bog-standard tenkeyless keyboard. On first use everything seemed to work OK, but it eventualy transpired that the Fkeys weren't working as expected. F1 through F6 didn't work at all and F7 through F12 acted as media keys as if the Fn key was being pressed. Holding down the Fn key and pressing Fkeys they worked as expected, so the default behaviour of the keyboard was as if the Fn key was being held down all the time. Plugging in to a mate's windows machine, the same behaviour didn't occur. On inspecting lsusb, it seemed that the keyboard was perhaps being erroneously detected as an Apple keyboard. lsusb output: Bus 001 Device 007: ID 05ac:024f Apple, Inc. Tbh, that sounds like a hardware issue, and not like a software issue. Why does Varmilo VA88M use the same vendor id as Apple? That sounds fishy. No idea on that, but I've just checked with the windows machine there and it reports the same VID and PID there too (I just assume Windows' handling for this keyboard/Mac keyboards is different). Have you tried contacting the hardware vendor? Yes, I've fired off a separate query to the hardware vendor, waiting back on a response. There's a recent reddit post here with what sounds like the same issue but I can't load the page past the initial comment for some reason. https://www.reddit.com/r/Varmilo/comments/g4sabk/fn_lock_on_va87m/ In the meantime, or in the event of there not being a viable fix, are there any "cleaner" ways to work around the issue? From having a cursory glance through the comments in the /lib/udev/hwdb files it seems like custom overrides can be set there and submitted upstream if deemed useful. Is this something that's likely work-aroundable with udev rules or tweaks to the hwdb or does the specific USB ID mean only a hardware fix will work? I'm still reading up on how all those files fit together with the module loading.
Bug#963002: udev: Keyboard mis-detected as Apple
Package: udev Version: 241-7~deb10u4 Severity: normal Dear Maintainer, * What led up to the situation? New Varmilo keyboard * What was the outcome of this action? Fn keys not working correctly * What outcome did you expect instead? Fn key to work out of the box (as it does with my other Varmilo KB) * Futher elaboration: I've run in to an odd problem recently with a new keyboard, a Varmilo VA88M (essentially the UK-ISO version of the VA87M); a fairly bog-standard tenkeyless keyboard. On first use everything seemed to work OK, but it eventualy transpired that the Fkeys weren't working as expected. F1 through F6 didn't work at all and F7 through F12 acted as media keys as if the Fn key was being pressed. Holding down the Fn key and pressing Fkeys they worked as expected, so the default behaviour of the keyboard was as if the Fn key was being held down all the time. Plugging in to a mate's windows machine, the same behaviour didn't occur. On inspecting lsusb, it seemed that the keyboard was perhaps being erroneously detected as an Apple keyboard. lsusb output: Bus 001 Device 007: ID 05ac:024f Apple, Inc. Corresponding udevinfo output confirming the VID and PID (but name is correctly identified as a Varmilo): udevadm info --path /devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/0003:05AC:024F.000D/input/input20 P: //devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/0003:05AC:024F.000D/input/input20 L: 0 E: DEVPATH=//devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/0003:05AC:024F.000D/input/input20 E: PRODUCT=3/5ac/24f/110 E: NAME="AONE Varmilo Keyboard" E: PHYS="usb-:00:14.0-4/input0" E: UNIQ="" E: PROP=0 E: EV=120013 E: KEY=1 0 0 0 1007b1007 ff9f207ac14057ff ffbeffdfffef fffe E: MSC=10 E: LED=1f E: MODALIAS=input:b0003v05ACp024Fe0110-e0,1,4,11,14,k71,72,73,74,75,77,78,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8C,8E,96,98,9E,9F,A1,A3,A4,A5,A6,AD,B0,B1,B2,B3,B4,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,CC,E0,E1,E3,E4,E5,E6,F0,1D0,ram4,l0,1,2,3,4,sfw E: SUBSYSTEM=input E: USEC_INITIALIZED=389851205999 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_INPUT_KEYBOARD=1 E: ID_VENDOR=AONE E: ID_VENDOR_ENC=AONE E: ID_VENDOR_ID=05ac E: ID_MODEL=Varmilo_Keyboard E: ID_MODEL_ENC=Varmilo\x20Keyboard E: ID_MODEL_ID=024f E: ID_REVISION=0100 E: ID_SERIAL=AONE_Varmilo_Keyboard E: ID_TYPE=hid E: ID_BUS=usb E: ID_USB_INTERFACES=:030101:03: E: ID_USB_INTERFACE_NUM=00 E: ID_USB_DRIVER=usbhid E: ID_PATH=pci-:00:14.0-usb-0:4:1.0 E: ID_PATH_TAG=pci-_00_14_0-usb-0_4_1_0 E: ID_FOR_SEAT=input-pci-_00_14_0-usb-0_4_1_0 E: TAGS=:seat: As far as I can tell, this keyboard should be being claimed by plain usbhid but is instead being claimed by hid_apple instead. At first I thought blacklisting the hid_apple module would force it to be claimed by regular usbhid but that just stopped the keyboard from working at all. Looking in to the modinfo of hid_apple I can see there's an option named fnmode that governs the default behaviour of the Fn key which sounded exactly like the issue I was experiencing. parm: fnmode:Mode of fn key on Apple keyboards (0 = disabled, [1] = fkeyslast, 2 = fkeysfirst) (uint) Sure enough, creating a module override for hid_apple setting this to 2 worked around the issue and then the Fkeys worked as expected: options hid_apple fnmode=2 However this workaround is less then ideal (since if anyone did plug in a real apple keyboard this behaviour would be enforced for anything using hid_apple) so I was wondering if there was a way of fixing this "properly". I've never done any messing about of this sort before (first real issue I've ever had with linux device detection TBH) but after a wee dig around I found the following file which seems to suggest that all 05ac devices are always read as Apple keyboard devices: grep -nB1 Apple /lib/udev/hwdb.d/20-usb-vendor-model.hwdb 22796-usb:v05AC* 22797: ID_VENDOR_FROM_DATABASE=Apple, Inc. Ditto for the linux UDB ID repo: https://usb-ids.gowdy.us/read/UD/05ac/024f I realise this is probably fairly esoteric and I'm not sure why the KB seemingly has the same IDs as apple kit but is there a better workaround that can be done for keyboards based on e.g. the name? A quick mess around with udev rules didn't reveal any obvious ways of forcing any particular module. I have another Varmilo keyboard, a VA69M also with similar Fn key functionality that doesn't present this problem (but it doesn't present itself as an Apple keyboard either, it shows as a Holtek). -- Package-specific info: -- System Information: Debian Release: 10.4
Bug#920307: Acknowledgement (kodi: Kodi crashes when attempting to play video via VDPAU)
This is now fixed following the upgrade to Mesa 18.3.6 so it looks like my bug might be associated with this, "AMD Raven hang during va-api decoding"; https://bugs.freedesktop.org/show_bug.cgi?id=109648 Happy for this one to be closed.
Bug#920530: AppArmor breaks bind/named DLZ with samba
On 2019-01-27 21:18, intrigeri wrote:
Control: reassign -1 bind9
Control: user pkg-apparmor-t...@lists.alioth.debian.org
Control: usertag -1 + modify-profile
Control: tag -1 + moreinfo
Thanks for your report.
I'm reassigning to the package that ships this profile, because that's
where the problem can be fixed.
Thanks! I wasn't entirely sure which package team was ultimately responsible for
this.
I'm not familiar with the BIND/Samba integration and I've never
touched the usr.sbin.named profile myself, and I'm not sure who's
upstream for it (surely the maintainers of BIND will know), so just my
2 cts:
- Regarding the 2 lines about /usr/lib/..., they are probably already
covered by these lines from /etc/apparmor.d/abstractions/base,
which usr.sbin.named includes:
/{usr/,}lib/@{multiarch}/**r,
/{usr/,}lib/@{multiarch}/lib*.so* mr,
/{usr/,}lib/@{multiarch}/**/lib*.so* mr,
It would be nice to actually test whether they're needed.
The above sample rules don't feel crazy so I say go ahead,
experiment with them and find out if which ones are needed
and if they're enough :)
Thanks for the clarification. In my /etc/apparmor.d/usr.sbin.named however the
includes for abstractions/base and abstractions/nameservice are hashed out - I
certainly didn't comment these out myself. As the top of the file currently reads:
/usr/sbin/named flags=(complain) {
#include
#include
capability net_bind_service,
capability setgid,
capability setuid,
...
...
Other installations I have not in complain mode (as they've not got apparmour
installed) also have those includes commented out so I assume this is the
default setting.
- Regarding the 3 paths under /var/lib/samba/private: are they common
practice, well documented, or something you happened to come up
with locally?
If the former, and assuming they don't break a security boundary
that could be expected by users of BIND and Samba that do *not*
wish to integrate them with each other, then it would probably make
sense to add them to the profile.
If the latter, then I'm not sure what we can do except add
documentation and recommend users adapt the example rules
and add them to /etc/apparmor.d/local/usr.sbin.named.
I believe these are Debian-standard installation paths (all of the samba doc
seems to assume self-compiled install into /usr/local IIRC); all of the AD and
other information ends up living under /var/lib/samba/private by default - no
special smb.conf entries used for this. There are a number of other files in
this dir that have custom bind group permissions as well (particularly the
domain LDB files such as
/var/lib/samba/private/sam.ldb.d/DC=DOMAINDNSZONES,DC=DOMAIN,DC=NAME.ldb and
/var/lib/samba/private/sam.ldb.d/DC=FORESTDNSZONES,DC=DOMAIN,DC=NAME.ldb) but I
don't know if the permissions are shipped as-is or are a function of the domain
provision task.
As you say, for those not using bind with samba integration I'm not sure how the
config should be handled but I *think* the parts of /var/lib/samba/private
involved are all named-specific so having them enabled on a permanent basis
shouldn't represent a security risk (but again I'm not an expert).
- Regarding smb.conf, I would hope that DAC permissions would
prevent BIND from reading it if it was too crazy, right?
(I mean, BIND does not run as root, does it?)
AIUI there shouldn't be any reason bind shouldn't be able to read smb.conf as
it's world-readable by default and shouldn't contain any sensitive information,
however I'm unsure of what happens when apparmour enters the fray (I assume when
you say DAC you mean Discretionary Access Control, i.e. the apparmour rules?)
and whether this actually stops the file being read. This was merely taken from
the samba doc, I've not tested it myself yet but I didn't see any problem with it.
So all in all, if these rules work for you, I think the main
issue is about the possible security boundary violations.
Cheers,
I'll let you know when I get either the thumbs up to test or have time to
replicate on a test VM.
Bug#920530: apparmor: Apparmour breaks bind/named DLZ with samba
Package: apparmor Version: 2.11.0-3+deb9u2 Severity: normal Dear Maintainer, A piece of replacement kit went in requiring a newer kernel from backports, which brought in apparmour as a recommend. However in its currently shipping form this broke the bind DLZ that's used with samba (to host DNS for active directory). For those unfamiliar, DLZ = Dynamically Loadable Zone and the way it works is samba populates a zone file which bind is then pointed at to load. Once this was spotted we didn't have a great deal of time to fix it and I eventually just placed apparmour in complain mode for named to bypass the issue; aa-complain /usr/sbin/named I did try modifying some of the config in order to get bind/samba to work, but it was my first time trying to futz apparmour and I ultimately didn't get it working. I've since discovered samba have official info on apparmour here https://wiki.samba.org/index.php/BIND9_DLZ_AppArmor_and_SELinux_Integration - following on from that and what I've seen in kern.log I believe the debian configuration in /etc/apparmor.d/usr.sbin.named should contain something like: /usr/lib/x86_64-linux-gnu/samba/** rm, /usr/lib/x86_64-linux-gnu/ldb/modules/ldb/** rm, /var/lib/samba/private/dns.keytab r, /var/lib/samba/private/named.conf r, /var/lib/samba/private/dns/** rwk, /etc/smb.conf r, ...but obviously I'd like someone who knows what they're doing to have a look first as it's possible those permissions are too loose (like I say, I'm still a-learnin'). If and when I get an opportunity to test this I'll report back as to whether it works. -- System Information: Debian Release: 9.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages apparmor depends on: ii debconf [debconf-2.0] 1.5.61 ii init-system-helpers 1.48 ii libapparmor-perl 2.11.0-3+deb9u2 ii libc6 2.24-11+deb9u3 ii lsb-base 9.20161125 ii python3 3.5.3-1 apparmor recommends no packages. Versions of packages apparmor suggests: pn apparmor-profiles pn apparmor-profiles-extra ii apparmor-utils 2.11.0-3+deb9u2 -- debconf information: apparmor/homedirs:
Bug#920307: kodi: Kodi crashes when attempting to play video via VDPAU
Package: kodi Version: 2:17.6+dfsg1-4 Severity: normal Dear Maintainer, Following what looks like an upgrade of mesa earlier today, XBMC/kodi started crashing when attempting to play videos; disabling VDPAU allowed the videos to play, although hardware decoding is then not used (kodi shows ff-h264 in use as the decoder). Kodi starts up fine but when you attempt to play a video it crashes straight back to desktop and there's no explicit error message in the log. This error only seems to occur in kodi - for instance mpv is able to play back via VDPAU just fine if I use the --hwdec switch. Hardware involves an AMD 2400G (Raven Ridge) with the VCN hardware decode block which was working fine up until this morning. 21:00:47.939 T:139828740391680 NOTICE: Running on Debian GNU/Linux buster/sid testing, kernel: Linux x86 64-bit version 4.19.0-1-amd64 21:00:47.939 T:139828740391680 NOTICE: Host CPU: AMD Ryzen 5 2400G with Radeon Vega Graphics, 8 cores available 21:00:48.640 T:139828740391680 NOTICE: GL_RENDERER = AMD RAVEN (DRM 3.27.0, 4.19.0-1-amd64, LLVM 7.0.1) Not a big problem as falling back to software decode is a viable option for me but it might cause grief for others. Attached are: 1) excerpt from kodi.log showing a crash when VDPAU is enabled 2) another log showing the same file being played through software when VDPAU is disabled and VAAPI is enabled 3) aptitude log detailing the upgrades prior to this problem appearing -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kodi depends on: ii kodi-bin 2:17.6+dfsg1-4 ii kodi-data 2:17.6+dfsg1-4 Versions of packages kodi recommends: ii kodi-repository-kodi [kodi-repository] 2:17.6+dfsg1-4 pn kodi-visualization-spectrum kodi suggests no packages. -- no debconf information 20:17:27.581 T:140632108638976 NOTICE: VideoPlayer: Opening: /srv/Calibration.mkv 20:17:27.581 T:140632108638976 WARNING: CDVDMessageQueue(player)::Put MSGQ_NOT_INITIALIZED 20:17:27.582 T:140629224969984 NOTICE: Creating InputStream 20:17:27.628 T:140629224969984 NOTICE: Creating Demuxer 20:17:27.634 T:140629224969984 NOTICE: Opening stream: 0 source: 256 20:17:27.634 T:140629224969984 NOTICE: Creating video codec with codec id: 27 20:17:27.634 T:140629224969984 NOTICE: CDVDVideoCodecFFmpeg::Open() Using codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 20:17:27.635 T:140629224969984 NOTICE: Creating video thread 20:17:27.635 T:140629224969984 NOTICE: Opening stream: 1 source: 256 20:17:27.635 T:140629224969984 NOTICE: Finding audio codec for: 86076 20:17:27.635 T:140629224969984 NOTICE: Creating audio thread 20:17:27.635 T:140629224969984 NOTICE: Opening stream: 2 source: 256 20:17:27.635 T:140628604204800 NOTICE: running thread: CVideoPlayerAudio::Process() 20:17:27.635 T:140628092503808 NOTICE: running thread: video_thread 20:17:27.635 T:140628092503808 NOTICE: VAAPI::Close 20:17:27.640 T:140628092503808 NOTICE: CDVDVideoCodecFFmpeg::Open() Using codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 20:17:27.645 T:140628604204800 NOTICE: Creating audio stream (codec id: 86076, channels: 2, sample rate: 48000, no pass-through) 20:17:27.711 T:140632108638976 NOTICE: GL: Selecting Single Pass YUV 2 RGB shader 20:17:27.711 T:140632108638976 NOTICE: GL: NPOT texture support detected 20:17:27.711 T:140632108638976 NOTICE: GL: Using GL_ARB_pixel_buffer_object 20:17:27.711 T:140632108638976 NOTICE: Using GL_TEXTURE_2D 20:17:27.718 T:140632108638976 NOTICE: GL: Selecting Single Pass YUV 2 RGB shader 20:17:27.718 T:140632108638976 NOTICE: GL: NPOT texture support detected 20:17:27.718 T:140632108638976 NOTICE: GL: Using GL_ARB_pixel_buffer_object 20:17:28.277 T:140628092503808 NOTICE: CDVDVideoCodecFFmpeg::CDropControl: calculated diff time: 4 20:17:47.377 T:140632108638976 NOTICE: CVideoPlayer::CloseFile() 20:17:47.377 T:140632108638976 NOTICE: VideoPlayer: waiting for threads to exit 20:17:47.377 T:140629224969984 NOTICE: CVideoPlayer::OnExit() 20:17:47.377 T:140629224969984 NOTICE: Closing stream player 1 20:17:47.377 T:140629224969984 NOTICE: Waiting for audio thread to exit 20:17:47.415 T:140628604204800 NOTICE: thread end: CVideoPlayerAudio::OnExit() 20:17:47.415 T:140629224969984 NOTICE: Closing audio device 20:17:47.465 T:140629224969984 NOTICE: Deleting audio codec 20:17:47.465 T:140629224969984 NOTICE: Closing stream player 2 20:17:47.465 T:140629224969984 NOTICE: waiting for video thread to exit 20:17:47.476 T:140628092503808 NOTICE: thread end: video_thread 20:17:47.477 T:140629224969984 NOTICE: deleting video codec
Bug#916798: Acknowledgement (firmware-iwlwifi 20180825+dfsg-1 breaks bluetooth on Intel 8265)
I've just upgraded to the latest firmware-iwlwifi_20190114-1_all.deb and I can confirm that the problem with bluetooth on the 8265 is now fixed so this bug report can be closed from my point of view. Thanks. P.S. Incidentally, the e91976c0 firmware for the wifi I was using previously also fixed all of the problems I was having with my wifi connection in earlier versions - even to the extent I no longer needed to specify any special options (mostly 11n_disable=1 and bt_coex_active=0 to attain a semi-reliable connection). I'll commence testing with the newer 9f0a2d68 version included in this release and make good on my threat to open a separate bug report if I run into any further problems.
Bug#916798: Acknowledgement (firmware-iwlwifi 20180825+dfsg-1 breaks bluetooth on Intel 8265)
Had some time for some manual tweaking on this today, so on a whim I wanted to see if the latest firmware from the kernel git repo worked. Currently with: a) the current bluetooth firmware from firmware-iwlwifi 20180518-1 b) the latest iwlwifi-8265-36.ucode from the kernel git (36.9f0a2d68.0 according to dmesg) ...I can confirm that the bluetooth firmware loads and the adapter works correctly. With the version included in 20180825+dfsg-1 (36.e91976c0.0 according to the changelog), the bluetooth firmware fails to load as per my original report. At the moment I've no idea which of the firmware files inside /lib/firmware/intel correspond to the bluetooth firmware for this chip so I've left those alone for the time being. On 2018-12-18 18:21, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 916798: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916798. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Kernel Team If you wish to submit further information on this problem, please send it to 916...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
Bug#916798: firmware-iwlwifi 20180825+dfsg-1 breaks bluetooth on Intel 8265
Subject: firmware-iwlwifi 20180825+dfsg-1 breaks bluetooth on Intel 8265 Package: firmware-iwlwifi Version: 20180825+dfsg-1 Severity: important I've been having problems with my new Intel wireless; I think I've actually got two problems here, one with 802.11x being unusably slow and one with bluetooth, so I'm doing my best to separate them into two different bug reports. This is the bluetooth one. I saw there were a couple of other "bluetooth not working" bugs but from a quick look through them none seemed to specifically apply to the 8265 so I felt it warranted a separate report. Long story short, bluetooth broke on this machine some time ago (my logs don't go back far enough) but I didn't notice at the time since bluetooth doesn't get used very much on this machine. Suffice to say that some time ago bluetooth stopped working - hci0 was never properly initialised. In dmesg I would get messages like the following (only showing blue|firm lines for the sake of brevity): Dec 9 19:49:00 raventest kernel: [ 3.865280] iwlwifi :24:00.0: firmware: direct-loading firmware iwlwifi-8265-36.ucode Dec 9 19:49:00 raventest kernel: [ 3.866366] iwlwifi :24:00.0: loaded firmware version 36.e91976c0.0 op_mode iwlmvm Dec 9 19:49:00 raventest kernel: [ 3.899700] Bluetooth: Core ver 2.22 Dec 9 19:49:00 raventest kernel: [ 3.899885] Bluetooth: HCI device and connection manager initialized Dec 9 19:49:00 raventest kernel: [ 3.899980] Bluetooth: HCI socket layer initialized Dec 9 19:49:00 raventest kernel: [ 3.900081] Bluetooth: L2CAP socket layer initialized Dec 9 19:49:00 raventest kernel: [ 3.900172] Bluetooth: SCO socket layer initialized Dec 9 19:49:00 raventest kernel: [ 3.935909] amdgpu :38:00.0: firmware: direct-loading firmware amdgpu/raven_gpu_info.bin Dec 9 19:49:00 raventest kernel: [ 3.961163] amdgpu :38:00.0: firmware: direct-loading firmware amdgpu/raven_asd.bin Dec 9 19:49:00 raventest kernel: [ 3.961898] amdgpu :38:00.0: firmware: direct-loading firmware amdgpu/raven_pfp.bin Dec 9 19:49:00 raventest kernel: [ 3.962113] amdgpu :38:00.0: firmware: direct-loading firmware amdgpu/raven_me.bin Dec 9 19:49:00 raventest kernel: [ 3.962455] amdgpu :38:00.0: firmware: direct-loading firmware amdgpu/raven_ce.bin Dec 9 19:49:00 raventest kernel: [ 3.963207] amdgpu :38:00.0: firmware: direct-loading firmware amdgpu/raven_rlc.bin Dec 9 19:49:00 raventest kernel: [ 3.964847] amdgpu :38:00.0: firmware: direct-loading firmware amdgpu/raven_mec.bin Dec 9 19:49:00 raventest kernel: [ 3.966346] amdgpu :38:00.0: firmware: direct-loading firmware amdgpu/raven_mec2.bin Dec 9 19:49:00 raventest kernel: [ 3.969347] amdgpu :38:00.0: firmware: direct-loading firmware amdgpu/raven_sdma.bin Dec 9 19:49:00 raventest kernel: [ 3.970821] amdgpu :38:00.0: firmware: direct-loading firmware amdgpu/raven_vcn.bin Dec 9 19:49:00 raventest kernel: [ 3.970919] [drm] Found VCN firmware Version: 1.73 Family ID: 18 Dec 9 19:49:00 raventest kernel: [ 3.970992] [drm] PSP loading VCN firmware Dec 9 19:49:00 raventest kernel: [ 4.498604] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Dec 9 19:49:00 raventest kernel: [ 4.498633] Bluetooth: BNEP filters: protocol multicast Dec 9 19:49:00 raventest kernel: [ 4.498663] Bluetooth: BNEP socket layer initialized Dec 9 19:49:01 raventest kernel: [ 5.952054] Bluetooth: hci0: command 0xfc05 tx timeout Dec 9 19:49:01 raventest kernel: [ 5.952153] Bluetooth: hci0: Reading Intel version information failed (-110) Dec 11 12:30:56 raventest kernel: [ 7369.237678] (NULL device *): firmware: direct-loading firmware iwlwifi-8265-36.ucode Dec 11 12:30:58 raventest kernel: [ 7378.282026] Bluetooth: hci0: command 0xfc05 tx timeout Dec 11 12:30:58 raventest kernel: [ 7378.286310] Bluetooth: hci0: Reading Intel version information failed (-110) Specifically the absence of the firmware beng loaded, and the following errors; Bluetooth: hci0: command 0xfc05 tx timeout Bluetooth: hci0: Reading Intel version information failed (-110) On tracking back through the changelogs I saw that firmware-iwlwifi_20180825 included new bluetooth firmware for the 8265; I downgraded to firmware-iwlwifi_20180518-1_all and now bluetooth initialises correctly again, dmesg|egrep 'blue|firm' from the latest boot below: Dec 18 16:29:53 raventest kernel: [ 0.087954] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored Dec 18 16:29:53 raventest kernel: [ 0.100678] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain [bus 00-3f] only partially covers this bridge Dec 18 16:29:53 raventest kernel: [ 3.718337] iwlwifi :24:00.0: firmware: direct-loading firmware iwlwifi-8265-36.ucode Dec 18 16:29:53 raventest kernel: [ 3.719238] iwlwifi :24:00.0: loaded firmware version 36.e91976c0.0 op_mode iwlmvm Dec 18 16:29:53 raventest kernel:
Bug#782416: Info received (Bug#782416: Bonded interface hanging on shutdown/restart)
I think this bug might have been fixed with the kernel upgrade to linux-image-3.16.0-4-amd64; the server where this went in (before the release to stable jessie) had this problem evaporate. As far as I can tell there've been no updates to ifupdown since then, so perhaps an upgrade to the igb driver...? Anyway, on at least two systems that were experiencing the bug, shutdown/network restart no longer hangs. On 2015-04-14 20:42, Debian Bug Tracking System wrote: Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Guus Sliepen g...@debian.org If you wish to submit further information on this problem, please send it to 782...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782416: Bonded interface hanging on shutdown/restart
Package: ifenslave Version: 2.6 Followup-For: Bug #782416 Dear Maintainer, *** trimmed *** -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages ifenslave depends on: ii ifupdown 0.7.53.1 ii iproute2 3.16.0-2 Versions of packages ifenslave recommends: ii net-tools 1.60-26+b1 ifenslave suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782416: Bonded interface hanging on shutdown/restart
Apologies for the slightly disjointed replies, this server doesn't have internet or outgoing SMTP access. On 2015-04-11 23:26, Dmitry Smirnov wrote: Do you have package network-manager installed? No, this is a CLI-only install. What is the version of ifupdown on your system? ifupdown is version 0.7.53.1. As mentioned below I now see that this was recently updated prior to observing the fault (all these years and I'd forgotted about history.log, embarrassing!). May be you could track down which package caused regression by analysing /var/log/apt/history.log? The latest range of updates is listed below; I didn't include them earlier since there didn't seem to be anything related to the network/scripts but I notice now that a new version of ifupdown was installed. The latest round of updates today (namely initscripts) haven't solved the issue either. Start-Date: 2015-04-09 23:44:06 Upgrade: geoip-database:amd64 (20150209-1, 20150317-1), libavformat56:amd64 (11.2-1, 11.3-1), apache2-utils:amd64 (2.4.10-9, 2.4.10-10), libavresample2:amd64 (11.2-1, 11.3-1), gdisk:amd64 (0.8.10-1, 0.8.10-2), libavfilter5:amd64 (11.2-1, 11.3-1), multiarch-support:amd64 (2.19-15, 2.19-17), perl:amd64 (5.20.2-2, 5.20.2-3), bsd-mailx:amd64 (8.1.2-0.20141216cvs-1, 8.1.2-0.20141216cvs-2), python-minimal:amd64 (2.7.8-4, 2.7.9-1), libssl1.0.0:amd64 (1.0.1k-1, 1.0.1k-3), perl-base:amd64 (5.20.2-2, 5.20.2-3), libgssapi-krb5-2:amd64 (1.12.1+dfsg-18, 1.12.1+dfsg-19), libapache2-mod-php5:amd64 (5.6.6+dfsg-2, 5.6.7+dfsg-1), debconf:amd64 (1.5.55, 1.5.56), libicu52:amd64 (52.1-7.1, 52.1-8), python-pil:amd64 (2.6.1-1+b1, 2.6.1-2), php5-common:amd64 (5.6.6+dfsg-2, 5.6.7+dfsg-1), coreutils:amd64 (8.23-3, 8.23-4), libkrb5-3:amd64 (1.12.1+dfsg-18, 1.12.1+dfsg-19), vim-common:amd64 (7.4.488-4, 7.4.488-6), util-linux-locales:amd64 (2.25.2-5, 2.25.2-6), console-setup:amd64 (1.118, 1.120), console-setup-linux:amd64 (1.118, 1.120), libsmartcols1:amd64 (2.25.2-5, 2.25.2-6), libtiff5:amd64 (4.0.3-12.1, 4.0.3-12.3), mount:amd64 (2.25.2-5, 2.25.2-6), libbz2-1.0:amd64 (1.0.6-7+b2, 1.0.6-7+b3), grub-common:amd64 (2.02~beta2-21, 2.02~beta2-22), file:amd64 (5.22+15-1, 5.22+15-2), libmagic1:amd64 (5.22+15-1, 5.22+15-2), libc-bin:amd64 (2.19-15, 2.19-17), libc6:amd64 (2.19-15, 2.19-17), php5-readline:amd64 (5.6.6+dfsg-2, 5.6.7+dfsg-1), libuuid1:amd64 (2.25.2-5, 2.25.2-6), libmount1:amd64 (2.25.2-5, 2.25.2-6), php5:amd64 (5.6.6+dfsg-2, 5.6.7+dfsg-1), libperl5.20:amd64 (5.20.2-2, 5.20.2-3), udev:amd64 (215-12, 215-14), ifupdown:amd64 (0.7.52, 0.7.53.1), librtmp1:amd64 (2.4+20131018.git79459a2-5, 2.4+20150115.gita107cef-1), libcap2:amd64 (2.24-6, 2.24-8), grub2-common:amd64 (2.02~beta2-21, 2.02~beta2-22), libswscale3:amd64 (11.2-1, 11.3-1), debconf-i18n:amd64 (1.5.55, 1.5.56), krb5-locales:amd64 (1.12.1+dfsg-18, 1.12.1+dfsg-19), libssh2-1:amd64 (1.4.3-4, 1.4.3-4.1), bzip2:amd64 (1.0.6-7+b2, 1.0.6-7+b3), libudev1:amd64 (215-12, 215-14), bsdutils:amd64 (2.25.2-5, 2.25.2-6), perl-modules:amd64 (5.20.2-2, 5.20.2-3), vim-tiny:amd64 (7.4.488-4, 7.4.488-6), libav-tools:amd64 (11.2-1, 11.3-1), installation-report:amd64 (2.57, 2.58), php5-xsl:amd64 (5.6.6+dfsg-2, 5.6.7+dfsg-1), php5-cli:amd64 (5.6.6+dfsg-2, 5.6.7+dfsg-1), grub-pc-bin:amd64 (2.02~beta2-21, 2.02~beta2-22), apache2-data:amd64 (2.4.10-9, 2.4.10-10), python:amd64 (2.7.8-4, 2.7.9-1), python-pygments:amd64 (2.0.1+dfsg-1, 2.0.1+dfsg-1.1), grub-pc:amd64 (2.02~beta2-21, 2.02~beta2-22), libmp3lame0:amd64 (3.99.5+repack1-6, 3.99.5+repack1-7), vim:amd64 (7.4.488-4, 7.4.488-6), libpython-stdlib:amd64 (2.7.8-4, 2.7.9-1), keyboard-configuration:amd64 (1.118, 1.120), libblkid1:amd64 (2.25.2-5, 2.25.2-6), libavcodec56:amd64 (11.2-1, 11.3-1), libavdevice55:amd64 (11.2-1, 11.3-1), apache2:amd64 (2.4.10-9, 2.4.10-10), tzdata:amd64 (2015a-1, 2015b-1), openssl:amd64 (1.0.1k-1, 1.0.1k-3), libjpeg62-turbo:amd64 (1.3.1-11+deb7u1, 1.3.1-12), apache2-bin:amd64 (2.4.10-9, 2.4.10-10), libsystemd0:amd64 (215-12, 215-14), util-linux:amd64 (2.25.2-5, 2.25.2-6), whois:amd64 (5.2.5, 5.2.7), rtmpdump:amd64 (2.4+20131018.git79459a2-5, 2.4+20150115.gita107cef-1), locales:amd64 (2.19-15, 2.19-17), libkrb5support0:amd64 (1.12.1+dfsg-18, 1.12.1+dfsg-19), libk5crypto3:amd64 (1.12.1+dfsg-18, 1.12.1+dfsg-19), libavutil54:amd64 (11.2-1, 11.3-1), libcap2-bin:amd64 (2.24-6, 2.24-8), vim-runtime:amd64 (7.4.488-4, 7.4.488-6), libgcrypt20:amd64 (1.6.2-4+b1, 1.6.3-2) End-Date: 2015-04-09 23:45:42 Start-Date: 2015-04-10 18:50:19 Upgrade: libtasn1-6:amd64 (4.2-2, 4.2-3) End-Date: 2015-04-10 18:50:19 Start-Date: 2015-04-14 03:45:24 Upgrade: initscripts:amd64 (2.88dsf-58, 2.88dsf-59), sysvinit:amd64 (2.88dsf-58, 2.88dsf-59), vim-common:amd64 (7.4.488-6, 7.4.488-7), sysvinit-core:amd64 (2.88dsf-58, 2.88dsf-59), vim-tiny:amd64 (7.4.488-6, 7.4.488-7), sysv-rc:amd64 (2.88dsf-58, 2.88dsf-59), vim:amd64 (7.4.488-6, 7.4.488-7), sysvinit-utils:amd64
Bug#782416: Bonded interface hanging on shutdown/restart
Package: ifenslave-2.6 Version: 2.6 One of my servers running Jessie hung on restart today and has been continuing to do so; rebooting now requires a hard reset be invoked over IPMI. When shutting down the last message displayed on the console was deconfiguring network interfaces. After doing some digging, the part of the init script that was failing was the segment that ran `ifdown -a --exclude lo`; if I run this manually I can trigger the same behaviour. After 120s the system console reports hung tasks belonging to kworker and ifenslave. Corresponding to these are faults/call traces reported in dmesg also belonging to ifenslave. Images of both are available on request (grabbed these from the BMC as and when I saw them), will try to extract them as text on the next available reboot slot. This behaviour only became apparent after the last round of updates went in - was working/rebooting perfectly fine a week ago. Hardware is an ASRock E3C224D2I with two Intel i210 NICs (igb driver). /etc/network/interfaces is as follows: auto lo iface lo inet loopback # The primary network interface auto bond0 iface bond0 inet static address 192.168.1.128 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 slaves eth0 eth1 bond_mode active-backup bond_miimon 250 bond_downdelay 250 bond_updelay 250 ifconfig from the running system as follows: bond0 Link encap:Ethernet HWaddr d0:50:99:26:4d:08 inet addr:192.168.1.128 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::d250:99ff:fe26:4d08/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:637 errors:0 dropped:0 overruns:0 frame:0 TX packets:492 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:419400 (409.5 KiB) TX bytes:62871 (61.3 KiB) eth0 Link encap:Ethernet HWaddr d0:50:99:26:4d:08 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:637 errors:0 dropped:0 overruns:0 frame:0 TX packets:492 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:419400 (409.5 KiB) TX bytes:62871 (61.3 KiB) Memory:f720-f727 eth1 Link encap:Ethernet HWaddr d0:50:99:26:4d:08 UP BROADCAST SLAVE MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Memory:f710-f717 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:188 (188.0 B) TX bytes:188 (188.0 B) Please let me know if there are any other investigations I can carry out to verify the cause. I don't know if it's related but the system only has one NIC plugged in at present. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
