Here are some pasted extracts from posts I've looked up that mirror my current questions. I want to confirm my understanding of the comments. Also I then have some further questions at the end: > >Jul 6 17:45:39 nameserver modprobe: can't locate module tap0 > > Read README.ethertap. If your kernel doesn't have an ethertap > module and you don't want to build one you can add "alias tap<n> off" > lines to /etc/modules.conf (or /etc/conf.modules or whatever your > dist. calls it this week) I get the modprobe error as above. My reading seems to indicate that: ethertap is optional and if not compiled in I wll get the above error but I can ignore it because if not there then diald will use the slip proxy ? But that if I do want to use the ethertap then I need to compile it in and edit modules.conf with tap<n> alias'. > > >Jul 6 17:45:40 nameserver diald[905]: start sl0: SIOCSIFMETRIC: > >Operation not supported > > 2.2 kernels don't support interface metrics. Diald tries in case > someone was relying on it with older kernels. > > >Jul 6 17:45:41 nameserver diald[905]: start sl0: SIOCADDRT: File exists > > 2.2 kernels add routes automatically. Diald tries to add the route anyway > because we need to do it on older kernels. I get these too but this says I can ignore these because I'm using Kernel 2.2.12 is that right ? NOW my diald dials my office server the trigger seems to be a domain packet but then it doesn't hang in. It exists and then delays for 30 seconds and then dials again. I'm finding it a bit hard to work out what is going on. Is there a minimal diald.conf that I can start with and slowly open up packets one at a time. If I start diald it doesn't connect immediately. The log says it's running. Then if I try say ftp ... or lynx ... or ... then it get a domain packet and dials so this seems ok to me. Problem is the ftp or whatever never works and if I try to start another lynx to see if it's just the first lot of packets through then they don't get anywhere either. Also will diald pass packets from the private network range or does it decide to play traffic enforcer and refuse to pass these on because my home server is 192.168.3.X and the other end is 192.168.2.x. Eventually these packets will be masqueraded before they leave our network as 203.26.11.145 but we don't bother masquerading across our internal subnets. I'd really appreciate it if someone can make sense of this rambling and provide some suggestions. thanks, Wilson Fletcher - To unsubscribe from this list: send the line "unsubscribe linux-diald" in the body of a message to [EMAIL PROTECTED]
