- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Wed, Apr 24
Tue, Apr 23
Thu, Apr 4
It is not a bug with the VyOS itself.
You don't need to create the task on Phabricator
Feel free to create a PR without the task https://github.com/vyos/vyos-documentation/tree/equuleus
Wed, Apr 3
Mon, Apr 1
Personally I dont think its a good idea to be able to use VyOS as a jumphost towards victims of scanning.
ok, i'll change a port list and nmap scenario
Sun, Mar 31
I'm not sure that a list of ports will be helpful in this way.
From time to time, we need to scan specific ports.
What about
force scan-port-host <x.x.x.x> proto <tcp|udp> port '8080-8081,9200' force port--discovery-host <x.x.x.x> proto <tcp|udp> port '8080' force port-scan host <x.x.x.x> proto <tcp|udp> port '8080'
And use native nmap binaries (as python3 nmap module is not installed by default)
Also, it has XML format if you want a custom table:
sudo nmap -oX - 127.0.0.1
Mar 28 2024
@sever what do you think about it?
Mar 15 2024
Mar 12 2024
Mar 8 2024
Mar 7 2024
In T6108#179246, @Viacheslav wrote:There is no 1.3.7 version ;)
There is no 1.3.7 version ;)
The issue persists in 1.3.4 too from what I have tested.
1.3.3 and rolling from 2020?
Feb 15 2024
Feb 8 2024
Feb 2 2024
I can reproduce this on VyOS 1.4.0-rc3. It also appears that IPv6 addresses are only garbled on subinterfaces.
Jan 20 2024
Jan 12 2024
PR for 1.4 https://github.com/vyos/vyos-1x/pull/2810
PR for 1.5 https://github.com/vyos/vyos-1x/pull/2809
Jan 11 2024
Jan 10 2024
Jan 9 2024
Jan 8 2024
Jan 1 2024
Sorry maybe I’m not understanding you. The address you’ve highlighted isn’t valid in any case (it only has 6 segments). At the very best it should look like 2602:fcad:2:fffe:5054:ff:XXXX:XXXX (with eight segments). 2602:fcad:2:fffe::/64 is a valid prefix on our network, but there would need to be another 4 segments at the end for SLAAC assigned addresses (which is how that particular address is being assigned). I’d need to look deeper into what the correct address should be, which is why we provided the iperf3 example given the shorter / defined host addresses (with the hope that someone else smarter than me might see the pattern of how the addresses are being mangled). Thanks.
Yes but "2602:fcad:2:fffe:5054:ff" is a valid host in your case?
Hmm, I also just realized the SRC_PORT and DST_PORT are 0 in both the IPv4 and IPv6 flows (also seen in the first example).
No -- I don't believe that's a valid IPv6 address. We just ran some iperf3 tests between two servers on our network 2602:fcad:1::12 <-> 2602:fcad:1:ffff::ffff. Here's what showed up in nfdump (our Netflow collector). I'm not seeing an obvious pattern on how the addresses are being mangled.
Dec 31 2023
You mean that for SRC_IP you expect it to be "2602:fcad:2:fffe:5054:ff" and not "14d:63f:2602:fcad:2:fffe:5054:ff" ?
Dec 25 2023
Dec 15 2023
Dec 14 2023
PR for 1.5: https://github.com/vyos/vyos-build/pull/469
Dec 13 2023
Dec 10 2023
Dec 4 2023
Nov 25 2023
KeyboardInterrupt is caught with an appropriate error message now.
Nov 23 2023
Nov 21 2023
I had the below set on the pppoe interface to allow for DHCPv6-PD. That part was working fine it was just the pppoe interface that wasn't picking up an address:
Nov 20 2023
Did you try it?
set interfaces pppoe pppoe1 ipv6
Nov 19 2023
Nov 14 2023
Nov 9 2023
Oct 28 2023
This functionality has also been backported to 1.4 so it will be in the next LTS release.
Oct 26 2023
Oct 25 2023
Oct 19 2023
Oct 16 2023
@fsbof This change was accepted so it should end up in the 1.5 rolling soon. I suspect backporting to 1.4 wouldn't be an issue but that is a question for a more senior dev. But as for 1.3, I am unsure as I have never ran that version and don't know if there are any changes between those releases that would make it a pain to backport.
Oct 14 2023
@JeffWDH I am happy to download, build and test when you're ready if you point me to the right version(s)/location(s). I'm also very new to this but I managed to Build Equuleus in a docker container which has been working ok. Appreciate your efforts.
I've updated this to default to no ASCII art as I think it's cleaner, but added an option to show it if you want to see it:
Wow - you guys work quickly! 👍
I think it should be included, its often used during generation in Debian among other distros.
I wonder if we need the ASCII art though or not the plain fingerprints only (first line of the command)
Oct 13 2023
$ show ssh fingerprints SSH server public key fingerprints: