[Touch-packages] [Bug 1822416] Re: resolve: do not hit CNAME or DNAME entry in NODATA cache

2019-04-08 Thread Chiang Fong Lee
*** This bug is a duplicate of bug 1818527 ***
https://bugs.launchpad.net/bugs/1818527

** This bug has been marked a duplicate of bug 1818527
   Stub resolver cache is corrupted

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1822416

Title:
  resolve: do not hit CNAME or DNAME entry in NODATA cache

Status in systemd package in Ubuntu:
  New

Bug description:
  The question: DNS A record lookups fail to resolve due to cached CNAME
  NODATA lookups ...

  https://askubuntu.com/questions/1063462/18-04-server-systemd-resolve-
  returns-cached-cname-nodata-for-a-lookup

  Upstream at Github: Systemd issue 998 - Cached cname NODATA returned
  for A lookup ...

  https://github.com/systemd/systemd/issues/9833

  
  Please patch ...

  
https://github.com/systemd/systemd/commit/3740146a4cbd99883af79e375ee4836206dcea4e

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1822416/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1818527] Re: Stub resolver cache is corrupted

2019-04-08 Thread Chiang Fong Lee
This seems to be the same issue previously reported at
https://github.com/systemd/systemd/issues/9833, which was fixed in
https://github.com/systemd/systemd/pull/9836 (commit 3740146) and
released in v240.

** Bug watch added: github.com/systemd/systemd/issues #9833
   https://github.com/systemd/systemd/issues/9833

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1818527

Title:
  Stub resolver cache is corrupted

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  It seems that when systemd-resolve cache an non-existent CNAME record
  for a domain, any attempt to resolve A record for the same domain
  fail.

  systemd version the issue has been seen with
  Installed: 237-3ubuntu10.13
  Used distribution

  Distributor ID: Ubuntu
  Description: Ubuntu 18.04.2 LTS
  Release: 18.04
  Codename: bionic

  Expected behaviour you didn't see

  Return A record for a domain when it exists.

  Unexpected behaviour you saw

  Resolution failed.

  Steps to reproduce the problem

  Whait for 1 minutes (github.com TTL for A record)

  Try to resolv github.com CNAME record dig CNAME github.com

  This will return an empty result.

  Then try to resolve github.com A record dig A github.com.

  This will now return empty result unless you restart systemd-resolved
  or wait for cache expiration.

  At the same time using another DNS will resolve correctly dig A
  github.com @8.8.8.8.

  Exemple :

  Wait for 1 minutes to let cache expire, then run

  dig CNAME github.com
  dig A github.com
  # no result
  dig A github.com @8.8.8.8
  # ;; ANSWER SECTION:
  # github.com. 59  IN  A   192.30.253.113
  # github.com. 59  IN  A   192.30.253.112

  PS: Don't forget to restart systemd-resolve, before trying to post an
  answer.

  This bug was first reported in github
  https://github.com/systemd/systemd/issues/11789 but systemd version in
  ubuntu is too  old.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818527/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1316017] Re: openssh client ignores -o Tunnel=ethernet option, creating an IP tunnel device instead of an ethernet tap device

2015-06-22 Thread Chiang Fong Lee
As I just noted on the upstream bug
(https://bugzilla.mindrot.org/show_bug.cgi?id=2365), the -o
Tunnel=ethernet option needs to be before the -w option. Then, the
tap device should be created as expected.

** Bug watch added: OpenSSH Portable Bugzilla #2365
   https://bugzilla.mindrot.org/show_bug.cgi?id=2365

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1316017

Title:
  openssh client ignores -o Tunnel=ethernet option, creating an IP
  tunnel device instead of an ethernet tap device

Status in openssh package in Ubuntu:
  Confirmed

Bug description:
  This is a regression from the version of the client in 14.04 compared
  to 13.10. I'm connecting to 12.04.4 for a server.

  Expected behaviour:
  Creating a connection with the option -o Tunnel=ethernet will create a 
layer2 ethernet tap device.

  Actual behaviour:
  New client creates a  layer3 IP tunnel.

  The old version of the client that works properly (installed manually on 
14.04):
  OpenSSH_6.2p2 Ubuntu-6ubuntu0.3, OpenSSL 1.0.1f 6 Jan 2014

  The new version of the client that does not work properly:
  OpenSSH_6.6p1 Ubuntu-2ubuntu1, OpenSSL 1.0.1f 6 Jan 2014

  The version of the SSH server I'm connecting to:
  openssh-server:
Installed: 1:5.9p1-5ubuntu1.3
Candidate: 1:5.9p1-5ubuntu1.3
Version table:
   *** 1:5.9p1-5ubuntu1.3 0
  500 http://us.archive.ubuntu.com/ubuntu/ precise-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:5.9p1-5ubuntu1 0
  500 http://us.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages


  #
  Terminal output with the old version:
  ssh -p 38613 username@IP -w any -o Tunnel=ethernet -vvv
  OpenSSH_6.2p2 Ubuntu-6ubuntu0.3, OpenSSL 1.0.1f 6 Jan 2014
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: Applying options for *
  debug1: auto-mux: Trying existing master
  debug1: Control socket path hidden does not exist
  debug2: ssh_connect: needpriv 0
  debug1: Connecting to IP [IP] port 38613.
  debug1: Connection established.
  debug1: permanently_set_uid: 0/0
  debug3: Incorrect RSA1 identifier
  debug3: Could not load /root/.ssh/id_rsa as a RSA1 public key
  debug1: identity file /root/.ssh/id_rsa type 1
  debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-16384
  debug1: Checking blacklist file /etc/ssh/blacklist.RSA-16384
  debug1: identity file /root/.ssh/id_rsa-cert type -1
  debug1: identity file /root/.ssh/id_dsa type -1
  debug1: identity file /root/.ssh/id_dsa-cert type -1
  debug3: Incorrect RSA1 identifier
  debug3: Could not load /root/.ssh/id_ecdsa as a RSA1 public key
  debug1: identity file /root/.ssh/id_ecdsa type 3
  debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-521
  debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-521
  debug1: identity file /root/.ssh/id_ecdsa-cert type -1
  debug1: Enabling compatibility mode for protocol 2.0
  debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.3
  debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 
Debian-5ubuntu1.3
  debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.3 pat OpenSSH_5*
  debug2: fd 3 setting O_NONBLOCK
  debug3: put_host_port: [IP]:38613
  debug3: load_hostkeys: loading entries for host [IP]:38613 from file 
/root/.ssh/known_hosts
  debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:24
  debug3: load_hostkeys: loaded 1 keys
  debug3: order_hostkeyalgs: prefer hostkeyalgs: 
ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
  debug1: SSH2_MSG_KEXINIT sent
  debug1: SSH2_MSG_KEXINIT received
  debug2: kex_parse_kexinit: 
ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
  debug2: kex_parse_kexinit: 
ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-rsa,ssh-dss
  debug2: kex_parse_kexinit: 
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-...@openssh.com,aes256-...@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
  debug2: kex_parse_kexinit: