I opened the champagne bottle a little bit too fast yesterday. ;-( Yes, I actually got diald working from the client, but it worked only the first time. Each time I reboot my gateway, the client is working once and the first time I bring the link up. I was also wrong about the need to have a route defined for the tap0 interface with the remote IP address as the destination (I fixed the problem by having local and remote addresses the same in my diald.conf file). Even if I am now much more close to a final solution, it is still not a working environment as expected. My routing table contains only the default entry as suggested by Christian below, the annoying message about char-major-108 was removed. Each time I reboot the gateway, I have a working environment for the first connection only. So, there should be something in the diald and/or ppp setup that is breaking the initial environment. But, what??? I included my diald.conf file if someone wants to look at it... Daniel Le lun, 17 avr 2000, vous avez �crit : > This message was sent from Geocrawler.com by "Christian" <[EMAIL PROTECTED]> > > Hi Daniel, > I met the same problems..! > Maybe it'll help you: > > At first, are you sure that routing is activated ? > # echo 1 > /proc/sys/net/ipv4/ip_forward > > >Routing table on the diald gateway while the link > is down : > >Kernel IP routing table > >Destination Gateway Genmask > Flags MSS Window irtt Iface > >192.168.0.1 * 255.255.255.255 > UH 0 0 0 tap0 > > I don't think this one is very good, just the > default route is necessary. > I had a similar pb due to the "sticky" parameter > in diald.conf which forced the same host route as > yours. The only difference is that I could make > one (the first in fact) connection because at that > time the host route was not here. After the link > has been down, the host route appeared and I never > could redial. > Try to see why it is here and prevent it to come. > > >syslog output: > >. > >Apr 16 13:56:32 yukawa diald[11093]: Running pppd > (pid = 11111). > >Apr 16 13:56:35 yukawa modprobe: can`t locate > module char-major-108 > > This error has nothing to see with your pb (I > think ;) but you can prevent it in adding in your > /etc/conf.modules > alias char-major-108 ppp > and create the dev : > # mknod ppp -c 108 0 > > For the ppp device, it seems that pppd doesn't > need it !? > I tried with and without, and had no pb ! > If someone can explain this point ???? > > Hope this help ! > @tchao > > Geocrawler.com - The Knowledge Archive -- Daniel Savard CIDS Inc. Courriel: [EMAIL PROTECTED]
# # diald.conf for videotron # debug 95 # Select the demand dial rules you want # Bring the link up for anything, timeout in seconds. Use this for # when the dompute has its own phone line #accept any 1200 any #bringup any 1200 any # Use the filter file that comes with diald. This can be a bit drastic, # so use the filter below # include /usr/lib/diald/standard.filter # or use the filter that brings the link up for use on a line shared with # a phone include /etc/diald/videotron.filter linkname Videotron linkdesc "Acces Internet Videotron" # stuff to set up the diald connection device /dev/modem speed 115200 lock mode ppp # We may get another terminal server, thus use # 'dynamic' and do not tell PPP the IP number of the other end # For use with gated, comment out the 'dynamic' option, and # set remote to be the same as local dynamic local 192.168.0.2 remote 192.168.0.2 pppd-options noauth # Delay sending packets for 5 seconds after PPP device opens - # this allows routes to be established back to the appropriate dialup server. #up-delay 15 defaultroute modem crtscts connect /etc/diald/videotron-chat #reroute #addroute /etc/diald/videotron-addroute #delroute /etc/diald/videotron-delroute redial-timeout 5 fifo /etc/diald/videotron.ctl # restrict 9:00:00 17:45:00 1 * * # or-restrict 9:00:00 17:45:00 2 * * # or-restrict 9:00:00 17:45:00 3 * * # or-restrict 9:00:00 17:45:00 4 * * # or-restrict 9:00:00 17:45:00 5 * * # up
