Repository navigation
Argument Error issue around max_envelop_size_kb #281
Copy link
Copy link
Open
Description
Working on upgrading our chef provisioning vsphere up to latest and am running into an issue where this library is erroring trying to get max_envelop_size_kb from the server. Can't seem to find anyone with the same issue, so maybe we just have something setup incorrectly. Any help would be appreciated.
https://github.com/WinRb/WinRM/blob/master/lib/winrm/shells/power_shell.rb#L152
Server:
Window 2016 with Desktop Experience VM
I can telnet to port 5985. Firewall is off.
Error Output:
ArgumentError: machine_batch[machine batch 1] (dms_common::provision line 62) had an error: ArgumentError: unknown type: 1235072778
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/rubyntlm-0.6.2/lib/net/ntlm/message.rb:53:in `parse'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/rubyntlm-0.6.2/lib/net/ntlm/message.rb:59:in `decode64'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/rubyntlm-0.6.2/lib/net/ntlm/client.rb:35:in `init_context'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-2.2.3/lib/winrm/http/transport.rb:229:in `init_auth'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-2.2.3/lib/winrm/http/transport.rb:181:in `send_request'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-2.2.3/lib/winrm/shells/power_shell.rb:152:in `max_envelope_size_kb'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-2.2.3/lib/winrm/shells/power_shell.rb:80:in `max_fragment_blob_size'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-2.2.3/lib/winrm/shells/power_shell.rb:198:in `fragmenter'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-2.2.3/lib/winrm/shells/power_shell.rb:162:in `block in open_shell_payload'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-2.2.3/lib/winrm/shells/power_shell.rb:161:in `map'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-2.2.3/lib/winrm/shells/power_shell.rb:161:in `open_shell_payload'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-2.2.3/lib/winrm/shells/power_shell.rb:122:in `open_shell'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-2.2.3/lib/winrm/shells/base.rb:168:in `block in open'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-2.2.3/lib/winrm/shells/retryable.rb:37:in `retryable'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-2.2.3/lib/winrm/shells/base.rb:166:in `open'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-2.2.3/lib/winrm/shells/base.rb:129:in `with_command_shell'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-2.2.3/lib/winrm/shells/base.rb:81:in `run'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-fs-1.1.1/lib/winrm-fs/core/file_transporter.rb:213:in `check_files'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-fs-1.1.1/lib/winrm-fs/core/file_transporter.rb:81:in `block in upload'
/opt/chefdk/embedded/lib/ruby/2.4.0/benchmark.rb:293:in `measure'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-fs-1.1.1/lib/winrm-fs/core/file_transporter.rb:79:in `upload'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-elevated-1.1.0/lib/winrm/shells/elevated.rb:73:in `block in upload_elevated_shell_script'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-elevated-1.1.0/lib/winrm/shells/elevated.rb:84:in `with_temp_file'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-elevated-1.1.0/lib/winrm/shells/elevated.rb:72:in `upload_elevated_shell_script'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/winrm-elevated-1.1.0/lib/winrm/shells/elevated.rb:58:in `run'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-provisioning-2.6.0/lib/chef/provisioning/transport/winrm.rb:43:in `execute'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-provisioning-2.6.0/lib/chef/provisioning/transport/winrm.rb:76:in `available?'
/root/.chefdk/gem/ruby/2.4.0/gems/chef-provisioning-vsphere-2.0.10/lib/chef/provisioning/vsphere_driver/driver.rb:356:in `transport_respond?'
/root/.chefdk/gem/ruby/2.4.0/gems/chef-provisioning-vsphere-2.0.10/lib/chef/provisioning/vsphere_driver/driver.rb:278:in `ready_machine'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-provisioning-2.6.0/lib/chef/provisioning/driver.rb:250:in `block in ready_machines'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-13.6.4/lib/chef/chef_fs/parallelizer/parallel_enumerable.rb:263:in `process_input'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-13.6.4/lib/chef/chef_fs/parallelizer/parallel_enumerable.rb:253:in `process_one'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-13.6.4/lib/chef/chef_fs/parallelizer.rb:92:in `call'
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-13.6.4/lib/chef/chef_fs/parallelizer.rb:92:in `worker_loop'
WinRM Config:
Config
MaxEnvelopeSizekb = 500
MaxTimeoutms = 1800000
MaxBatchItems = 32000
MaxProviderRequests = 4294967295
Client
NetworkDelayms = 5000
URLPrefix = wsman
AllowUnencrypted = false
Auth
Basic = true
Digest = true
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = false
DefaultPorts
HTTP = 5985
HTTPS = 5986
TrustedHosts
Service
RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
MaxConcurrentOperations = 4294967295
MaxConcurrentOperationsPerUser = 1500
EnumerationTimeoutms = 240000
MaxConnections = 300
MaxPacketRetrievalTimeSeconds = 120
AllowUnencrypted = true
Auth
Basic = true
Kerberos = true
Negotiate = true
Certificate = false
CredSSP = true
CbtHardeningLevel = Relaxed
DefaultPorts
HTTP = 5985
HTTPS = 5986
IPv4Filter = *
IPv6Filter = *
EnableCompatibilityHttpListener = false
EnableCompatibilityHttpsListener = false
CertificateThumbprint
AllowRemoteAccess = true
Winrs
AllowRemoteShellAccess = true
IdleTimeout = 7200000
MaxConcurrentUsers = 2147483647
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 2147483647
MaxMemoryPerShellMB = 1024
MaxShellsPerUser = 2147483647
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels
Activity
mwrock commentedon Jan 7, 2018
Based on the stack trace, it looks like the failure is occuring in the
rubyntlmlibrary trying to parse the ntlm message type in the auth headers of the response. So this error would likely occur on any WinRM call and it just so happens that the envelope check is the first one.I have never seen this particular error before but it suggests that something may be intercepting the WinRM traffic and injecting a different response so that the auth headers do not contain valid NTLM messages. A proxy would be a good place to start looking for suspects here.