PDA

View Full Version : PPPoE client failing


davidsc
26-01-2004, 04:44 PM
I have downloaded the rp-pppoe-3.5-1.i386.rpm file from www.roaringpenguin.com and run adsl-setup successfully on my Linux box. I am running a Redhat 7.2 distribution (Clark Connect 1.1).

I have configured my Netcomm 1300B ADSL modem into full bridge mode as per the user guide - this includes using a cross-over cable (I have tried straight thru also) between my modem and the Linux box eth0 card. I run adsl-start and it reports that it has connected OK but when I try to browse the internet it doesn’t work. I can ping neither www.google.com nor 198.133.219.25.

Here is the output from ifconfig after I have run adsl-start:
eth0 Link encap:Ethernet HWaddr 00:90:27:90:D1:EA
inet addr:192.168.1.4 Bcast:255.255.255.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1
RX packets:49 errors:0 dropped:0 overruns:0 frame:0
TX packets:198 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3493 (3.4 Kb) TX bytes:13906 (13.5 Kb)
Interrupt:9 Base address:0xb000

eth1 Link encap:Ethernet HWaddr 00:04:E2:22:47:04
inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:77 errors:0 dropped:0 overruns:0 frame:0
TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:8246 (8.0 Kb) TX bytes:8842 (8.6 Kb)
Interrupt:10 Base address:0x2000

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:25 errors:0 dropped:0 overruns:0 frame:0
TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1430 (1.3 Kb) TX bytes:1430 (1.3 Kb)

ppp0 Link encap:Point-to-Point Protocol
inet addr:218.214.23.xxx P-t-P:202.154.95.173 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:78 (78.0 b) TX bytes:30 (30.0 b)

Here is the output from running route:
--------------------------------------------------------------------------------
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
202.154.95.xxx * 255.255.255.255 UH 0 0 0 ppp0192.168.1.0 * 255.255.255.0 U 0 0 0 eth0192.168.0.0 * 255.255.255.0 U 0 0 0 eth1127.0.0.0 * 255.0.0.0 U 0 0 0 lodefault 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

--------------------------------------------------------------------------------

My suspicion is that I have the Linux box setup OK but my modem may be at fault. My modem is working OK however when I connect successfully to the internet with the modem in default mode as the PPPoE client.

David

:rolleyes:

Cammyron
27-01-2004, 12:01 PM
Not sure if this will help but i can tellyou how i have configured my stuff to use with linux.

I already have my modem/router runnign on a winXP machine. I just pluged my linux box (in this case my laptop) in to a spare port on the modem and used the netconfig command to set up my details. Gave my laptop an ip number 1 different from my destop computer. used the same subnet and gateway settigns as my destop pc as well. entered in the dns server details for victria from the swift members page.

Thats it is all wors fine.

I am running Slacware 9.1 on a DE destop but most things should be very similar

fugitive
27-01-2004, 12:09 PM
It has been a while since I ran PPPoE on Linux but if I can recall back that far I see that you have addresses assigned to both ethernet cards. There is not supposed to be any address assignment for the card that the pppo connection will be running on.

If I recall correctly the ethernet card definition should be down and the pppo connection should be up.

I hope this helps, if not I might be able to dig up a configuration somewhere, let me know.

davidsc
28-01-2004, 09:17 AM
:(

My var/log/messages suggests(?) something awry with pppoe:

Jan 28 09:51:32 clarkconnect pppd[4231]: pppd 2.4.1 started by root, uid 0
Jan 28 09:51:32 clarkconnect pppd[4231]: Using interface ppp0
Jan 28 09:51:32 clarkconnect pppd[4231]: Connect: ppp0 <--> /dev/pts/0
Jan 28 09:51:33 clarkconnect pppoe[4232]: PPP session is 4988
Jan 28 09:51:36 clarkconnect pppd[4231]: not replacing existing default route to eth0 [192.168.1.1]
Jan 28 09:51:36 clarkconnect pppd[4231]: local IP address 218.214.23.121
Jan 28 09:51:36 clarkconnect pppd[4231]: remote IP address 202.154.95.173

I agree with fugitive who has remarked (see my ifconfig output) that the ethernet card definition should be down and the pppo connection should be up. :confused:

davidsc
28-01-2004, 09:56 AM
I tried removing my eth0 ifconfig before running adsl-setup. It helped insofar as I was then able to ping internet addresses from my Linux box. However my Windows machine behind the Linux firewall was no longer able to see the internet. It appears that routing thru the Linux box got screwed up by taking out eth0 from my network configuration on Linux.

fugitive
28-01-2004, 10:10 AM
Any firewall software running on the Linux box - like iptables or ipchains (or a software package like firestarter). You might have to modify the rules. Don't know for sure though, just a thought.

berin
02-02-2004, 04:58 PM
Looks like a routing problem.

According to your routing table, you have a default route set to go to 192.168.1.1, which is off eth0. So by default, anything the box doesn't know about (which is anything not directly attached), it will send to whatever is at 192.168.1.1. That will be why you couldn't see anything until you killed eth0, which will have immediately killed that default route.

So the first thing to do would be remove that, and then PPP should automatically load a default route when you connect to the Internet.

You may then need to add some routes ("route" command) to talk to your Windows box if it is not directly attached. What IP address is your Windows box? Is it directly attached? Does it have a default route that points to the Linux firewall?

Cheers,
Berin

smkranz0506
12-02-2004, 07:34 AM
i'd definitely say it's a routing prob.

default route must be thru ppp. your eth0 can be up, but must come up after ppp is up.

eth0 needs to be up so you can talk to your modem??

davidsc
12-02-2004, 08:38 AM
I can reliably run adsl-start and connect to the internet from my Linux console by pinging any internet address.

Most certainly it is a routing problem I am experiencing, but I am having heaps of trouble getting to the bottom of the problem.

I was advised to run 'service firewall restart' and did so. The iptables set up doesn't work. I get back message 'External IP not available ... exiting'

What is the external IP referred to?

smkranz0506
12-02-2004, 10:07 AM
been a while since i used clarkconnect, used it to get some experience before moving to debian.

if i remember correctly, clarkconnect have written their own firewall script (rc.firewall) or something that is called when you do service firewall restart. use locate to find the file. the error you receive is from that script i think.

check in that script for the reference to $extip. if you're using adsl, it should point to ppp0 (correct me if i am wrong). the script does an ifconfig ppp0 and then uses sed & awk to get the external ip. it then uses that extip in all your iptable rules.

my firewall script i use on debian was derived from the one in clarkconnect, but i have now customised it for my debian setup.

let me know how you go.

sticky_chicken
12-02-2004, 10:30 AM
Originally posted by fugitive
It has been a while since I ran PPPoE on Linux but if I can recall back that far I see that you have addresses assigned to both ethernet cards. There is not supposed to be any address assignment for the card that the pppo connection will be running on.




No, that's not correct. Here's the output of an ifconfig on my linux box.

eth0 Link encap:Ethernet HWaddr 00:60:67:01:88:8B
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5852 errors:0 dropped:0 overruns:0 frame:0
TX packets:5242 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1246557 (1.1 Mb) TX bytes:770604 (752.5 Kb)
Interrupt:9 Base address:0xf000


eth1 Link encap:Ethernet HWaddr 00:A0:0C:C2:88:6C
inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2228 errors:0 dropped:0 overruns:0 frame:0
TX packets:2270 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:226507 (221.1 Kb) TX bytes:700565 (684.1 Kb)
Interrupt:9 Base address:0xd400

ppp0 Link encap:Point-to-Point Protocol
inet addr:218.214.0.x P-t-P:202.154.95.173 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:5287 errors:0 dropped:0 overruns:0 frame:0
TX packets:4686 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:1072798 (1.0 Mb) TX bytes:611852 (597.5 Kb)

Destination Gateway Genmask Flags MSS Window irtt Iface
255.255.255.255 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
202.154.95.173 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 202.154.95.173 0.0.0.0 UG 0 0 0 ppp0


The NIC that goes into my ADSL modem is eth0, and as you can see it has 192.168.1.3 assigned to it.

davidsc
12-02-2004, 11:40 AM
Triumph at last!!

I found that I had to modify the GATEWAYDEV setting in etc/sysconfig/network to be ppp0 and not eth0 and lo and behold the problem is solved.

For everybody's information as I am using my ADSL modem is pptpd pass thru mode (yes it does work with a Netcomm 1300B), the modem is operating in bridge mode and consequently there is NO IP address associated with eth0 when I run ifconfig.

Furthermore I have now tested VPN connectivity to my network and it also works!

And I was on the verge of blowing away my CC setup.

smkranz0506
12-02-2004, 12:04 PM
good to hear,

did you also figure out your rc.firewall errors? or was what i said completely wrong.

the GATEWAYTDEV variable does ring a bell though.