@dmbaturin, should this task be in the rolling release project, too?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Sat, Oct 19
Fri, Oct 18
@dmbaturin Just to confirm/clarify, does this mean the public sagitta branches will cease to receive public updates? It will now be impossible to inspect the LTS source code (or, in the case of 1.4 / sagitta, any future updates) without a subscription?
Probably related driver T6713
Should be fixed in the next rolling release
It has a capcha on it so you will probably have to host it yourselves, also see note re new version yesterday. looks like the same one from May to me.
@SteveP could you provide the link to the source code (git) for the official drivers?
Where we can clone the code and build correct package for Debian?
Thu, Oct 17
@Apachez: This may be fine for new features, but some bugs may affect just the LTS releases (for example in the ISC DHCP server, replaced by Kea) or it may be necessary to test the fixes in production environment on LTS (or at least unofficial "LTS" rebuilt from source, which was an option for those without subscriptions for some time thanks to the good work of a few community members - it was fun while it lasted) which happens to be the case with one bug I've been working on (T4600). The bug turns out to be more complex than I first suspected, but I've already spent a lot of time on it, wanted to continue but didn't expect new hoops to jump through. I'm still running 1.3.8 from back when I had access (not anymore) and would like to test just changes to the one accel-ppp package without touching anything else that works otherwise, my setup is fairly complex and I'm not brave enough to try even 1.4.0 just yet, let alone rolling/circinus/stream whatever you name it.
Realtek also listed a new driver yesterday.
Bump Realtek driver version
PR https://github.com/vyos/vyos-build/pull/814
Now that I have stopped your vyos-drivers-realtek-r8152_2.18.1-1_amd64.deb module from loading in data/architectures/amd64.toml and have turned off CONFIG_MODULE_SIG_FORCE, I can load my unsigned r8152.ko re-compiled for 6.6.56 and loaded from vyos-preconfig-bootup.script as I always have and everything is working. I suspect that this is because it is loading later after the nic renaming has been done.
Wed, Oct 16
@marekm: Bugfixes will be towards current (aka 1.5-rolling as of writing) which then is being cherrypicked and backported by VyOS Networks to whatever older releases that needs that and are compatible with the change/fix/added feature.
OK, I'll keep on it
That looks like a very much breaking change to me, not perfectly compatible. No more access to source code for LTS branches means it may not be possible to work on bug fixes (not just new functionality) anymore. So, to submit three PRs with bug fixes in the LTS branch to qualify for a subscription, one first needs to have a subscription. I don't think this will encourage more contributors to help the project. Is this intentional?
You can add PR a delete here https://github.com/vyos/vyos-build/blob/2359180068a653e39724a33b91bfa1ed395c1993/data/architectures/amd64.toml#L9
I think it is better to figure out what could be wrong
I have compiled a kernel with CONFIG_MODULE_SIG_FORCE off so I can load unsigned drivers. This worked fine. I then made an iso with the stock r8152 drivers, all good so far. I can now load the 2.18.1 drivers on 6.6.56 after everything has booted and settled down. It still breaks the router.
Tue, Oct 15
PR for current/Circinus/Sagitta:
https://github.com/vyos/vyos-http-api-tools/pull/19
I've checked on 1.4.0 and BGP session is stable
@jvandenbroek fell free to cereate a PR for fix.
I was wondering why I couldn't get DSCP marked packets to match, just to discover that the code to make the rules are actually incorrect. OP gave the exact code - which I wish had noticed earlier - to make it work as intended. I can confirm it does work with both ipv4 and ipv6, with and without ECN bit set. So maybe you can use that code to update vyos/qos/base.py, which I currently run without problems:
Hi, If we are not going forward with this could we please remove the broken driver and go back to the stock one. It is not useable at all with a r8152 loaded at the moment as it breaks eth0 too early on.
@c-po So what's interesting here is it seems like it might be something with the reconfiguration of the daemon. Try deleting and then adding the default config, like this:
delete service ntp vyos@cr01-vyos# set service ntp allow-client address 127.0.0.0/8 [edit] vyos@cr01-vyos# set service ntp allow-client address 169.254.0.0/16 [edit] vyos@cr01-vyos# set service ntp allow-client address 10.0.0.0/8 [edit] vyos@cr01-vyos# set service ntp allow-client address 172.16.0.0/12 [edit] vyos@cr01-vyos# set service ntp allow-client address 192.168.0.0/16 [edit] vyos@cr01-vyos# set service ntp allow-client address ::1/128 [edit] vyos@cr01-vyos# set service ntp allow-client address fe80::/10 [edit] vyos@cr01-vyos# set service ntp allow-client address fc00::/7 [edit] vyos@cr01-vyos# [edit] vyos@cr01-vyos# set service ntp server time1.vyos.net [edit] vyos@cr01-vyos# set service ntp server time2.vyos.net [edit] vyos@cr01-vyos# set service ntp server time3.vyos.net [edit] vyos@cr01-vyos# commit Archiving config... sftp://stor01a-rh9.int.trae32566.org/bhs/cr01-vyos Host 'stor01a-rh9.int.trae32566.org' not found in known hosts. Fingerprint: 1083a0c4ff8380df83596781bcddf2a9 Do you wish to continue? [y/N] y
Mon, Oct 14
Raised https://github.com/sflow/host-sflow/issues/68 with the above information. Will move over there to continue discussion
If it's helpful, here's a tcpdump of me pinging a resolver, with the response
21:41:33.485179 1e:43:be:d9:9c:90 > 80:7f:f8:74:c8:db, ethertype 802.1Q (0x8100), length 110: vlan 10, p 0, ethertype PPPoE S (0x8864), PPPoE [ses 0x72d] IP (0x0021), length 86: ??.??.??.?? > 1.1.1.1: ICMP echo request, id 1, seq 1, length 64 21:41:33.487988 80:7f:f8:74:c8:db > 1e:43:be:d9:9c:90, ethertype 802.1Q (0x8100), length 110: vlan 10, p 0, ethertype PPPoE S (0x8864), PPPoE [ses 0x72d] IP (0x0021), length 86: 1.1.1.1 > ??.??.??.??: ICMP echo reply, id 1, seq 1, length 64
Looks like Linux doesn't provide the PPPoE interface MAC via SIOCGIFHWADDR :(
The server code is (unfortunately) proprietary, but the client is open source (and even in F-Droid).
With my FR I also meant the client and not the server part, so VyOS can be part of a tailnet.
We couldn't find a use case for SNMPv3 certs. If anyone knows of a valid use case and how to test it, we are ready to reimplement it.
There was a licensing issue with tailscale - you would need a container to solve this or use headscale instead.
Vyconfd running all validators in links above; integration with T6717 remaining to complete before PR.