this was abondoned
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Oct 30 2024
Oct 29 2024
In T6545#204568, @ordex wrote:Thanks for the pointer. I am even surprised that this worked with --cipher. In any case, I presume that template needs an exception.
Thanks for the pointer. I am even surprised that this worked with --cipher. In any case, I presume that template needs an exception.
The problem is that the template returns the none values in uppercase https://github.com/vyos/vyos-1x/blob/ba18d12f6863505133cde688d5e8188689af63bb/python/vyos/template.py#L567
This is the bad one:
Oct 28 18:03:45 debian vyos_net_name[896]: Started with arguments: ['/lib/udev/vyos_net_name', 'e8']
Oct 28 18:03:45 debian vyos_net_name[886]: Started with arguments: ['/lib/udev/vyos_net_name', 'e4', '00:0c:29:2d:44:53', 'eth4']
Oct 28 18:03:45 debian vyos_net_name[888]: Started with arguments: ['/lib/udev/vyos_net_name', 'e6', '00:0c:29:2d:44:3f', 'eth2']
Oct 28 18:03:45 debian vyos_net_name[887]: Started with arguments: ['/lib/udev/vyos_net_name', 'e5', '00:0c:29:2d:44:35', 'eth1']
Oct 28 18:03:45 debian vyos_net_name[884]: Started with arguments: ['/lib/udev/vyos_net_name', 'e3', '00:0c:29:2d:44:49', 'eth3']
Oct 28 18:03:45 debian vyos_net_name[885]: Started with arguments: ['/lib/udev/vyos_net_name', 'e2', '00:0c:29:2d:44:2b', 'eth0']
e7 is missing e8 has no mac address
FTR --ncp-disable was only supposed to disable the cipher negotiation. It was not meant to disable encryption entirely. --data-ciphers none is the way to go, but it seems you've already figure this out.
@sarthurdev not sure if it's still actual for new implementation, if no please close as NA
The issue with automatic offload settings was addressed in T6716
Oct 28 2024
@SteveP could you attach those files for debugging where the issue exists?
/config/config.boot /run/udev/log/vyos-net-name sudo journalctl -b | tee /tmp/journalct.log sudo journalctl -k | tee /tmp/journalct-k.log
@n.fort please take a look to this
This task is obsolete
@Viacheslav Can you take a look at this and close it if it's obsolete?
@Viacheslav @c-po
what is the decision here?
@rps @dmbaturin it seems old
is this still the case for 1.4/1.5 ?
This task is obsolete
@dmbaturin automation tagged this as bug, and many other tasks
that automation is not work properly
Oct 27 2024
No worries, I'm all good here. I can turn off signing and carry on with the unsigned drivers as before. It is all good if I load them in the pre-script. If I figure it out I'll let you know.
I’d prefer to drop it at all for now.
Until someone can investigate it more deeply.
I don’t have any idea what is wrong.
Thanks
Looking at dmesg from a working config we can see:
nothing in the difference between .51 & .52. I'm beginning to doubt myself now that that was the point it broke. That was also the point where you started requiring signed drivers and maybe I'm conflating the problems I had at that point.
Oct 26 2024
Still broken I'm afraid.
@SteveP Can you try the latest rolling?
Oct 25 2024
Oct 24 2024
I just built from the current top-of-tree and installed onto my working system and I no longer am getting that log message filling up my system logs. I'm not sure if something indirectly fixed it or what - regardless it appears fixed now. Therefore, I'm moving the status to resolved.