Age | Commit message (Collapse) | Author |
|
convert all call to jinja to use template.render
|
|
|
|
As PPP can be used to establish a connection on-demand it manages the Kernel
default route. This can not be used when using VRFs which are managed by
the ip-up.d and ip-down.d scripts - thus those options are now mutially
exclusive.
The best fix would be adding support for VRFs into PPP.
|
|
|
|
... to make it clear also directories can be chown(-ed)
|
|
|
|
Now both files and directories are supported.
|
|
Commit b250b233ec1 ("pppoe: T1318: move Jinja2 templates to data/templates
folder") actually placed the pre-up configuration script into the ip-up
folder.
|
|
As PPPoE interfaces should be part of a VRF it is required that the default
can also be set into the specified VRF. The default way of PPP by setting the
"defaultroute" option does not take a VRF into account. In this case PPP
installs a Kernel route forwarding all default traffic over this interface.
This change installs a static route with metric 1 instead into the routing
table via FRR. This is not the same as a Kernel route in terms of metric 1
compared to 0 but it should do the trick.
|
|
This makes the actual code which generates the configs much more human
readable.
|
|
|
|
|
|
Commit 6a0c6783d8b2 ("pppoe: migrate alias and vrf script from pre-up to up")
changed the name of the ip-up script template but the template definition has
been forgotten.
This caused:
NameError: name 'config_pppoe_ip_up_tmpl' is not defined
|
|
As the pre-up script is only run once when the interface is brought up but
not when the interface maybe only comes up 20 seconds later due to the remote
site some actions can not be performed as placing the interface e.g. into a VRF
instance.
|
|
Commit d2cf287 ("vyos.util: add chown_file and chmod_x_file helpers") added
common helper functions to chown or chmod +x a file. Make use of those
helpers.
|
|
|
|
|
|
The creation of this directory has been done in the past using vyatta-
wirelessmodem and after it's replacement in vyos-1x the directory has not been
deployed anymore. Thos when rendering the PPPoE configuration the directory will
be created on deemand.
|
|
|
|
|
|
|
|
|
|
|
|
Commit d161cbb ("pppoe: T1493: fix invalid reference of ipv6-up script file")
actually introduced another bug instead of fixing it. It was catched by
vyos-smoketest ... luckily!
Sorry!
|
|
|
|
|
|
|
|
os.environ['VYOS_TAGNODE_VALUE']
This has been only a theoretical problem but then the error condition was
triggered - only an error has been printed instead of raising an Exception.
|
|
|
|
|
|
* 'pppoe-t2070' of github.com:c-po/vyos-1x:
pppoe: T2070: rewrite (dis-)connect op-mode commands in XML and Python
gitignore: fix ignore pattern of all debhelper files
pppoe: T2055: make logfile owned by root/vyattacfg
pppoe: T1318: validate existing source-interface
|
|
|
|
It is not only sufficient to check if there is a source-interface configured,
but rather it must also be checked if the source-interface exists at all in the
system.
If the interface does not exist pppd will complain with:
pppd[2778]: /usr/sbin/pppd: In file /etc/ppp/peers/pppoe1: unrecognized option 'eth0.202'
|
|
|
|
|
|
|
|
Instead of letting the user choose between auto and none where auto is default,
it makes more sesne to just offer an option to disable the default behavior.
|
|
|
|
|
|
|
|
|
|
The generated script was not called at all. Verified in vyOS 1.2.3 and rolling.
Looks like a leftover from the past. If this functionality is required - it
should be re-implemented the proper way!
|
|
This reduces the amount of self written code to start-stop-daemon and also kill
the process if it has no connection yet (there won't be a PID file in this case)
and getting the proper PID for multiple processes would require me to walk the
/proc/<pid>/cmdline for every binary involved.
|
|
We no longer need to see the command which is used to spawn up PPPd and dial
the connection.
|
|
|
|
|
|
vyos@vyos# show interfaces pppoe
pppoe pppoe0 {
default-route force
link eth2.7
mtu 400
name-server auto
password 12345678
user-id vyos@vyos.io
}
|