Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-66736

Connect to Windows Agent failing with "different server found for same hostname"

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Blocker Blocker
    • ec2-plugin
    • Jenkins version: 2.303.1
      ec2-plugin: 1.64
      Master/Controller OS: CentOS 7 (fully up-to-date)
      Slave/Agent OS: Windows Server 2019

      Agent launches and begins to connect, but then log on master/controller shows error below and eventually Windows agent connection times out as failure. No Windows agents are thus available to perform build tasks.

      {{2021-09-26 14:28:22.740+0000 [id=3752]  INFO    c.h.smbj.connection.Connection#close: Closed connection to 10.134.37.223
      2021-09-26 14:28:22.740+0000 [id=3901]  INFO    c.h.smbj.transport.PacketReader#run: Thread[Packet Reader for 10.134.37.223,5,main] stopped.
      2021-09-26 14:28:22.740+0000 [id=3752]  WARNING h.plugins.ec2.win.WinConnection#pingFailingIfSSHHandShakeError: Failed to verify connectivity to Windows agent
      com.hierynomus.protocol.transport.TransportException: Different server found for same hostname '10.134.37.223', disconnecting...
              at com.hierynomus.smbj.connection.SMBProtocolNegotiator.initializeOrValidateServerDetails(SMBProtocolNegotiator.java:232)
              at com.hierynomus.smbj.connection.SMBProtocolNegotiator.negotiateDialect(SMBProtocolNegotiator.java:83)
              at com.hierynomus.smbj.connection.Connection.connect(Connection.java:141)
              at com.hierynomus.smbj.SMBClient.getEstablishedOrConnect(SMBClient.java:96)
              at com.hierynomus.smbj.SMBClient.connect(SMBClient.java:71)
              at hudson.plugins.ec2.win.WinConnection.pingFailingIfSSHHandShakeError(WinConnection.java:136)
              at hudson.plugins.ec2.win.EC2WindowsLauncher.connectToWinRM(EC2WindowsLauncher.java:189)
              at hudson.plugins.ec2.win.EC2WindowsLauncher.launchScript(EC2WindowsLauncher.java:52)
              at hudson.plugins.ec2.EC2ComputerLauncher.launch(EC2ComputerLauncher.java:48)
              at hudson.slaves.SlaveComputer.lambda$_connect$0(SlaveComputer.java:295)
              at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
              at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:80)
              at java.util.concurrent.FutureTask.run(FutureTask.java:266)
              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
              at java.lang.Thread.run(Thread.java:748)}}
      

      The issue seems tied to this method where the cached server is being validated and coming back as invalid from here.

      This seems to be regression in 1.64 version of the plugin as nothing in our environment has changed since this was validated as working with version 1.61.

          [JENKINS-66736] Connect to Windows Agent failing with "different server found for same hostname"

          This bug is present in 1.61 as well. But ill work on a fix for this

          Raihaan Shouhell added a comment - This bug is present in 1.61 as well. But ill work on a fix for this

          Guy Davis added a comment -

          Thanks! There was a hint posted on the smbj github that might help? https://github.com/hierynomus/smbj/issues/672#issuecomment-930066460

          Guy Davis added a comment - Thanks! There was a hint posted on the smbj github that might help? https://github.com/hierynomus/smbj/issues/672#issuecomment-930066460

          The same issue in the 1.65 plugin too.
          When the plugin launch a new windows instance, it starts with AMI's SSID then changes it to a new one during the sysprep process.
          Plugin remembers the first SSID from the 'Negotiate Protocol Response' packet and throws an error when SSID changes.
          The 1.65 bugfix brings an exception catch, but to the wrong place. 

          This changes fix the problem(tested with latest official Windows 2019 AMI), but I'm not sure, that I arranged the PR well.
          https://github.com/jenkinsci/ec2-plugin/pull/672

          Sergei Smozhevskii added a comment - The same issue in the 1.65 plugin too. When the plugin launch a new windows instance, it starts with AMI's SSID then changes it to a new one during the sysprep process. Plugin remembers the first SSID from the 'Negotiate Protocol Response' packet and throws an error when SSID changes. The 1.65 bugfix brings an exception catch, but to the wrong place.  This changes fix the problem(tested with latest official Windows 2019 AMI), but I'm not sure, that I arranged the PR well. https://github.com/jenkinsci/ec2-plugin/pull/672

            raihaan Raihaan Shouhell
            guy_davis Guy Davis
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: