www.zeroshell.org Forum Index www.zeroshell.org
Linux Distribution for server and embedded devices
 
 SearchSearch  RegisterRegister  UsergroupsUsergroups 
 ProfileProfile  Log inLog in  Log in to check your private messagesPrivate Message 

PPPOE

 
Post new topic   Reply to topic    www.zeroshell.org Forum Index -> Signal a BUG
View previous topic :: View next topic  
Author Message
mdemel



Joined: 07 Jun 2011
Posts: 2

PostPosted: Wed Jan 16, 2013 12:25 am    Post subject: PPPOE Reply with quote

First off thanks to Fulvio for this project.

I will try to explain the best I can on what is happening. For a while now I have been having trouble with PPPOE and the Failover\Netbalancer.

Current setup is:
Zeroshell Release 2.0.RC2
P4 box with 3 nics

ISP1 - Wireless to Ethernet always on (ETH01)
ISP2 - DSL modem attached to ETH02 with PPPoE (PPP0)
1 - LAN (ETH00)

NAT is enabled for both ISP interfaces.
Default route is set to PPP0
Netbalancer is configured with ETH01 and PPP0 as the gateways.
Failover Monitor is set with default timeout and Immediately restart PPPoE enabled
Failover IP Addresses are populated with valid external addess.

Everything works perfectly until ZS detects a fault on the PPP0. The link goes down as expected but will never come back up.
I have witnessed the PPP0 redial\reconnect in the "Network" tab, with an IP address from the peer so I believe that ZS is trying to reconnect but the Failover\Netbalancer is not re-enabling the gateway when the modem is redialed. I can also verify when this event occurs that the PPP0 gateway can not ping the ips in the "Failover IP Addresses" when I click the "TEST" button (see the Code section). This interface will stay like that, however I can click "save" under the "NET BALANCER" tab and the link will come back to life. In the code section at the time stamps 04:47:23 and 17:01:19 is where I clicked "save".

So in short ZS is redailing the modem and receives an IP address but the Net Balancer\ Failover is not seeing the connection so that it can ping the ips in the failover list to bring the interface back up.

I have tried many different settings and even wiped the system and started over and have the same issue. I have read the documentation and the forum and if I'm missing something, for the life of me I can not find what I have done wrong.
I'm willing to try a statrup\cron job or change some settings that you can suggest.


Code:
04:41:04    [ICMP] Failover monitor has started
04:44:24    (TEST) ==============================================================
04:44:24    (TEST) GATEWAY : DEFAULT GATEWAY (ppp0)
04:44:25    (TEST) => [8.8.8.8] : Success (Round Trip Time: 339 ms)
04:44:25    (TEST) => [4.2.2.2] : Success (Round Trip Time: 362 ms)
04:44:25    [ICMP] Failover monitor has started
04:44:25    (TEST) => [74.125.227.110] : Success (Round Trip Time: 267 ms)
04:44:25    (TEST) GATEWAY : ERF (ETH01)
04:44:26    (TEST) => [8.8.8.8] : Success (Round Trip Time: 68.4 ms)
04:44:26    (TEST) => [4.2.2.2] : Success (Round Trip Time: 26.9 ms)
04:44:26    (TEST) => [74.125.227.110] : Success (Round Trip Time: 23.8 ms)
04:44:26    (TEST) ==============================================================
04:44:27    [ICMP] Failover monitor has started
04:45:54    Default Route has been changed: nexthop dev ETH01 weight 1 realm 102
04:46:58    [ICMP] No link detected with the gateway (DEFAULT GATEWAY)
04:46:58    [ICMP] FAULT: DEFAULT GATEWAY (Interface: ppp0) [Last Uptime: 6m 22s]
04:47:23    [ICMP] Failover monitor has started
04:47:23    [ICMP] RECOVERED: DEFAULT GATEWAY (Interface: ppp0) [Last Downtime: 25s]
04:47:24    Default Route has been changed: nexthop dev ppp0 weight 1 realm 100 nexthop dev ETH01 weight 1 realm 102
06:25:11    [ICMP] No link detected with the gateway (DEFAULT GATEWAY)
06:25:11    [ICMP] FAULT: DEFAULT GATEWAY (Interface: ppp0) [Last Uptime: 1h 37m 48s]
06:25:11    Default Route has been changed: nexthop dev ETH01 weight 1 realm 102
16:54:36    (TEST) ==============================================================
16:54:36    (TEST) GATEWAY : DEFAULT GATEWAY (ppp0)
16:54:36    (TEST) => [8.8.8.8] : ERROR
16:54:36    (TEST) => [4.2.2.2] : ERROR
16:54:36    (TEST) => [74.125.227.110] : ERROR
16:54:36    (TEST) GATEWAY : ERF (ETH01)
16:54:37    (TEST) => [8.8.8.8] : Success (Round Trip Time: 117 ms)
16:54:37    (TEST) => [4.2.2.2] : Success (Round Trip Time: 216 ms)
16:54:37    (TEST) => [74.125.227.110] : Success (Round Trip Time: 51.2 ms)
16:54:37    (TEST) ==============================================================
16:54:37    [ICMP] Failover monitor has started
17:00:05    (TEST) ==============================================================
17:00:05    (TEST) GATEWAY : DEFAULT GATEWAY (ppp0)
17:00:05    (TEST) => [8.8.8.8] : ERROR
17:00:05    (TEST) => [4.2.2.2] : ERROR
17:00:05    (TEST) => [74.125.227.110] : ERROR
17:00:05    (TEST) GATEWAY : ERF (ETH01)
17:00:06    (TEST) => [8.8.8.8] : Success (Round Trip Time: 124 ms)
17:00:06    (TEST) => [4.2.2.2] : Success (Round Trip Time: 99.8 ms)
17:00:06    (TEST) => [74.125.227.110] : Success (Round Trip Time: 51.9 ms)
17:00:06    (TEST) ==============================================================
17:00:06    [ICMP] Failover monitor has started
17:00:52    (TEST) ==============================================================
17:00:52    (TEST) GATEWAY : DEFAULT GATEWAY (ppp0)
17:00:56    (TEST) => [8.8.8.8] : ERROR
17:01:00    (TEST) => [4.2.2.2] : ERROR
17:01:04    (TEST) => [74.125.227.110] : ERROR
17:01:04    (TEST) GATEWAY : ERF (ETH01)
17:01:04    (TEST) => [8.8.8.8] : Success (Round Trip Time: 50.4 ms)
17:01:04    (TEST) => [4.2.2.2] : Success (Round Trip Time: 38.9 ms)
17:01:04    (TEST) => [74.125.227.110] : Success (Round Trip Time: 34.0 ms)
17:01:04    (TEST) ==============================================================
17:01:04    [ICMP] Failover monitor has started
17:01:19    [ICMP] Failover monitor has started
17:01:20    [ICMP] RECOVERED: DEFAULT GATEWAY (Interface: ppp0) [Last Downtime: 10h 36m 8s]
17:01:20    Default Route has been changed: nexthop dev ppp0 weight 1 realm 100 nexthop dev ETH01 weight 1 realm 102
17:01:26    (TEST) ==============================================================
17:01:26    (TEST) GATEWAY : DEFAULT GATEWAY (ppp0)
17:01:26    (TEST) => [8.8.8.8] : Success (Round Trip Time: 92.6 ms)
17:01:26    (TEST) => [4.2.2.2] : Success (Round Trip Time: 80.8 ms)
17:01:26    (TEST) => [74.125.227.110] : Success (Round Trip Time: 83.7 ms)
17:01:27    (TEST) GATEWAY : ERF (ETH01)
17:01:27    (TEST) => [8.8.8.8] : Success (Round Trip Time: 41.6 ms)
17:01:27    (TEST) => [4.2.2.2] : Success (Round Trip Time: 49.9 ms)
17:01:27    (TEST) => [74.125.227.110] : Success (Round Trip Time: 47.6 ms)
17:01:27    (TEST) ==============================================================
17:01:27    [ICMP] Failover monitor has started
Back to top
View user's profile Send private message
zgypa



Joined: 12 Jul 2011
Posts: 21

PostPosted: Mon Dec 30, 2013 3:23 pm    Post subject: netbalancer not enabling route after link comes back up Reply with quote

mdemel,

i have the same exact situation, and i've had it ever since ZS 1 beta 15 or so: i've had it with a satellite modem, and three different kinds of DSL modems. I've had it with new and old profiles: link goes down and comes back up, however NetBalancer doesn't realizes it's back up until i manually de-activate it and re-activate it, which defeats the entire purpose of having the FailOver feature in the first place. I'm still using NetBalancer for IP address based routing.

Did you figure something out?
Back to top
View user's profile Send private message
gastone



Joined: 17 Dec 2014
Posts: 3

PostPosted: Wed Dec 17, 2014 12:48 pm    Post subject: [SOLVED] netbalancer not enabling route after link comes bac Reply with quote

Hello,

I'm an user of the Italian forum and I spend lot of times trying to solve this issue.

Finally I discovered that with ZS 3.2.1 the problem is solved, but it's necessary to use the most recent kernel 3.4.90-ZS

Infact with the "standard" kernel 3.14.21-ZS (delivered with ZS 3.2.1) this issue was still there.

By default the ZS image contain kernel version 3.14.21-ZS, as far as I know it's necessary an active subscription to upgrade ZS 3.2.1 with Kernel version 3.4.90-ZS.

Hope it helps
Back to top
View user's profile Send private message
zgypa



Joined: 12 Jul 2011
Posts: 21

PostPosted: Fri Mar 13, 2015 8:43 am    Post subject: Reply with quote

gastone,

how about the 3.14.31-ZS stock kernel from 3.3.2? I haven't tested it yet. The older 3.4.90 kernel is no longer available.
Back to top
View user's profile Send private message
fulvio
Site Admin


Joined: 01 Nov 2006
Posts: 1077

PostPosted: Wed Mar 18, 2015 3:39 am    Post subject: Reply with quote

Hi,
for the release 3.3.2 it is available a fix into repository.
Regards
Fulvio
Back to top
View user's profile Send private message Send e-mail
gastone



Joined: 17 Dec 2014
Posts: 3

PostPosted: Wed Mar 25, 2015 1:20 pm    Post subject: Fix works only if ICMP failover checking is enabled Reply with quote

Hello Fulvio,

thank you for your fix #23320.

Your correction works well if ICMP failover checking is enabled, but it seems to have the same identical behaviour (PPPoE back available but stay "down" forever in NetBalancer) if ICMP failover checking is disabled.

I remember in older version the ICMP failover checking was not mandatory... Can you please make a double check?

Thank you very much for the time you dedicate to this excellent job. Razz
Back to top
View user's profile Send private message
WaltonQuake



Joined: 30 Sep 2016
Posts: 1

PostPosted: Sat Oct 01, 2016 7:33 am    Post subject: Re: Fix works only if ICMP failover checking is enabled Reply with quote

gastone wrote:
Hello Fulvio,

thank you for your fix #23320.

Your correction works well if ICMP failover checking is enabled, but it seems to have the same identical behaviour (PPPoE back available but stay "down" forever in NetBalancer) if ICMP failover checkout the pics of venapro which is disabled.

I remember in older version the ICMP failover checking was not mandatory... Can you please make a double check?

Thank you very much for the time you dedicate to this excellent job. Razz


Hey Gastone, I just noticed the same thing when I tried it. I take it there was no fix?
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    www.zeroshell.org Forum Index -> Signal a BUG All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group