Hi Ed (and everybody else who could help me out)

Yes i've tried must of what you suggest and have come to a state where i
can make diald run the login-script in order to both login and logout. (BTW
i don't have to maintain the telnet-session, luckily) This runs almost as it
should.
However i have one major problem left: i loose the first few packets.
As far as i have found out it is because diald wants a device-name. I have
giving diald the name eth1 since this is the device which i use for the
cable-modem. However the problem is that this device
is always up !! Thus diald does not buffer the packets (or what ?).
Anybody got a hint ? I suppose i could fake some device that diald could
play with (using tunnel-devices or something) but it seems like a clumsy
way to do it.

Niels Ole Staub Kirkeby
[EMAIL PROTECTED]

Ed Doolittle wrote:

> On Sun, 14 Mar 1999, Niels Ole Staub Kirkeby wrote:
>
> > I have a permanent connection to my ISP through my cable modem. However
> > this connection does NOT allow me to have internet access, only access
> > to a login-server located at my ISP. I dont have to pay for this
> > connection. I have a static ip-address for my PC.  In order to gain
> > internet access i must tell the login-server that i want to get access.
> > Once i get access i have to pay some amount per minute. The access is
> > controlled by some sort of NAT/firewall located at my ISP. I'm
> > automatically logged off if there has been no traffic between me and the
> > internet for a period of 5 min.
>
> This is much clearer than your first post.
>
> > What i would like to do is to have diald call the login-server to let me
> > out if i need access and use the rules of diald to log me off again. I
> > dont want to have a permanent connection since i pay per minute.
>
> Yes, I think diald is just the right tool for this job.
>
> 1) With the route command, you should set up a special route just to your
> ISP (where you telnet to "turn on the internet").  That way diald isn't
> involved when you try to turn it on.  Don't set up a default route to the
> internet with the route command.
>
> 2) For starters, set up diald with the static ip you were given and the
> defaultroute option.  Have your connect and disconnect scripts just log
> messages to some file in tmp or something.
>
> Test the setup by starting some network app, say telnet to a location
> other than your ISP.  The connect script should run.  While the first
> telnet is waiting, telnet to your ISP and do whatever you have to do to
> "turn on the internet".  The first telnet should then connect.  Log out of
> the first telnet.  The disconnect script should run.  Then "turn off the
> internet".
>
> 3) Now you can try to automate the procedure you use to turn on/turn off
> the internet.  Forget diald for a while.  Install the "expect" utility if
> you haven't already.  Write an expect script the mimics your actions when
> you turn on/off the internet.
>
> Then split the script into two, one that starts it up and one that ends
> it.  I forsee a problem if you have to maintain a single telnet session at
> the ISP while your internet is active.  I hope that isn't the case.  If it
> is, you may need to keep the telnet process alive even after the connect
> script has died.  Offhand, I don't know how you can do that, but I'm sure
> there's a way with expect.
>
> 4) Combine diald with the expect scripts: make those scripts the connect
> and disconnect scripts for diald.
>
> You may have trouble due to the timeout at the ISP end, but don't worry
> about that until everything else is working.  If you do have trouble, the
> simplest thing to do would be to make sure most of your diald timeouts are
> less than the ISP timeouts -- either make sure your filter file has no
> timeouts larger than 5 minutes, or ask your ISP to extend their timeout to
> 10 or 15 minutes.
>
> Ed
>
> --
> Ed Doolittle <mailto:[EMAIL PROTECTED]>
> "Everything we do, we do for a reason."  -- Peter O'Chiese


-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]

Reply via email to