Astaro not compatible with my ISP’s PPPoE?

Ver. 7.101
Since no one is able to help me with my PPPoE problem, I've been using the NetGear router to connect to the internet and have the Astaro gateway connected to it through the DMZ.  This seems to work ok except that I'm now trying to set up a VPN and the Astaro box is seeing the LAN address of the NetGear as the external address.  I think this is why the VPN can't make a connection.  Are there any settings I can make in the Astaro box to point it at the correct external address?  The external address is dynamic and I use dyndns to find it.

Also, I made a mistake in the first post about the PPPoE connection.  Ignor the printout of the PPPoE log.  When Astaro is trying to make a connection, nothing is sent to this log.  I think what is printed there is from when I disconnected the network cable while troubleshooting.

BillE

Ver. 7.101
Since no one is able to help me with my PPPoE problem, I've been using the NetGear router to connect to the internet and have the Astaro gateway connected to it through the DMZ.  This seems to work ok except that I'm now trying to set up a VPN and the Astaro box is seeing the LAN address of the NetGear as the external address.  I think this is why the VPN can't make a connection.  Are there any settings I can make in the Astaro box to point it at the correct external address?

Putting the router in "bridged" mode would be the best option, but that may not be possible with a PPPoE link on your router.

Barry

BillE,
swapping your NIC will not have any affect, the DG834 is not designed to do what you want. As you explained in your original post the ASG will work as a internal connection off the DG834. The ASG NIC never sees the ISP ADSL connection.

In the end I bought a modem that could be used as a router or put in bridge mode and the DG 834 ended up as a wireless point until I blew it up with the wrong power connector.

Ian M

The pppoe client in Astaro works just fine. Your is sending LCP Config Requests, and getting nothing back from the AC according to your pppoe.log snippet. Your ASG does see the AC though.

What do you have between the Astaro and your provider, as a modem?

Here is what mine looks like, in a successful pppoe handshake:

2007:12:17-20:46:25 (none) pppoe-sh: Access-Concentrator: bas3-kitchener06 Got a cookie: ba 40 ad 1c f8 21 af 7e 76 03 a4 89 35 64 77 ea AC-Ethernet-Address: 00:90:1a:a0:a2:7d --------------------------------------------------
2007:12:17-20:46:25 (none) pppd-pppoe[3592]: pppd 2.4.3 started by root, uid 0
2007:12:17-20:46:25 (none) pppd-pppoe[3592]: using channel 1
2007:12:17-20:46:25 (none) pppd-pppoe[3592]: Using interface ppp0
2007:12:17-20:46:25 (none) pppd-pppoe[3592]: Connect: ppp0  /dev/ttyp0
2007:12:17-20:46:25 (none) pppoe[3598]: PADS: Service-Name: ''
2007:12:17-20:46:25 (none) pppoe[3598]: PPP session is 4788 (0x12b4)
2007:12:17-20:46:26 (none) pppd-pppoe[3592]: sent [LCP ConfReq id=0x1     ]
2007:12:17-20:46:26 (none) pppd-pppoe[3592]: rcvd [LCP ConfReq id=0x6a   ]
2007:12:17-20:46:26 (none) pppd-pppoe[3592]: sent [LCP ConfAck id=0x6a   ]
2007:12:17-20:46:26 (none) pppd-pppoe[3592]: rcvd [LCP ConfAck id=0x1     ]
2007:12:17-20:46:26 (none) pppd-pppoe[3592]: sent [LCP EchoReq id=0x0 magic=0xff48bbca]
2007:12:17-20:46:26 (none) pppd-pppoe[3592]: sent [PAP AuthReq id=0x1 user="user@domain.com" password=]
2007:12:17-20:46:26 (none) pppd-pppoe[3592]: rcvd [LCP EchoRep id=0x0 magic=0x121e919e]
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: rcvd [LCP ConfReq id=0x1  ]
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: sent [LCP ConfReq id=0x2     ]
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: sent [LCP ConfAck id=0x1  ]
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: rcvd [LCP ConfNak id=0x2 ]
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: sent [LCP ConfReq id=0x3    ]
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: rcvd [LCP ConfAck id=0x3    ]
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: sent [LCP EchoReq id=0x0 magic=0x9cdd8d2a]
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: sent [PAP AuthReq id=0x2 user="user@domain.com" password=]
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: rcvd [LCP EchoRep id=0x0 magic=0xc9664318]
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: rcvd [PAP AuthAck id=0x2 ""]
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: PAP authentication succeeded
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: sent [CCP ConfReq id=0x1    ]
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: sent [IPCP ConfReq id=0x1    ]
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: rcvd [IPCP ConfReq id=0x1 ]
2007:12:17-20:46:27 (none) pppd-pppoe[3592]: sent [IPCP ConfAck id=0x1 ]
2007:12:17-20:46:28 (none) pppd-pppoe[3592]: rcvd [LCP ProtRej id=0x2 80 fd 01 01 00 15 12 06 00 00 00 01 1a 04 78 00 18 04 78 00 15 03 2f]
2007:12:17-20:46:28 (none) pppd-pppoe[3592]: rcvd [IPCP ConfRej id=0x1 ]
2007:12:17-20:46:28 (none) pppd-pppoe[3592]: sent [IPCP ConfReq id=0x2   ]
2007:12:17-20:46:28 (none) pppd-pppoe[3592]: rcvd [IPCP ConfNak id=0x2   ]
2007:12:17-20:46:28 (none) pppd-pppoe[3592]: sent [IPCP ConfReq id=0x3   ]
2007:12:17-20:46:28 (none) pppd-pppoe[3592]: rcvd [IPCP ConfAck id=0x3   ]
2007:12:17-20:46:28 (none) pppd-pppoe[3592]: local  IP address 1.1.1.1
2007:12:17-20:46:28 (none) pppd-pppoe[3592]: remote IP address 2.2.2.2
2007:12:17-20:46:28 (none) pppd-pppoe[3592]: primary   DNS address 3.3.3.3
2007:12:17-20:46:28 (none) pppd-pppoe[3592]: secondary DNS address 4.4.4.4
2007:12:17-20:46:28 (none) pppd-pppoe[3592]: Script /etc/ppp/ip-up started (pid 3811)
2007:12:17-20:46:30 (none) pppd-pppoe[3592]: Script /etc/ppp/ip-up finished (pid 3811), status = 0x0

You were right Ian; different NIC cards didn’t make any difference.  Last night I tried 3 different brands and they all failed to connect.  I would buy a Netgear DG834, except it wouldn’t work for me.  This is a wireless connection with the transmitter/receiver built into the modem, which means I don’t have a phone line to plug into.  

I do have a Netgear FVS124G router that allows me to turn off NAT routing, but it will only work if I got a static IP address.  This may end up being my only option.

I will contact the ISP with some of the suggestions that were made and see if it will help.  When going through my old correspondence with the ISP I found some comments that may help you diagnose the problem:

“It is seeing the concentrator - it starts the LCP process but never terminates it, the client seems to Hammer the LCP request a bunch of times then give up- I wonder if there is more PPPoE setting on that router?  Sometimes it can be setup for PPPoA or PPPoEoA - which some DSL providers
use- we are straight up PPPoE.”

It seems to me that there is a definite flaw in the Astaro PPPoE software that keeps it from working while hardware routers work just fine.

BillE

Hi BillE,
sorry, my mistake I thought you had a DG834.

What sort of wireless modem do you have? I am not sure what you mean by the static IP is that for the Netgear FVS124G or the ASG?

According to Netgear the FVS124G will auto discover you ISP's details.

If you have a look at ReD-MaN's response you can see the returned packets from the ISP. It would appear from your original posting that your ISP is very slow in responding to packet requests at initial connection time. There isn't one received packet after you received the cookie. Try a cross over cable, some modems don't auto negotiate very well.

Ian M

You can also try these command line options to pppoe.

This one sets the discovery packet timeout to 90 seconds, just in case the ISP end is a bit slow in sending back packets since we are talking about wireless here.

You can either run these commands from the system console using a keyboard, logged in as root, or through ssh, using the loginuser account, and then using "su" to switch to root.

/var/sec/chroot-pppoe/usr/sbin/pppoe -I eth0 -m 1452 -t 90

This one will perform a discovery, print the results, and then exit.

/var/sec/chroot-pppoe/usr/sbin/pppoe -I eth0 -m 1452 -d

Finally, this one will enable debugging of the pppoe client, and save the info into debug.txt in the current directory you are in.

/var/sec/chroot-pppoe/usr/sbin/pppoe -I eth0 -m 1452 -D debug.txt

Try these and let us know how the results turn out. I wonder if just increasing the discovery timeout to 90 seconds will allow a connection to occur.

Hi Ian M

I’m not sure what kind of wireless modem I have.  It is up on roof behind the antenna.  All I have inside is a power supply and a network cable from the modem.  I can get that information from the ISP.

What I meant by getting a static IP address is to have the ISP assign me a permanent IP address.  The documentation for the FVS124G states that I can select either Nat Routing or Classical Routing.  If I selected Classical Routing and set the Astaro External interface to Standard Ethernet with the assigned IP address, then the Netgear router would act as a bridge.

When we were troubleshooting I tried using cross-over cables and/or Ethernet switches between the Astaro box and the modem, but that didn’t seem to help.

As I stated earlier, when the Astaro box is trying to make the initial connection, nothing is printed to the Live PPPoE log.  Is there some switch I could turn on to give me more information in the log?

I’ll be too busy for the next couple of days to do further troubleshooting, but if someone comes up with an idea, I’ll try it when I get time.

BillE

Thanks ReD-MaN

I will try these settings the next time I get a chance.

BillE

Hi BillE,
if you can get a cheap 4 port switch and put it between your modem and the ASG.

If nothing is appearing in the PPPoE log then I would suggest that PPPoE isn't enabled. Also the logs run a little behind reality.

From the ASG console you could try experimenting with tcpdump to see what packets are hitting the interface.

Ian M

We have also had a kind of similar problem with an ASG220 and a wireless modem.  For secondary (multiple) connections off of one NIC, the Astaro and ISP would negotiate, we'd get a connection for a few seconds as long as there was traffic, then the ISP's router would drop the connection.  After a lot of analysis of the route negotiation and working with Astaro and the ISP's tech support - both of them swearing it's the "other guy", we had the ISP nail up the connection permanently - no timeouts allowed.

This has resolved the problem except when the ISP cleans up his routes every once and a while and we have to remind them to nail up our connection again.  We never have had either side admit to being the source of the problem - both of them still say their side is working exactly to spec, that they don't have this problem with anyone else, and it's the "other guy."

Maybe there is just something about wireless connections.  I'm curious now, what brand of wireless equipment do you have?

OK, It’s working now, but I’m not sure why.  I suspect the ISP did something since I had emailed him a link to this forum thread a few days ago and asked if any of your suggestions might help.  I never got a response, but if I do, I will let you know what fixed it.  

It didn’t connect right away, but it did do something that it had never done before.  Every 20 seconds it would print the following messages in the PPPoE live log:

2007:12:31-17:42:58 (none) pppoe[6442]: Interface eth1 has MTU of 1492 -- should be 1500.  You may have serious connection problems.
2007:12:31-17:43:13 (none) pppoe[6442]: Timeout waiting for PADO packets
2007:12:31-17:43:13 (none) pppoe-sh: Can not connect DSL AC - retry in 5 seconds

The ISP had told me previously that the MTU should be 1492, so this message really confused me.  After about 10 minutes of these messages repeating I tried changing the internal interface MTU to 1492 also.  I don’t know why this worked, but it connected immediately after that. 
 
I was really happy until I noticed that every few minutes the connection was going down and would come back up a few seconds later.  The live log showed “(sendPacket): Message too long” followed by “Modem hangup”.  This is really strange behavior, so I just rebooted the Astaro gateway computer in frustration.  On reboot the connection came up right away and it has been solid ever since.

Thank you all for your suggestions, and for those that wanted to know what wireless modem I have, it’s a “Canopy” from Motorola wireless.

BillE

OK, It’s working now, but I’m not sure why.  I suspect the ISP did something since I had emailed him a link to this forum thread a few days ago and asked if any of your suggestions might help.  I never got a response, but if I do, I will let you know what fixed it.  

It didn’t connect right away, but it did do something that it had never done before.  Every 20 seconds it would print the following messages in the PPPoE live log:

2007:12:31-17:42:58 (none) pppoe[6442]: Interface eth1 has MTU of 1492 -- should be 1500.  You may have serious connection problems.
2007:12:31-17:43:13 (none) pppoe[6442]: Timeout waiting for PADO packets
2007:12:31-17:43:13 (none) pppoe-sh: Can not connect DSL AC - retry in 5 seconds

The ISP had told me previously that the MTU should be 1492, so this message really confused me.  After about 10 minutes of these messages repeating I tried changing the internal interface MTU to 1492 also.  I don’t know why this worked, but it connected immediately after that. 
 
I was really happy until I noticed that every few minutes the connection was going down and would come back up a few seconds later.  The live log showed “(sendPacket): Message too long” followed by “Modem hangup”.  This is really strange behavior, so I just rebooted the Astaro gateway computer in frustration.  On reboot the connection came up right away and it has been solid ever since.

Thank you all for your suggestions, and for those that wanted to know what wireless modem I have, it’s a “Canopy” from Motorola wireless.

BillE

Given that your changes didnt' really affect it, I'd have to point at the ISP... I've also never seen a PPPOE connection (granted this has been on ADSL connections) that worked properly with a MTU other than 1492 (an MTU of 1500 often resulted in intermittent / no connection issues)... I guess your ISP went back and reviewed his settings, and fixed it... not uncommon when dealing with Telcos, etc.  I can't tell you how many times when telco / ISP issues were fixed by "pure magic"... when I was sitting at the site and nothing changed on my end, except that I finally woke someone up at the CO, and they made some "mysterious" changes.

[FONT="Courier New"]I'm back again. The connection ran perfect for four days then it just quit and I can't get it back again.  Extending the time-out to 90 seconds didn't help.  I'm back to using the Netgear router as a middle man in order to access the internet.  Here is the debug log that ReD-MaN asked for:

rp-pppoe-3.8
20:02:19.950 SENT PPPoE Discovery (8863) PADI sess-id 0 length 4
SourceAddr 00:10:5a:99:06:4a DestAddr ff:ff:ff:ff:ff:ff
01 01 00 00                                       ....

20:02:19.987 RCVD PPPoE Discovery (8863) PADI sess-id 0 length 12
SourceAddr 00:18:e7:13:a4[:D]2 DestAddr ff:ff:ff:ff:ff:ff
01 01 00 00 01 03 00 04 00 00 00 01               ............

20:02:19.999 RCVD PPPoE Discovery (8863) PADI sess-id 0 length 12
SourceAddr 00:0c:41:38[:D]9:50 DestAddr ff:ff:ff:ff:ff:ff
01 03 00 04 00 00 00 01 01 01 00 00               ............

20:02:20.009 RCVD PPPoE Discovery (8863) PADO sess-id 0 length 40
SourceAddr 00:09:b6:58:64:38 DestAddr 00:10:5a:99:06:4a
01 01 00 00 01 02 00 0c 72 74 32 2d 64 63 63 2d   ........rt2-dcc-
37 32 30 36 01 04 00 10 db 95 80 e1 be 9c 29 82   7206..........).
a2 59 b1 fa e1 27 75 0f                           .Y...'u.

20:02:20.009 SENT PPPoE Discovery (8863) PADR sess-id 0 length 24
SourceAddr 00:10:5a:99:06:4a DestAddr 00:09:b6:58:64:38
01 01 00 00 01 04 00 10 db 95 80 e1 be 9c 29 82   ..............).
a2 59 b1 fa e1 27 75 0f                           .Y...'u.

20:02:20.019 RCVD PPPoE Discovery (8863) PADI sess-id 0 length 26
SourceAddr 00:13:10:a3:82:94 DestAddr ff:ff:ff:ff:ff:ff
01 10 00 0a 01 00 00 00 00 0c 41 38 d9 50 01 03   ..........A8.P..
00 04 00 00 00 01 01 01 00 00                     ..........

20:02:20.034 RCVD PPPoE Discovery (8863) PADI sess-id 0 length 18
SourceAddr 00:13:10:a3:82:94 DestAddr ff:ff:ff:ff:ff:ff
01 10 00 0a 01 00 00 00 00 10 5a 99 06 4a 01 01   ..........Z..J..
00 00                                             ..

20:02:20.039 RCVD PPPoE Discovery (8863) PADS sess-id 54564 length 24
SourceAddr 00:09:b6:58:64:38 DestAddr 00:10:5a:99:06:4a
01 01 00 00 01 04 00 10 db 95 80 e1 be 9c 29 82   ..............).
a2 59 b1 fa e1 27 75 0f                           .Y...'u.

20:02:22.037 RCVD PPPoE Session (8864) SESS sess-id 54564 length 20
SourceAddr 00:09:b6:58:64:38 DestAddr 00:10:5a:99:06:4a
c0 21 01 02 00 12 01 04 05 d4 03 04 c0 23 05 06   .!...........#..
e2 f9 e9 cf                                       ....

20:02:24.054 RCVD PPPoE Session (8864) SESS sess-id 54564 length 20
SourceAddr 00:09:b6:58:64:38 DestAddr 00:10:5a:99:06:4a
c0 21 01 03 00 12 01 04 05 d4 03 04 c0 23 05 06   .!...........#..
e2 f9 e9 cf                                       ....

20:02:26.069 RCVD PPPoE Session (8864) SESS sess-id 54564 length 20
SourceAddr 00:09:b6:58:64:38 DestAddr 00:10:5a:99:06:4a
c0 21 01 04 00 12 01 04 05 d4 03 04 c0 23 05 06   .!...........#..
e2 f9 e9 cf                                       ....

20:02:28.084 RCVD PPPoE Session (8864) SESS sess-id 54564 length 20
SourceAddr 00:09:b6:58:64:38 DestAddr 00:10:5a:99:06:4a
c0 21 01 05 00 12 01 04 05 d4 03 04 c0 23 05 06   .!...........#..
e2 f9 e9 cf                                       ....

20:02:30.102 RCVD PPPoE Session (8864) SESS sess-id 54564 length 20
SourceAddr 00:09:b6:58:64:38 DestAddr 00:10:5a:99:06:4a
c0 21 01 06 00 12 01 04 05 d4 03 04 c0 23 05 06   .!...........#..
e2 f9 e9 cf                                       ....

20:02:32.117 RCVD PPPoE Session (8864) SESS sess-id 54564 length 20
SourceAddr 00:09:b6:58:64:38 DestAddr 00:10:5a:99:06:4a
c0 21 01 07 00 12 01 04 05 d4 03 04 c0 23 05 06   .!...........#..
e2 f9 e9 cf                                       ....

20:02:34.139 RCVD PPPoE Session (8864) SESS sess-id 54564 length 20
SourceAddr 00:09:b6:58:64:38 DestAddr 00:10:5a:99:06:4a
c0 21 01 08 00 12 01 04 05 d4 03 04 c0 23 05 06   .!...........#..
e2 f9 e9 cf                                       ....

20:02:36.149 RCVD PPPoE Session (8864) SESS sess-id 54564 length 20
SourceAddr 00:09:b6:58:64:38 DestAddr 00:10:5a:99:06:4a
c0 21 01 09 00 12 01 04 05 d4 03 04 c0 23 05 06   .!...........#..
e2 f9 e9 cf                                       ....

20:02:38.167 RCVD PPPoE Session (8864) SESS sess-id 54564 length 20
SourceAddr 00:09:b6:58:64:38 DestAddr 00:10:5a:99:06:4a
c0 21 01 0a 00 12 01 04 05 d4 03 04 c0 23 05 06   .!...........#..
e2 f9 e9 cf                                       ....

20:02:40.214 RCVD PPPoE Session (8864) SESS sess-id 54564 length 6
SourceAddr 00:09:b6:58:64:38 DestAddr 00:10:5a:99:06:4a
c0 21 05 0a 00 04                                 .!....

20:02:40.217 RCVD PPPoE Discovery (8863) PADT sess-id 54564 length 0
SourceAddr 00:09:b6:58:64:38 DestAddr 00:10:5a:99:06:4a

20:02:40.217 SENT PPPoE Discovery (8863) PADT sess-id 54564 length 47
SourceAddr 00:10:5a:99:06:4a DestAddr 00:09:b6:58:64:38
02 03 00 17 52 65 63 65 69 76 65 64 20 50 41 44   ....Received PAD
54 20 66 72 6f 6d 20 70 65 65 72 01 04 00 10 db   T from peer.....
95 80 e1 be 9c 29 82 a2 59 b1 fa e1 27 75 0f      .....)..Y...'u.

While running the diagnostic, this is what printed in the live PPPoE log:

2008:01:04-20:01:27 (none) pppoe[5807]: PADS: Service-Name: '' 
2008:01:04-20:01:27 (none) pppoe[5807]: PPP session is 54385 (0xd471) 
2008:01:04-20:02:20 (none) pppoe[5877]: PADS: Service-Name: '' 
2008:01:04-20:02:20 (none) pppoe[5877]: PPP session is 54564 (0xd524) 
2008:01:04-20:02:40 (none) pppoe[5877]: Session 54564 terminated -- received PADT from peer 
2008:01:04-20:02:40 (none) pppoe[5877]: Sent PADT 

I'm going to contact my ISP, but it would help if I could tell him what to fix.

BillE
[/FONT]

I got a reply from my ISP about this problem:

I haven't changed anything in the network (or even rebooted anything) in that timeframe.  I'm not sure what else to look at on this at this point. I'm willing to try any suggestions you or the forum has but It really seems like an Astaro software issue to me- but I could be wrong.

Now I'm really confused.  Why did it start working and then stop again?  I googled "PADT" and found out that DLink had this problem but it was solved with a firmware update.  So maybe it is an Astaro problem.

BillE

Well the thing is, Astaro is just using standard RP-PPPOE package. So if it was a problem with Astaro, it would be a problem with many, many other users as well.

http://www.roaringpenguin.com/products/pppoe

Maybe you can try posting something in their forum as well?

Looks like a similar problem exists for Fedora Core users... 

http://www.voy.com/41165/4201.html

It looks to be a problem with the version of pppd used...

Maybe your provider can do some debugging on his end while your system attempts to connect? He should see entries on his end about what is going on as well.

Astaro, can you guys provide input??? Looks like this has affected Fedora and Debian users when using RP-PPPOE 3.8 with pppd higher than 2.4.2.