Re: ppp loopback
[EMAIL PROTECTED] writes: [snip] > I also have to say that only getmail is not working .. mail get > sent. So probably it's a problem with popclient (which is newer than > Slack and has some differencies in options .. and is obsolete, > substituted by .. fetchmail? that was alos substituted by .. don't > remember .. I'll try qpopper and see how it behaves. fetchmail is still being maintained and improved. The latest version is 3.9; I think the latest Debian version I've seen is 3.8. IMHO, the latest versions of fetchmail are very nice. (But I've also had some input into it's development so I have a vested interest in getting its NEWS file distributed widely...) [snip] > Well. I'm almost sure here (but could be wrong anyway). My LAN is made up of > two PCs, rarely up together (it's my home LAN). So default route is usually > thru eth0, like this: (route -n) > > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse Iface > a.b.c.0 0.0.0.0 255.255.255.0 U 0 00 eth0 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 05 lo > 0.0.0.0 0.0.0.0 0.0.0.0 U 0 01 eth0 My feeling is that unless you can get to an arbitrary address over the default route (e.g. the other PC is running diald or is permanently connected) the default route is overkill. Actually, the whole Internet would have to be on your LAN, since there's no gateway. If you have just one other PC, you can add a route to just that machine and probably save yourself a lot of grief: ifconfig eth0 192.168.10.1 # The local machine route add -host 192.168.10.2# The other machine Or you can use your local network only, which is basically your example above without the last line: ifconfig eth0 192.168.10.1 route add -net 192.168.10.0 # Class C network -- Carey Evans <*> [EMAIL PROTECTED] "Double, double, toil and trouble, / Fire burn and cauldron bubble."
Re: ppp loopback
> > [EMAIL PROTECTED] writes: > > [snip] > > > But .. it doesn't start ip-up properly, since > > ip-up does the following: > > [snip] > > > and I get messages from the echo lines, but I don't get any mail > > popped or sent. Strange is, if I run ip-up by hand, it behaves > > properly. > > Do putmail and getmail rely on any settings of uid? Slackware 3.0's I don't know. Maybe. putmail simply checks if there are files in /var/spool/mqueue and if so starts sendmail on the queue. getmail starts popclient with appropriate parameters, and the filters received mail with awk. I'll check on this, but id doesn't work with root either. I also have to say that only getmail is not working .. mail get sent. So probably it's a problem with popclient (which is newer than Slack and has some differencies in options .. and is obsolete, substituted by .. fetchmail? that was alos substituted by .. don't remember .. I'll try qpopper and see how it behaves. > pppd ran ip-up (for me) with euid=root, uid=carey. Debian's pppd runs > ip-up with euid=root, uid=root. I'm using the gid=carey to work out > who invoked pppd. > > > Also, in debian pppd I have to set default route by hand, since pppd > > informs me that he refuses to substitute my default route (usually > > to eth0) to ppp0 I'm using defaultroute in options file, but this > > doesn't help. > > Are you sure the previous default route is right? For example, at Well. I'm almost sure here (but could be wrong anyway). My LAN is made up of two PCs, rarely up together (it's my home LAN). So default route is usually thru eth0, like this: (route -n) Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface a.b.c.0 0.0.0.0 255.255.255.0 U 0 00 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 05 lo 0.0.0.0 0.0.0.0 0.0.0.0 U 0 01 eth0 This is how both Slack and Debian (with /etc/init.d/network) set it up. When I call my ISP, I want my default route to be thru it: Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface a.b.c.0 0.0.0.0 255.255.255.0 U 0 00 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 05 lo 0.0.0.0 my.isp.addr 255.255.255.0 U 0 01 ppp0 that's it. When I hang up, it has to revert to prior setup. With Slack that happened simply using defaultroute in /etc/ppp/options. > The best solution is to start "routed -q" which updates my machine You probably have real networks, so you have real routers and gateways. I think mine would be a little up-on-steroids home LAN if I used routed. > from the router's periodic broadcasts. I think I should put some > stuff in /etc/gateways in case someone else's machine starts > broadcasting bogus routes though. Thanks for your suggestions, -- |||| ||| Marco Frattola Microsoft is not the answer ||`..'|| |||... Piacenza, ItalyMicrosoft is the question ||| ||| |||''[EMAIL PROTECTED]"No" is the answer ||| ||| ||| www.enjoy.it/users/~mk/index.html Live Linux, live free!
Re: ppp loopback
[EMAIL PROTECTED] writes: [snip] > But .. it doesn't start ip-up properly, since > ip-up does the following: [snip] > # routing > route del default > route add default dev ppp0 > > # send mail > echo 'doing putmail' > /dev/console > $EXECDIR/putmail > > # get mail > echo 'doing getmail' > /dev/console > $EXECDIR/getmail [snip] > and I get messages from the echo lines, but I don't get any mail > popped or sent. Strange is, if I run ip-up by hand, it behaves > properly. Do putmail and getmail rely on any settings of uid? Slackware 3.0's pppd ran ip-up (for me) with euid=root, uid=carey. Debian's pppd runs ip-up with euid=root, uid=root. I'm using the gid=carey to work out who invoked pppd. > Also, in debian pppd I have to set default route by hand, since pppd > informs me that he refuses to substitute my default route (usually > to eth0) to ppp0 I'm using defaultroute in options file, but this > doesn't help. Are you sure the previous default route is right? For example, at work we use 192.168.17.* and 192.168.18.* subnets, where 192.168.17.200 aka 192.168.18.200 is the router. My machine is 192.168.17.11, so I can access the first subnet OK with route add -net 192.168.17.0. To access the second I could route add default 192.168.17.200 (I think), but the better solution is route add -net 192.168.18.0 gw 192.168.17.200. The best solution is to start "routed -q" which updates my machine from the router's periodic broadcasts. I think I should put some stuff in /etc/gateways in case someone else's machine starts broadcasting bogus routes though. -- Carey Evans <*> [EMAIL PROTECTED] "Double, double, toil and trouble, / Fire burn and cauldron bubble."
Re: ppp loopback
Hi all and thanks to Dimitri and Bruce Perens who showed me the way .. > >> Apr 1 21:05:52 zanzy pppd[351]: Serial line is looped back. > ... > >What does this mean?(*) What can I do to prevent it? > > Usually happens when > a) you forgot to send "ppp" command to your ISP (ie. common > login sequence is to to send username, password and then "type of > service -- ppp, slip, whatever) This is not the case, since, as I said, the same script with same hw works fine .. but it's Slackware, and I want to get rid of it and move completely to debian. > b) ppp takes long time to start on your ISP's box. This is probably the cause, but still I don't see why .. except Slack pppd being slower than debian pppd .. so not catching up with my ISP. Reading Debian doc about pppd (/usr/doc/pppd/README) suggest me to put a chat && sleep 5 in my script and this fixed it. But .. it doesn't start ip-up properly, since ip-up does the following: #!/bin/sh # # $Id: ip-up,v 1.1 1996/01/31 21:25:59 alvar Exp $ # # This script is run by the pppd after the link is established. # It should be used to add routes, set IP address, run the mailq # etc. # # This script is called with the following arguments: #Arg Name Example #$1 Interface name ppp0 #$2 The ttyttyS1 #$3 The link speed 38400 #$4 Local IP number12.34.56.78 #$5 Peer IP number12.34.56.99 # # The environment is cleared before executing this script # so the path must be reset # PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin export PATH # ADDED # MK @ PC 96/01/25 # say we're on-line echo "running on $1 to $5 as $4 @ $3" > /dev/console EXECDIR=/etc/ppp # routing route del default route add default dev ppp0 # send mail echo 'doing putmail' > /dev/console $EXECDIR/putmail # get mail echo 'doing getmail' > /dev/console $EXECDIR/getmail echo "ip-up done!" > /dev/console # last line and I get messages from the echo lines, but I don't get any mail popped or sent. Strange is, if I run ip-up by hand, it behaves properly. Also, in debian pppd I have to set default route by hand, since pppd informs me that he refuses to substitute my default route (usually to eth0) to ppp0 I'm using defaultroute in options file, but this doesn't help. I'm not complaining, when I compare slackware to debian. In all machine I have installed (up to now, more than 10) debian behaves generally better than Slack, so I'm happily moving all machine to debian. I just want to know what I'm doing wrong here, since probably it's my fault. Thanks to all the folks who made and still make debian so good! Any help is welcome Thanks in advance > b) use "TIMEOUT" chat commands, "passive" or "silent" pppd options. I'll try them -- |||| ||| Marco Frattola Microsoft is not the answer ||`..'|| |||... Piacenza, ItalyMicrosoft is the question ||| ||| |||''[EMAIL PROTECTED]"No" is the answer ||| ||| ||| www.enjoy.it/users/~mk/index.html Live Linux, live free!
Re: ppp loopback
It means the remote system echoed serial characters that PPP sent. This happens when the remote pppd hasn't started and you are sending packets at the login prompt or the shell prompt. Run through the chat script by hand and see if it really gets you logged in. Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3
Re: ppp loopback
In message <[EMAIL PROTECTED]> you wrote: >Hi all, > ... >> Apr 1 21:05:52 zanzy pppd[351]: Serial line is looped back. ... >What does this mean?(*) What can I do to prevent it? Usually happens when a) you forgot to send "ppp" command to your ISP (ie. common login sequence is to to send username, password and then "type of service -- ppp, slip, whatever) b) ppp takes long time to start on your ISP's box. In both cases the remote box simply echoes back whatever you send them, hence the error message. Fixes: ( best thing to do is to use minicom to manually go through the login sequence so that you know what exactly is going on there ) a) check your chat script b) use "TIMEOUT" chat commands, "passive" or "silent" pppd options. -- Dimitri mailto:emaziuk at curtin.edu.au and don't forget to relace " at " with "@" --- The views expressed above (hereafter, views) are mine and ownership remains with me. They are provided "as is" without expressed or implied warranty of any kind, including, but not limited to, the implied warranties of the suitability of the views for any purpose.
