Mike,
Did you change the logic for the call to ip in the latest version?
I ask because I am seeing the following with kernel 2.2.3-ac1, diald 0.98.3,
iproute2 2-1-99 and net-tools 1.50
ip is installed in /sbin, for this exercise tap-local is 10.0.0.1 tap-remote
is 10.0.0.2, ppp-local is 1.2.3.4, ppp-remote is 1.2.3.5
-- problem one
The route command is formatted for ip but the string '/sbin/ip' or even 'ip'
is never output to the routing command so it is in effect calling
/sbin/route with the wrong set of arguments.
This resulted in no default route being set at all. I could not reach the
internet without manually setting up routes.
Resolution: setting 'path-ip /sbin/ip' solved the problem of the wrong
command being called.
Recommendation: if you have to probe for ip for setting the syntax of the
routing command, then you should use that result in outputting the whole
command rather than appending the proper parameters to the value of path-ip
which is empty by default. Alternately only use ip and it's syntax if
path-ip is actually given a value in the options.
[note: reading the man page gave the impression that path-ip should be the
path without the executable name. This fails with identical results as not
having path-ip set at all. eg. command is called as '/sbin route ...']
-- problem two
After the link goes up for the first time, local traffic still does not
bring up the link. It looks like it may be because you are doing a
'/sbin/ip route add ...' (which gives an error of 'RTNETLINK error: File
exists') because tap0 already exists with routing rather than an '/sbin/ip
route replace' which produces no error at all.
[The ifconfig error is 'SIOCSIFMETRIC: Operation not supported' which from
earlier emails is reported to be harmless. tap0 is not in point to point
mode though which may effect things.]
Now there is a default route in place but traffic on the local net does not
trigger a dialup.
Resolution: manually setting up the same route commands with the replace
parameter allows local traffic to trigger the link once again.
The critical command is '/sbin/ip route replace 10.0.0.2 dev tap0 scope link
src 10.0.0.1 metric 0 ' which seems to be retained there after so it diald
continues to work even after the next dialing.
Hope this make sense, (I've got to get some sleep)
Lourdes
-- /var/log/messages error on link up
Mar 16 09:23:17 ishhara diald[1525]: Nonzero exit status (1) on command
'/sbin/ifconfig ppp0 1.2.3.4 pointopoint 1.2.3.5 netmask 255.255.255.255
metric 0 mtu 1500 up'
-- /var/log/messages errors on link down
Mar 16 09:41:23 ishhara diald[1525]: FIFO: link down request
Mar 16 09:41:24 ishhara diald[1525]: Nonzero exit status (1) on command
'/sbin/ifconfig tap0 10.0.0.1 pointopoint 10.0.0.2 netmask 255.255.255.255
metric 0 mtu 1500 up'
Mar 16 09:41:24 ishhara pppd[4145]: Terminating on signal 2.
Mar 16 09:41:24 ishhara pppd[4145]: Connection terminated.
Mar 16 09:41:26 ishhara pppd[4145]: Exit.
Mar 16 09:41:26 ishhara diald[1525]: Nonzero exit status (1) on command
'/sbin/ifconfig tap0 10.0.0.1 pointopoint 10.0.0.2 netmask 255.255.255.255
metric 0 mtu 1500 up'
Mar 16 09:41:26 ishhara diald[1525]: Nonzero exit status (2) on command
'/sbin/ip route add 10.0.0.2 dev tap0 scope link src 10.0.0.1 metric 0 '
Mar 16 09:41:26 ishhara diald[1525]: Nonzero exit status (2) on command
'/sbin/ip route add default dev tap0 scope link src 10.0.0.1 metric 0 '
-- ip route list
default dev tap0 scope link src 10.0.0.1
-- ifconfig tap0
tap0 Link encap:Ethernet HWaddr FE:FD:00:00:00:00
inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.255.255.255
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:144 errors:0 dropped:0 overruns:0 frame:0
TX packets:144 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
Interrupt:5
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
