Modify

Opened 5 years ago

Last modified 2 years ago

#12277 new defect

pppd demand does not work

Reported by: anonymous Owned by: developers
Priority: normal Milestone: Bugs Paradise
Component: packages Version: Trunk
Keywords: Cc:

Description

There is no way to initiate a ppp-connection from outside of the router when dial on demand is enabled. The ppp-device (here 3g-wan) is up but there is no default route. Currently I manually up the device (after idle-timeout, see below) and either set the route manually or send one ping directly to the device, the further automated setup works either way.
After the connection idles out, the ppp device is set down, so have to restart it manually as mentioned before.

I am using Attitude Adjustment r33628, it worked before. I have no idea when but after 10.03.1 stable, I think it didn't use netifd.

Attachments (0)

Change History (11)

comment:1 Changed 5 years ago by jow

  • Milestone changed from Attitude Adjustment (trunk) to Bugs Paradise

comment:2 Changed 5 years ago by andreas@…

Hmm, I just noticed that "defaultroute" was not set as a pppd parameter (in fact, nodefaultroute was set). "Use default gateway" is enabled in luci but it seems to have no effect on the configuration. Adding option defaultroute '1' in /etc/config/network works.

comment:3 Changed 5 years ago by andreas@…

I was too quick with that answer. It doesn't work once the connection idles out, the device gets still set down, so the route is lost as well.

comment:4 Changed 5 years ago by anonymous

I can confirm that in current trunk r34122 the problem persist. There is no default route as soon as PPPoE interface is down.
There is default IP on this interface: 10.64.64.64. When I adding new default route to this default IP=10.64.64.64 as the gateway, after first outgoing packet the PPPoE is momentary waking-up and operates until inactivity timeout.
When connection is timed-out by inactivity, PPPoE is going down and default route become deleted at all. This is strange because one default route to 10.64.64.64 still persist in static routes in the configuration.
I suppose that something deletes more than it should at disconnecting the PPPoE. Only automatically-created default route which created on PPPoE start should be deleted. Nor any default route in system running configuration.
-=-
As an employee of ISP, I can't recommend OpenWRT to the clients without DoD working flawlessly.

Thank You for paying attention,
Nikolay_Po

OpenWrt Barrier Breaker r34122 @ TP-Link TL-WA901N/ND v2

comment:5 Changed 5 years ago by anonymous

It's still a problem in "OpenWrt r35193 / LuCI Trunk (trunk+svn9622)". However, using the "nopersist", "defaultroute" on pppd and a custom forward-accept-rule (interface is set "down" after connection times out by netifd) makes the demand-option usable.

The normal way, netifd would neither set a default route to the ppp-if in the first place nor set it "up" again after putting it "down" when the connection idles out.

comment:6 Changed 4 years ago by TobsTec

Can you elaborate a bit on that "custom forward-accept-rule"?
I am a bit... ehm... firewall-challenged and don't want to add a gaping security hole when i mess it up. :)

Thanks you!

comment:7 Changed 4 years ago by anonymous

Barrier Breaker 3.10.44 svn-r1045 @ tl-wrb841n
Connect on demand is not working. Same problem. Have to use it for ISP.
Is there any way to solve it?

comment:9 Changed 3 years ago by anonymous

I had the same problem in Barrier Bratker 14.07. I solved the problem by changing 2 files:

  1. /etc/config/network, disable IPv6 because my ISP doesn't support IPv6
config interface 'wan'
        option ipv6 0
  1. /lib/netifd/proto/ppp.sh: change nodefaultroute to defaultroute in the function of ppp_generic_setup()
	proto_run_command "$config" /usr/sbin/pppd \
		nodetach ipparam "$config" \
		ifname "$pppname" \
		${keepalive:+lcp-echo-interval $interval lcp-echo-failure ${keepalive%%[, ]*}} \
		${ipv6:++ipv6} \
		defaultroute \

comment:10 follow-up: Changed 2 years ago by anonymous

CHAOS CALMER (15.05, r46767) ,tl-wr841n v5
Setting the Inactivity timeout to something not 0 in luci,the pppoe-wan can't work.
Setting the Inactivity timeout to 0,the pppoe-wan works fine.

comment:11 in reply to: ↑ 10 Changed 2 years ago by anonymous

Same here:
OpenWrt Chaos Calmer 15.05 (r46450) with LuCI (git-15.248.30277-3836b45) on TP-Link TL-WDR4900 v1:
Setting the Inactivity timeout to something not 0 in luci,the pppoe-wan can't work.
Setting the Inactivity timeout to 0,the pppoe-wan works fine.

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.