@alainlamar as you seem to be the VyOS Wireless expert, you know why we have VLAN support on it?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Sep 28 2019
Sep 28 2019
c-po updated the task description for T1512: vyos 1.2 openvpn client names with spaces created incorrectly.
c-po added a parent task for T1496: Separate rolling release and LTS kernel builds: T1682: Migrate to new Jenkins Pipeline script.
Sep 27 2019
Sep 27 2019
sorry, but their licensing model incompatible with what we do.
ZeroTier was added to the Ubiquiti EdgeRouter (which runs a vyatta fork) as a demo. Relevant to this thread:
https://blog.kruyt.org/zerotier-on-edgerouter-p2/
Yes, this _was_ still a problem but the workaround solves the issue for
me. I've been able to upgrade the 1.1.8 instances to 1.2.3 after adding
this extra interface route.
Pull request created: https://github.com/vyos/vyos-1x/pull/141
vindenesen changed the status of T1696: NTP - Tests fail when building vyos-1x from Open to In progress.
vindenesen changed the status of T1695: Syntax error in interface-dummy.py from Open to In progress.
Pull request created: https://github.com/vyos/vyos-1x/pull/140
Been pretty busy lately, but ran a quick test tonight. Wireguard keys are properly moved in my VM.
Sep 26 2019
Sep 26 2019
vindenesen updated the task description for T1691: OpenVPN - Commiting config when OpenVPN peer/server not available makes commit hang.
vindenesen renamed T1691: OpenVPN - Commiting config when OpenVPN peer/server not available makes commit hang from OpenVPN - Commiting config when OpenVPN peer/server not available hangs to OpenVPN - Commiting config when OpenVPN peer/server not available makes commit hang.
hagbard changed Difficulty level from unknown to easy on T1690: restart op-mode commands for 'service (pppoe|ipoe)-server'.
hagbard changed the status of T1690: restart op-mode commands for 'service (pppoe|ipoe)-server' from Open to In progress.
hagbard triaged T1690: restart op-mode commands for 'service (pppoe|ipoe)-server' as Normal priority.
c-po triaged T1689: "reset openvpn" op-mode command should terminate and restart OpenVPN process as Low priority.
hagbard renamed T1682: Migrate to new Jenkins Pipeline script from Migrate to new Jenkins Pieline script to Migrate to new Jenkins Pipeline script.
I have rebuilt the router and this appears to be working as expected now. Marking as resolved.
Unknown Object (User) added a comment to T1686: Spam.
Unknown Object (User) updated the task description for T1686: Spam.
Unknown Object (User) updated the task description for T1686: Spam.
Unknown Object (User) updated the task description for T1686: Spam.
Unknown Object (User) updated the task description for T1686: Spam.
Unknown Object (User) created T1686: Spam.
Sep 25 2019
Sep 25 2019
Unknown Object (User) changed the status of T1685: Improvement cli ethernet helper for vif/vif-s/vif-c from Open to Needs testing.
PR 138
Unknown Object (User) triaged T1685: Improvement cli ethernet helper for vif/vif-s/vif-c as Low priority.
hagbard added a comment to T1663: T1656 equuleus: buster: arm64/aarch64: ipaddrcheck does not complete testing.
I've tested it and can't reproduce. There are a few issues in the debian files and autoreconf, but other than that everything seems to work just fine.
There is no such thing like separate identities. You can either decrypt a package or you can't, that's about it. You basically have to hand out more public keys, you have to maintain more keys. As I mentioned before I only see currently disadvantages so far. However the user can chose what way to go and multiple options are always good. If it helps you, well that's nice to hear.
In T1572#42883, @hagbard wrote:It's not so much the implementation as I wrote before, it just doesn't seem beneficial. It gets implemented anyway, but I try to understand why a user would like to use that. The private key is by the way no identity and also won't interfere with multiple VPN peers if you are using only one pk. On IP:12345 arrives an encrypted packet, it is simply decrypted using your pk. If it works it's given to your kernel netlink interface as far as I recall and routed there, so no verification of the private key anywhere. If it can't be decrypted, it's discarded. If you have multiple wg interfaces, your 'crypto routing' either allows the traffic to the peer or discards it if it doesn't fit, the private key has nothing to do with that, since the public key of your peer is used to encrypt it. Summary, I still cna't see any benefit having that, which doesn't mean that I won't implement it.
hagbard moved T1672: Wireguard keys not automatically moved from In Progress to Finished on the VyOS 1.3 Equuleus board.
This feature is currently in the 1.2 rolling release.
It would be awsome if the feature could also be made available in the next VyOS 1.2.x version.
Because it likely takes a lot more time until version 1.3 gets released.
Sep 24 2019
Sep 24 2019
hagbard moved T1635: Rewrite interface pseudo-ethernet in new XML/Python style from Need Triage to In Progress on the VyOS 1.3 Equuleus board.
hagbard moved T1672: Wireguard keys not automatically moved from Need Triage to In Progress on the VyOS 1.3 Equuleus board.
hagbard moved T1681: cleanup wireguard code since tagnodes are now visible from Need Triage to In Progress on the VyOS 1.3 Equuleus board.
hagbard changed the status of T1681: cleanup wireguard code since tagnodes are now visible from In progress to Needs testing.
Unknown Object (User) added a comment to T1678: hostfile-update missing line feed.
PR https://github.com/vyos/vyos-1x/pull/137, using vyos-hostsd-client instead of typical adding record to /etc/hosts
Unknown Object (User) claimed T1678: hostfile-update missing line feed.
Can confirm. All my routing tables now have 0.0.0.0/0, no matter what the device is. This is just in 1.2.3.
Seems that it s merged an in 1.2.3 it looks in the moment good for me:
srgjp added a comment to T1560: "set load-balancing wan rule 0" causes segfault and prevents load balancing from starting.
reproduced on 1.2-rolling-201909100338
zsdc assigned T1212: IPSec Tunnel to Cisco ASA drops reliably after 4.2GB transferred to Unknown Object (User).
Unfortunately we have multiple commands like this.
dmbaturin edited projects for T1638: vyos-hostsd not setting system domain name , added: VyOS 1.2 Crux (VyOS 1.2.4); removed VyOS 1.2 Crux (VyOS 1.2.3).
Sep 23 2019
Sep 23 2019
Unknown Object (User) updated the name of F411016: LLDP_sch1.png from "Снимок экрана 2019-09-24 в 1.59.25.png" to "LLDP_sch1.png".
Unknown Object (User) added a comment to T1169: LLDP potentially broken.
Exist interesting moment when LLDPD communicate with cisco ios, after 1 min 55 second LLDPD in VyOS forget cisco device, but cisco device send LLDP (with ethertype encapsulated in vlan 1 0x8100). However LLDPD in VyOS remember mikrotik and other VyOS router, which directly connected, and which also transmit LLDP. I was try using and new version LLDPD which build for myself, but same result.
After adding vlan 1 on directly connected interface with cisco device LLDPD in VyOS, R1 don't forget it.
That's fixed the problem we had, but we've encountered some other strangeness.
hagbard changed the status of T1681: cleanup wireguard code since tagnodes are now visible from Open to In progress.
danhusan added a comment to T1219: Redundant active-active configuration, asymmetric routing and conntrack-sync cache.
Bump
c-po closed T1680: DHCP client does not release IP address on exit/deletion, a subtask of T1557: Create generic abstraction for configuring interfaces e.g. IP address, as Resolved.
c-po changed the status of T1680: DHCP client does not release IP address on exit/deletion, a subtask of T1557: Create generic abstraction for configuring interfaces e.g. IP address, from Open to In progress.
c-po changed the status of T1680: DHCP client does not release IP address on exit/deletion from Open to In progress.
At this point I've moved all my ASAs to VyOS, and all my tunnels to Wireguard. Unfortunately I cannot test this setup anymore.
Unknown Object (User) added a comment to T1212: IPSec Tunnel to Cisco ASA drops reliably after 4.2GB transferred.
Do you still have that problem?
Did you see EwaldvanGeffen's message?
Do you have any comment on it?
Thank you, @c-po, I'll go deploy it now, then! :-)
ISO rebuild triggered