> > > 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: <<A HREF="http://www.nealis.net/ascend/faq">http://www.nealis.net/ascend/faq</A>> </PRE> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <STRONG>Follow-Ups</STRONG>: <UL> <LI><STRONG><A HREF="msg09599.html">Re: (ASCEND) Feature Requests and Ascend?</A></STRONG></LI> <UL> <LI><EM>From</EM>: Marc Slemko <marcs@znep.com></LI> </UL> </UL> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <HR> <UL> <LI>Prev by Date: <STRONG><A HREF="msg09596.html">Re: (ASCEND) Feature Requests and Ascend?</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg09595.html">Re: (ASCEND) Re: T1 problems with Pipeline 130 and 5.1a</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg09594.html">Re: (ASCEND) Feature Requests and Ascend?</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg09599.html">Re: (ASCEND) Feature Requests and Ascend?</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="mail17.html#09597"><STRONG>Main</STRONG></A></LI> <LI><A HREF="thrd198.html#09597"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> </BODY> </HTML>