ike_ipsec_dude has asked for the wisdom of the Perl Monks concerning the following question:

What I am try to do is open a telnet connection to a telnet server. As soon as the client connects to the server I just send and endless loop banner back to the telnet client
to keep the connection open and active. Now I want to keep this connection open and iterate
thru the IP addresses of a classB net. ie;64k

My thought was "see example below" was to take the var $t =Net:: etc Was on the next iteration change $t to $t2 then $t3 etc hence making many open telnet connections with data streaming back to them. I am having major brain farts here. Maybe there is a better way?
and how to increment a var before it gets assigned by...

$t = Net::Telnet->new(Timeout => 10, Port => 23,Prompt => '/.*\>/');
so that on the next iteration we get....
$t2 = Net::Telnet->new(Timeout => 10, Port => 23,Prompt => '/.*\>/');
Example code:
use Net::Telnet; use Getopt::Long; getOpts (); create_streams (); if (defined($duration)) {sleep $duration;} if (!defined($duration)) {sleep 3600;}# default to an hours run time ############################################################ # A simple routine to connect to a telnet Virtual IP ,port 23 # ############################################################ sub create_streams { $ip1 = 192.168; $ip3 = 1; $ip4 = 1; LOOP: if ($ip4 == 254) { $ip3++; $ip4 = 1; } $t = Net::Telnet->new(Timeout => 10, Port => 23,Prompt => +'/.*\>/'); $t->timeout; $t->open(Host => "$ip.$ip3.$ip4", Errmode => "return", Tim +eout => 1); if ($ip3 == 254) {goto NEXT;} $ip4++; goto LOOP; NEXT: }

Replies are listed 'Best First'.
Re: how to fork/spawn 64k telnet connections and keep them all open
by DrHyde (Prior) on Oct 02, 2003 at 08:19 UTC
    If you want to open 65536 connections in parallel, you're going to have problems because you'll run out of local sockets. But let's ignore that. Let's also ignore the minor detail that the range 192.168.0.0 - 192.168.255.255 is *not* a class B network :-) oops I didn't ignore it! It's a series of 255 class C networks.

    Creating a bunch of variables like $t1, $t2, $t3 and so on for each connection would be a bad idea, as perl already has data structures available for storing lists of data like this, which are much easier to use. You could either store them in an array like so:

    $t = Net::Telnet->new(...); $t->open(...); push @array, $t;
    Or you could store them in a hash with the target IP addresses as the keys:
    $hash{"$ip.$ip3.$ip4"} = $t
    You are also *not* iterating over all of the addresses you want to. The range you say you want to work through runs from FOO.BAR.0.0 to FOO.BAR.255.255. You ignore a whole bunch of them. I'm not going to pick over your convoluted method for generating the list to figure out exactly what you skip over, but here's how I'd do it:
    my $base = (192 << 24) + (168 << 16); foreach my $ip ($base .. $base+65535) { $t = Net::Telnet ... $t->open(... $hash{$ip} = $t; }
      Thanks for the advice / inspiration :)

      As for it being useful it will be tremendously for IKE testing.
Re: how to fork/spawn 64k telnet connections and keep them all open
by BrowserUk (Patriarch) on Oct 02, 2003 at 09:59 UTC

    You can forget using threads for this, and in all likelyhood processes too on most systems.

    All in all, that probably not a bad thing as I fail to a see a legitimate use for this.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
    If I understand your problem, I can solve it! Of course, the same can be said for you.

      network device testing?? ensuring that a firewall/filter/shaper/whatever can handle the number of connections you need it to support? it's a stretch.

      one might be able to put the interface in promiscuous mode and process the packets without having to actually place IPs on the interface (is there an OS that would hold a class B's worth of addresses on an interface?)

      about the same on the sending side. craft your packets, change the dest IP field, recalc checksums and shove it out the interface.

      but i doubt opee has a good reason or is using the right tools. or enough bandwidth...

        The point is, if the aim to to do legitimate saturation or stress testing, there are much better, more efficient ways of doing it than squirreling together a hookey perl script.


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
        If I understand your problem, I can solve it! Of course, the same can be said for you.