Jacob:
Some networking info that might be helpful.
If you want to chat about full specs let me know, or we can review what is relevant.
What is your requirements / recommended setup?
Type0: 1 Gbps Network (2 × 1Gbps w/ TLB) full hardware redundancy but no active/active bond.
Type1: 2 Gbps Bonded Network (2 × 1Gbps w/ LACP) full hardware redundancy and active/active bond.
Type1e: 10 Gbps Network (2 × Intel X710 NIC's in TLB) full hardware redundancy but no active/active bond.
Type2: 20 Gbps Bonded Network (2 × 10Gbps w/ LACP) full hardware redundancy and active/active bond.
Type2A: 20 Gbps Bonded Network (2 × 10Gbps w/ LACP) full hardware redundancy and active/active bond.
Type3: 20 Gbps Bonded Network (2 × 10Gbps w/ LACP) full hardware redundancy and active/active bond.
TypeS: 20 Gbps Bonded Network ( 2 × 10 Gbps w/ LACP) full hardware redundancy and active/active bond.

@Asteroza
If you'd like to see FreeDNS support in VyOS you might want to open a feature request.

straight firewalling won't help if the logon attempts still come from a presumably trusted LAN. I like the idea of at least a temporary lockout to prevent mass attempts when someone is running a big password list, though the utility of this naturally drops if VyOS can be fingerprinted before the attempt and the instance runs with a default password, but that's a sysadmin problem.

How about

I also tried without edit mode like this with same result:

Ah ok, you are in edit mode, this is different to me.

I just tested on VyOS 999.201802080337 with same result:

Another idea would be to wrap the system options in the python configuration script with e.g. a dictionary.

Unfortunately I can't reproduce this. @Line2 could you please try with the latest version again?

Proper firewalling will be better...

whitelisted, should be ok now

Sorry @c-po i think it will not hurt

Ok, as this is a rather minimal change I just added it and triggered the CI build. Will be in the next rolling release...

No worries, that is the eternal state of wiki

Sorry for that
Will whitelist you now
we had issue with spammers in past  and not much contributors :)

The details of how to boot were improved. I tried to add a few things directly to the wiki - mostly links to Packet help pages - but they were rejected as spam (!).

Ed please share this extra details so we can add it on wiki too

Hey @syncer good news, yes we communicated via email. We were just discussing this on the Packet community channel (on Slack, or IRC #packethost) and managed to improve the boot process to avoid a manual step. Happy to help iterate to make this as easy as possible.

@syncer go for it, hopefully it helps some people out :)

Hey @ed We talked on email if i'm not wrong.

What kind of hardware info do you need? Happy to provide any specs or details.

Not sure if it's much help, but here is how we got it working: https://gist.github.com/mikeburgh/7fef199dfc0e4edf20b1292a69500159

It will have to be refactored for the new vyos-1x approach, but then the entire package will, so we'll better have the .ac support now, and refactor later.

1. A nicer version of os.system('iw reg get')

This makes me think we should make a shared nicer version that returns a tuple of exit code and combined stdout/stderr and put it somewhere in a utility module.

I will suggest few things,

OH! Well that's a relief. So this documentation is just out-of-date, then: https://wiki.vyos.net/wiki/Version_history

It's an ACK from my side and can be easily done. @syncer ACK/NACK?

I think this is the way to do it:

@syncer if it's inside the stock kernel, we should enable it ....

VyOS 1.2.x (all nightly builds) is based on Debian GNU/Linux 8 (jessie)
VyOS 1.3.x is planned to be based onDebian GNU/Linux 9 (stretch)

My apologies. I meant to post this as a question, not a bug, and now I do not know how to delete it.

As pointed out in T529#11515, I rewrote this command to now do the following:

I'd like to prompt for a decision:

• break backward compatibility to implement the above scheme (I'd suggest that) or
• stick with this pull request (T452) and work around the regdom-setting by using the existing pull request in T529.

Please keep in mind:

• ioctl() like interfaces are usually proprietary or encapsulated by the socket API (keeping the fucus on a network device only here)
• systl is used for tuning kernel internal parameters that are usually compiled statically, most of the time it wraps the /proc pseudo filesystem, e.g. networking stuff
• /etc/modprobe.d is used by modprobe for kernel load parameters when the module is inserted. Sometimes they can be manipulated by sysctl, sometimes not. Always depends if the module has been loaded before calling sysctl or where in the driver this setting is referenced.

@c-po I don's think that there is unique-one-ideal way to configure kernel modules in run time - some of them have interfaces as files in /proc or /sys filesystems, some don't and expect some ioctl on some /dev/ device or on some network device. Others, as netfilter, expect whole bunch of binary data to be pushed to kernel after being compiled by their own userspace tool.
As far as I understand, what we can do - is to make some use of sysctl to adjust the parameters that it can access. Thus, more or less generic way is to call sysctl something=somevalue in op mode and to write something=somevalue to file like /etc/sysctl.d/path_to_conf_entry.conf together with calling sysctl something=somevalue in configuration mode. This way we can get more-or-less generic way to describe sysctl's parameters in conf and op mode.

Why is this tagged under 1.2.x? You stated you're on version 1.1.8.

Sorry, I just now came across this fixed issue by random chance.

@mickvav sure it will work without T123 and a test is very good.

In T529#11515, @alainlamar wrote:

I had a chat with @syncer yesterday, where we also discussed the approach of setting WiFi regulatory domains. We agreed upon two issues prompting for an Architect's decision (@dmbaturin):

• Code that does persistent changes should go to the configure section. This would mean three things:
  • The part writing to files would be moved from T529 to T452.
  • Backward compatibility in T452 would be broken as the set interfaces wireless wlanX country DE node would be moved in front of the interface name tag config node: set interfaces wireless regulatory-domain DE which would allow for a complete and easy to understand way of making all persistent changes in one go. [...]

Hi folks,

@c-po this thing should work already without T123, if someone can test this code on live hardware - it seems to be ready to merge.

@alainlamar , well done!

Looks like one has to run also something like

IRC meetings can be held every evening starting 19:00 UTC+1

Related to T123

I'll be available this Monday and Thursday after 21:30 until 23:30 CET.

Yes, that is all parts of same story

• guidelines for bug submission
• guidelines for pull request submission
• guidelines for feature submission (less strict)

I agree with your approach on handing in bug reports and feature requests. What I try to figure out is how folks trying to solve these bugs and implement feature requests would best approach maintainers. Since there is very few maintainers and they spend their spare time on VyOS project maintainance, I think there should be guidelines for folks (like me) on how to hand in code for review - and maybe how not to. This, I hope, would allow maintainers to accept more pull requests with less use of their valuable spare time.

Now like everybody doing it in own maneer.
I think we need to define approach for bugs and tasks
for bugs is like well described issue and procedure how to reproduce bug or issue
for tasks at least some background on what we trying to achieve with it

Thanks mate,

Historically that was few people,
now that is more people works on that we can actually do meeting and agree approach

Pull request created: https://github.com/vyos/vyatta-wireless/pull/9/files

https://github.com/openwrt/packages/tree/master/net/zerotier ZeroTier is now an OpenWrt package.

Pull request sent. Please consider a merge.

thanks @c-po !