[issue39685] Python 3.8 regression Socket operation on non-socket

2020-05-28 Thread Brian May


Brian May  added the comment:

Consensus seems to be that this is a bug in sshuttle, not a bug in python. 
Thanks for the feedback.

I think this bug can be closed now...

--

___
Python tracker 
<https://bugs.python.org/issue39685>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39685] Python 3.8 regression Socket operation on non-socket

2020-02-18 Thread Brian May


New submission from Brian May :

After upgrading to Python 3.8, users of sshuttle report seeing this error:

Traceback (most recent call last):
  File "", line 1, in 
  File "assembler.py", line 38, in 
  File "sshuttle.server", line 298, in main
  File "/usr/lib/python3.8/socket.py", line 544, in fromfd
return socket(family, type, proto, nfd)
  File "/usr/lib/python3.8/socket.py", line 231, in __init__
_socket.socket.__init__(self, family, type, proto, fileno)
OSError: [Errno 88] Socket operation on non-socket

https://github.com/sshuttle/sshuttle/issues/381

The cause of the error is this line: 
https://github.com/sshuttle/sshuttle/blob/6ad4473c87511bcafaec3d8d0c69dfcb166b48ed/sshuttle/server.py#L297
 which does:

socket.fromfd(sys.stdin.fileno(), socket.AF_INET, socket.SOCK_STREAM)
socket.fromfd(sys.stdout.fileno(), socket.AF_INET, socket.SOCK_STREAM)

Where sys.stdin and sys.stdout are stdin/stdout provided by the ssh server when 
it ran our remote ssh process.

I believe this change in behavior is as a result of a fix for the following 
bug: https://bugs.python.org/issue35415

I am wondering if this is a bug in Python for causing such a regression, or a 
bug in sshuttle. Possibly sshuttle is using socket.fromfd in a way that was 
never intended?

Would appreciate an authoritative answer on this.

Thanks

--
components: IO
messages: 362255
nosy: brian
priority: normal
severity: normal
status: open
title: Python 3.8 regression Socket operation on non-socket
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue39685>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue30181] Correct the parsing of a test case docstring.

2017-05-12 Thread Brian May

Brian May added the comment:

I have already created such a pull requests. It is bidirectionally linked to 
this ticket.

However concerns have been raised that the automatic bot hasn't recognised that 
Ben Finney has signed the CLA. Hence it appears the pull request might be 
rejected.

Sure there are currently problems with the pull request, and it fails the 
tests, however I am not going to spend any additional efforts fixing them 
unless this situation with the CLA can be resolved first.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30181>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue30181] Correct the parsing of a test case docstring.

2017-05-08 Thread Brian May

Brian May added the comment:

Me getting confused at the newline in the comparison output.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30181>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue30181] Correct the parsing of a test case docstring.

2017-05-08 Thread Brian May

Brian May added the comment:

I made an attempt at a PR. Unfortunately some of the tests appear to fail on 
some environments, and the messages produced don't exactly clarify why.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30181>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue30181] Incorrect parsing of test case docstring

2017-04-26 Thread Brian May

Changes by Brian May <br...@microcomaustralia.com.au>:


--
nosy: +brian

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30181>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6560] socket sendmsg(), recvmsg() methods

2011-08-21 Thread Brian May

Changes by Brian May br...@microcomaustralia.com.au:


--
nosy: +ncoghlan

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6560
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6560] socket sendmsg(), recvmsg() methods

2011-06-05 Thread Brian May

Brian May br...@microcomaustralia.com.au added the comment:

To address some of the comments above:

* Yes, the patch is large. However, most of this is in the tests. Only A 
relatively small part is in the code that implements the required 
functionality. I don't care much myself about the test cases, however would 
have assumed these would help get it into upstream.

(baikie-hwundram-v5-hg.diff)

 Doc/library/socket.rst  |  176 +++
 Lib/ssl.py  |   24 
 Lib/test/test_socket.py | 2120 
 Lib/test/test_ssl.py|   13 
 Modules/socketmodule.c  |  809 ++
 5 files changed, 3142 insertions(+)

* raw sockets are inappropriate for using UDP TPROXY support. I don't want to 
bypass the kernel code and have to pass headers etc myself, I just want to get 
the destination address so I know where the packet was original destined for. 
recvmsg() is the correct solution.

* Thanks for the 2.x patch. Will try that out now.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6560
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6560] socket sendmsg(), recvmsg() methods

2011-05-30 Thread Brian May

Brian May br...@microcomaustralia.com.au added the comment:

Have tested my code with this patch, the recvmsg(...) call seems to work fine.

Also had a half-hearted attempt at porting to Python 2.7, but didn't get past 
compiling, the code requires BEGIN_SELECT_LOOP and END_SELECT_LOOP macros that 
aren't defined in Python 2.7 - I tried copying the definitions from Python 3.3, 
but that didn't work either. Not sure if it is worth the effort if Python 2.7 
is closed to new features.

Brian May

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6560
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6560] socket sendmsg(), recvmsg() methods

2011-05-23 Thread Brian May

Brian May br...@microcomaustralia.com.au added the comment:

Hello,

Are there any problems applying the v5 version of the patch to 3.3?

Also is there any remote chance for a backport to 2.7?

Thanks

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6560
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6560] socket sendmsg(), recvmsg() methods

2011-05-21 Thread Brian May

Brian May br...@microcomaustralia.com.au added the comment:

What needs to happen to get recvmsg() supported in Python?

recvmsg() is required to get get transparent UDP proxies working under Linux 
using tproxy, the code needs to run recvmsg() to be able to find out what the 
original destination address was for the the packet.

Thanks

Brian May

--
nosy: +brian

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6560
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com