Page MenuHomeVyOS Platform

jjakob (Jernej Jakob)
User

Projects

User Details

User Since
Nov 6 2018, 10:08 PM (107 w, 5 d)

I'm usually on #vyos:chat.freenode.net.

Recent Activity

Sep 30 2020

jjakob triaged T2941: Using a unicode character in the description field causes UnicodeDecodeError in configsource.py as Normal priority.
Sep 30 2020, 9:55 PM · VyOS 1.3 Equuleus

Sep 10 2020

jjakob triaged T2873: "show nat destination translation address" doesn't filter at all as Normal priority.
Sep 10 2020, 1:35 PM · VyOS 1.3 Equuleus

Aug 6 2020

jjakob changed the status of T2764: Increase maximum number of NAT rules from Open to In progress.
Aug 6 2020, 3:37 PM · VyOS 1.3 Equuleus
jjakob triaged T2764: Increase maximum number of NAT rules as Normal priority.
Aug 6 2020, 11:35 AM · VyOS 1.3 Equuleus

Aug 4 2020

jjakob added a comment to T2750: Use m4 as a template processor.

I wasn't trying to solve any specific issue. I was working on some other project, trying to use GCC as a preprocessor, the same way as it's used here, and ran into those obstacles I listed in the original description, which are present here too. I was made aware m4 is much more suitable to template processing than GCC as it was actually designed and made for it.
As for using any self-made code to do this, I have no problem with that as long as it's well known this is what is now used, is documented, and then an effort made to port all preprocessing to it. I see no sense using two or three different preprocessors.

Aug 4 2020, 2:31 PM · VyOS 1.3 Equuleus

Jul 31 2020

jjakob triaged T2750: Use m4 as a template processor as Wishlist priority.
Jul 31 2020, 4:31 PM · VyOS 1.3 Equuleus

Jul 30 2020

jjakob added a comment to T2746: IPv6 link-local addresses not configured.

No I didn't, sorry. I'll test it and see :)

Jul 30 2020, 10:25 PM · VyOS 1.3 Equuleus
jjakob added a comment to T2746: IPv6 link-local addresses not configured.

This is not enough, bridge and bond members also didn't get IPv6 link-locals in the previous implementation. To have them is incorrect and a security risk.

Jul 30 2020, 9:37 PM · VyOS 1.3 Equuleus

Jul 23 2020

jjakob added a comment to T2177: Commit fails on adding disabled interface to bridge.

This is expected as disabling an ethernet interface is different than any other interface, they're still present but just put admin down. All other interfaces get deleted and thus throw this error.

Jul 23 2020, 7:52 PM · VyOS 1.3 Equuleus

Jul 21 2020

jjakob added a comment to T2722: get_config_dict() and key_mangling=('-', '_') will alter CLI data for tagNodes.

I assume this will break 'system static-host-mapping host-name' and other places where tagnodes are used to carry string values as well

Jul 21 2020, 2:35 PM · VyOS 1.3 Equuleus

Jul 20 2020

jjakob added a comment to T2717: Wrong DHCP server pool size in statistics.

I could file a PR if you like, already prepared it.

Jul 20 2020, 2:10 PM
jjakob changed Difficulty level from unknown to easy on T2709: Destination NAT translation port without address fails to commit.
Jul 20 2020, 9:47 AM · VyOS 1.3 Equuleus
jjakob closed T2709: Destination NAT translation port without address fails to commit as Resolved.
Jul 20 2020, 9:46 AM · VyOS 1.3 Equuleus
jjakob changed Difficulty level from unknown to easy on T2519: Broadcast address does not add automatically.
Jul 20 2020, 9:46 AM · VyOS 1.3 Equuleus
jjakob closed T2519: Broadcast address does not add automatically as Resolved.
Jul 20 2020, 9:44 AM · VyOS 1.3 Equuleus

Jul 19 2020

jjakob changed the status of T2709: Destination NAT translation port without address fails to commit from Open to In progress.

https://github.com/vyos/vyos-1x/pull/507

Jul 19 2020, 7:37 PM · VyOS 1.3 Equuleus
jjakob added a comment to T2519: Broadcast address does not add automatically.

https://github.com/vyos/vyos-1x/pull/506

Jul 19 2020, 7:28 PM · VyOS 1.3 Equuleus
jjakob triaged T2713: VyOS must not change permissions on files in /config/auth as High priority.
Jul 19 2020, 11:49 AM · VyOS 1.3 Equuleus

Jul 17 2020

jjakob changed the subtype of T2709: Destination NAT translation port without address fails to commit from "Task" to "Bug".
Jul 17 2020, 1:43 PM · VyOS 1.3 Equuleus
jjakob triaged T2709: Destination NAT translation port without address fails to commit as High priority.
Jul 17 2020, 1:42 PM · VyOS 1.3 Equuleus

Jul 8 2020

trae32566 awarded T2650: interfaces bridge, bonding: revert back to per-interface membership syntax a Like token.
Jul 8 2020, 7:58 PM · VyOS 1.3 Equuleus

Jul 5 2020

jjakob added a comment to T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot.

The most likely culprit is /opt/vyatta/sbin/vyatta_interface_rescan. I'm not sure if this should be fixed or migrated to Python.
The rewrite would need to be done together with all other vyatta interface renaming and detection scripts.

Jul 5 2020, 9:30 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot.

Upgrading a different test VM with different config that starts at eth0: on 2nd reboot the hw-id lines are duplicated too, but they are the same on a single interface, and there are no new interfaces created, so the config loads and works fine. The duplicated hw-id lines stay in the config for all subsequent reboots.
Example:

ethernet eth0 {
    address "192.0.2.1"
    hw-id "52:54:00:2d:29:19"
    ipv6 {
        address {
        }
    }
    smp-affinity "auto"
    speed "auto"
    hw-id 52:54:00:2d:29:19
}

What I'm noticing is that the migration scripts save all nodes with quotes, but saving in config mode (through vyatta-cfg) results in most nodes not having quotes (mostly just those with spaces have it). Maybe there is a vyatta script that adds any new interfaces to config.boot that runs on each boot that doesn't like these quoted hw-id lines that the migration scripts produce.

Jul 5 2020, 9:08 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot.

I tried reupgrading from 1.3-rolling-202006110117 to 1.3-rolling-202007050117 and the exact same error occurred - on first reboot everything was fine (config.boot was migrated, looked correct, and loaded fine). On 2nd reboot, the exact same thing happened.

Jul 5 2020, 8:42 AM · VyOS 1.3 Equuleus

Jul 4 2020

jjakob added a comment to T2683: no dual stack in system static-host-mapping host-name .

Duplicate of T2627

Jul 4 2020, 9:11 PM

Jun 30 2020

jjakob added a comment to T2664: vyos-hostsd overriding dns forward configuration.

Possible by backporting https://github.com/vyos/vyos-1x/pull/452 and https://github.com/vyos/vyatta-cfg-system/pull/125 though I think some code using Config would need to be modified - add .exists calls before each .return_value(s) - 1.3's vyos.config doesn't require them, 1.2's I think does.

Jun 30 2020, 8:25 PM · VyOS 1.2 Crux
jjakob added a comment to T2664: vyos-hostsd overriding dns forward configuration.

This is already fixed in 1.3

Jun 30 2020, 1:57 PM · VyOS 1.2 Crux

Jun 27 2020

jjakob created T2657: dhcp-server hostfile-update allows any DHCP client to inject an arbitrary hostname into /etc/hosts and pdns-recursor's zones (DNS spoofing as a vector for MITM attacks).
Jun 27 2020, 8:22 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2654: Multiple names unable to be assigned to the same static mapping. .

Will you be doing this change or can I claim it? I'm ready to work on it right now if you prefer.

Jun 27 2020, 7:48 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot.

To clarify, I'm not actually sure the formatting is the reason for the bug - I just observed that it happened. It may have no impact on functionality. The real problem is that something is messing with the hw-id entries, and I don't think it's the migrator scripts, as those weren't executed when it happened. Maybe some legacy Vyatta code.

Jun 27 2020, 7:34 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2654: Multiple names unable to be assigned to the same static mapping. .

Looking at the code, there is a missing error check for when an alias is the same as a static-host-mapping or already existing alias (either of this mapping or any other one). It will require some additional iteration.
Or maybe these should be converted to warnings and not errors, as they don't cause anything to break, just not work as expected?

Jun 27 2020, 7:21 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2654: Multiple names unable to be assigned to the same static mapping. .

I agree, we can make the error message point the user towards using an alias instead. But I don't think doing so is common practice, such things are usually written in docs.

Jun 27 2020, 7:14 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2508: Enable user to configure a LUA script that modifies resolving in PowerDNS.

Maybe the problem was that it exposed a configuration only understood by pdns-recursor, so replacing it with something else would be impossible if we ever considered so? That was the reason for not allowing certain patches in the past.

Jun 27 2020, 7:06 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2655: ConfigError formatting issue.

The reason I do it this way is to comply with the 80-column limit. Any strings separated by whitespace will be transparently concatenated by Python to one string, it requires adding extra braces around the multi-line string.

Jun 27 2020, 7:02 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2655: ConfigError formatting issue.

No, the string concatenation is done by Python (these are not multiple arguments but one argument) so there's nothing ConfigError can do. It's simply a mistake (typo) on my part.

Jun 27 2020, 6:59 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2654: Multiple names unable to be assigned to the same static mapping. .

Yeah, only the first line will be used, the subsequent lines for an already existing IP or hostname will be ignored. pdns-recursor also behaves the same, it logs "not replacing entry" (or something similar, I can't recall) when encountering a entry with a different IP for a hostname already defined, so it behaves the same as getent. You can't add multiple entries for round-robin resolution, hosts has no support for that, if we want that we need to use zone files instead (but those only work for pdns-recursor and not the system, so are not a suitable replacement here, they could be added under the dns forwarding node)

Jun 27 2020, 6:55 AM · VyOS 1.3 Equuleus
jjakob reopened T2654: Multiple names unable to be assigned to the same static mapping. as "Needs testing".

Have you tested that this actually works as intended? The reason I added that check is that each static-host-mapping "inet" address translates to a line in /etc/hosts. The hosts manpage says there should be only one line for each host:

Jun 27 2020, 6:26 AM · VyOS 1.3 Equuleus

Jun 26 2020

jjakob added a comment to T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot.

Migration scripts use vyos.configtree which uses libvyosconfig so it's probably a bug there.

Jun 26 2020, 9:09 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot.
Jun 26 2020, 8:42 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot.

Attached are config.boot post-upgrade(migration) and config.boot pre-migration.
Notice:

  • doubled hw-id lines
  • missing opening and closing curly braces on lines 45, 75-77 (tag nodes)
  • lines 8, 33, 35 are leaf nodes, those shouldn't have opening/closing curly braces after them
  • some things are quoted, some are not
Jun 26 2020, 8:39 AM · VyOS 1.3 Equuleus
jjakob moved T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot from In Progress to Need Triage on the VyOS 1.3 Equuleus board.
Jun 26 2020, 8:16 AM · VyOS 1.3 Equuleus
jjakob reopened T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot as "Open".
Jun 26 2020, 8:15 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot.

Not doing anything regarding the failed load and just rebooting has now hard-baked the eth0-eth2 names into config.boot without me doing anything. So something effectively decided to rename eth1-eth3 to eth0-eth2 and save it to config.boot.

Jun 26 2020, 8:15 AM · VyOS 1.3 Equuleus
jjakob claimed T2519: Broadcast address does not add automatically.
Jun 26 2020, 8:08 AM · VyOS 1.3 Equuleus

Jun 25 2020

jjakob added a comment to T2649: Ensure configration mode scripts conform to coding guidelines.

To be fair, I'm getting frustrated by the layers-upon-layers of new abstractions getting added on old code that doesn't work properly in the first place. I'd much prefer if we just started with a clean slate. I liked @thomas-mangin 's idea of replacing vyatta-cfg completely with our own code, either vyconf or his python daemon. I wouldn't waste time patching up the old backend, just make a decision in one place to replace it completely.

Jun 25 2020, 2:25 PM · VyOS 1.3 Equuleus
jjakob added a comment to T2523: Upgrade from 1.2.5 to 1.3-rolling-202005261512 results in broken network config on second boot.

I think I ran into this today after upgrading from 1.3-rolling-202006110117 to 1.3-rolling-202006241940. My config had eth1-eth3 (as those were the default names created by a previous install of 1.3 somewhere around May) and those worked fine for numerous reboots before this upgrade. The first reboot after adding the new image, everything was fine. The 2nd reboot (actually a power outage) the interfaces were eth0-eth2 on the system, but eth1-eth3 in the config, so the config load failed.

Jun 25 2020, 2:18 PM · VyOS 1.3 Equuleus
jjakob added a comment to T2649: Ensure configration mode scripts conform to coding guidelines.

Keep in mind that the preferred way to implement scripts is, in my mind, the one used by interfaces-tunnel.py: it takes both session and effective configs and compares them, only applying the changes for the differences that are required. get_config_dict just takes the session config and so it requires a complete teardown and re-initialization of any system component that is configured from it (restarting instead of reloading services, deleting interfaces instead of modifying just 1 setting, ...)
I don't consider just get_config_dict as the preferred future way to implement features for that reason, rather it is the interfaces-tunnel that could be made the reference.
get_config_dict could be ran 2 times (once with effective=True) in each script, then the script could compare/make a diff of the 2 dicts, but that's what interfaces-tunnel ConfigurationState does.
Take for example a minor change in the current openvpn code - changing the description of the interface - currently results in a complete service outage (restart). AFAIK all scripts are like this. It didn't use to be that way in Vyatta, most perl scripts compared session and effective configs and just applied the necessary changes.

Jun 25 2020, 1:56 PM · VyOS 1.3 Equuleus
jjakob created T2650: interfaces bridge, bonding: revert back to per-interface membership syntax.
Jun 25 2020, 1:40 PM · VyOS 1.3 Equuleus
jjakob triaged T2648: router-advert: erroneous syslog warning about invalid all-zeros prefix as Low priority.
Jun 25 2020, 10:45 AM · VyOS 1.3 Equuleus
jjakob changed the status of T2155: Cannot set anything on Intel 82599ES 10-Gigabit SFI/SFP+ from Open to Needs testing.

Possibly related to T2205, it might have been fixed since this was reported.

Jun 25 2020, 9:49 AM · VyOS 1.3 Equuleus

Jun 23 2020

jjakob added a comment to T2587: Cannot enable the interface when the MTU is set to less than 1280.

It would be possible to make the scripts check if IPv6 is enabled on the interface (or system?) and make the minimal MTU 1280 in that case. If IPv6 on the interface is disabled or not supported, have it go as low as it can.

Jun 23 2020, 11:07 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2630: Allow Interface MTU over 9000.

This was discussed already in T2404. The problem is that NICs that expose their min/max MTU are rare. None of the NICs I have expose it, neither through sysfs nor through 'ip -d link show'. If I recap the discussion from T2404, there are 2 main ways to solve this:
a) not have any limitations regarding MTU at all and then detect an error when trying to apply the new MTU. This means no way to verify if the new mtu is correct beforehand so it doesn't comply with the verify/apply separation that's prescribed in the developer docs. I described a possible workaround using revert code in T2404.
b) have a mtu detection script that would be ran by udev on every new NIC detection (to support hotplugging NICs) that would determine the min/max mtu with a bruteforce binary search algorythm (try to set a mtu and see if it errors), then record the results in some temporary file that would get read by the config script. The idea was proposed by @thomas-mangin.

Jun 23 2020, 11:04 AM · VyOS 1.3 Equuleus

Jun 22 2020

jjakob changed the subtype of T2627: 'system static-host-mapping' only allows one IP address per hostname, it should allow one IPv4 and one IPv6 simultaneously from "Task" to "Enhancement".
Jun 22 2020, 10:38 AM · VyOS 1.3 Equuleus
jjakob triaged T2627: 'system static-host-mapping' only allows one IP address per hostname, it should allow one IPv4 and one IPv6 simultaneously as Wishlist priority.
Jun 22 2020, 10:37 AM · VyOS 1.3 Equuleus
jjakob added a comment to T1751: DNS server addresses from DHCPv6 are not added to resolv.conf.

This would have been fixed for isc-dhcp-client if T2590 hadn't happened in the process of me working on it, now it requires writing a new dhclient script for the WIDE client.

Jun 22 2020, 9:47 AM · VyOS 1.3 Equuleus
jjakob changed the status of T1751: DNS server addresses from DHCPv6 are not added to resolv.conf, a subtask of T2464: DNS bugs (parent task), from In progress to Blocked.
Jun 22 2020, 9:44 AM · VyOS 1.3 Equuleus
jjakob changed the status of T1751: DNS server addresses from DHCPv6 are not added to resolv.conf from In progress to Blocked.
Jun 22 2020, 9:44 AM · VyOS 1.3 Equuleus
jjakob added a parent task for T2590: DHCPv6 not updating nameservers and search domains since replacing isc-dhcp-client with WIDE dhcp6c: T1751: DNS server addresses from DHCPv6 are not added to resolv.conf.
Jun 22 2020, 9:44 AM · VyOS 1.3 Equuleus
jjakob added a subtask for T1751: DNS server addresses from DHCPv6 are not added to resolv.conf: T2590: DHCPv6 not updating nameservers and search domains since replacing isc-dhcp-client with WIDE dhcp6c.
Jun 22 2020, 9:43 AM · VyOS 1.3 Equuleus
jjakob closed T2054: Changing "system name-server" doesn't update dns forwarding config, neither does "restart dns forwarding", a subtask of T2464: DNS bugs (parent task), as Resolved.
Jun 22 2020, 9:42 AM · VyOS 1.3 Equuleus
jjakob closed T2054: Changing "system name-server" doesn't update dns forwarding config, neither does "restart dns forwarding" as Resolved.

Fixed as part of T2486

Jun 22 2020, 9:42 AM · VyOS 1.3 Equuleus
jjakob closed T2463: DHCP-received nameserver not added to vyos-hostsd, a subtask of T2464: DNS bugs (parent task), as Resolved.
Jun 22 2020, 9:41 AM · VyOS 1.3 Equuleus
jjakob closed T2463: DHCP-received nameserver not added to vyos-hostsd as Resolved.

Fixed as part of T2486

Jun 22 2020, 9:41 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2483: DHCP most likely not restarting pdns_recursor.

The above PR419 did not fix the issue as a wrong pdns-recursor process name was used (its real name is 'pdns-rec/worker'). It was fixed as part of T2486.

Jun 22 2020, 9:40 AM · VyOS 1.3 Equuleus
jjakob closed T2534: pdns-recursor override.conf error, a subtask of T2464: DNS bugs (parent task), as Resolved.
Jun 22 2020, 9:34 AM · VyOS 1.3 Equuleus
jjakob closed T2534: pdns-recursor override.conf error as Resolved.
Jun 22 2020, 9:34 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2564: Extend VyOS to support appliance LCDs.

That's great, I like the config syntax. What does the interface alias do regarding the display? Maybe it could be read from the interface description? Then again the display name needs to be short as the displays are small and the interface description can be longer. Maybe default to reading the alias from the interface description and override it with the display alias.
For starting services in 1.3 we use systemd, it's simple to create new service files in src/systemd that will be put in /lib/systemd/system. Just make sure they're started manually by the config script and not as part of a target (just creating a service file without the Install section should ensure that).

Jun 22 2020, 9:33 AM · VyOS 1.2 Crux (VyOS 1.2.7), VyOS 1.3 Equuleus

Jun 19 2020

jjakob added a comment to T2564: Extend VyOS to support appliance LCDs.

Fair point. In that case I agree with not including a raw config option.
As for the errors when installing vyos-1x, c-po already pointed out why this occurs.For this reason I don't rebase on upstream while working on a set of changes locally, I always try to keep the installed iso and local git state as much together as possible. I also run docker from the vyos-build repo and have the vyos-1x repo dir in vyos-build/packages/vyos-1x (where the included scripts/build-packages would put it) so I can just docker run and build without having to copy any files anywhere, just scp the built deb into the VM.

Jun 19 2020, 7:21 PM · VyOS 1.2 Crux (VyOS 1.2.7), VyOS 1.3 Equuleus
jjakob added a comment to T2564: Extend VyOS to support appliance LCDs.

@c-po I tend to agree to have as much predefined templates, but I'd leave the option to have a custom config if the user wants to, I don't like imposing artificial limitations. We already allow custom options with dhcp-server, openvpn..., why not allow specifying your own conf file for the driver section to include? Some things are impossible without either this or going with approach 2 by exposing absolutely all configurable driver options through the config. I'd prefer that, but if it results in too much options/config size, the alternative is as I described. But in the long term I think approach 2 would be the best.

Jun 19 2020, 9:16 AM · VyOS 1.2 Crux (VyOS 1.2.7), VyOS 1.3 Equuleus

Jun 18 2020

jjakob added a comment to T2564: Extend VyOS to support appliance LCDs.

I'd go with approach 3, if 2 is too complex. Have a predefined set of appliances that can be configured by a single option. For all other scenarios, one of:
a) have the user supply the path to a file in /config that the script will include in lcdd.conf as-is (as including a multi-line string in the config directly is very awkward and unreadable).
b ) we could for example make a /config/lcdproc directory, containing a template conf file that would be used if the user selected that option in config, still starting the daemon via the config.
c) or split out the individual driver sections with defaults (as in lcdd.conf) into many files in /config/lcdproc/$drivername.conf that can be edited by the user, and have a config option that selects which driver to use, and have the user edit the file to configure it.

Jun 18 2020, 9:21 PM · VyOS 1.2 Crux (VyOS 1.2.7), VyOS 1.3 Equuleus

Jun 17 2020

jjakob added a comment to T2582: Script daemon to offload processing during commit.

There is another use of is_tag/is_leaf in python/vyos/validate.py is_member, as it can work on both bridge and bond members, and they have different syntax for member interfaces. It would only be possible to hardcode each case and remove the use of is_*

Jun 17 2020, 9:02 AM · VyOS 1.3 Equuleus

Jun 14 2020

jjakob added a comment to T2594: Missing firmware for iwlwifi.

This is the users dmesg with failed firmware load

[   21.951100] iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[   21.951932] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000-6.ucode failed with error -2
[   21.951961] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000-5.ucode failed with error -2
[   21.951982] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000-4.ucode failed with error -2
[   21.951985] iwlwifi 0000:03:00.0: no suitable firmware found!
[   21.958303] iwlwifi 0000:03:00.0: minimum version required: iwlwifi-6000-4
[   21.967817] iwlwifi 0000:03:00.0: maximum version supported: iwlwifi-6000-6
[   21.975992] iwlwifi 0000:03:00.0: check git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
Jun 14 2020, 11:10 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2594: Missing firmware for iwlwifi.

I suggested to install the firmware-iwlwifi package from the debian repos as part of the debugging process. Of course this isn't a supported way for end users, this is known for a long time, and you must take care to not run apt-get upgrade, dist-upgrade or install a package that conflicts or overrides a vyos package. It is safe to install packages that don't conflict.

Jun 14 2020, 10:37 AM · VyOS 1.3 Equuleus
jjakob added a comment to T2594: Missing firmware for iwlwifi.

Non-free firmware was added by default in crux: T15

Jun 14 2020, 9:04 AM · VyOS 1.3 Equuleus
jjakob triaged T2594: Missing firmware for iwlwifi as Normal priority.
Jun 14 2020, 9:01 AM · VyOS 1.3 Equuleus

Jun 12 2020

jjakob added a comment to T421: VyOS lacks DHCPv6-PD (Prefix delegation) length / IA_PD support.

I have no need for PD for now, so this isn't an important issue for me. I just noticed that WIDE didn't run any scripts, so right now it can't set any nameservers obtained from DHCP. If anyone needs that, I guess it would be simplest to write a script (by using the existing dhclient-script hooks as a guide) just for vyos-hostsd, since PD is already done with WIDE. Switching to ISC would mean we'd need to improve that PD script I linked to, since it only supports a single interface, and we need multiple.

Jun 12 2020, 12:26 PM · VyOS 1.3 Equuleus
jjakob added a comment to T421: VyOS lacks DHCPv6-PD (Prefix delegation) length / IA_PD support.

@jack9603301 you're not the one that made the choice so you can't know why it was made.
ISC-DHCP can do prefix delegation too (not by itself, but with a helper script that others already made: https://wiki.debian.org/IPv6PrefixDelegation ) so that's not why WIDE was chosen.

Jun 12 2020, 10:40 AM · VyOS 1.3 Equuleus
jjakob added a comment to T421: VyOS lacks DHCPv6-PD (Prefix delegation) length / IA_PD support.

What was the reason for choosing WIDE dhcp6c and not keeping isc-dhcp? This has now caused T2590 which will require making a new set of dhclient scripts just for WIDE, so we'll be maintaining 2 separate scripts. If it was due to the support for prefix length hint, isc-dhcp has added that too, as I mentioned in this task before https://phabricator.vyos.net/T421#49842

Jun 12 2020, 10:07 AM · VyOS 1.3 Equuleus
jjakob triaged T2590: DHCPv6 not updating nameservers and search domains since replacing isc-dhcp-client with WIDE dhcp6c as High priority.
Jun 12 2020, 10:02 AM · VyOS 1.3 Equuleus

Jun 11 2020

jjakob changed the status of T2534: pdns-recursor override.conf error from Confirmed to In progress.
Jun 11 2020, 8:19 AM · VyOS 1.3 Equuleus
jjakob changed the status of T2534: pdns-recursor override.conf error, a subtask of T2464: DNS bugs (parent task), from Confirmed to In progress.
Jun 11 2020, 8:19 AM · VyOS 1.3 Equuleus
jjakob added a subtask for T2464: DNS bugs (parent task): T2534: pdns-recursor override.conf error.
Jun 11 2020, 8:19 AM · VyOS 1.3 Equuleus
jjakob added a parent task for T2534: pdns-recursor override.conf error: T2464: DNS bugs (parent task).
Jun 11 2020, 8:19 AM · VyOS 1.3 Equuleus
jjakob changed the status of T2521: Need to restart pdns-recursor to check new entries in /etc/hosts from Open to In progress.
Jun 11 2020, 8:18 AM · VyOS 1.3 Equuleus
jjakob changed the status of T2521: Need to restart pdns-recursor to check new entries in /etc/hosts, a subtask of T2464: DNS bugs (parent task), from Open to In progress.
Jun 11 2020, 8:18 AM · VyOS 1.3 Equuleus
jjakob added a subtask for T2464: DNS bugs (parent task): T2521: Need to restart pdns-recursor to check new entries in /etc/hosts.
Jun 11 2020, 8:17 AM · VyOS 1.3 Equuleus
jjakob added a parent task for T2521: Need to restart pdns-recursor to check new entries in /etc/hosts: T2464: DNS bugs (parent task).
Jun 11 2020, 8:17 AM · VyOS 1.3 Equuleus
jjakob updated the task description for T2583: vyos-hostsd improvements (partial rewrite).
Jun 11 2020, 5:12 AM · VyOS 1.3 Equuleus
jjakob changed the status of T2583: vyos-hostsd improvements (partial rewrite) from Open to In progress.
Jun 11 2020, 5:11 AM · VyOS 1.3 Equuleus

Jun 10 2020

jjakob added a comment to T2216: Containerized third-party applications for VyOS.

+1 for this, it would be very useful for a lot of use cases, we wouldn't need to add everything to vyos-1x and the config syntax, but users could add "missing" services on their own. For example T2195

Jun 10 2020, 8:34 PM · VyOS 1.3 Equuleus
jjakob changed the status of T2054: Changing "system name-server" doesn't update dns forwarding config, neither does "restart dns forwarding", a subtask of T2464: DNS bugs (parent task), from Needs testing to In progress.
Jun 10 2020, 8:08 PM · VyOS 1.3 Equuleus
jjakob changed the status of T2054: Changing "system name-server" doesn't update dns forwarding config, neither does "restart dns forwarding" from Needs testing to In progress.
Jun 10 2020, 8:08 PM · VyOS 1.3 Equuleus
jjakob changed the status of T1751: DNS server addresses from DHCPv6 are not added to resolv.conf, a subtask of T2464: DNS bugs (parent task), from Needs testing to In progress.
Jun 10 2020, 8:07 PM · VyOS 1.3 Equuleus
jjakob changed the status of T1751: DNS server addresses from DHCPv6 are not added to resolv.conf from Needs testing to In progress.
Jun 10 2020, 8:07 PM · VyOS 1.3 Equuleus
jjakob closed T2553: Regression: set interface ethN vif-s nnnn does not commit on 1.3-rolling-202006050621 as Resolved.
Jun 10 2020, 6:29 PM · VyOS 1.3 Equuleus

Jun 8 2020

jjakob changed the status of T2279: Router resolves as 127.0.1.1 when using Router's Recursive DNS, a subtask of T2464: DNS bugs (parent task), from Open to In progress.
Jun 8 2020, 7:29 PM · VyOS 1.3 Equuleus
jjakob changed the status of T2279: Router resolves as 127.0.1.1 when using Router's Recursive DNS from Open to In progress.
Jun 8 2020, 7:29 PM · VyOS 1.3 Equuleus
jjakob added a comment to T2564: Extend VyOS to support appliance LCDs.

This has been on my extended todo list for a long time now, but there were always higher priority issues. I'm glad someone is working on it!

Jun 8 2020, 11:10 AM · VyOS 1.2 Crux (VyOS 1.2.7), VyOS 1.3 Equuleus

Jun 7 2020

jjakob added a comment to T2550: OpenVPN: IPv4 not working in client mode.

@mrozentsvayg look at https://community.openvpn.net/openvpn/ticket/360 (this is documented in the code comment right above your change as well). OpenVPN on Linux in server mode with standard protocols doesn't listen on IPv6, just IPv4. We need to force it to bind to a IPv6 socket using these undocumented *6 protocols, then it'll listen on both IPv4 and IPv6. This wouldn't be necessary if OpenVPN listened on IPv6 with the default protocols or autodetected whether the local or remote IPs are v4 or v6 and chose the correct socket type, but it doesn't. Complain to the above ticket 360. We're just working within the limitations imposed by OpenVPN.

Jun 7 2020, 7:56 AM · VyOS 1.3 Equuleus

Jun 6 2020

jjakob added a comment to T2554: Failsafe reboot timer.

Can you ask the user if you want to start the migration failure fallback mechanism on the first boot of the new image when upgrading, and if the user chooses to enable this mechanism, you should let the user select an old secure image (execute the mechanism only on the first boot)?

Jun 6 2020, 8:37 PM · VyOS 1.3 Equuleus