PPPoE WAN bug?

[Eric]

It looks like the retry mechanism is part of the daemon (C) code.

You'll find the pppd source code in the [target]-src/build_dir/[arch]/ppp-2.4.3/pppd directory. The "System time change detected" print statement can be found in main.c in that directory.

The init scripts are in /lib/network/ (ppp.sh and pppoe.sh), but I'm pretty sure the retry is occurring within the compiled daemon.

[pbix]

I have a proposed fix for this issue. Anyone who read this far down into this thread might be motivated to try it. The fix requires a change to the pppd executable. If you have a brcm-2.4 platform then you need only to replace your copy of /usr/sbin/pppd with the executable in the attached archive. Make sure to chmod +x /use/sbin/pppd to make it executable after replacing it.

If you have this problem on a different platform then you will have to create your own binary by building Gargoyle after replacing "main.c" in your pppd directory with the one in the attached archive.

Once the fix is confirmed to work a decision will be made on how to get it in a future release of Gargoyle.

I would appreciate your feedback in this thread.

If the above is beyond your capabilities then you will have to wait for the formal Gargoyle release that includes this fix.

Enjoy,
pbix

[Jase]

Once the fix is confirmed to work a decision will be made on how to get it in a future release of Gargoyle.

I would appreciate your feedback in this thread.

Hi,

Good news, i tried the fix on my WRT-54GL and it works perfectly, the PPPoE connection comes up straight away after a reboot

[NL2009]

Hi Pbix

Many thanks - this now works for me as well!

My only concern is that the router initially "played dead" after the first reboot after transferring the updated pppd file. I did execute the chmod +x command on the pppd file before rebooting.

I could not get web access or ssh into the router for quite a few minutes after this. The PPPoE link only appeared to recover automatically after about the 3rd reboot, but now it works every time.

Many thanks for your work on this project!

[Eric]

Thanks for everyones help testing this, and especially to pbix for working on this patch.

I've been discussing this solution with pbix via email, and I will be releasing a patched version within a week. Pbix and I have been considering a slightly more elegant solution than the one implemented in the patch above, but one which addresses the same issue. It therefore may be a few more days before a corrected version gets uploaded, but it should be soon.

[Eric]

I would be very grateful if some of you could help test another version of this patch.

A tar.gz file containing the new pppd daemon for brcm devices can be downloaded here.

A full brcm firmware trx file (based on 1.1.7) with the patch can be downloaded here.

[hotzenpl0tz]

Ok, I just installed the firmware and tested it. Now, what seems to work is that after a reboot, the pppd daemon connects again - but what I did notice is that it takes a very long time until my connected PC's get an outside connection to the itnernet again.

Here is the output of logread after the boot process:
http://pastebin.com/2bLeJu6e

After reboot it takes about a minute (maybe a bit less) until I can ssh into the box again. As soo as that happens, I can type ping http://www.heise.de from the router and get a response from the webpage, internet seems to be up at this stage. But until the firewall is loaded and everything is setup, I would estimate it takes at least another minute, it might even be more until everything is setup and my connected PC's get internet access again, I am not sure if that is supposed to happen.

Also note the last few lines in the log, not sure if those errors are supposed to happen. All this with a freshly installed firmware without having restored any configuration, since my last gargoyle version was more than a year old Everything is setup manually, there are qos rules etc. setup.

[Maniac]

Thanks for the work on this guys, I'll see if I can test it over the weekend.

[geekgirl]

In the next few days I'm going to make a release where I bump the version to the latest OpenWrt.

Has anyone tried the latest OpenWrt (8.09.2) and found whether this is working? Maybe this has been fixed upstream...

I had the same problem on 8.09.2 (r18961)

I believe the *ideal* (and least invasive) fix is r17527:
https://dev.openwrt.org/changeset/17527

You can see last two comments (luca, and me) on how this fixed the issue. Why it wasn't incorporated in 8.09.2 before it was released, despite being a previous revision? I honestly don't know.

Will post in another thread about my fun with gargoyle, on AR7

Cheers

[pbix]

geekgirl,
I did try the lastest revision of OpenWRT and found that I did not have the problem in question here. This problem as it turns out was related to the way Gargoyle does date/time changes at boot. This in turn is related to the quota functionality it has.

Finally the Gargole problem was related to the patch “compensate_time_change” which someone put on pppd in OpenWRT. The patch caused this problem by its rather poor design.

The issue you raise I do not know much about. I saw this changeset when researching this problem but must admit I do not know the history of it or if it is still a problem or not. It does not look like this changeset exists in the latest release of OpenWRT. But I suppose it is possible that it was solved in another way. I can say that pppd was being brought up correctly, it was just hanging in a code loop it could not get out of.

BTW, do you know how pppd is started in OpenWRT? This is somewhat of a mystery to me. Somehow pppd is started before any scripts in /etc/init.d are executed.