[JENKINS-23232] Jenkins CLI: java.io.StreamCorruptedException: invalid stream header: 0A0A0A0A

[jenkins-infra-bot]

We use the jenkins-cli.jar to attach new slaves and this has been working successfully in v1.534, however when upgrading to v1.554.1, we are unable to do so and a "SEVERE: I/O error in channel Chunked connection" error occurs.

Tested on linux slaves using java version "1.6.0_35" and "1.7.0_45" and the same error occurs.

Attached console output to error.log

Workaround: -Dhudson.diyChunking=false on both slave/agent and master sides

---

Originally reported by ashokm, imported from: Jenkins CLI: java.io.StreamCorruptedException: invalid stream header: 0A0A0A0A

• assignee: oleg_nenashev
• status: Resolved
• priority: Major
• component(s): cli, core, remoting
• label(s): 1.554.1, 2.19.2-fixed, cli, exception, jenkins, severe
• resolution: Fixed
• resolved: 2016-10-01T14:24:49+00:00
• votes: 6
• watchers: 22
• imported: 2025-11-24

Raw content of original issue

We use the jenkins-cli.jar to attach new slaves and this has been working successfully in v1.534, however when upgrading to v1.554.1, we are unable to do so and a "SEVERE: I/O error in channel Chunked connection" error occurs.

Tested on linux slaves using java version "1.6.0_35" and "1.7.0_45" and the same error occurs.

Attached console output to error.log

Workaround: -Dhudson.diyChunking=false on both slave/agent and master sides

• environment: Jenkins v1.554.1 running on CentOS 6.3

1 attachment

• error.log

[jenkins-infra-bot]

kohsuke:

• Original comment link
• Raw content of original comment:

  My guess is that this is because hudson.diyChunking is still set to true, and between Jetty and Jenkins we end up double-decoding chunked encoding. Needs to verify.
  

My guess is that this is because hudson.diyChunking is still set to true, and between Jetty and Jenkins we end up double-decoding chunked encoding. Needs to verify.

[jenkins-infra-bot]

ashokm:

• Original comment link
• Raw content of original comment:

  Thanks for the update Kohsuke. Looking forward to the resolution 
  

Thanks for the update Kohsuke. Looking forward to the resolution

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  Ashok: What's the output of 
  
  System.getProperty('hudson.diyChunking')
  
   in Manage Jenkins » Script Console?
  

Ashok: What's the output of

System.getProperty('hudson.diyChunking')

in Manage Jenkins » Script Console?

[jenkins-infra-bot]

ashokm:

• Original comment link
• Raw content of original comment:

  @Daniel Beck - Result: true
  

@​Daniel Beck - Result: true

[jenkins-infra-bot]

peter_kline:

• Original comment link
• Raw content of original comment:

  Possibly related –  JENKINS-23223
  

Possibly related – JENKINS-23223

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  Ashok: Check your startup scripts (e.g. /etc/sysconfig/jenkins, /etc/init.d/jenkins, ... when using the RPM installer) for any occurrence of 
  
  -Dhudson.diyChunking=true
  
   and remove it. Restart Jenkins using 
  
  service restart jenkins
  
   (rather than via e.g. /safeRestart) so it picks up the changes. See whether the issue disappears.
  

Ashok: Check your startup scripts (e.g. /etc/sysconfig/jenkins, /etc/init.d/jenkins, ... when using the RPM installer) for any occurrence of

-Dhudson.diyChunking=true

and remove it. Restart Jenkins using

service restart jenkins

(rather than via e.g. /safeRestart) so it picks up the changes. See whether the issue disappears.

[jenkins-infra-bot]

peter_kline:

• Original comment link
• Raw content of original comment:

  By setting
  
  -Dhudson.diyChunking=false
  
  
  in /etc/sysconfig/jenkins and restarting I am now able to run remote build calls.  Not sure if this fixes the remote slave issue but it certainly solves my issue when running the jenkins-cli.jar problems with Chunking
  

By setting

-Dhudson.diyChunking=false

in /etc/sysconfig/jenkins and restarting I am now able to run remote build calls. Not sure if this fixes the remote slave issue but it certainly solves my issue when running the jenkins-cli.jar problems with Chunking

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  slave-setup is a plugin, removing that component.
  

slave-setup is a plugin, removing that component.

[jenkins-infra-bot]

ashokm:

• Original comment link
• Raw content of original comment:

  @Daniel - There were no occurrences of "-Dhudson.diyChunking=true" in my startup scripts, yet this is set as true (even though the default is false)
  I followed Peter's comment above to set this property to 'false' in /etc/sysconfig/jenkins and this has resolved the reported problem.
  

@​Daniel - There were no occurrences of "-Dhudson.diyChunking=true" in my startup scripts, yet this is set as true (even though the default is false)
I followed Peter's comment above to set this property to 'false' in /etc/sysconfig/jenkins and this has resolved the reported problem.

[jenkins-infra-bot]

geerlingguy:

• Original comment link
• Raw content of original comment:

  In my case (1.574, CentOS 6.5), I was getting the same error, but it seems it was a case of DNS resolution failure with my URL. I had to explicitly map the IP of the server to the server's hostname (as used in the jenkins-cli command) and this error went away. The diyChunking property was false when I checked.
  

In my case (1.574, CentOS 6.5), I was getting the same error, but it seems it was a case of DNS resolution failure with my URL. I had to explicitly map the IP of the server to the server's hostname (as used in the jenkins-cli command) and this error went away. The diyChunking property was false when I checked.

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  Given the recent responses, reducing priority.
  
  kohsuke: Is there still a bug left to be fixed? Or is this a doc issue? Or not a defect at all?
  

Given the recent responses, reducing priority.

kohsuke: Is there still a bug left to be fixed? Or is this a doc issue? Or not a defect at all?

[jenkins-infra-bot]

dserodio:

• Original comment link
• Raw content of original comment:

  I've seen this error message when trying to use jenkins-cli pointing to a Jenkins master where the JNLP port is blocked by a firewall
  

I've seen this error message when trying to use jenkins-cli pointing to a Jenkins master where the JNLP port is blocked by a firewall

[jenkins-infra-bot]

stevejansen:

• Original comment link
• Raw content of original comment:

  Not sure if this helps or not, but I faced a similar issue with this network topology:
  
  
  	
  LAN A (OpenStack cluster with a 192.168.2.0/24 internal network, NAT'd to the rest of the LAN via "floating" public IPs on 10.166.140.0/24)
  	
  Jenkins master  @ 192.168.2.10 or 10.166.140.10
  	
  Jenkins slave 1 @ 192.168.2.11
  	
  Jenkins slave 2 @ 192.168.2.12
  
  
  
  
  	
  LAN B (3rd party data center, connected to LAN A via site-to-site VPN which NAT to 10.21.26.0/24 on LAN A)
  	
  Jenkins slave 3 @ 10.21.26.50
  	
  Jenkins slave 4 @ 10.21.26.51
  
  
  
  The CLI worked as expected when using the master node's private ip address but not the master node's public ip address.
  
  For example `java -jar jenkins-cli.jar -s http://192.168.2.10:8080/ help` worked, but `java -jar jenkins-cli.jar -s http://10.166.140.10:8080/ help` raised the error "SEVERE: I/O error in channel Chunked connection" on any slave.
  
  The problem was ultimately the software firewall in the OpenStack cluster that only applied to the floating IPs (e.g., 10.166.140.0/24). 
  
  The resolution was to allowing UDP ingress on ports 1024-65535 and TCP ingress on ports 1024-65535 where the destination was the Jenkins master node and the source was my slaves public IPs (10.21.26.0/24 and 10.166.140.0/24).  
  
  After the firewall change, executing  `java -jar jenkins-cli.jar -s http://10.166.140.10:8080/ help` worked as expected on all slaves in both data centers.
  
  My $0.02 - there is some complex networking for CLI connections: there seems to be ICMP, UDP, and TCP in use at the same time, along with random (JNLP?) ports on the server.  The CLI client could use connectivity checks and/or clearcut error messages to better explain when connectivity fails for a specific protocol/address/port.
  

Not sure if this helps or not, but I faced a similar issue with this network topology:

• LAN A (OpenStack cluster with a 192.168.2.0/24 internal network, NAT'd to the rest of the LAN via "floating" public IPs on 10.166.140.0/24)
• Jenkins master @ 192.168.2.10 or 10.166.140.10
• Jenkins slave 1 @ 192.168.2.11
• Jenkins slave 2 @ 192.168.2.12

• LAN B (3rd party data center, connected to LAN A via site-to-site VPN which NAT to 10.21.26.0/24 on LAN A)
• Jenkins slave 3 @ 10.21.26.50
• Jenkins slave 4 @ 10.21.26.51

The CLI worked as expected when using the master node's private ip address but not the master node's public ip address.

For example `java -jar jenkins-cli.jar -s http://192.168.2.10:8080/ help` worked, but `java -jar jenkins-cli.jar -s http://10.166.140.10:8080/ help` raised the error "SEVERE: I/O error in channel Chunked connection" on any slave.

The problem was ultimately the software firewall in the OpenStack cluster that only applied to the floating IPs (e.g., 10.166.140.0/24).

The resolution was to allowing UDP ingress on ports 1024-65535 and TCP ingress on ports 1024-65535 where the destination was the Jenkins master node and the source was my slaves public IPs (10.21.26.0/24 and 10.166.140.0/24).

After the firewall change, executing `java -jar jenkins-cli.jar -s http://10.166.140.10:8080/ help` worked as expected on all slaves in both data centers.

My $0.02 - there is some complex networking for CLI connections: there seems to be ICMP, UDP, and TCP in use at the same time, along with random (JNLP?) ports on the server. The CLI client could use connectivity checks and/or clearcut error messages to better explain when connectivity fails for a specific protocol/address/port.

[jenkins-infra-bot]

dserodio:

• Original comment link
• Raw content of original comment:

  Thanks Steve, it does help. However, we'd have a hard time asking our security team to open a firewall rule allowing so many ports (1024-65535). I don't understand the details of Jenkins CLI networking, is it possible to narrow the range of ports, or are they this much dynamic?
  

Thanks Steve, it does help. However, we'd have a hard time asking our security team to open a firewall rule allowing so many ports (1024-65535). I don't understand the details of Jenkins CLI networking, is it possible to narrow the range of ports, or are they this much dynamic?

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  Doesn't it just use the port configured on the Configure Global Security page? (needs security enabled)
  

Doesn't it just use the port configured on the Configure Global Security page? (needs security enabled)