warning: closed channel

[Ben Alpert]

I get many of these warnings when using sshuttle.

client: warning: closed channel 42 got cmd=STOP_SENDING len=0
server: warning: closed channel 42 got cmd=STOP_SENDING len=0
server: warning: closed channel 21 got cmd=STOP_SENDING len=0
client: warning: closed channel 49 got cmd=DATA len=2048
client: warning: closed channel 49 got cmd=STOP_SENDING len=0
client: warning: closed channel 49 got cmd=EOF len=0
client: warning: closed channel 37 got cmd=STOP_SENDING len=0
server: warning: closed channel 51 got cmd=STOP_SENDING len=0
server: warning: closed channel 56 got cmd=STOP_SENDING len=0
server: warning: closed channel 57 got cmd=STOP_SENDING len=0
client: warning: closed channel 51 got cmd=STOP_SENDING len=0

Is this anything to worry about? If so, what can I do to fix it? (If
not, what can I do to suppress them? They make me feel sad inside…)

Thanks Avery for all your wonderful work.

[Avery Pennarun]

They're a bug, but the bug is just that it prints the warning, not so
much that it hurts anything. Well, okay, if the channel number
wrapped all the way around in 0.1 seconds or something, which I think
is impossible at least on modern computers, then it would cause a real
bug.

I've been too lazy to fix it so far. In case someone is feeling
motivated, what happens is:

- a connection isn't officially closed until both ends close it.
- when one end decides that it's closed, it sends the other end a
STOP_SENDING message.
- if the other end has *already* decided it's closed, then it prints
the warning.

...hmm, actually the closed connection getting a DATA message is
pretty bad; it means somebody closed it before they felt safe.

All in all, the connection closing state machine isn't quite right. It
needs to be thoroughly traced through and thought about. The final
fix will probably only be two or three lines, but it has to be the
*right* two or three lines :)

Have fun,

Avery

[ash...@gmail.com]

Just wondering if there has been any update to fix the warning closed channel messages.  Thanks

Ashley Anderson

[david...@gmail.com]

6 years after the original post the answer seems to be no. Having the same issue in 2017.

[ryan....@gmail.com]

Well fun..  I came here as I was hoping to find a non-mjölnir way of fixing this.

[Brian May]

ryan....@gmail.com writes:

> Well fun.. I came here as I was hoping to find a non-mjölnir way of fixing
> this.

I don't have time to look at this right now.

Pull requests are welcome.
--
Brian May <br...@microcomaustralia.com.au>

[Aniket Shaha]

The year is 2021, and we still are facing the same issue while using sshuttle 🙄

[linux sup]

ditto with 2022

[Bradley Stannard]

November 2022, Still having the issue :( 

[Jason Oriente]

You can get rid of these messaged by changing the log priority.

ssyslog.py

Change this....

    _p = ssubprocess.Popen(['logger',
                            '-p', 'daemon.notice',
                            '-t', 'sshuttle'], stdin=ssubprocess.PIPE)

To this....

    _p = ssubprocess.Popen(['logger',
                            '-p', 'daemon.err',
                            '-t', 'sshuttle'], stdin=ssubprocess.PIPE)

Then disconnect and reconnect your tunnels.

[Ryan McHale]

https://github.com/sshuttle/sshuttle/pull/824 made this

--
You received this message because you are subscribed to a topic in the Google Groups "sshuttle" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sshuttle/hTMW2OCpAmk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sshuttle+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sshuttle/c70cb7bd-6b79-449e-82fc-770fb4870687n%40googlegroups.com.

[seyed amirhossein hosseini]

August 2023 still the same problem XD