Re: [RFC/RFT] projects/ipsec
On 27 Dec 2016, at 10:18, Andrey V. Elsukov wrote: So, if there will no objection, I'll merge projects/ipsec into head/ within two weeks. I still keep seeing almost daily changes to the branch and am having a hard time to convince myself to do a proper review that way. I would very much prefer this to be (a) either become stable first and then give people a chance, or (b) see if you can break out small self-contained changes put them up into review and merge them piece by piece making it a lot easier to convince ourselves that things still look good. /bz ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
On 09.01.2017 14:38, Bjoern A. Zeeb wrote: On 27 Dec 2016, at 10:18, Andrey V. Elsukov wrote: So, if there will no objection, I'll merge projects/ipsec into head/ within two weeks. I still keep seeing almost daily changes to the branch and am having a hard time to convince myself to do a proper review that way. I would very much prefer this to be (a) either become stable first and then give people a chance, or (b) see if you can break out small self-contained changes put them up into review and merge them piece by piece making it a lot easier to convince ourselves that things still look good. Hi, yes, I hope I have fixed all found issues, now I will test the changes in our environment. I prefer the first way (a), because another splitting into small pieces requires a lot of time that I don't have. So, if you want to do a review, you are welcome :) Now I'll be focused on testing with different IKEd, documenting the changes, and fixing possible NO_INET/NO_INET6 related build issues. -- WBR, Andrey V. Elsukov ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 183148] [patch] add getaddrinfo(1) tool from NetBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183148 Eric van Gyzen changed: What|Removed |Added CC||vangy...@freebsd.org --- Comment #2 from Eric van Gyzen --- I have wanted a tool like this a few times over the years. This should still be considered. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 183148] [patch] add getaddrinfo(1) tool from NetBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183148 Lohith Bellad changed: What|Removed |Added CC||lohith...@gmail.com --- Comment #3 from Lohith Bellad --- I will adapt the patch to HEAD and test it. Thanks, Lohith -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Gigabit USB NIC for RPi
Hello again, thanks a lot for you reply. On 08.01.2017 22:57, Mark Martinec wrote: > 2017-01-08 20:33, diffusae wrote: >> Hi! >> >> I am looking for an compatible USB2Gigabit ethernet adapter for a RPi. >> That should work with the ISO Images of FreeBSD 11 stable (armv6). >> >> Do you have any suggestions? > > Raspberry Pi model 3 B and its predecessors only have USB 2.0 (not 3.0), > which (according to Wikipedia) only goes up to about 280 Mbit/s, > so an adapter to a gigabit ethernet is not particularly useful. > > You are not the only one to regret that RPi 3 did not introduce > a proper Gb ethernet interface. > > Mark Yes, I know this and it's a pity. You're right, it isn't really useful. But I also have a Linux Box (RPi 2) with a Gigabit WLAN Interface. It has a bandwidth about 200 Mbit/s or more, this is a bit higher than the internal USB NIC (100 Mbit/s). Especially if you stream HD videos, you could measure this difference. So, I only like to know which gigabit ethernet USB NIC would work with FreeBSD 11 and the Raspberry Pi? Thanks again Regards, Reiner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 189219] [dummynet] [patch] using dummynet on sparc64 and configuring a pipe is an insta-panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189219 --- Comment #9 from commit-h...@freebsd.org --- A commit references this bug: Author: marius Date: Mon Jan 9 20:51:51 UTC 2017 New revision: 311817 URL: https://svnweb.freebsd.org/changeset/base/311817 Log: In dummynet(4), random chunks of memory are casted to struct dn_*, potentially leading to fatal unaligned accesses on architectures with strict alignment requirements. This change fixes dummynet(4) as far as accesses to 64-bit members of struct dn_* are concerned, tripping up on sparc64 with accesses to 32-bit members happening to be correctly aligned there. In other words, this only fixes the tip of the iceberg; larger parts of dummynet(4) still need to be rewritten in order to properly work on all of !x86. In principle, considering the amount of code in dummynet(4) that needs this erroneous pattern corrected, an acceptable workaround would be to declare all struct dn_* packed, forcing compilers to do byte-accesses as a side-effect. However, given that the structs in question aren't laid out well either, this would break ABI/KBI. While at it, replace all existing bcopy(9) calls with memcpy(9) for performance reasons, as there is no need to check for overlap in these cases. PR: 189219 MFC after:5 days Changes: head/sys/netpfil/ipfw/ip_dummynet.c -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 215874] [patch] [icmp] [mbuf_tags] teach icmp_error() optionally keep original packet's mbuf_tags
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215874 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending
tl;dir --> you get to keep your igbX devices(thanks jhb), no POLA violations this week. I've updated sys/dev/e1000 at svn R311849 to match Matt Macy's work on IFLIB in the kernel. At this point, the driver deviates from Intel's code dramatically and you now get to yell directly into the freebsd-net@ megaphone for things that I may have broken. man page updates are coming up next. Please let us know if this revision has made things better, worse or none-of-the above on whatever Intel Gigabit NIC you happen to have lying around. sean On 01/05/17 20:18, Sean Bruno wrote: > tl;dr --> igbX devices will become emX devices > > We're about to commit an update to sys/dev/e1000 that will implement and > activate IFLIB for em(4), lem(4) & igb(4) and would appreciate all folks > who can test and poke at the drivers to do so this week. This will have > some really great changes for performance and standardization that have > been bouncing around inside of various FreeBSD shops that have been > collaborating with Matt Macy over the last year. > > This will implement multiple queues for certain em(4) devices that are > capable of such things and add some new sysctl's for you to poke at in > your monitoring tools. > > Due to limitations of device registration, igbX devices will become emX > devices. So, you'll need to make a minor update to your rc.conf and > scripts that manipulate the network devices. > > UPDATING will be bumped to reflect these changes. > > MFC to stable/11 will have a legacy implementation that doesn't use > IFLIB for compatibility reasons. > > A documentation and man page update will follow in the next few days > explaining how to work with the changed driver. > > sean > > bcc net@ current@ re@ > > > > > signature.asc Description: OpenPGP digital signature
