[Bug 199174] em tx and rx hang
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174 --- Comment #20 from david.kel...@litchis.fr --- (In reply to Sean Bruno from comment #19) 10.1-RELEASE-p10 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Same NIC name to MAC mapping on FreeBSD
On 01/07/2015 05:42, Julian Elischer wrote: > On 7/1/15 6:56 AM, Adrian Chadd wrote: >> Hi, >> >> If we don't support this as part of the interface renaming stuff, it >> would certainly be good to. >> >> >> a- >> >> >> On 29 June 2015 at 21:36, Wei Hu wrote: -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- n...@freebsd.org] On Behalf Of Paul S. Sent: Monday, June 29, 2015 7:53 PM To: freebsd-net@freebsd.org Subject: Re: Same NIC name to MAC mapping on FreeBSD On my production systems, I've never seen it deviate without hardware changes. Are you seeing otherwise? >>> In Hyper-V, if say three NICs were assigned to the VM, I got >>> following mapping >>> Initially: >>> >>> Hn0 -> MAC 0 >>> Hn1 -> MAC 1 >>> Hn2 -> MAC2 >>> >>> Then if I remove the NIC with MAC 1 and reboot, I want the other two >>> interfaces to keep the same >>> Names instead of reassigning hn1 to MAC2. This is a requirement from >>> virtual appliance >>> Vendor to retain such mappings. I am wondering if there is any way >>> to do this without >>> Asking customer or manually editing any config files. > do interface arrivals show up in devd? if so they could be renamed on > arrival > I vaguely remember being able to do this some years ago but I can't > remember the details. This sounds horribly like the Linux solution, where I always have to refind eth0 and eth1 because the assignments in the devd config. Swapping a disk to another system, changes MACs and looses the devices. :( But I've been bitten so often now, that I do know where to look. Bhyve virtualisation and disk image replication is one of the cases where this comes into play. --WjW ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: rc settings for ipv6 in 9.3?
On 01/07/2015 06:40, Kevin Oberman wrote: > On Tue, Jun 30, 2015 at 5:29 PM, wrote: > >> I just got a /56 block of ipv6 addresses today and I'm trying to figure >> out how to use it. >> >> Before I go rebooting my server I wanted to ask if the information in the >> handbook "https://www.freebsd.org/doc/handbook/network-ipv6.html"; is >> correct >> for 9.3-p14. >> >> I have a static address for my server and I've been given the static >> address of the router. So I should just be able to set (in my rc.conf) >> ifconfig_bce0_ipv6 and ipv6_defaultrouter, correct? >> >> Or do I really need these two lines from the handbook?: >> ifconfig_bce0_ipv6="inet6 accept_rtadv" >> rtsold_enable="YES" >> >> Also, can someone translate this statement from my provider for me: >> "Note: [provider] is routing 2607:f758:2280::/56 to 2607:f758:2280::4/64" >> >> BTW, is the term "netmask" ever used in IPv6? I thought "prefixlen" was >> the term and "netmask" was for v4 only? >> >> Thanks for any help! >> -- >> Kevin P. Nealhttp://www.pobox.com/~kpn/ >> > > No, If your system has a static address (and a server should have one), you > don't need SLAAC or Router Solicitation. You just need to set the address: > ifconfig_bce0_ipv6="inet6 2607:f758:2280::n/64" and > ipv6_defaultrouter="Router address". > > Netmasks are obsolete everywhere and really should not be used. CIDR > addressing has been the standard for a quarter century. Netmasks really > should not be used for either IPv4 or IPv6. > > I am unable to translate the statement from the provider with certainty. I > am guessing that the /64 2607:f758:2280::/64 is used by their router with > 2607:f758:2280::4 as the address on their router(s). The remainder of the > /56 is yours but I could not swear to that. > > You will probably want more than one /64 for different purposes. Other than > externally accessible servers, you should put systems in a different /64 > and spread them at random around that space if they are statically > addressed. (I don't recommend for or against statically addressing, though.) This is different from what was usually done in IPv4, because there seperate ip-numbers where used on links... I've even seen ISP use RFC-1918 address on the links. What ISP usually do for IPv6 is assign a block (/48 /56 or /64) to a customer, and then take a smaller block from that to build the link between ISP and customer... The smaller block in this case being 2607:f758:2280::/64 Routing really works in cases like this without much trouble, because IPv6 uses shortes-prefix-first for route selection. Next to the fact that both routers have that smaller block on their interfaces. If the endpoint is actually a server, then forget about the next part, because you're going to terminate the whole block on that server. Now trouble starts if you DID NOT SUBNET behind the customer router, and have more devices on the link between ISP and customer. Then every internal device needs to be told that the linking network needs to go thru the router... Either by starting a route announcement system, on all systems (eg. route6d) or add them manual to the routing table of the client systems. For smaller networks the later is faster, but harder to maintain in case of renumbering. All this is prevented by subnetting the customer network also in /64 blocks... And then things just work, and the customer router does the job. :) The ISP does not have this problem since the full block is routed to the aggregation router te customer is connected to. And that router knows about the smaller linking network. --WjW ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Same NIC name to MAC mapping on FreeBSD
On Wed, Jul 01, 2015 at 11:42:43AM +0800, Julian Elischer wrote: > On 7/1/15 6:56 AM, Adrian Chadd wrote: > > Hi, > > > > If we don't support this as part of the interface renaming stuff, it > > would certainly be good to. > > > > > > a- > > > > > > On 29 June 2015 at 21:36, Wei Hu wrote: > >>> -Original Message- > >>> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- > >>> n...@freebsd.org] On Behalf Of Paul S. > >>> Sent: Monday, June 29, 2015 7:53 PM > >>> To: freebsd-net@freebsd.org > >>> Subject: Re: Same NIC name to MAC mapping on FreeBSD > >>> > >>> On my production systems, I've never seen it deviate without hardware > >>> changes. > >>> > >>> Are you seeing otherwise? > >>> > >> In Hyper-V, if say three NICs were assigned to the VM, I got following > >> mapping > >> Initially: > >> > >> Hn0 -> MAC 0 > >> Hn1 -> MAC 1 > >> Hn2 -> MAC2 > >> > >> Then if I remove the NIC with MAC 1 and reboot, I want the other two > >> interfaces to keep the same > >> Names instead of reassigning hn1 to MAC2. This is a requirement from > >> virtual appliance > >> Vendor to retain such mappings. I am wondering if there is any way to do > >> this without > >> Asking customer or manually editing any config files. > do interface arrivals show up in devd? if so they could be renamed on > arrival > I vaguely remember being able to do this some years ago but I can't > remember the details. I believe they do, yes. In fact I seem to remember a discussion on this in the last year and someone shared either a devd or an rc.d script to ensure static NIC names, however searching the web archvies I couldn't find it Regards, Gary ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
IPFW divert and suricata
Hello, I hope this is a good list to post this on, I have a feeling the solution is somewhere obscure in the networking layer. I've set up an IPS system, using: * FreeBSD 10.1 (guest OS, plenty of RAM/CPU) * ESXi 5.5 (host OS, using Intel X520 10Gb cards. Not overloaded, all graphs show it's got plenty of RAM/CPU spare at all times) * vmxnet3 drivers * ipfw (very small ruleset, basically just a divert rule) * suricata, in ipfw divert mode I'm having a couple of major issues. The first is that every so often, even with relatively little traffic, the load on the box suddenly spikes and pings to a neighbouring router (via the divert rule) go from <1ms to >300ms. Generally this resolves itself after a few minutes, although last night it went on for an hour until I restarted ipfw and suricata. The second is that if I do a large download, eg a FreeBSD ISO, the download usually hangs somewhere between 5MB and 100MB through. I can see traffic trying to get through on neighbouring routers, it's just the interface with the divert to suricata where they disappear into a black hole. The connection speed is around 50Mb, btw. Now it's possible it's suricata being weird, but there's nothing untoward in its events and stats logs, and if I replay the traffic from a pcap file then suricata processes everything fine (a pcap taken over a 90s period during a slowdown is processed in under a second). So my guess is that if suricata takes slightly longer than normal to process a packet, something in the networking or ipfw divert system is tripping itself up. Maybe a queue is filling up? I've set net.inet.ip.fw.dyn_buckets=16384, and done an ipfw flush, but net.inet.ip.fw.curr_dyn_buckets is stubbornly sticking at 256: have I done something wrong? Other tunables I've set are: kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.point_to_point=0 kern.random.sys.harvest.interrupt=0 kern.ipc.soacceptqueue=1024 Can anyone suggest either tests to see what might be going wrong, or tunables to help things run smoother? Both myself and a colleague have used FreeBSD for over 15 years, and never quite seen anything like it. Many thanks, Oliver. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Same NIC name to MAC mapping on FreeBSD
Gary Palmer gpalmer at freebsd.org wrote: On Wed, Jul 01, 2015 at 11:42:43AM +0800, Julian Elischer wrote: > I vaguely remember being able to do this some years ago but I can't > remember the details. I believe they do, yes. In fact I seem to remember a discussion on this in the last year and someone shared either a devd or an rc.d script to ensure static NIC names, however searching the web archvies I couldn't find it https://lists.freebsd.org/pipermail/freebsd-net/2014-December/040533.html Be sure to read all the way to the end, some things that appeared to work initially... did not. This has come up enough that we should probably add it to the Advanced Networking chapter of the Handbook. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 199174] em tx and rx hang
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174 Sean Bruno changed: What|Removed |Added Status|New |In Progress --- Comment #21 from Sean Bruno --- (In reply to david.keller from comment #20) oh, I see. Changes to em(4) have not propagated to the releng/10.1 branch and won't appear in an installable version until 10.2r https://svnweb.freebsd.org/base/releng/10.1/?view=log vs https://svnweb.freebsd.org/base/stable/10/sys/dev/e1000/?view=log so until 10.2r is out, you could apply r283504 and r28 to see if the problem goes away for you, and if not apply r284522 and test as well. Is this something you can do? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 162153] [em] intel em driver 7.2.4 don't compile
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162153 Sean Bruno changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress |Closed --- Comment #2 from Sean Bruno --- Current em(4) driver version in freebsd *is* "7.4.2" on head and "7.3.7" on the stable/8 branch. These are the most recent versions from Intel that are available for this driver. Hopefully these are working for you. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPFW divert and suricata
On Wed, Jul 1, 2015 at 3:15 PM, Oliver Humpage wrote: > > Hello, > > I hope this is a good list to post this on, I have a feeling the solution > is somewhere obscure in the networking layer. > > I've set up an IPS system, using: > > * FreeBSD 10.1 (guest OS, plenty of RAM/CPU) > * ESXi 5.5 (host OS, using Intel X520 10Gb cards. Not overloaded, all > graphs show it's got plenty of RAM/CPU spare at all times) > * vmxnet3 drivers > * ipfw (very small ruleset, basically just a divert rule) > * suricata, in ipfw divert mode > > I'm having a couple of major issues. > > The first is that every so often, even with relatively little traffic, the > load on the box suddenly spikes and pings to a neighbouring router (via the > divert rule) go from <1ms to >300ms. Generally this resolves itself after a > few minutes, although last night it went on for an hour until I restarted > ipfw and suricata. > typical problems with divert sockets are 1. if the interface has offloads (checksums, tso, etc.) enabled, packets may be moved up and down with invalid checksums resulting in all sort of odd behaviours 2. likewise if there are huge segments (virtual nics often pass up and down up to 64k in one shot) the divert socket is unable to handle them and either truncates or drops disabling all accelerations and setting the mtu to 1500 or so usually fixes the above two. 3. divert probably loses important context on the packets (e.g. incoming or outgoing interface) so when traffic is reinjected bad things occur 4. performancewise, moving traffic back and forth to userspace is a bad idea. For the latter two, you might be better off using netmap on vmxnet3 (in emulated mode, also disabling offloads), and if i remember well a couple of years ago there were efforts to use suricata on top of netmap. Worst case, you can just use the netmap-enabled libpcap. cheers luigi The second is that if I do a large download, eg a FreeBSD ISO, the download > usually hangs somewhere between 5MB and 100MB through. I can see traffic > trying to get through on neighbouring routers, it's just the interface with > the divert to suricata where they disappear into a black hole. The > connection speed is around 50Mb, btw. > > Now it's possible it's suricata being weird, but there's nothing untoward > in its events and stats logs, and if I replay the traffic from a pcap file > then suricata processes everything fine (a pcap taken over a 90s period > during a slowdown is processed in under a second). So my guess is that if > suricata takes slightly longer than normal to process a packet, something > in the networking or ipfw divert system is tripping itself up. Maybe a > queue is filling up? > > I've set net.inet.ip.fw.dyn_buckets=16384, and done an ipfw flush, but > net.inet.ip.fw.curr_dyn_buckets is stubbornly sticking at 256: have I done > something wrong? Other tunables I've set are: > > kern.random.sys.harvest.ethernet=0 > kern.random.sys.harvest.point_to_point=0 > kern.random.sys.harvest.interrupt=0 > kern.ipc.soacceptqueue=1024 > > Can anyone suggest either tests to see what might be going wrong, or > tunables to help things run smoother? Both myself and a colleague have used > FreeBSD for over 15 years, and never quite seen anything like it. > > Many thanks, > > Oliver. > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 150249] [ixgbe] Media type detection broken
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=150249 Sean Bruno changed: What|Removed |Added Assignee|freebsd-net@FreeBSD.org |e...@freebsd.org --- Comment #2 from Sean Bruno --- A casual look over ixgbe/if_ix.c seems to show that a lot of changes in the optics detection have been made. I suspect that this ticket is mostly deprecated, but I'm unclear if its been fully resolved. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 170267] [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentional no-op
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=170267 Sean Bruno changed: What|Removed |Added Assignee|freebsd-net@FreeBSD.org |e...@freebsd.org --- Comment #2 from Sean Bruno --- Hrm ... currently, its not even defined to le32dec() in head. ixgbe_osdep.h: /* XXX these need to be revisited */ #define IXGBE_CPU_TO_LE32 htole32 #define IXGBE_LE32_TO_CPUS(x) #define IXGBE_CPU_TO_BE16 htobe16 #define IXGBE_CPU_TO_BE32 htobe32 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPFW divert and suricata
On 1 Jul 2015, at 15:31, Luigi Rizzo wrote: > For the latter two, you might be better off using netmap > on vmxnet3 (in emulated mode, also disabling offloads), > and if i remember well a couple of years ago there were > efforts to use suricata on top of netmap. > Worst case, you can just use the netmap-enabled libpcap. Looks like netmap support has been finished and will be in version 2.1 of Suricata, so that's promising. For now I'll try turning off all the hardware offloads and see what happens. > 3. divert probably loses important context on the packets >(e.g. incoming or outgoing interface) so when traffic is >reinjected bad things occur Would specifying a reinject rule (eg a "pass all") help, do you think? And/or having different divert rules for incoming/outgoing? I had assumed it wouldn't, but I'm not an expert. Many thanks for replying, Oliver. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [Bug 200210] adding vtnet to bridge results to kernel panic
Hi Kristof, Thanks for fixing this! Could you MFC the fix? On 06/13/15 22:39, bugzilla-nore...@freebsd.org wrote: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200210 --- Comment #1 from commit-h...@freebsd.org --- A commit references this bug: Author: kp Date: Sat Jun 13 19:39:22 UTC 2015 New revision: 284348 URL: https://svnweb.freebsd.org/changeset/base/284348 Log: Fix panic when adding vtnet interfaces to a bridge vtnet interfaces are always in promiscuous mode (at least if the VIRTIO_NET_F_CTRL_RX feature is not negotiated with the host). if_promisc() on a vtnet interface returned ENOTSUP although it has IFF_PROMISC set. This confused the bridge code. Instead we now accept all enable/disable promiscuous commands (and always keep IFF_PROMISC set). There are also two issues with the if_bridge error handling. If if_promisc() fails it uses bridge_delete_member() to clean up. This tries to disable promiscuous mode on the interface. That runs into an assert, because promiscuous mode was never set in the first place. (That's the panic reported in PR 200210.) We can only unset promiscuous mode if the interface actually is promiscuous. This goes against the reference counting done by if_promisc(), but only the first/last if_promic() calls can actually fail, so this is safe. A second issue is a double free of bif. It's already freed by bridge_delete_member(). PR:200210 Differential Revision:https://reviews.freebsd.org/D2804 Reviewed by:philip (mentor) Changes: head/sys/dev/virtio/network/if_vtnet.c head/sys/net/if_bridge.c ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 175864] [re] Intel MB D510MO, onboard ethernet not working after update to 9.1 [regression]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175864 Sean Bruno changed: What|Removed |Added CC||sbr...@freebsd.org, ||yong...@freebsd.org --- Comment #3 from Sean Bruno --- This card should be working now as far as I know. Adding Pyun for commentary. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Sequence number handling issue with TCP data and FIN flag with a transient error
Created https://reviews.freebsd.org/D2970 to get faster closure on this issue. Cheers, Hiren ps: To comment, you need to sign up for an account. :-( I am not a fan of the whole thing but people seem to respond faster on reviews.freebsd.org so I went with it. pgpYf6BdgHz3N.pgp Description: PGP signature
Re: [Bug 200210] adding vtnet to bridge results to kernel panic
Done in r285016. Regards, Kristof > On 01 Jul 2015, at 18:11, Nikos Vassiliadis wrote: > > Hi Kristof, > > Thanks for fixing this! Could you MFC the fix? > > On 06/13/15 22:39, bugzilla-nore...@freebsd.org wrote: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200210 >> >> --- Comment #1 from commit-h...@freebsd.org --- >> A commit references this bug: >> >> Author: kp >> Date: Sat Jun 13 19:39:22 UTC 2015 >> New revision: 284348 >> URL: https://svnweb.freebsd.org/changeset/base/284348 >> >> Log: >> Fix panic when adding vtnet interfaces to a bridge >> >> vtnet interfaces are always in promiscuous mode (at least if the >> VIRTIO_NET_F_CTRL_RX feature is not negotiated with the host). >> if_promisc() >> on >> a vtnet interface returned ENOTSUP although it has IFF_PROMISC set. This >> confused the bridge code. Instead we now accept all enable/disable >> promiscuous >> commands (and always keep IFF_PROMISC set). >> >> There are also two issues with the if_bridge error handling. >> >> If if_promisc() fails it uses bridge_delete_member() to clean up. This >> tries >> to >> disable promiscuous mode on the interface. That runs into an assert, >> because >> promiscuous mode was never set in the first place. (That's the panic >> reported >> in >> PR 200210.) >> We can only unset promiscuous mode if the interface actually is >> promiscuous. >> This goes against the reference counting done by if_promisc(), but only the >> first/last if_promic() calls can actually fail, so this is safe. >> >> A second issue is a double free of bif. It's already freed by >> bridge_delete_member(). >> >> PR:200210 >> Differential Revision:https://reviews.freebsd.org/D2804 >> Reviewed by:philip (mentor) >> >> Changes: >> head/sys/dev/virtio/network/if_vtnet.c >> head/sys/net/if_bridge.c >> > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 200210] adding vtnet to bridge results to kernel panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200210 --- Comment #2 from commit-h...@freebsd.org --- A commit references this bug: Author: kp Date: Wed Jul 1 21:21:15 UTC 2015 New revision: 285016 URL: https://svnweb.freebsd.org/changeset/base/285016 Log: MFC r284348: Fix panic when adding vtnet interfaces to a bridge vtnet interfaces are always in promiscuous mode (at least if the VIRTIO_NET_F_CTRL_RX feature is not negotiated with the host). if_promisc() on a vtnet interface returned ENOTSUP although it has IFF_PROMISC set. This confused the bridge code. Instead we now accept all enable/disable promiscuous commands (and always keep IFF_PROMISC set). There are also two issues with the if_bridge error handling. If if_promisc() fails it uses bridge_delete_member() to clean up. This tries to disable promiscuous mode on the interface. That runs into an assert, because promiscuous mode was never set in the first place. (That's the panic reported in PR 200210.) We can only unset promiscuous mode if the interface actually is promiscuous. This goes against the reference counting done by if_promisc(), but only the first/last if_promic() calls can actually fail, so this is safe. A second issue is a double free of bif. It's already freed by bridge_delete_member(). PR: 200210 Changes: _U stable/10/ stable/10/sys/dev/virtio/network/if_vtnet.c stable/10/sys/net/if_bridge.c -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 199174] em tx and rx hang
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174 --- Comment #22 from david.kel...@litchis.fr --- (In reply to Sean Bruno from comment #21) Sure, I'running now a releng 10.1 kernel with dev/e1000/ from r28. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: rc settings for ipv6 in 9.3?
On Wed, Jul 1, 2015 at 8:17 AM, wrote: > On Tue, Jun 30, 2015 at 09:40:46PM -0700, Kevin Oberman wrote: > >On Tue, Jun 30, 2015 at 5:29 PM, <[1]kpn...@pobox.com> wrote: > > > > I just got a /56 block of ipv6 addresses today and I'm trying to > > figure > > out how to use it. > > Before I go rebooting my server I wanted to ask if the information > > in the > > handbook "[2]https://www.freebsd.org/doc/handbook/network-ipv6.html > " > > is correct > > for 9.3-p14. > > I have a static address for my server and I've been given the static > > address of the router. So I should just be able to set (in my > > rc.conf) > > ifconfig_bce0_ipv6 and ipv6_defaultrouter, correct? > > Or do I really need these two lines from the handbook?: > > ifconfig_bce0_ipv6="inet6 accept_rtadv" > > rtsold_enable="YES" > > Also, can someone translate this statement from my provider for me: > > "Note: [provider] is routing 2607:f758:2280::/56 to > > 2607:f758:2280::4/64" > > BTW, is the term "netmask" ever used in IPv6? I thought "prefixlen" > > was > > the term and "netmask" was for v4 only? > > Thanks for any help! > > -- > > Kevin P. Neal                > > [3]http://www.pobox.com/~kpn/ > > > >No, If your system has a static address (and a server should have > one), > >you don't need SLAAC or Router Solicitation. You just need to set the > >address: > > ifconfig_bce0_ipv6="inet6 2607:f758:2280::n/64" and > >ipv6_defaultrouter="Router address". > > Excellent. Thanks! > > >I am unable to translate the statement from the provider with > >certainty. I am guessing that the /64 2607:f758:2280::/64 is used by > >their router with 2607:f758:2280::4 as the address on their > >router(s). The remainder of the /56 is yours but I could not swear > to > >that. > >You will probably want more than one /64 for different purposes. Other > >than externally accessible servers, you should put systems in a > >different /64 and spread them at random around that space if they are > >statically addressed. (I don't recommend for or against statically > >addressing, though.) > > Wouldn't each /64 need a router, then? I've got most of the /56 to myself, > but there's only one router address. So how can it work to use different > /64 subnets? > > Sorry, this is my first time playing with IPv6. I do appreciate your help. > -- > Kevin P. Nealhttp://www.pobox.com/~kpn/ > > "A pig's gotta fly." - Crimson Pig > Each interface on an IPv6 capable router will get one or more IPv6 addresses. IPv6 mandates that any interface on a host or router may have many addresses. You will need an IPv6 capable router to do this. So you put a different /64 on(for several reasons, you really should stick to using /64s until/unless you have multiple routers. Prefixes longer than /64 have a lot of problems, though they theoretically can work. In practice, they don't. Also, you will need to adjust any firewalls to allow NDP (Neighbor Discovery Protocol) which replaces ARP for IPv6. This is usually the default, but not always.In general, IPv6 will just work aslong as your system can find the gateway/router and the gateway/router can find your system. Since your addresses are public, you do need a stateful firewall. With IPv4 and NAT, you get one automatically as NAT won't work without one. IPv6 does not have such a requirement. Almost all IPv6 capable CPE routers include a stateful firewall, but a few don't and ISPs generally don't provide this capability unless they also provide the customer edge hardware. If you really want to learn about IPv6, you might want to look at "IPv6 for IPv4 Experts" available in PDF from The Internet Society at http://www.internetsociety.org/deploy360/resources/ebook-ipv6-for-ipv4-experts-available-in-english-and-russian/. It's really a book at around 700 pages. (It came out after I retired and I'll have to admit that I have only skimmed it, but it looked good and it's free!) -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
strongswan ikev2 slow on FreeBSD (DigitalOcean)
It might be hypervisor's problem because they use KVM, but here are some information I have: DO smallest instance. > uname -a FreeBSD megashadow2 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #3 r284996: Wed Jul 1 17:58:13 UTC 2015 freebsd@megashadow2:/usr/obj/usr/src/sys/DOIPSEC amd64 cryptotest w/wo -p -- 2Gb/s, 400Mb/s, aesni, cryptodev present. strongswan ipsec.conf: ike=aes256-sha1-modp1024! esp=aes256-sha1! NAT done through one simple pf rule. natstat -inw1 shows no error, no drop, just very small packets (10K-30K) even for large data. Top two functions in pmcstat -TS instructions -w1 are kernel rijndaelEncrypt and sha1_step are the top two consuming function, 10%-20% for each. TSO, IPSEC_DEBUG do not matter. Boost performance is same as Ubuntu 15 (300kb/s in ssh, downloading to my laptop), but most of the time is < 100kb/s, and overall speed is 50% slower. Uploading is good. -- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. ___ 4BSD -- http://bit.ly/blog4bsd ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPFW divert and suricata
On 7/1/15 10:31 PM, Luigi Rizzo wrote: On Wed, Jul 1, 2015 at 3:15 PM, Oliver Humpage wrote: Hello, I hope this is a good list to post this on, I have a feeling the solution is somewhere obscure in the networking layer. I've set up an IPS system, using: * FreeBSD 10.1 (guest OS, plenty of RAM/CPU) * ESXi 5.5 (host OS, using Intel X520 10Gb cards. Not overloaded, all graphs show it's got plenty of RAM/CPU spare at all times) * vmxnet3 drivers * ipfw (very small ruleset, basically just a divert rule) * suricata, in ipfw divert mode I'm having a couple of major issues. The first is that every so often, even with relatively little traffic, the load on the box suddenly spikes and pings to a neighbouring router (via the divert rule) go from <1ms to >300ms. Generally this resolves itself after a few minutes, although last night it went on for an hour until I restarted ipfw and suricata. typical problems with divert sockets are 1. if the interface has offloads (checksums, tso, etc.) enabled, packets may be moved up and down with invalid checksums resulting in all sort of odd behaviours 2. likewise if there are huge segments (virtual nics often pass up and down up to 64k in one shot) the divert socket is unable to handle them and either truncates or drops disabling all accelerations and setting the mtu to 1500 or so usually fixes the above two. 3. divert probably loses important context on the packets (e.g. incoming or outgoing interface) so when traffic is reinjected bad things occur actually this is one that it tries to keep. the interface name is in the sockaddr (ipv4) hidden at the end. If you use the same sockaddr that the packet arrived with, you will pass the interface back again.. (actually in the man page I think). 4. performancewise, moving traffic back and forth to userspace is a bad idea. For the latter two, you might be better off using netmap on vmxnet3 (in emulated mode, also disabling offloads), and if i remember well a couple of years ago there were efforts to use suricata on top of netmap. Worst case, you can just use the netmap-enabled libpcap. cheers luigi The second is that if I do a large download, eg a FreeBSD ISO, the download usually hangs somewhere between 5MB and 100MB through. I can see traffic trying to get through on neighbouring routers, it's just the interface with the divert to suricata where they disappear into a black hole. The connection speed is around 50Mb, btw. Now it's possible it's suricata being weird, but there's nothing untoward in its events and stats logs, and if I replay the traffic from a pcap file then suricata processes everything fine (a pcap taken over a 90s period during a slowdown is processed in under a second). So my guess is that if suricata takes slightly longer than normal to process a packet, something in the networking or ipfw divert system is tripping itself up. Maybe a queue is filling up? I've set net.inet.ip.fw.dyn_buckets=16384, and done an ipfw flush, but net.inet.ip.fw.curr_dyn_buckets is stubbornly sticking at 256: have I done something wrong? Other tunables I've set are: kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.point_to_point=0 kern.random.sys.harvest.interrupt=0 kern.ipc.soacceptqueue=1024 Can anyone suggest either tests to see what might be going wrong, or tunables to help things run smoother? Both myself and a colleague have used FreeBSD for over 15 years, and never quite seen anything like it. Many thanks, Oliver. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Fwd: Integrating OpenSSL app with NetMap [Help needed]
Hi , As we all know, OpenSSL community moved away from the kernel implementation to a user-space one not so long ago. Now trying to port the latest OpenSSL code into FreeBSD kernel is one of the items i was looking at and after having exhaustive rounds of discussion with relavent stake-holders, we decided not to pursue the path of porting the whole user-space OpenSSL code into kernel. Now we have decided to retain openSSL library in user-space but i wanted to integrate NetMAP API's so that known system overheads such as context switches etc are eliminated and we could get good performance. Now the workflow that i have in mind is that the encrypted packet gets pulled in from the MMAP'd region and OpenSSL code in user-space goes about doing the de-cryption part. But before that, i wanted to know which library can be used to actually do the TCP/IP packet processing in user-space. The next part is how to push the decrypted packets back to kernel for services in kernel to consume. Can NetMap API's push the decrypted packets down to lets say another MMAP'd region so that kernel services/components can act on the de-crypted packet to proceed with execution further? Your inputs and Giudance would be really helpful. Thanks! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: strongswan ikev2 slow on FreeBSD (DigitalOcean)
AESNI is not hooked yet to the IPsec stack. On Thu, Jul 2, 2015 at 2:42 AM, Zhihao Yuan wrote: > It might be hypervisor's problem because they use KVM, but here are > some information I have: > > DO smallest instance. > > > uname -a > FreeBSD megashadow2 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #3 > r284996: Wed Jul 1 17:58:13 UTC 2015 > freebsd@megashadow2:/usr/obj/usr/src/sys/DOIPSEC amd64 > > cryptotest w/wo -p -- 2Gb/s, 400Mb/s, aesni, cryptodev present. > > strongswan ipsec.conf: > > ike=aes256-sha1-modp1024! > esp=aes256-sha1! > > NAT done through one simple pf rule. > > natstat -inw1 shows no error, no drop, just very small packets (10K-30K) > even > for large data. > > Top two functions in pmcstat -TS instructions -w1 are kernel > rijndaelEncrypt and sha1_step are the top two consuming function, > 10%-20% for each. > > TSO, IPSEC_DEBUG do not matter. > > Boost performance is same as Ubuntu 15 (300kb/s in ssh, downloading to > my laptop), but most of the time is < 100kb/s, and overall speed is > 50% slower. Uploading is good. > > -- > Zhihao Yuan, ID lichray > The best way to predict the future is to invent it. > ___ > 4BSD -- http://bit.ly/blog4bsd > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > -- > Ermal > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
