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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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.
--
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
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
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
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
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
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
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
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
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
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 help if got you to put the relevant code here.
>
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.
>
> The error you are
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 are experiencing means that the Port you
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.
That error usually
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
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/
192: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.
--
42 matches
Mail list logo
