search for: fmyhr

https://bugzilla.netfilter.org/show_bug.cgi?id=1243 Bug ID: 1243 Summary: Wildcard can only include <16 files Product: nftables Version: unspecified Hardware: x86_64 OS: All Status: NEW Severity: normal Priority: P5 Component: nft Assignee: pablo at netfilter.org

https://bugzilla.netfilter.org/show_bug.cgi?id=925 Summary: icmp: ICMPv4 types are not supported Product: nftables Version: unspecified Platform: x86_64 OS/Version: Debian GNU/Linux Status: NEW Severity: normal Priority: P5 Component: nft AssignedTo: pablo at netfilter.org ReportedBy:

https://bugzilla.netfilter.org/show_bug.cgi?id=1404 Bug ID: 1404 Summary: Problems with dynamically managing interval sets with auto-merge Product: nftables Version: unspecified Hardware: All OS: Debian GNU/Linux Status: NEW Severity: blocker Priority: P5 Component:

https://bugzilla.netfilter.org/show_bug.cgi?id=1185 Bug ID: 1185 Summary: counter flag proposal for sets and maps Product: nftables Version: unspecified Hardware: x86_64 OS: All Status: NEW Severity: enhancement Priority: P5 Component: nft Assignee: pablo at netfilter.org

Hi list, I'm hoping someone can help me understand when to use IndirectData. Quoting the manual: IndirectData = <yes|no> (no) This option specifies whether other tinc daemons besides the one you specified with ConnectTo can make a direct connection to you. This is especially useful if you are behind a firewall and it is impossible to make a connection from the outside to your tinc

On 02/10/2018 17:02, Michael Munger wrote: > there might be another way to skin that cat. Additional complexity, but you could set up *four* tinc VPNs: 1) admin VPN 2) site A VPN 3) site B VPN 4) site C VPN Each of your client machines would then participate in 2 VPNs: the admin VPN and the appropriate site VPN. Each site VPN is NOT a subnet of the admin VPN, but its own separate network.

Hi, If host B is not directly reachable from host A so that tinc packets flow: A -> (C) -> B where C is a 3rd host that both A and B can reach, which public key does A use when sending these packets to B? C's public key, or B's public key? In other words, are these packets encrypted hop-by-hop, or end-to-end? Does it make a difference whether legacy or SPTPS protocol is being

On 2019/11/24 16:52, Frank Myhr wrote: > When tinc says it "disabled" the old key, did it it in fact *delete* it? > I haven't found it anywhere on the system. Crisis averted. Turns out I have another local host whose public key is known by my remote hosts. So I can use this 2nd local host to update host_on_existing_net's public key on the remote hosts and all should be

QEMU's default qcow2 L2 cache size is too small for large images (and small cluster sizes), resulting in very bad performance. https://blogs.igalia.com/berto/2015/12/17/improving-disk-io-performance-in-qemu-2-5-with-the-qcow2-l2-cache/ shows huge performance hit for a 20GB qcow2 with default 64kB cluster size: L2 Cache, MiB Average IOPS 1 (default) 5100 1.5

Well, I goofed and entered the wrong network name while trying to set up keys for a new network: # tincd -n existing_net -K Generating 2048 bits keys: ............................................+++++ p ..................................................................+++++ q Done. Please enter a file to save private RSA key to [/etc/tinc/existing_net/rsa_key.priv]: Warning: old key(s) found