@UnicronNL can you look into that please

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

the flag accept-any-service is interest to implement, to accept any service name from client side

@dmbaturin Yes. We'll try tomorrow morning and give you feedback.

vyos-1.2.0-rolling+201811281529-amd64.iso works good for me. And it has CONFIG_FB_VGA16=m same as rc8.

@dmbaturin maybe can, need to verify this behavior together with the EFI stuff when I'm back in germany. If =n works for all szenarios I'm happy with it.

@bswinnerton Ha, no problem. I just figured with a bit more insight maybe it would be worth breaking this out into two tasks

Sorry about that @kroy. That was the default value when I fixed a typo in the title 😬. I didn't mean to update that value.

No ISP problems. Vyos always has the problem that when i install a new vyos on a server with a intel network adapter which has 4 ports. Every time i need to change the mac address of each network interface. I'm sure it's a bug that got the wrong mac address of each interface(eth0-eth4, not pppope interface).

@bswinnerton I think the "in certain situations" should be defined "when the config on disk is invalid for whatever reason"

@arne I think it's a sensible workaround. It's an interesting design question whether we should escape backslashes in config output.

I've verified that it writes the grub.cfg correctly now.

The daemons package is in the rc9. Could anyone test in Hyper-V if it works as expected?

I hope 256 will be enough for everyone. ;)

Did anything happen to the github integration?

Will just setting it to =n solve the problem?

@oliko Could you retest it with rc9, which uses a 4.19.4 kernel?

Apparently we do not have phabricator integration setup for the ipaddrcheck repo, since it didn't pick this commit up: https://github.com/vyos/ipaddrcheck/commit/21c0775c51da1ca3d4ef6506fca82bce5b334c79

The problem is fixed by the following pull request: https://github.com/vyos/vyos-1x/pull/60
Detailed description is added to the pull request.

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.

Can you please double-check with latest rolling release: vyos-1.2.0-rolling+201811281529-amd64.iso?

Dear, Hagbard
Seem like that i found the problem that mac address of each interfaces had been switched randomly after upgrade rc7 to rc8.

Sorry. When i upgrade rc7 to rc9 is okay. but when i reboot to rc8 and then reboot to rc9. it failed again.

In T1031#26684, @hagbard wrote:

@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.

Sadly not. I can reproduce the error but i am not able to fix the problem in the code.

With some small changes i changed the scripts to create the proposed NETMAP rules when editing the NPTv6 rules in the configuration. For me this is working and surviving reboot.
I can add the diff files if anyone wants them.

Re-tested with 1.2.0-rc9 with the same result.
I found that i can enable debug in /opt/vyatta/sbin/vyos-update-nptv6.pl to see what is added and deleted.

Latest RC will work for testing? Ill try a lab here to validate the fix if its available in the RC.