Uh, yeah, that sucks. I'm implementing the kernel variables for wireguard at the moment and have a look into the other interfaces after that.

@runar I should have something ready tomorrow or at the weekend at the latest you could test for IPv4. I basically started implementing the 'set interfaces <intf> ip' options including the kernel vars which you can set on other interfaces since wireguard is using that interface and looks like a normal network interface to the kernel.

Ahh, I think I found it. Usually sysctl sets it to 1, or at least it must have that done in 1.1. I think the command should be called then enable-arp-filter to correct it.

Unless I misunderstood you, int(0) does disable (no source validation) rp_filter.

After playing around with it, I think I create an extra script just for that task, it'll be easier to maintain until that parts are moved out to 'set protocol'.

Oh I see, so it would be then in /opt/vyatta/share/vyatta-cfg/templates/interfaces/wireguard/node.tag/ip/ospf/cost/node.def.
What do you mean with moving it into the protocol subtree?
I also would then handle it within the wireguard code, like I did for the firewall stuff.
(https://github.com/vyos/vyos-1x/commit/51f61991092a163f680e4ec8f122e73f4074ddf9)
Let me know what you think, would be just an extra node and leavenode to handle.

Hi @Barrysdca , can you please test if the issue persists with https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201812120337-amd64.iso
I tested it on the image and it appears that I can't reproduce it anymore.

@runar How do you set it on other interfaces?

the new syntax is being applied to the config file.

I've tested it successfully multiple times and pushed the fix upstream, the configured MTU is now being requested with the first PADI.

Thanks for testing and confirming. @trystan

All right, thanks bunch. I think I found the issue but before I expose it into the image, I'd like to test with you the functionality.

@trystan next rolling image will have the functionality, if you'd like to manual install it, you can do so by installing http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-8_all.deb.
Thanks for your request and please let me know your results.

can you please test with the latest rolling if it fixes your issue?
https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201812110337-amd64.iso

pending ci integration

I've tested that I can utilize the existing firewall functions/scripts which work, so I need to write a wrapper for it, but that will solve the issue. Shouldn't take too long.

can you please do the following and post the result:

All right. First of all MTU != MRU. (MTU - 8 byte IP header = MRU). I used your config example and I see a difference. The conf request has to come from your side, that happens durig the discovery pahase (PADI). I see that it is not being sent before you reconnect.

I don't think That I use netplugd for now. I have just a check in the script how an address had been setup on the system, if it's been dhcp then I send a release (suspend doesn't do that) and a new dhcp request. I have to chat with @c-po about T894 first.
If netplugd is being introduced to the OS, I can simply remove an else clause.

I will add the dhcp functionality too. The problem is that the network config is very different from the approach within the OS and additional software is written the way to work with whatever has the OS, it doesn't know about vyos and it's cli etc.
Thanks for testing, I will integrate the dhcp functionality asap and see that I can quickly get it into the rolling branch.

Bug confirmed, I can reproduce it. I can't tell you how long it takes to fix it, it's all old code base.

Hey @yun, could you test it under vmware, I just used the scripts to trigger resume and suspend.

Could you please do it via: 'show config command'. thx.

Ok, so I think I know how to attack that. either we use the tools then from debian directly and add an extra package with the user scripts, ot we do it directly in the tools package which is forked anyway. I would personally lean torwards option 2, since debian would take care of patching.

@Barrysdca Can you please share your config? At least the tunnel parts.

you can test it in the rolling release of Dec 7th. or manually install http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-cfg-vpn/vyatta-cfg-vpn_0.12.105+vyos2+current4_all.deb. Please let me know if it works like expected.

So, I can reproduce the missing initrd issue now as well, but I have no idea why it happens. It doesn't happen in ci, so I assume some local pacakge or command is missing. I did chroot into the chroot before squashfs is being packed and did a live-update-initramfs, which worked with no issues. So a missing driver can be ruled out here.
but I get then an issued that the arch isn't supported :D.

That looks liek a similar f'up. The correct ddclient version is 3.8.2+vyos2+current1, no idea where lithium6 comes from. The correct pkg is within the repo: http://dev.packages.vyos.net/repositories/current/vyos/pool/main/d/ddclient/ddclient_3.8.2+vyos2+current1_all.deb and the current vyatta-cfg-system has no dependency to vyatta-dhcp3-client (https://github.com/vyos/vyatta-cfg-system/blob/current/debian/control).

I see, I have a look.

Can you record the PADI requests when the router reboots? It's plain text anyway, important question is if it sends "PPP-Max-Payload 1500", which it does in all my tests. I was only able to reproduce your issue when the sends a max mtu 1492 or even lower, then the client (depending on mru) negotiates the highest possible mtu and sets it on the pppoe interface. But it's also possible that my tests are different from what you see. I used accel-ppp to use as pppoe server.

@kroy please make sure that you do it from a clean build tree. I run it now locally from home and everything is working well. You can also do a ./configure --debug && make iso, which is more verbose.

@kroy or @runar
Can please one of you test if the build outside ci is working again too? Shouldn't make any difference, but before I close this bug I'd like to have confirmation (and happy faces) from one of you as well.

I rebuilt the package (vyatta-cfg-quagga) which removed the old one from the repo and re-published the correct version. I tested with apt that the correct packages is being queried/installed. Looks all good now from my point of view.

http://dev.packages.vyos.net/repositories/current/vyos/dists/unstable/main/binary-amd64/Packages contains the wrong package.
faulty one: http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-cfg-quagga/vyatta-cfg-quagga_0.18.172_amd64.deb

@runar How do you set it on other interfaces?

@SteveP Can you please test if the pppoe server supports a mtu of 1500? In my tests an mtu of 1500 is requested by the client, I just send from the server back 1492 which is then used on the interface.

<<<<<<< HEAD

#define RCSID "$Id: tty.c,v 1.25 2006/06/04 07:04:57 paulus Exp $"

#define RCSID "$Id: tty.c,v 1.27 2008/07/01 12:27:56 paulus Exp $"

ppp-2.4.7

It's actually a ppp bug, it simply ignores mtu when setup in the peers config. I'm about to update pppd, since a new version from backports is working however it creates instead of pppoe interfaces a ppp interface, which may break something else.
Maybe its now the time to rewrite the pppoe client from scratch.

Bug confirmed, but not easy to fix.

The vmware tools scripts work as expected, they are stopping and starting the network config as they are supposed to do, but are using debian defaults. So they are not executing the config. I'm going to check of we can extend it a little somewhere to execute the config again when 'resume' happens. In general that won't be an easy fix.

Implementation doesn't take long, testing it will take a little.

Had been resolved already via https://phabricator.vyos.net/T1054 and is available via latest rolling release.

https://github.com/vyos/vyos-1x/commit/a29898b2ea15b7d9cea7fade1b27d38967c52d52, will be available with the next latest rolling or via: http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-7_all.deb

Yes it will be implemented as soon as it turns out that the switch from the old implementation was successful. We have seen kernel crashes every now and then with the shaper enabled, so I would be keen to know if that happens to you as well to investigate the root cause.

That is already the case if you don't configure a SN on the server side. So I'm not sure if this setting is not more of a pain instead of a help.

left|rightprotoport has been removed from strongswan since version 5.1. %.6 is running on the latest rolling. Protocols can now be defined via left|rightsubnet (leftsubnet=fec1::1[udp/%any],10.0.0.0/16[%any/53]) .

Ooops X-fire. I grab the IP and prefix from the interface, that way I know it exists and can be removed and won't have to many test cycles. The subsystem needs to be rewritten at one point, but as you can imagine that is quite a task. DHCPv6 won't be affected since it uses always IP/prefix, but I haven't tested it yet.

Actually it returns the IP allocated via DHCP, however the ip-normalize script needs a prefix for the regex, which is not set when dhcp was set.

Hi @andersonpcazm,
I'd suggest to open a ticket with mikrotik in that case (https://mikrotik.com/support).
The source code fro accel in the version we use in the OS can be found here: https://github.com/vyos/vyos-accel-ppp.
Feel free to contact me any time if you or mikrotek support need further details, but so far, as you found out as well, your client side (the mikrotek device) has a faulty pppoe implementation or is just misconfigured.

can you please let me know from where you have that flag? It dosn't exist in the accel-ppp documentation.

It's triggered by systemd, so it will happen before the config is fully loaded. It might be better to move that into the cli config and execute with prio 999, that way it will be definitely the last script running.

fixed and available in the next rolling release or via http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-webproxy/vyatta-webproxy_0.2.110+vyos2+current2_all.deb.

Your ISP uses mac filters then as part of AAA. No ideas why mac addresses would change, they are directly read from the NIC, the config just overwrites it then.

Nov 28 20:09:18 rc9 accel-pppoe: eth1: recv [PPPoE PADI 08:00:27:fa:3e:50 => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 390c0000>]
Nov 28 20:09:18 rc9 accel-pppoe: eth1: send [PPPoE PADO 08:00:27:c8:4a:32 => 08:00:27:fa:3e:50 sid=0000 <AC-Name vyos-ac> <Service-Name > <AC-Cookie ca898c164463d5ae46b694ff9e09c27d61efcc897802c91b> <Host-Uniq 390c0000>]
Nov 28 20:09:18 rc9 accel-pppoe: eth1: recv [PPPoE PADR 08:00:27:fa:3e:50 => 08:00:27:c8:4a:32 sid=0000 <Service-Name > <Host-Uniq 390c0000> <AC-Cookie ca898c164463d5ae46b694ff9e09c27d61efcc897802c91b>]
Nov 28 20:09:18 rc9 accel-pppoe: eth1: send [PPPoE PADS 08:00:27:c8:4a:32 => 08:00:27:fa:3e:50 sid=0001 <AC-Name vyos-ac> <Service-Name > <Host-Uniq 390c0000>]
Nov 28 20:09:18 rc9 accel-pppoe: eth1:: send [LCP ConfReq id=1 <auth PAP> <mru 1492> <magic 6b8b4567>]
Nov 28 20:09:18 rc9 accel-pppoe: eth1:: recv [LCP ConfReq id=1 <mru 1492> <magic 5624ae46>]
Nov 28 20:09:18 rc9 accel-pppoe: eth1:: send [LCP ConfAck id=1 ]
Nov 28 20:09:21 rc9 accel-pppoe: eth1:: send [LCP ConfReq id=1 <auth PAP> <mru 1492> <magic 6b8b4567>]
Nov 28 20:09:21 rc9 accel-pppoe: eth1:: recv [LCP ConfAck id=1 <auth PAP> <mru 1492> <magic 6b8b4567>]
Nov 28 20:09:21 rc9 accel-pppoe: eth1:: recv [PAP AuthReq id=1]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: connect: ppp0 <--> pppoe(08:00:27:fa:3e:50)
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: send [PAP AuthAck id=1 "Authentication succeeded"]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: send [CCP ConfReq id=1 <mppe +H -M +S -L -D -C>]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: test: authentication succeeded
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: recv [IPCP ConfReq id=1 <addr 0.0.0.0> <dns1 0.0.0.0> <dns2 0.0.0.0>]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: send [IPCP ConfReq id=1 <addr 179.109.80.55>]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: send [IPCP ConfNak id=1 <addr 100.64.0.1> <dns1 179.109.80.19> <dns2 179.109.80.20>]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: recv [CCP ConfReq id=1]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: send [CCP ConfAck id=1]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: recv [CCP ConfRej id=1]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: send [CCP ConfReq id=2]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: recv [IPCP ConfAck id=1 <addr 179.109.80.55>]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: recv [IPCP ConfReq id=2 <addr 100.64.0.1> <dns1 179.109.80.19> <dns2 179.109.80.20>]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: send [IPCP TermAck id=2]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: recv [CCP ConfAck id=2]
Nov 28 20:09:24 rc9 accel-pppoe: ppp0:test: recv [IPCP ConfReq id=2 <addr 100.64.0.1> <dns1 179.109.80.19> <dns2 179.109.80.20>]
Nov 28 20:09:24 rc9 accel-pppoe: ppp0:test: send [IPCP ConfAck id=2]

Tested functionality, no issues found:

Your client (00:0c:42:bd:02:05) disconnects.
PADT = Active Discovery Termination
Nov 27 18:16:43 vyos accel-pppoe: eth1: recv [PPPoE PADT 00:0c:42:bd:02:05 => 68:05:ca:01:6d:9d sid=1f80]

@kroy can you please use the rolling release. I checked the module does work in rolling.

I was thinking about swatting. Draws the most attention. (We(s)tcoast Canada)

@Line2 He will be in bed right now. It's 11pm in Germany.

Well not really, the ones who rebuilt the new kernel didn't know about those. I'm working on IPoE integration (similar like a PPPoE server but without the PPP =), They won't do anything.

Hmm, ok I gotta check on that.

Hmm. looks strange. 4.19.0-amd64-vyos isn't required as you are running on 4.19.4-amd64-vyos. Can you load the module manually? (sudo modprobe wireguard).

Please download http://dev.packages.vyos.net/repositories/current/vyos/pool/main/w/wireguard/wireguard-modules_0.0.20181018-1_amd64.deb and install via 'dpkg -i <pkg name>'.

Kernel module hasn't been rebuilt on our side. The current package will put that under /lib/modules/4.19.0-amd64-vyos/extra/ and your kernel is 4.19.4 and won't find it. I have a look into the package right now.

Can you please send me the output of 'uname -a'. Thx.

It seems that local auth is impossible, all I found is to configure it against radius, user should check abills as billing system. (https://sourceforge.net/projects/abills/)
If anyone knows how to use local authentication like chap or pap or anything, let me know please. Otherwise IPoE seems a real nice option, not as robust as ppp, but quite nice.

@dongjunbo Perfect. So it looks like that you have a valid ppp session established (session id 0x5d58). Does 'sudo ip sh a' show you a ppp0 interface or something similar? I tested the ppp client shipped in rc7 and rc8 and it appears it works as expected, so we need to find out what's going wrong on your side.

@patrickbrandao Your input is required.

@dongjunbo Your input is required.

https://vyos.readthedocs.io/en/latest/services.html#pppoe-server