Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (ASCEND) Feature Requests and Ascend?

[If we go another round on this, do you mind if we change the subject?]

> > > The problem I have is that the box has the bug of crashing if someone
> > > opens a couple (what some would consider a reasonable number; after all,
> > > there could be that many actual modems in a box for people to connect to)
> > > of connections to it.
> > 
> > I have had more than two ("a couple") Immediate Modem sessions going
> > without any problems. You have mentioned "access to the modems", so
> > I assumed you meant preventing access. The fact that you had mentioned
> > "just by making ~60 or 80 telnet connections" also led me to believe
> > you are talking about a rather large number, which implied an access
> > problem. You now say you are not talking about preventing access
> > ("I can already control the access very nicely") so now you have lost me
> > again.
> 
> I can control who can access them. To access them you need a password.
> Telnetting to the immediate modem port does not immediately give you a
> modem in my setup. It gives you a password prompt. If you know the
> password, you get access. If you don't, you don't. Assume that security
> is sufficient.
>
> The problem is that someone can, without knowing the password or having
> any access to the modems, connect to the port a "couple" (large couple,
> but certainly nothing that takes more than a couple of seconds to do and
> which can be done over a low-bandwidth line; does need real IPs though) of
> times and bring down the box. Repeat, this is _without_ having access to
> the modems just the ability to telnet to the immediate modem port.

Hmm... what version of software were you using and what else was happening
on the MAX?

I just tried to reproduce your problem here and I was not [fully] able to.
I was not able to bring the MAX to its knees or completely destroy performance.
I was able to produce a measurable change in latency.  It might or might not
be noticeable to a remote user.  I did not measure throughput.

First, I took a MAX and checked the ping round-trip time on the LAN over
a 60 second period.  
 61 packets transmitted, 61 packets received, 0% packet loss
 round-trip min/avg/max = 1.551/1.613/2.190 ms
I then started up 60 simultaneous telnet sessions to the Immediate Modem port.
I did not attempt to authenticate, but left each session at the "login:"
prompt.  I then checked the ping round-trip time over 60 seconds.  The change
was relatively small in absolute terms.
 61 packets transmitted, 61 packets received, 0% packet loss
 round-trip min/avg/max = 3.759/13.962/24.753 ms
After terminating the sessions, I rechecked the round-trip time.  The latency
returned to the previous levels.
 61 packets transmitted, 61 packets received, 0% packet loss
 round-trip min/avg/max = 1.551/1.876/10.806 ms

Second, I used the same MAX and checked the ping round-trip time from a
host on the LAN to a host across a WAN link.  
  61 packets transmitted, 61 packets received, 0% packet loss
  round-trip min/avg/max = 41.126/42.451/67.123 ms
I then started up 60 simultaneous telnet sessions to the Immediate Modem
port.  I did not attempt to authenticate, but left them at "login:".
I again checked the ping round-trip time.
  61 packets transmitted, 61 packets received, 0% packet loss
  round-trip min/avg/max = 103.917/191.473/855.968 ms
After terminating the telnet sessions, latency returned to the previous
levels.
  61 packets transmitted, 61 packets received, 0% packet loss
  round-trip min/avg/max = 41.135/42.478/58.157 ms

I checked the behavior with telnet and due to the limit on telnet sessions
(12 max) was not able to force the same level of connections.  Using the
same maximum (12) with Immediate Modems did not display a significant change
in latency.
 61 packets transmitted, 61 packets received, 0% packet loss
 round-trip min/avg/max = 41.031/41.740/49.667 ms

So, it could be that other service ports on the MAX might exhibit the same
problem.  But, I think I agree with the service rep.  I am not sure this is a
"bug" since the MAX continues to operate.  But it would probably be nice
to have a new feature to limit the maximum number of allowed Immediate Modem
connections to prevent abuse of the service.

I do feel that using a packet filter or firewall seems to be a valid way
to address the problem in the interim.  I also feel that the above information
would be needed to show a good reason for the feature request.  I invite you
to use it if you still want the feature.
++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>
Follow-Ups: