https://phabricator.vyos.net/R3:15a9a405e03165b798776b9f779426bdfa779d03

https://github.com/vyos/vyatta-cfg-vpn/commit/8365c04cccb6e0216b048ca30e289081f0c0ae44
https://github.com/vyos/vyos-1x/commit/ac7c868dcba4dd6738eb0087c4f414b92bf10c9d

@syncer I was thinking to add a cli menu for vmwaretoolsd mitgation like these things. It seems that not many were affected by that but if there is anything in the cli available, it can configure the toolsd to prevent things like that plus the toolsd has tons of options. So, I'm not really sure how I should go forward with this one.

Next rolling will have the fix applied:
https://github.com/vyos/vyos-1x/commit/76fe726e3530158ee175d34b9cb74209ccca2345

@c-po I have access to it, let me know if you need a pdf out of it.

I stumbled over the same issue and since then I contribute to @UnicronNL and @c-po documentation. I think the old wiki will go away at one point, have a look at the github link @c-po posted above, it's also way easier to maintain the new documentation.

Hi @rherold , these messages are verbose debug messages, change to virtio-net or to a different emulated driver to have them disappear. In general I recommend to use the virtio one which has a better performance too compared to emulated ones, plus less complex code. (https://github.com/MorteNoir1/virtualbox_e1000_0day)

Thanks for testing that guys.

@MrXermon , yes that sounds reasonable. I found in the code that they limit it to 100 routes, can you please try the following:
(https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/include/conf.h#L138)

Hi @Barrysdca did you have a chance to test again?

Hi @danhusan, did you ever try another poll value, like 3 secs or 5 or anything like that? If set to 0, the host system won't show you any updated meta data, like if you change the ip address etc.
(https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/services/plugins/guestInfo/guestInfoServer.c#L1662)
I'm therefore not entirely sure if that should be treated as a special case scenario (we could publish a kb if you run into that condition), or if it is a general issue since you 2 were the only ones experience that issue as far as I know.
I'm also not sure it only is triggered by your situation (full bgp table) or if it can happen on other occasions as well, if you came across more issues regarding that value, please let me know.

I have a look into it but I doubt that this will be an issue. Charon is usually taking care of the routes if an IPSec tunnel has been established and you have a valid SA. The redirects from the settings above shouldn't interferer with it at all. If a mode tunnel is being used with public IPs, the packets will leave the system unencrypted anyway as long as no valid SA exists, so they will go the default route. I'll check if the perl script is actually changing these settings, that would be not so nice since you will face a race condition which would explain why I can't reproduce your issue, since I never tested with a working IPSec tunnel :). I'm having the flu right now, so please give me a few days to have a look.

Can you check ig you have any postscripts running or any manual sysctl variable set? Or do you experience that on new insatllations?

Yes, that's correct. When I enable redirects, it automatically disables receive redirects, which I didn't know but makes sense.
I have only set the redirect and dhcp on eth0, commit && save and rebooted, all looks good.

I still have no luck reproducing it, I loaded your config on a vm, runni9ng the smae version as you do but if I enable and disable redirects it switches between 1 and 0, as expected.

@zsdc I can't reproduce it, can you please share your config? I have only enable send redirects set, nothing else in the config and everything works like expected. I suspect that something is overwriting your variables. We'll find out.

Next rolling release tonight will have the bugfix in place. Thanks for reporting.

@Barrysdca Can you please test with the latest rolling release, please?

@Unicron Can you please integrate the package below into ci?
https://github.com/vyos/vyos-vmwaretools-scripts

@hexes Should be fixed now. (https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201812171828-amd64.iso)

https://phabricator.vyos.net/R11:9e03aa762bac9919db2dae774062b179f9478b70

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.