Create/update/delete are all called implicit by the execution of the given Python script.

@Asteroza can you add the approriate Task here in the comments?

By this you mean VyOS should act as TFTP server and provide files to clients?

This would make sense. Some could imagine that there is a P2P linkt between two sites and a WAN IPSec Backup link

Is there a CSR1000v license available or will we stick with the bandwidth limitation?

We should rewrite legacy DDNS first and then could add aws53 as alternative provider that would make sense.

Besides the typo,

Hmm I'm wondering b/c I've seen a provider in germany (HETZNER) where they do NAT (not PAT) for their cloud customers. Every vServer has the same IP configuration with RFC1918 addresses and an outside router does the mapping. Implementing this would break such a szenario if it can't be disabled.

We can't do anything about the truncated encrypted-key b/c it's actually truncated by SNMP itself.

Issue should be fixed starting with vyos-1.2.0-rolling+201806062125-amd64.iso at least it was tested positively when updating from 1.2.0-rolling+201806040337 to 1.2.0-rolling+201806062125

Okay, when not executing the marked part (https://github.com/vyos/vyos-1x/blob/743b16de1aac4c6b579767f28d57bc2156d3acdf/src/conf_mode/snmp.py#L704-L729) reboots work but then we loose transformation from plaintext o encrypted passwords. So the bug is definately here. Will check!

Okay, when rebooting both encrypted keys change, thats a bug in the Python script too ... sorry for the trouble.

Okay, there was definately a problem with the listen address which is fixed now. Waiting for a new ISO and then I try upgrading from old version, too

Thanks @hagbard

Looks like there is no listen address agentaddress unix:/run/snmpd.socket configured and if there is none inside the configuration, we won't listen on all addresses. This is likely the cause. Could you please add for validation a set service snmp listen-address <ipv4> and check if you can now reach the server again?

Could you please paste the content of the following files:

Could you check if the snmpd process is running at all? Please execute ps faux | grep snmp in the commandline.

@Line2 new ISO building right now which converts plaintext-keys to encrypted keys again.

Okay, the encrypted passwords are re-read from /var/lib/snmp/snmpd.conf and set on the CLI. The truncation originats from that file.

Ah, yes. In the past the Perl scripts re-read the newly generated configuration and altered the running configuration using /opt/vyatta/sbin/my_set or /opt/vyatta/sbin/my_delete. That's indeed missing. Thanks for the commands and I'll fix it this evening.

@Line2 thanks for the feedback. Could you tell me how you generated that encrypted key so I can retest this evening and bugfix this?

A first implementation is merged

Tested using:

Working again with 1.2.0-rolling+201806020337

@syncer this is implemented and working with a patched xl2tpd (T605).

This one should be closed and reopened if required @syncer

Good catch. The proper solution should be:

As soon as someone sets set system ntp allow-clients address 172.16.0.0/12 we act as NTP server for this network,too. It's a bit odd that this node is under system but ... it is as it is.

@syncer we do offer NTP as service (unfortunately it's unter the system tree instead of service.

any updates on this?

looks like a missing check on commit. Will add this case to the new Python script.

Ah, there it is! Thanks!

Implemented in https://github.com/c-po/vyos-1x/commit/b871546cdde982c65e243ec57610edecddb4701b

Even after changing the configuration to

snmp {
    listen-address 172.16.37.241 {
    }
    v3 {
        engineid 0xff42
        user test {
            auth {
                encrypted-key 0x63119b4e19ce4d69c7ad678ffe110047
                type sha
            }
            engineid 0xff42
            mode rw
            privacy {
                encrypted-key 0x63119b4e19ce4d69c7ad678ffe110047
                type aes
            }
        }
    }
}