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

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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Blocker
    • Resolution: Unresolved
    • Component/s: ec2-plugin
    • Labels:
    • Environment:
      Jenkins version: 2.303.1
      ec2-plugin: 1.64
      Master/Controller OS: CentOS 7 (fully up-to-date)
      Slave/Agent OS: Windows Server 2019
    • Similar Issues:

      Description

      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.

        Attachments

          Activity

          Hide
          raihaan Raihaan Shouhell added a comment -

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

          Show
          raihaan Raihaan Shouhell added a comment - This bug is present in 1.61 as well. But ill work on a fix for this
          Hide
          guy_davis 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

          Show
          guy_davis 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
          Hide
          ssmozhevskii 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

          Show
          ssmozhevskii 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

            People

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

              Dates

              Created:
              Updated: