On 02/07/2018 18:51, T Berger wrote:
On Monday, July 2, 2018 at 1:22:59 PM UTC-4, T Berger wrote:
On Saturday, June 30, 2018 at 6:02:06 PM UTC-4, T Berger wrote:
On Friday, June 29, 2018 at 7:00:15 PM UTC-4, Cameron Simpson wrote:
The key point here from Jim is "simultaneously". Are you prope
Grant Edwards :
> Found a NetBSD 7.1 system to test on...
>
> After killing a server with an active connection, a new server can
> bind to the same socket regardless of the SO_REUSEADDR setting in
> either server. I don't know if that's some sort of system
> configuration setting or what...
The qu
On 2018-07-03, Grant Edwards wrote:
> On 2018-07-03, Grant Edwards wrote:
>> On 2018-07-01, Marko Rauhamaa wrote:
>>> Gregory Ewing :
>>>
I don't see how the address-reuse timeout can be a security measure,
because the process trying to take over the address can easily
circumvent
On 2018-07-03, Grant Edwards wrote:
> On 2018-07-01, Marko Rauhamaa wrote:
>> Gregory Ewing :
>>
>>> I don't see how the address-reuse timeout can be a security measure,
>>> because the process trying to take over the address can easily
>>> circumvent it by setting SO_REUSEADDR.
>>
>> [...]
>>
>>
On 2018-07-01, Marko Rauhamaa wrote:
> Gregory Ewing :
>
>> I don't see how the address-reuse timeout can be a security measure,
>> because the process trying to take over the address can easily
>> circumvent it by setting SO_REUSEADDR.
>
> [...]
>
> Nevertheless, the later socket object cannot un
Chris Angelico :
> On Tue, Jul 3, 2018 at 10:26 PM, Marko Rauhamaa wrote:
>> It's crucial that the killed party is the server for the situation to
>> arise.
>>
>> That's why polite clients close their end of the connection before
>> the server. Whoever closes first will suffer the TIME-WAIT state
On Tue, Jul 3, 2018 at 10:26 PM, Marko Rauhamaa wrote:
> Gregory Ewing :
>
>> Marko Rauhamaa wrote:
>>> Nevertheless, the later socket object cannot unilaterally take over a
>>> socket using SO_REUSEADDR. The earlier socket object must have set the
>>> same option previously.
>>
>> I just did an e
Gregory Ewing :
> Marko Rauhamaa wrote:
>> Nevertheless, the later socket object cannot unilaterally take over a
>> socket using SO_REUSEADDR. The earlier socket object must have set the
>> same option previously.
>
> I just did an experiment that suggests that's not the case.
> I created a socket
Marko Rauhamaa wrote:
Nevertheless, the later socket object cannot unilaterally take over a
socket using SO_REUSEADDR. The earlier socket object must have set the
same option previously.
I just did an experiment that suggests that's not the case.
I created a socket without SO_REUSEADDR, made a
On Monday, July 2, 2018 at 1:22:59 PM UTC-4, T Berger wrote:
> On Saturday, June 30, 2018 at 6:02:06 PM UTC-4, T Berger wrote:
> > On Friday, June 29, 2018 at 7:00:15 PM UTC-4, Cameron Simpson wrote:
> >
> > > The key point here from Jim is "simultaneously". Are you properly
> > > shutting down
Gregory Ewing :
> Dan Stromberg wrote:
>> On Thu, Jun 28, 2018 at 10:30 PM, Marko Rauhamaa wrote:
>>
>>>Well, the same security issue can be demonstrated without
>>>SO_REUSEADDR:
>>>
>>>The security issue can be real but is not directly related with
>>>SO_REUSEADDR.
>>
>> Yes, it can. It just ta
On Saturday, June 30, 2018 at 6:02:06 PM UTC-4, T Berger wrote:
> On Friday, June 29, 2018 at 7:00:15 PM UTC-4, Cameron Simpson wrote:
>
> > The key point here from Jim is "simultaneously". Are you properly shutting
> > down
> > the Flask instance in IDLE before running from Terminal, and vice v
On 2018-07-01 01:52:12 +, Steven D'Aprano wrote:
> On Sat, 30 Jun 2018 23:49:41 +0200, Peter J. Holzer wrote:
> > The old adage that "security is binary" is utter balderdash.
>
> I think that "old adage" is one of those ones that only people denying it
> actually use.
>
> I've never seen any
On Saturday, June 30, 2018 at 6:39:36 PM UTC-4, MRAB wrote:
> On 2018-06-30 23:01, T Berger wrote:
> > On Friday, June 29, 2018 at 7:00:15 PM UTC-4, Cameron Simpson wrote:
> >
> >> The key point here from Jim is "simultaneously". Are you properly shutting
> >> down
> >> the Flask instance in IDL
On Sat, 30 Jun 2018 23:49:41 +0200, Peter J. Holzer wrote:
> The old adage that "security is binary" is utter balderdash.
I think that "old adage" is one of those ones that only people denying it
actually use.
I've never seen anyone say "security is binary" except to disagree with
it, "don't m
On 2018-06-30, Gregory Ewing wrote:
> Dan Stromberg wrote:
>> On Thu, Jun 28, 2018 at 10:30 PM, Marko Rauhamaa wrote:
>>
>>>Well, the same security issue can be demonstrated without SO_REUSEADDR:
>>>
>>>The security issue can be real but is not directly related with
>>>SO_REUSEADDR.
>>
>> Yes, i
Dan Stromberg wrote:
On Thu, Jun 28, 2018 at 10:30 PM, Marko Rauhamaa wrote:
Well, the same security issue can be demonstrated without SO_REUSEADDR:
The security issue can be real but is not directly related with
SO_REUSEADDR.
Yes, it can. It just takes longer.
I don't see how the addres
On 2018-06-30 23:01, T Berger wrote:
On Friday, June 29, 2018 at 7:00:15 PM UTC-4, Cameron Simpson wrote:
The key point here from Jim is "simultaneously". Are you properly shutting down
the Flask instance in IDLE before running from Terminal, and vice versa?
Cameron, I try every option to qui
On Friday, June 29, 2018 at 7:00:15 PM UTC-4, Cameron Simpson wrote:
> The key point here from Jim is "simultaneously". Are you properly shutting
> down
> the Flask instance in IDLE before running from Terminal, and vice versa?
Cameron, I try every option to quit either program, but they don't
On 2018-06-30 14:01:56 -0700, Dan Stromberg wrote:
> On Sat, Jun 30, 2018 at 11:19 AM, Peter J. Holzer wrote:
> > On 2018-06-28 18:04:16 -0700, Dan Stromberg wrote:
> > > If someone else comes along soon after and starts a different echo server
On Sat, Jun 30, 2018 at 11:19 AM, Peter J. Holzer wrote:
> On 2018-06-28 18:04:16 -0700, Dan Stromberg wrote:
> > On Thu, Jun 28, 2018 at 1:27 PM, Marko Rauhamaa
> wrote:
> > Start an echo server process P that listens on tcp/.
> >
> > Initiate a connection from a client machine to process P
On 06/28/18 18:04, Dan Stromberg wrote:
[snip]
Start an echo server process P that listens on tcp/.
Initiate a connection from a client machine to process P at tcp/. It
works as expected.
Kill P.
Initiate a connection from a client machine to process P at tcp/. It
gives a connec
On 2018-06-28 18:04:16 -0700, Dan Stromberg wrote:
> On Thu, Jun 28, 2018 at 1:27 PM, Marko Rauhamaa wrote:
> > Dan Stromberg :
> > > On Wed, Jun 27, 2018 at 10:31 PM, Marko Rauhamaa
> > > wrote:
> > >> Dan Stromberg :
> > >> >> > The problem can be solved by turning on the SO_REUSEADDR flag of
>
On Thu, Jun 28, 2018 at 10:30 PM, Marko Rauhamaa wrote:
> Well, the same security issue can be demonstrated without SO_REUSEADDR:
>
> The security issue can be real but is not directly related with
> SO_REUSEADDR.
>
Yes, it can. It just takes longer.
--
https://mail.python.org/mailman/listinfo
On 29Jun2018 09:50, Jim Lee wrote:
On 06/29/18 08:05, T Berger wrote:
On Friday, June 29, 2018 at 10:45:10 AM UTC-4, T Berger wrote:
On Thursday, June 28, 2018 at 1:21:32 AM UTC-4, T Berger wrote:
I have to backtrack on my optimistic pronouncement. I know why I'm getting
"address already in u
On 06/29/18 08:05, T Berger wrote:
On Friday, June 29, 2018 at 10:45:10 AM UTC-4, T Berger wrote:
On Thursday, June 28, 2018 at 1:21:32 AM UTC-4, T Berger wrote:
Hi Guys,
Thanks for all the suggestions. I found the problem. I had saved my program in
IDLE and quit out of the shell, and then
On Friday, June 29, 2018 at 10:45:10 AM UTC-4, T Berger wrote:
> On Thursday, June 28, 2018 at 1:21:32 AM UTC-4, T Berger wrote:
> > Hi Guys,
> >
> > Thanks for all the suggestions. I found the problem. I had saved my program
> > in IDLE and quit out of the shell, and then tried to run the progra
On Thursday, June 28, 2018 at 1:21:32 AM UTC-4, T Berger wrote:
> Hi Guys,
>
> Thanks for all the suggestions. I found the problem. I had saved my program
> in IDLE and quit out of the shell, and then tried to run the program in
> Terminal. Previously, restarting the shell was enough to break th
Dan Stromberg :
> [on how SO_REUSEADDR is a security risk]
> Start an echo server process P that listens on tcp/.
>
> Initiate a connection from a client machine to process P at tcp/. It
> works as expected.
>
> Kill P.
>
> Initiate a connection from a client machine to process P at tcp/55
On Thu, Jun 28, 2018 at 1:27 PM, Marko Rauhamaa wrote:
> Dan Stromberg :
> > On Wed, Jun 27, 2018 at 10:31 PM, Marko Rauhamaa
> wrote:
> >> Dan Stromberg :
> >> >> > The problem can be solved by turning on the SO_REUSEADDR flag of
> >> >> > the socket.
> >> > BTW, it's a security feature you're
On Thu, 28 Jun 2018 23:27:38 +0300, Marko Rauhamaa wrote:
> Dan Stromberg :
>> On Wed, Jun 27, 2018 at 10:31 PM, Marko Rauhamaa
>> wrote:
>>> Dan Stromberg :
>>> >> > The problem can be solved by turning on the SO_REUSEADDR flag of
>>> >> > the socket.
>>> > BTW, it's a security feature you're tu
Dan Stromberg :
> On Wed, Jun 27, 2018 at 10:31 PM, Marko Rauhamaa wrote:
>> Dan Stromberg :
>> >> > The problem can be solved by turning on the SO_REUSEADDR flag of
>> >> > the socket.
>> > BTW, it's a security feature you're turning off. If you're on a
>> > multiuser box, it prevents a second us
On Wed, Jun 27, 2018 at 10:31 PM, Marko Rauhamaa wrote:
> Dan Stromberg :
> >> > The problem can be solved by turning on the SO_REUSEADDR flag of
> >> > the socket.
> > BTW, it's a security feature you're turning off. If you're on a
> > multiuser box, it prevents a second user from stealing linge
Dan Stromberg :
>> > The problem can be solved by turning on the SO_REUSEADDR flag of
>> > the socket.
> BTW, it's a security feature you're turning off. If you're on a
> multiuser box, it prevents a second user from stealing lingering
> connections from a first user on the same port.
Can you prov
Hi Guys,
Thanks for all the suggestions. I found the problem. I had saved my program in
IDLE and quit out of the shell, and then tried to run the program in Terminal.
Previously, restarting the shell was enough to break the connection with the
port. This time, I guess, it wasn't. So after think
On Wed, Jun 27, 2018 at 10:44 AM, T Berger wrote:
> On Wednesday, June 27, 2018 at 1:40:20 PM UTC-4, Marko Rauhamaa wrote:
> > Joaquin Henriquez :
> >
> > >>Subject: EXTERNAL: OSError: [Errno 48] Address already in use
> > >
> > > The best way to
On 27Jun2018 10:44, Tamara Berger wrote:
On Wednesday, June 27, 2018 at 1:40:20 PM UTC-4, Marko Rauhamaa wrote:
Joaquin Henriquez :
>>Subject: EXTERNAL: OSError: [Errno 48] Address already in use
> The best way to help if got you to put the relevant code here.
>
> Th
On Wednesday, June 27, 2018 at 1:40:20 PM UTC-4, Marko Rauhamaa wrote:
> Joaquin Henriquez :
>
> >>Subject: EXTERNAL: OSError: [Errno 48] Address already in use
> >
> > The best way to help if got you to put the relevant code here.
> >
> > The error you a
Joaquin Henriquez :
>>Subject: EXTERNAL: OSError: [Errno 48] Address already in use
>
> The best way to help if got you to put the relevant code here.
>
> The error you are experiencing means that the Port you are trying to
> bind is already taken by another running process
Let me add this information to clarify the context in which I got this error
48. It doesn't make sense to me, and it might not to you.
This morning, I opened my webapp (vsearch4web.py in the terminal code above)
and noticed a whole bunch of code I had not typed. I also noticed something
weird a
On Wednesday, June 27, 2018 at 12:17:28 PM UTC-4, Joaquin Henriquez wrote:
> >Subject: EXTERNAL: OSError: [Errno 48] Address already in use
>
> The best way to help if got you to put the relevant code here.
Last login: Wed Jun 27 12:45:08 on ttys000
192:~ TamaraB$ cd Desktop/Webapp
>Subject: EXTERNAL: OSError: [Errno 48] Address already in use
The best way to help if got you to put the relevant code here.
The error you are experiencing means that the Port you are trying to bind is
already taken by another running process.
--
https://mail.python.org/mailman/listi
42 matches
Mail list logo
