PPP server doesn't work

PPP server doesn't work

[Anton Martchukov]

I did install a small PPP server on my home machine in order to play 
FreeCiv etc., but can't figure out why it refuses to run. According to 
pppd debug logs all goes right, here is the options I use for pppd:

auth
-chap
+pap
login
debug
proxyarp
ktune
asyncmap 0
netmask 255.255.0.0
lock
crtscts
modem
vhcastle:ppp
ms-dns 192.168.1.1
mtu 576
mru 576
logfile /var/log/pppd.log

I use proxyarp and pppd tells that allright in logs:

found interface eth0 for proxy arp
local  IP address 192.168.1.1 (this is vhcastle)
remote IP address 192.168.10.1 (this is ppp)

But anyway I can't ping remote machine, none of packets are sent thru 
the link, I've checked it with tcpdump. IP forwarding is enabled via 
sysctl.

ifconfig ppp0:
ppp0   Link encap:Point-to-Point Protocol
          inet addr:192.168.1.1  P-t-P:192.168.10.1 Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:576  Metric:1
          RX packets:5 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0
          RX bytes:102 (102.0 b)  TX bytes:96 (96.0 b)

route on server:
ppp                 *      255.255.255.255 UH  0      0        0 ppp0
169.254.0.0     *      255.255.0.0        U     0      0        0 eth0
192.168.0.0     *      255.255.0.0        U     0      0        0 eth0
127.0.0.0         *       255.0.0.0          U     0      0        0 lo

So, I completely stuck with this. Some points confusing me are NOARP for 
ppp0 in the output of ifconfig (is this a problem?). Also, I can't 
pinpoint where the net 169.254.0.0 is assigned to eth0 in configs, I 
did not specify it anywhere. 

I use RedHat 9 (ASP 9) with pppd 2.4.2, same on the other end + KPPP 
from KDE 3.1. Any ideas will be greatly appreciated.






-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: PPP server doesn't work

[Ray Olszewski]

You are going to have to say a bit more about the setup to get good help. 
For now ...

1. Your routing table is hard to read (due to the "ppp" entry on the first 
line). But your ifconfig output says that both ends of the ppp link are in 
netwotk 192.168.0.0/16, which the routing talbe says is in eth0, not ppp0. 
Usually host routes supersede network routes, but the use of "ppp" conceals 
the actual address set. When reporting routing tables, ALWAYS use a flag to 
force reporting by address (e.g., "netstat -nr" or "route -n").

2. Since you are familiar with tcpdump ... are the ping packets going out 
ANY interface? (Answer with respect both to the host you are ping'ing from 
AND the "ppp server", if they are different hosts.)

3. here are you ping'ing FROM? The server itself? Some other host on 
192.168.0.0/16? Since you talk about proxyarp, I'd guess the second. If so, 
after you try and fail to ping, does this third host's arp table have an 
entry for the "ppp server "host? Does the ping fail silently, or is there 
some error message?

4. Can you ping the "ppp server" from the "ppp client"? If not, how does 
that ping fail (silently, or is there an error message)?

5. Next time please be very exact about which machine is which.

         You say you put "a small PPP server on my home machine".

         Later, you talk about "local" and "remote" machines, but I am 
unclear as to which of these is the ppp "server" (since you said it was 
your "home" machine, does that mean it is "local"?).

         Then you tell us which IP address is "vhcastle", which "ppp", 
without explaining what the hostnames refer to.

         Similarly, later switching to referring to the "server" and the 
"other end" leaves me confused ... pick one way to refer to each host and 
stick with it, please.

In addition to clarifying the above items, next time please provide for 
BOTH hosts (or all 3, if you are ping'ing from yet a different host), the 
unedited output of

         ifconfig -a
         netstat -nr
         cat /proc/net/arp [this AFTER an unsuccessful ping]

labeling them very clearly as to which is which.

At 01:46 PM 3/27/2004 +0300, Anton Martchukov wrote:
>I did install a small PPP server on my home machine in order to play
>FreeCiv etc., but can't figure out why it refuses to run. According to
>pppd debug logs all goes right, here is the options I use for pppd:
>
>auth
>-chap
>+pap
>login
>debug
>proxyarp
>ktune
>asyncmap 0
>netmask 255.255.0.0
>lock
>crtscts
>modem
>vhcastle:ppp
>ms-dns 192.168.1.1
>mtu 576
>mru 576
>logfile /var/log/pppd.log
>
>I use proxyarp and pppd tells that allright in logs:
>
>found interface eth0 for proxy arp
>local  IP address 192.168.1.1 (this is vhcastle)
>remote IP address 192.168.10.1 (this is ppp)
>
>But anyway I can't ping remote machine, none of packets are sent thru
>the link, I've checked it with tcpdump. IP forwarding is enabled via
>sysctl.
>
>ifconfig ppp0:
>ppp0   Link encap:Point-to-Point Protocol
>           inet addr:192.168.1.1  P-t-P:192.168.10.1 Mask:255.255.255.255
>           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:576  Metric:1
>           RX packets:5 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0
>           RX bytes:102 (102.0 b)  TX bytes:96 (96.0 b)
>
>route on server:
>ppp                 *      255.255.255.255 UH  0      0        0 ppp0
>169.254.0.0     *      255.255.0.0        U     0      0        0 eth0
>192.168.0.0     *      255.255.0.0        U     0      0        0 eth0
>127.0.0.0         *       255.0.0.0          U     0      0        0 lo
>
>So, I completely stuck with this. Some points confusing me are NOARP for
>ppp0 in the output of ifconfig (is this a problem?). Also, I can't
>pinpoint where the net 169.254.0.0 is assigned to eth0 in configs, I
>did not specify it anywhere.
>
>I use RedHat 9 (ASP 9) with pppd 2.4.2, same on the other end + KPPP
>from KDE 3.1. Any ideas will be greatly appreciated.


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

[extra] PPP server doesn't work

[Anton Martchukov]

Sorry for extra traffic to the list.

I've only one machine 192.168.1.1 with ethernet card attached to it, but 
with no other hosts in network 192.168.0.0/16. This machine is PPP 
server which assigns IP address 192.168.10.1 for connected client and 
tries to do proxyarp with no success. Here is some info I collected out 
after the ppp connection has been established:

ifconfig -a on 192.168.1.1

eth0 Link encap:Ethernet  HWaddr 00:00:21:67:2C:49
     inet addr:192.168.1.1  Bcast:192.168.255.255  Mask:255.255.0.0
     UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
     RX packets:0 errors:0 dropped:0 overruns:0 frame:0
     TX packets:0 errors:69 dropped:0 overruns:0 carrier:69
     collisions:1104 txqueuelen:100
     RX bytes:0 (0.0 b)  TX bytes:4140 (4.0 Kb)
     Interrupt:5 Base address:0x300 

lo   link encap:Local Loopback inet addr:127.0.0.1  Mask:255.0.0.0
     UP LOOPBACK RUNNING  MTU:16436  Metric:1
     RX packets:98873 errors:0 dropped:0 overruns:0 frame:0
     TX packets:98873 errors:0 dropped:0 overruns:0 carrier:0
     collisions:0 txqueuelen:0
     RX bytes:11084300 (10.5 Mb)  TX bytes:11084300 (10.5 Mb)

ppp0 link encap:Point-to-Point Protocol inet addr:192.168.1.1
     P-t-P:192.168.10.1  Mask:255.255.255.255
     UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:576  Metric:1
     RX packets:5 errors:0 dropped:0 overruns:0 frame:0
     TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
     collisions:0 txqueuelen:3
     RX bytes:102 (102.0 b)  TX bytes:96 (96.0 b)

route -n on 192.168.1.1

192.168.10.1  0.0.0.0  255.255.255.255  UH  0  0  0 ppp0
169.254.0.0   0.0.0.0  255.255.0.0      U   0  0  0 eth0
192.168.0.0   0.0.0.0  255.255.0.0      U   0  0  0 eth0
127.0.0.0     0.0.0.0  255.0.0.0        U   0  0  0 lo

ifconfig -a on 192.168.10.1

lo   Link encap:Local Loopback
     inet addr:127.0.0.1  Mask:255.0.0.0
     UP LOOPBACK RUNNING  MTU:16436  Metric:1
     RX packets:147 errors:0 dropped:0 overruns:0 frame:0
     TX packets:147 errors:0 dropped:0 overruns:0 carrier:0
     collisions:0 txqueuelen:0 
     RX bytes:15516 (15.1 Kb)  TX bytes:15516 (15.1 Kb)

ppp0 Link encap:Point-to-Point Protocol  
     inet addr:192.168.10.1  P-t-P:192.168.1.1  Mask:255.255.255.255
     UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:576  Metric:1
     RX packets:134 errors:33 dropped:0 overruns:0 frame:0
     TX packets:111 errors:0 dropped:0 overruns:0 carrier:0
     collisions:0 txqueuelen:3 
     RX bytes:2017 (1.9 Kb)  TX bytes:2686 (2.6 Kb)

route -n on 192.168.10.1

192.168.1.1  0.0.0.0     255.255.255.255  UH  0  0  0  ppp0
169.254.0.0  0.0.0.0     255.255.0.0      U   0  0  0  lo
127.0.0.0    0.0.0.0     255.0.0.0        U   0  0  0  lo
0.0.0.0      192.168.1.1 0.0.0.0          UG  0  0  0  ppp0

Then ping on both hosts has been run
ping 192.168.10.1 (from 192.168.1.1)
ping 192.168.1.1 (from 192.168.10.1)
Both of pings told nothing, but 100% packet loss.
Packets were also dumped by tcpdump on both machines.

tcpdump -n -i ppp0 on 192.168.1.1

02:11:31.477168 192.168.1.1 > 192.168.10.1: icmp: echo request (DF)
02:11:31.482446 192.168.10.1 > 192.168.1.1: icmp: echo request (DF)
02:11:31.482672 192.168.1.1 > 192.168.10.1: icmp: echo reply

There were no echo reply from 192.168.10.1 to 192.168.1.1
tcpdump running on eth0 and lo on 192.168.1.1 shows no packets.

tcpdump -n -i ppp0 on 192.168.10.1

02:39:33.552747 192.168.10.1 > 192.168.1.1: icmp: echo request (DF)

There were no echo reply from 192.168.1.1 to 192.168.10.1 :-(

Finally arp table on both hosts after ping:

arp -n on 192.168.1.1

192.168.10.1  *  *  MP  eth0

arp -n on 192.168.10.1 shows nothing.

Manually running "arp -i eth0 -s 192.168.1.1 -D eth0" on 192.168.1.1 did
nothing, but appropriate record in arp cache of 192.168.1.1.

I'm not sure whether I really need proxyarp, but in manuals I've read 
were pointed that it's the easiest way of getting working remote 
network access in may case (I need only one client to access only my 
computer).

And could anybody tell me what the hell with this 169.254.0.0/16 
network? Nobody ever specified it anywhere on both hosts.

Thank you!

















-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: [extra] PPP server doesn't work

[Ray Olszewski]

OK. FIrst thing -- since we are talking about communication between the two 
hosts that have the ppp connection between them, proxyarp is irrelevant. 
That affects only connections from other hosts. (For example, if another 
host on 192.168.10.x/16 connected to the "server" end's Ethenet tried to 
reach the "client", the server would have to proxyarp the client's address 
so the third host could find the "client".)

Second, since there is a ppp connection between the two hosts, not an 
ethernet connection, each would not show up in the other's arp table, 
whether a connection is working or not.

Third, from the tcpdump output on the pings, it appears that 192.168.1.1 is 
working properly (it sends both pings and ping replies, -AND- it replies to 
a request), but 192.168.10.1 does not see icmp traffic coming from 
192.168.1.1. The possibilites to check are:

1. Does any firewalling on 192.168.1.1 interfere with transmission of icmp 
traffic? Depending on details you have not reported (what kernel you are 
using, what iptables or ipchains rulesets, some kernel switches set in the 
/proc filesystem) you may be blocking ping traffic at the server.

2. Related to (1), have you tested with anything ohter than ping? Can you, 
as an example, make an ssh connection between the two hosts?

3. Might there be a hardware problem at the "client" end? In the old days, 
for example, when a usable modem or NIC shared an IRQ with a Winmodem, the 
modem or NIC could send traffic but not receive replies. I haven't seen 
this in quite some time, but old problems do tend to come back. In general, 
is the modem on the client end known to work under Linux when connecting to 
someplace else?

4. I do not recall what the "DF"entry in the tcpdump output means, and I 
can't find a reference to it in the man page. Perhaps someone else here 
recognizes this and can jump in?

Fianlly, as to 169.254.0.0/16 ... this is a private address range used in 
the case of DHCP failures. Many DHCP clients are configured so that if they 
request a DHCP assignment and get no lease offers, they assign themselves a 
random address on this network. (The procedure is in the same addressing 
RFC as the more familiar private ranges, like 192.168.0.0/16.) In practice, 
the use for this is to facilitate hubness connections between two hosts 
(laptops, say) as temporary hookups for file transfer and the like. WIndows 
users are more familiar with this private-address range than are Linux users.

As to how it gets into *your* routing table ... how can I (or anyone) 
possibly say, when you don't say what Linux distro or version or kernel the 
"client" is using? Check its init scripts, wherever they are (it varies 
quite a bit from one distro to another) for one that sets up a routing 
table entry of this sort.

At 03:16 PM 3/28/2004 +0400, Anton Martchukov wrote:
>Sorry for extra traffic to the list.
>
>I've only one machine 192.168.1.1 with ethernet card attached to it, but
>with no other hosts in network 192.168.0.0/16. This machine is PPP
>server which assigns IP address 192.168.10.1 for connected client and
>tries to do proxyarp with no success. Here is some info I collected out
>after the ppp connection has been established:
>
>ifconfig -a on 192.168.1.1
>
>eth0 Link encap:Ethernet  HWaddr 00:00:21:67:2C:49
>      inet addr:192.168.1.1  Bcast:192.168.255.255  Mask:255.255.0.0
>      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>      TX packets:0 errors:69 dropped:0 overruns:0 carrier:69
>      collisions:1104 txqueuelen:100
>      RX bytes:0 (0.0 b)  TX bytes:4140 (4.0 Kb)
>      Interrupt:5 Base address:0x300
>
>lo   link encap:Local Loopback inet addr:127.0.0.1  Mask:255.0.0.0
>      UP LOOPBACK RUNNING  MTU:16436  Metric:1
>      RX packets:98873 errors:0 dropped:0 overruns:0 frame:0
>      TX packets:98873 errors:0 dropped:0 overruns:0 carrier:0
>      collisions:0 txqueuelen:0
>      RX bytes:11084300 (10.5 Mb)  TX bytes:11084300 (10.5 Mb)
>
>ppp0 link encap:Point-to-Point Protocol inet addr:192.168.1.1
>      P-t-P:192.168.10.1  Mask:255.255.255.255
>      UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:576  Metric:1
>      RX packets:5 errors:0 dropped:0 overruns:0 frame:0
>      TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
>      collisions:0 txqueuelen:3
>      RX bytes:102 (102.0 b)  TX bytes:96 (96.0 b)
>
>route -n on 192.168.1.1
>
>192.168.10.1  0.0.0.0  255.255.255.255  UH  0  0  0 ppp0
>169.254.0.0   0.0.0.0  255.255.0.0      U   0  0  0 eth0
>192.168.0.0   0.0.0.0  255.255.0.0      U   0  0  0 eth0
>127.0.0.0     0.0.0.0  255.0.0.0        U   0  0  0 lo
>
>ifconfig -a on 192.168.10.1
>
>lo   Link encap:Local Loopback
>      inet addr:127.0.0.1  Mask:255.0.0.0
>      UP LOOPBACK RUNNING  MTU:16436  Metric:1
>      RX packets:147 errors:0 dropped:0 overruns:0 frame:0
>      TX packets:147 errors:0 dropped:0 overruns:0 carrier:0
>      collisions:0 txqueuelen:0
>      RX bytes:15516 (15.1 Kb)  TX bytes:15516 (15.1 Kb)
>
>ppp0 Link encap:Point-to-Point Protocol
>      inet addr:192.168.10.1  P-t-P:192.168.1.1  Mask:255.255.255.255
>      UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:576  Metric:1
>      RX packets:134 errors:33 dropped:0 overruns:0 frame:0
>      TX packets:111 errors:0 dropped:0 overruns:0 carrier:0
>      collisions:0 txqueuelen:3
>      RX bytes:2017 (1.9 Kb)  TX bytes:2686 (2.6 Kb)
>
>route -n on 192.168.10.1
>
>192.168.1.1  0.0.0.0     255.255.255.255  UH  0  0  0  ppp0
>169.254.0.0  0.0.0.0     255.255.0.0      U   0  0  0  lo
>127.0.0.0    0.0.0.0     255.0.0.0        U   0  0  0  lo
>0.0.0.0      192.168.1.1 0.0.0.0          UG  0  0  0  ppp0
>
>Then ping on both hosts has been run
>ping 192.168.10.1 (from 192.168.1.1)
>ping 192.168.1.1 (from 192.168.10.1)
>Both of pings told nothing, but 100% packet loss.
>Packets were also dumped by tcpdump on both machines.
>
>tcpdump -n -i ppp0 on 192.168.1.1
>
>02:11:31.477168 192.168.1.1 > 192.168.10.1: icmp: echo request (DF)
>02:11:31.482446 192.168.10.1 > 192.168.1.1: icmp: echo request (DF)
>02:11:31.482672 192.168.1.1 > 192.168.10.1: icmp: echo reply
>
>There were no echo reply from 192.168.10.1 to 192.168.1.1
>tcpdump running on eth0 and lo on 192.168.1.1 shows no packets.
>
>tcpdump -n -i ppp0 on 192.168.10.1
>
>02:39:33.552747 192.168.10.1 > 192.168.1.1: icmp: echo request (DF)
>
>There were no echo reply from 192.168.1.1 to 192.168.10.1 :-(
>
>Finally arp table on both hosts after ping:
>
>arp -n on 192.168.1.1
>
>192.168.10.1  *  *  MP  eth0
>
>arp -n on 192.168.10.1 shows nothing.
>
>Manually running "arp -i eth0 -s 192.168.1.1 -D eth0" on 192.168.1.1 did
>nothing, but appropriate record in arp cache of 192.168.1.1.
>
>I'm not sure whether I really need proxyarp, but in manuals I've read
>were pointed that it's the easiest way of getting working remote
>network access in may case (I need only one client to access only my
>computer).
>
>And could anybody tell me what the hell with this 169.254.0.0/16
>network? Nobody ever specified it anywhere on both hosts.
>
>Thank you!


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs