[Desktop-packages] [Bug 1393502] Re: [MacBookPro11, 3, Cirrus Logic CS4208, Pink Mic] Combo jack not recognized.
Same issue on Macbook Pro 11,4 19.04. Please fix. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1393502 Title: [MacBookPro11,3, Cirrus Logic CS4208, Pink Mic] Combo jack not recognized. Status in alsa-driver package in Ubuntu: Confirmed Bug description: New Macbook comes with a four-conductor TRRS jack for headset. With headset plugged in the microfone is recognized on Mac os-x. Ubuntu recognizes the external headphones but not the microphone. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: alsa-base 1.0.25+dfsg-0ubuntu4 ProcVersionSignature: Ubuntu 3.16.0-23.31-generic 3.16.4 Uname: Linux 3.16.0-23-generic x86_64 NonfreeKernelModules: nvidia wl ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: mikaelb2403 F pulseaudio /dev/snd/controlC0: mikaelb2403 F pulseaudio CurrentDesktop: Unity Date: Mon Nov 17 18:58:35 2014 InstallationDate: Installed on 2014-10-20 (28 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_Jack: Pink Mic, N/A Symptom_Type: No auto-switch between inputs Title: [MacBookPro11,3, Cirrus Logic CS4208, Pink Mic, N/A] No autoswitch UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/12/2014 dmi.bios.vendor: Apple Inc. dmi.bios.version: MBP112.88Z.0138.B07.1402121134 dmi.board.asset.tag: Base Board Asset Tag# dmi.board.name: Mac-2BD1B31983FE1663 dmi.board.vendor: Apple Inc. dmi.board.version: MacBookPro11,3 dmi.chassis.type: 10 dmi.chassis.vendor: Apple Inc. dmi.chassis.version: Mac-2BD1B31983FE1663 dmi.modalias: dmi:bvnAppleInc.:bvrMBP112.88Z.0138.B07.1402121134:bd02/12/2014:svnAppleInc.:pnMacBookPro11,3:pvr1.0:rvnAppleInc.:rnMac-2BD1B31983FE1663:rvrMacBookPro11,3:cvnAppleInc.:ct10:cvrMac-2BD1B31983FE1663: dmi.product.name: MacBookPro11,3 dmi.product.version: 1.0 dmi.sys.vendor: Apple Inc. mtime.conffile..etc.modprobe.d.alsa.base.conf: 2014-11-10T22:25:45.211791 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1393502/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1688018] Re: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6
... and my issue is now resolved in Ubuntu 17.10, at least on a fresh install. Not sure what changed, but no changes are necessary to /etc/nsswitch.conf in order to make resolving DNS work with internal domains while connect to openconnect VPN. Probably I should stick with LTS :-) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1688018 Title: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6 Status in network-manager package in Ubuntu: Triaged Status in network-manager source package in Xenial: In Progress Status in network-manager source package in Yakkety: Triaged Bug description: This was initially opened as #1671606 then later duped to #1639776. Discussion in #1639776 indicate that we need new bug for this so I am opening one ... Please don't mark this as duplicate to #1639776 or other similar bug report. We already lost several months and we are again at beginning ... TL;DR; -> network-manager-1.2.2-0ubuntu0.16.04.4 use DNS defined by VPN (correct). network-manager-1.2.6-0ubuntu0.16.04.1 use DNS from DHCP instead of one defined by VPN (wrong). DNS resolver should query only DNS servers defined by VPN while connection is active. = Test steps / result: - upgraded network-manager to 1.2.6-0ubuntu0.16.04.1 (dnsmasq-base-2.75-1ubuntu0.16.04.2) - restated my laptop to ensure clean start - connected to VPN using openconnect / network-manager-openconnect-gnome Observed results -> DNS queries are forwarded only to DNS servers defined by LAN connection (this is wrong / connection not working at all) - "killall dnsmasq" - dnsmasq get automatically restarted by system Observed results -> most of the the queries are forwarded to DNS servers defined by VPN, but lot of queries get forwarded to DNS servers defined by LAN connection (this is still wrong / DNS leaks, attacker can hijack connection even if VPN is enabled) - I downgraded back network-manager to 1.2.2-0ubuntu0.16.04.4 (dnsmasq-base stay same) - restated my laptop to ensure clean test - connected to same VPN using openconnect Observed results -> DNS queries are forwarded only to DNS servers defined by VPN connection. There are no leaks to LAN DNS server (this is correct behavior). = Paul Smith requested additional details in #1639776. Here are: * If you're using IPv4 vs. IPv6 -> IPv4 only. I have IPv6 set to ignore on all network definition (lan / wifi /vpn) * If you have checked or unchecked the "Use this connection only for resources on its network" -> unchecked on all nw definition * If you have this checked, try unchecking it and see if that makes a difference -> no change if I toggle this option. Behavior is same. * When you say "DNS lookups" please be clear about whether the hostnames being looked up are public (e.g., www.google.com or whatever), on your local LAN, or in the network accessed via the VPN. Does it make a difference which one you choose? -> No difference. * Are you using fully-qualified hostnames, or relying on the DNS domain search path? Does it make a difference if you do it differently? -> I normaly use FQDN due to nature of HTTPs cert validation. I don't see difference when I try same using hostname + domain search. = I am using openconnect (cisco) and openvpn. Test result are by using openconnect but I saw same behaviour also while using openvpn. = Thanks Lukas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1688018/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1688018] Re: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6
I don't know if my issue is related to this or the few others I've seen, so I pre-apologize if this should be moved elsewhere or even if it's not relevant in this context. I'm far from an expert in DNS . . . My experience was that after upgrading to 16.10 (or higher: it happens in 17.10, too, and I imagine it will in 18.04). DNS lookup for internal sites would fail when I was connected to an openconnect VPN. In 16.04, my workaround was to comment out dnsmasq in NetworkManager.conf, but in 16.10, 17.04, and 18.04, this option no longer appeared. Also, I additionally had to comment out a reference to a local host in /etc/resolv.conf, which was added below the VPN-only nameservers, which in my case were sufficient. Recently, I tried Fedora 25 and was surprised to see the same issue -- this suggests it's not an Ubuntu-specific problem, unless Canonical is providing some libs that Fedora is using, I don't know. I found this workaround for my particular case while again searching in a Fedora context for a workaround: https://www.freedesktop.org/software/systemd/man/nss-resolve.html TL;DR: I added "resolve [!UNAVAIL=return]" to the hosts line in /etc/nsswitch.conf right before any entry that has "dns" in it. This worked for me in Fedora and Ubuntu both. (Note that in the latest Arch release, this was not an issue for me.) I'm hoping that this comment will prove helpful to anyone like me who might be searching in vain for a workaround. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1688018 Title: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6 Status in network-manager package in Ubuntu: Triaged Status in network-manager source package in Xenial: In Progress Status in network-manager source package in Yakkety: Triaged Bug description: This was initially opened as #1671606 then later duped to #1639776. Discussion in #1639776 indicate that we need new bug for this so I am opening one ... Please don't mark this as duplicate to #1639776 or other similar bug report. We already lost several months and we are again at beginning ... TL;DR; -> network-manager-1.2.2-0ubuntu0.16.04.4 use DNS defined by VPN (correct). network-manager-1.2.6-0ubuntu0.16.04.1 use DNS from DHCP instead of one defined by VPN (wrong). DNS resolver should query only DNS servers defined by VPN while connection is active. = Test steps / result: - upgraded network-manager to 1.2.6-0ubuntu0.16.04.1 (dnsmasq-base-2.75-1ubuntu0.16.04.2) - restated my laptop to ensure clean start - connected to VPN using openconnect / network-manager-openconnect-gnome Observed results -> DNS queries are forwarded only to DNS servers defined by LAN connection (this is wrong / connection not working at all) - "killall dnsmasq" - dnsmasq get automatically restarted by system Observed results -> most of the the queries are forwarded to DNS servers defined by VPN, but lot of queries get forwarded to DNS servers defined by LAN connection (this is still wrong / DNS leaks, attacker can hijack connection even if VPN is enabled) - I downgraded back network-manager to 1.2.2-0ubuntu0.16.04.4 (dnsmasq-base stay same) - restated my laptop to ensure clean test - connected to same VPN using openconnect Observed results -> DNS queries are forwarded only to DNS servers defined by VPN connection. There are no leaks to LAN DNS server (this is correct behavior). = Paul Smith requested additional details in #1639776. Here are: * If you're using IPv4 vs. IPv6 -> IPv4 only. I have IPv6 set to ignore on all network definition (lan / wifi /vpn) * If you have checked or unchecked the "Use this connection only for resources on its network" -> unchecked on all nw definition * If you have this checked, try unchecking it and see if that makes a difference -> no change if I toggle this option. Behavior is same. * When you say "DNS lookups" please be clear about whether the hostnames being looked up are public (e.g., www.google.com or whatever), on your local LAN, or in the network accessed via the VPN. Does it make a difference which one you choose? -> No difference. * Are you using fully-qualified hostnames, or relying on the DNS domain search path? Does it make a difference if you do it differently? -> I normaly use FQDN due to nature of HTTPs cert validation. I don't see difference when I try same using hostname + domain search. = I am using openconnect (cisco) and openvpn. Test result are by using openconnect but I saw same behaviour also while using openvpn. = Thanks Lukas To manage notifications about this bug go to:
[Desktop-packages] [Bug 1631086] [NEW] Resume from suspend works only once after reboot macbook pro 11, 4
Public bug reported: Macbook Pro 11,4 until recently was unable to shutdown or suspend due to a kernel bug. Fortunately, an (unofficial?) "quirks.c" kernel patch was released that fixed the problem . . . almost. On a stock install of 16.04.1 on a macbook pro 11,4, with no external monitors connected, suspend and shutdown do work correctly except: To reproduce the problem: 1. Install 16.04.1 on a macbook pro 11,4 2. Boot 3. Sign in 4. Shut the lid, wait for suspend 5. Open the lid 6. Sign in 7. Shut the lid, wait for suspend 8. Open the lid 9. Screen shows lightdm login for perhaps a quarter of a second and then goes black. Note that the suspend/wake cycle does work the first time after a reboot. Also note that the suspend/wake cycle works fine when you use an external monitor with the lid always closed. The problem only occurs when you used the laptop screen only. Workaround for me to avoid hard shutdown all the time: 1. Create a keyboard shortcut for "xset s activate" 2. In blank screen, type password 3. Activate keyboard shortcut and the screen comes back ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: xorg 1:7.7+13ubuntu3 ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19 Uname: Linux 4.4.0-38-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true CurrentDesktop: Unity Date: Thu Oct 6 13:22:29 2016 DistUpgraded: Fresh install DistroCodename: xenial DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation Crystal Well Integrated Graphics Controller [8086:0d26] (rev 08) (prog-if 00 [VGA controller]) Subsystem: Apple Inc. Crystal Well Integrated Graphics Controller [106b:0147] InstallationDate: Installed on 2016-10-05 (1 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) MachineType: Apple Inc. MacBookPro11,4 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-38-generic.efi.signed root=UUID=891cc2ac-fe31-4ad2-a08e-177007c9141c ro quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/15/2016 dmi.bios.vendor: Apple Inc. dmi.bios.version: MBP114.88Z.0172.B09.1602151732 dmi.board.name: Mac-06F11FD93F0323C5 dmi.board.vendor: Apple Inc. dmi.board.version: MacBookPro11,4 dmi.chassis.type: 9 dmi.chassis.vendor: Apple Inc. dmi.chassis.version: Mac-06F11FD93F0323C5 dmi.modalias: dmi:bvnAppleInc.:bvrMBP114.88Z.0172.B09.1602151732:bd02/15/2016:svnAppleInc.:pnMacBookPro11,4:pvr1.0:rvnAppleInc.:rnMac-06F11FD93F0323C5:rvrMacBookPro11,4:cvnAppleInc.:ct9:cvrMac-06F11FD93F0323C5: dmi.product.name: MacBookPro11,4 dmi.product.version: 1.0 dmi.sys.vendor: Apple Inc. version.compiz: compiz 1:0.9.12.2+16.04.20160823-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.67-1ubuntu0.16.04.2 version.libgl1-mesa-dri: libgl1-mesa-dri 11.2.0-1ubuntu2.2 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 11.2.0-1ubuntu2.2 version.xserver-xorg-core: xserver-xorg-core 2:1.18.3-1ubuntu2.2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20160325-1ubuntu1.1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.12-1build2 xserver.bootTime: Thu Oct 6 10:10:15 2016 xserver.configfile: default xserver.errors: xserver.logfile: /var/log/Xorg.0.log xserver.outputs: product id 41007 vendor APP xserver.version: 2:1.18.3-1ubuntu2.2 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug compiz-0.9 ubuntu xenial -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1631086 Title: Resume from suspend works only once after reboot macbook pro 11,4 Status in xorg package in Ubuntu: New Bug description: Macbook Pro 11,4 until recently was unable to shutdown or suspend due to a kernel bug. Fortunately, an (unofficial?) "quirks.c" kernel patch was released that fixed the problem . . . almost. On a stock install of 16.04.1 on a macbook pro 11,4, with no external monitors connected, suspend and shutdown do work correctly except: To reproduce the problem: 1. Install 16.04.1 on a macbook pro 11,4 2. Boot 3. Sign in 4. Shut the lid, wait for suspend 5. Open the lid 6. Sign in 7. Shut the lid, wait for suspend 8. Open the lid 9. Screen shows lightdm login for perhaps a quarter of a second and then goes black. Note that the suspend/wake cycle
