[Bug 200379] SCTP stack is not FIB aware
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379 --- Comment #18 from Michael Tuexen tue...@freebsd.org --- (In reply to Craig Rodrigues from comment #17) Ahh. Thanks for the hint. Will do. Best regards Michael -- You are receiving this mail because: You are on the CC list 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
On 06/17/15 at 03:10P, Jean-Francois HREN wrote:
Hello, while investigating a freeze on a modified FreeBSD 9.3 I stumbled upon
a potential bug in netinet/tcp_output.c
If an error occurs while processing a TCP segment with some data and the FIN
flag,
the back out of the sequence number advance does not take into account
the increase by 1 due to the FIN flag
(see
https://svnweb.freebsd.org/base/head/sys/netinet/tcp_output.c?view=markup#l1360
and
https://svnweb.freebsd.org/base/head/sys/netinet/tcp_output.c?view=markup#l1439
).
In the case of a transient error, this leads to a retransmitted TCP segment
with
a shifted by 1 sequence number and a missing first byte in the TCP payload.
In FreeBSD 9.3, it happens only when an error occurs in
netinet/ip_output.c::ip_output()
or netinet6/ip6_output::ip6_output() but in head, R249372
( https://svnweb.freebsd.org/base?view=revisionrevision=249372 ) now allows
the same behaviour if an ENOBUFS error occurs in netinet/tcp_output.c
Your analysis looks correct to me.
Tentative solutions would be either to remove the back out of the sequence
number advance completely and to treat transient error cases like real lost
packets
--- netinet/tcp_output.c
+++ netinet/tcp_output.c
@@ -1435,8 +1435,7 @@
tp-sackhint.sack_bytes_rexmit -= len;
KASSERT(tp-sackhint.sack_bytes_rexmit = 0,
(sackhint bytes rtx = 0));
- } else
- tp-snd_nxt -= len;
+ }
}
SOCKBUF_UNLOCK_ASSERT(so-so_snd); /* Check gotos. */
switch (error) {
or to decrease the sequence number advance by 1 if a FIN flag was sent.
--- netinet/tcp_output.c
+++ netinet/tcp_output.c
@@ -1435,8 +1435,11 @@
tp-sackhint.sack_bytes_rexmit -= len;
KASSERT(tp-sackhint.sack_bytes_rexmit = 0,
(sackhint bytes rtx = 0));
- } else
+ } else {
tp-snd_nxt -= len;
+ if (flags TH_FIN)
+ tp-snd_nxt--;
+ }
}
SOCKBUF_UNLOCK_ASSERT(so-so_snd); /* Check gotos. */
switch (error) {
I like the second approach better.
Cheers,
Hiren
pgpzITCe9ef4C.pgp
Description: PGP signature
Re: Reg Intel Fortville IXL driver on 11-CURRENT
On Wed, Jun 17, 2015 at 7:00 AM, Lakshmi Narasimhan Sundararajan lakshm...@msystechnologies.com wrote: [lakshmis@mau-bsd-10a ~/fortville/hol/sys/dev/ixl]$ diff -c5pt ixl_txrx.c ixl_txrx.c.mod *** ixl_txrx.c Fri Jun 12 06:56:51 2015 --- ixl_txrx.c.mod Fri Jun 12 06:56:33 2015 *** ixl_mq_start(struct ifnet *ifp, struct m *** 96,112 --- 96,115 } else #endif i = m-m_pkthdr.flowid % vsi-num_queues; } else i = curcpu % vsi-num_queues; + + #if 0 /* ** This may not be perfect, but until something ** better comes along it will keep from scheduling ** on stalled queues. */ if (((1 i) vsi-active_queues) == 0) i = ffsl(vsi-active_queues); + #endif que = vsi-queues[i]; txr = que-txr; err = drbr_enqueue(ifp, txr-br, m); [lakshmis@mau-bsd-10a ~/fortville/hol/sys/dev/ixl]$ My understanding is that this code is intended to be triggered as a last resort. If that code is firing regularly then the driver is not correctly tracking which queues are alive in the active_queues bitmask. ___ 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
Notice to Appear in Court
Notice to Appear, This is to inform you to appear in the Court on the June 22 for your case hearing. You are kindly asked to prepare and bring the documents relating to the case to Court on the specified date. Note: The case will be heard by the judge in your absence if you do not come. You can review complete details of the Court Notice in the attachment. Yours faithfully, Keith Frederick, Clerk of Court. ___ 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: Reg Intel Fortville IXL driver on 11-CURRENT
As Ryan said, its there to keep queues marked as hung from getting more work scheduled on them. I really don't know what to make of it if commenting it out is somehow improving things :) I would suggest more careful analysis of what is going wrong before committing anything like deleting this. Jack On Wed, Jun 17, 2015 at 12:17 PM, Ryan Stone ryst...@gmail.com wrote: On Wed, Jun 17, 2015 at 7:00 AM, Lakshmi Narasimhan Sundararajan lakshm...@msystechnologies.com wrote: [lakshmis@mau-bsd-10a ~/fortville/hol/sys/dev/ixl]$ diff -c5pt ixl_txrx.c ixl_txrx.c.mod *** ixl_txrx.c Fri Jun 12 06:56:51 2015 --- ixl_txrx.c.mod Fri Jun 12 06:56:33 2015 *** ixl_mq_start(struct ifnet *ifp, struct m *** 96,112 --- 96,115 } else #endif i = m-m_pkthdr.flowid % vsi-num_queues; } else i = curcpu % vsi-num_queues; + + #if 0 /* ** This may not be perfect, but until something ** better comes along it will keep from scheduling ** on stalled queues. */ if (((1 i) vsi-active_queues) == 0) i = ffsl(vsi-active_queues); + #endif que = vsi-queues[i]; txr = que-txr; err = drbr_enqueue(ifp, txr-br, m); [lakshmis@mau-bsd-10a ~/fortville/hol/sys/dev/ixl]$ My understanding is that this code is intended to be triggered as a last resort. If that code is firing regularly then the driver is not correctly tracking which queues are alive in the active_queues bitmask. ___ 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
[Differential] [Commented On] D1761: Extend LRO support to accumulate more than 65535 bytes
hselasky added a comment. lawrence: It is someone well known to be using FreeBSD. This patch makes such a big difference when applied to +10Gbit/s connections that we can run 2 TCP streams totalling 37.5 GBit/s on a single 2.x GHz CPU core instead of only one. REPOSITORY rS FreeBSD src repository REVISION DETAIL https://reviews.freebsd.org/D1761 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: hselasky, rrs, glebius, gnn, emaste, rwatson, bz, imp, np, jfv, adrian, lstewart Cc: imp, freebsd-net-list ___ 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
[Differential] [Commented On] D1761: Extend LRO support to accumulate more than 65535 bytes
lstewart added a comment. Ok, but that's anecdotal and gives us reviewers nothing to go on - without any methodology or raw data who knows whether the LRO change is solely responsible for the improvement and if it introduced any undesired side effects. It's also possible that with tuning, the same results could have been obtained without the jumbo LRO change. As there seems to be some sensitivity around sharing specific details from field deployments which is fine, the path forward is therefore for you and/or Mellanox test engineers to run experiments, capture + analyse data and present it for discussion. You should provide your methodology so anyone wanting to replicate your experiments and results can do so. That being said, I personally feel the energy would be better spent on batching, which would allow a tunable number of 64k correctly formed packets to be passed up the stack which should give 99% of the benefits of this work without the hackiness, plus gives us a win in many other workloads when LRO is unavailable or not used. REPOSITORY rS FreeBSD src repository REVISION DETAIL https://reviews.freebsd.org/D1761 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: hselasky, rrs, glebius, gnn, emaste, rwatson, bz, imp, np, jfv, adrian, lstewart Cc: imp, freebsd-net-list ___ 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
[Differential] [Commented On] D1761: Extend LRO support to accumulate more than 65535 bytes
lstewart added a comment. I hope I didn't delete it... from what I could see online, the Abandon Phabricator action is the means by which a reviewer indicates they have permanently rejected the patch (as opposed to suggesting changes). As to people using the patch, can you say who and why? REPOSITORY rS FreeBSD src repository REVISION DETAIL https://reviews.freebsd.org/D1761 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: hselasky, rrs, glebius, gnn, emaste, rwatson, bz, imp, np, jfv, adrian, lstewart Cc: imp, freebsd-net-list ___ 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
[Differential] [Commented On] D1761: Extend LRO support to accumulate more than 65535 bytes
hselasky added a comment. lstewart: OK, just don't delete this patch, because some people are using it. REPOSITORY rS FreeBSD src repository REVISION DETAIL https://reviews.freebsd.org/D1761 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: hselasky, rrs, glebius, gnn, emaste, rwatson, bz, imp, np, jfv, adrian, lstewart Cc: imp, freebsd-net-list ___ 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
[Differential] [Abandoned] D1761: Extend LRO support to accumulate more than 65535 bytes
lstewart abandoned this revision. lstewart added a comment. Hans, Just because some hardware is capable of coalescing more than 64k of data doesn't mean we should feel obligated to support the functionality. I'd be curious to understand the anticipated use cases that led to hardware support being added. Without some compelling data to show that this is useful, I think this work should be put on ice until such time as it can be shown to be worthwhile. If such data exists, I'm willing to give it due consideration and revise my judgment, but at this stage I strongly suspect there is no workload we support or will support in the near future that would significantly benefit from raising the LRO chunk size above 64k vs the hacks required to make it work, so that's why I'm voting against this patch outright rather than suggesting changes. The real goal is to remove LRO entirely anyway, which I believe we have ideas on how to do e.g. packet batching techniques. As an aside, it would be useful to socialise ideas like this a bit more along with good data before investing the time and energy into doing the work unless it's trivial enough that it doesn't matter. Ideally we should have had this discussion on the mailing list centered around proposed use case(s) and a data set showing the limitations of the 64k limit on those use cases before the patch was proposed. REPOSITORY rS FreeBSD src repository REVISION DETAIL https://reviews.freebsd.org/D1761 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: hselasky, rrs, glebius, gnn, emaste, rwatson, bz, imp, np, jfv, adrian, lstewart Cc: imp, freebsd-net-list ___ 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 200379] SCTP stack is not FIB aware
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379 --- Comment #16 from Michael Tuexen tue...@freebsd.org --- (In reply to Alan Somers from comment #15) Yes, you can failover from one ISP to another. Currently this is done by having corresponding entries in a single routing table for the multiple peer addresses. I have checked in support for FIB support in https://svnweb.freebsd.org/changeset/base/284515 This is a single fib per socket. This way you can have multiple applications on a single host using SCTP and they can have individual setups. Better than the current situation. -- You are receiving this mail because: You are on the CC list 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
oce(4) promiscous mode bug(?)
Hi, I’ve got problems with HP NC550SFP NIC (http://www.emulex.com/products/ethernet-networking-storage-connectivity/ethernet-networking-adapters/hp-branded/nc550sfp/overview/ ) Setup information: I’m intended to use this system for traffic monitoring: switchport configured for traffic mirroring to 10 Gbit port of NC550SFP adapter. Adapter is detected by oce(4) driver: $ dmesg … oce0: Emulex CNA NIC function:///10.0.664.0/// mem 0xfbff-0xfbff3fff,0xfbfc-0xfbfd,0xfbfa-0xfbfb irq 32 at device 0.0 on pci4 oce0: Ethernet address: 10:60:4b:01:12:48 oce1: Emulex CNA NIC function:///10.0.664.0/// mem 0xfbf9-0xfbf93fff,0xfbf6-0xfbf7,0xfbf4-0xfbf5 irq 42 at device 0.1 on pci4 oce1: Ethernet address: 10:60:4b:01:12:4c $ pciconf –vl oce0@pci0:4:0:0:class=0x02 card=0x1747103c chip=0x070019a2 rev=0x02 hdr=0x00 vendor = 'Emulex Corporation' device = 'OneConnect 10Gb NIC' class = network subclass = ethernet oce1@pci0:4:0:1:class=0x02 card=0x1747103c chip=0x070019a2 rev=0x02 hdr=0x00 vendor = 'Emulex Corporation' device = 'OneConnect 10Gb NIC' class = network subclass = Ethernet sysctl info: dev.oce.0.sfp_vpd_dump: 0 dev.oce.0.aic_enable: 0 dev.oce.0.fw_upgrade: dev.oce.0.loop_back: 0 dev.oce.0.speed: 1 dev.oce.0.max_rsp_handled: 64 dev.oce.0.firmware_version: 4.9.416.2 dev.oce.0.component_revision: ///10.0.664.0/// dev.oce.0.%parent: pci4 dev.oce.0.%pnpinfo: vendor=0x19a2 device=0x0700 subvendor=0x103c subdevice=0x1747 class=0x02 dev.oce.0.%location: pci0:4:0:0 handle=\_SB_.PCI0.PT09.PES1 dev.oce.0.%driver: oce dev.oce.0.%desc: Emulex CNA NIC function:///10.0.664.0/// Problem: It is switched to promiscuous mode: $ ifconfig oce0 oce0: flags=68143UP,BROADCAST,RUNNING,PROMISC,MULTICAST,PPROMISC,MONITOR metric 0 mtu 1500 options=407bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO ether 10:60:4b:01:12:48 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (10Gbase-SR full-duplex) status: active Via tcpdump I see only broadcast frames. Via sysctl I see constantly increasing error counter: dev.oce.0.stats.rx.err.address_match_errors: 124171960 It seems that all unicast frames not addressed to adapter's MAC-address are dropped at hardware, which means that promiscuous mode is not working as intended. Behavior is similar under 10.1 RELEASE, and 11.0-CURRENT (FreeBSD 11.0-CURRENT #0 r284443). GENERIK kernel. The same box works fine under Linux with be2net driver, so It’s definitely not a hardware problem and seems like a problem with FreeBSD oce(4) driver Any suggestions? Thanks in advance. Best regards, Sergey Akhmatov ___ 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 200323] BPF userland misuse can crash the system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200323 --- Comment #14 from commit-h...@freebsd.org --- A commit references this bug: Author: eri Date: Wed Jun 17 12:23:05 UTC 2015 New revision: 284512 URL: https://svnweb.freebsd.org/changeset/base/284512 Log: If there is a system with a bpf consumer running and a packet is wanted to be transmitted but the arp cache entry expired, which triggers an arp request to be sent, the bpf code might want to sleep but crash the system due to a non sleep lock held from the arp entry not released properly. Release the lock before calling the arp request code to solve the issue as is done on all the other code paths. PR:200323 Approved by: ae, gnn(mentor) MFC after:1 week Sponsored by:Netgate Differential Revision:https://reviews.freebsd.org/D2828 Changes: head/sys/netinet/if_ether.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
Reg Intel Fortville IXL driver on 11-CURRENT
Hi FreeBSD folks, I am part of Panasas and working on evaluating IXL over FreeBSD [11-CURRENT] on Intel Taylor Pass platform for our next product. In that regard, while evaluating performance, we found the Tx performance to be very poor. We found it to be so because the tx interrupts are spread over all the CPUs even if the traffic handling process is pinned at a particular cpu. And we narrowed it down to the below lines of code in the tx path within the IXL driver. It seems to me that the logic for finding whether tx queue is stalled might be incorrect or too aggressive. Either ways, removing the below lines makes the tx interrupt being handled on the same cpu on which the request was raised and the performance is very good as expected. Filename: sys/dev/ixl/ixl_txrx.c [lakshmis@mau-bsd-10a ~/fortville/hol/sys/dev/ixl]$ diff -c5pt ixl_txrx.c ixl_txrx.c.mod *** ixl_txrx.c Fri Jun 12 06:56:51 2015 --- ixl_txrx.c.mod Fri Jun 12 06:56:33 2015 *** ixl_mq_start(struct ifnet *ifp, struct m *** 96,112 --- 96,115 } else #endif i = m-m_pkthdr.flowid % vsi-num_queues; } else i = curcpu % vsi-num_queues; + + #if 0 /* ** This may not be perfect, but until something ** better comes along it will keep from scheduling ** on stalled queues. */ if (((1 i) vsi-active_queues) == 0) i = ffsl(vsi-active_queues); + #endif que = vsi-queues[i]; txr = que-txr; err = drbr_enqueue(ifp, txr-br, m); [lakshmis@mau-bsd-10a ~/fortville/hol/sys/dev/ixl]$ Would appreciate your feedback on the same. Thanks, LN ___ 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: oce(4) promiscous mode bug(?)
On Jun 17, 2015, at 11:48 AM, Sergey Akhmatov wrote: Hi, I’ve got problems with HP NC550SFP NIC (http://www.emulex.com/products/ethernet-networking-storage-connectivity/ethernet-networking-adapters/hp-branded/nc550sfp/overview/ ) Beware The driver was unusable until fixes were applied on 21st December. http://svnweb.freebsd.org/base/stable/10/sys/dev/oce/?view=log Better use a recent 10-STABLE if possible. Borja. ___ 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: oce(4) promiscous mode bug(?)
I've tried 10.1-RELEASE, then 10-STABLE and finaly 11-CURRENT with the same result. Beware The driver was unusable until fixes were applied on 21st December. http://svnweb.freebsd.org/base/stable/10/sys/dev/oce/?view=log Better use a recent 10-STABLE if possible. ___ 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
Sequence number handling issue with TCP data and FIN flag with a transient error
Hello, while investigating a freeze on a modified FreeBSD 9.3 I stumbled upon
a potential bug in netinet/tcp_output.c
If an error occurs while processing a TCP segment with some data and the FIN
flag,
the back out of the sequence number advance does not take into account
the increase by 1 due to the FIN flag
(see
https://svnweb.freebsd.org/base/head/sys/netinet/tcp_output.c?view=markup#l1360
and
https://svnweb.freebsd.org/base/head/sys/netinet/tcp_output.c?view=markup#l1439
).
In the case of a transient error, this leads to a retransmitted TCP segment with
a shifted by 1 sequence number and a missing first byte in the TCP payload.
In FreeBSD 9.3, it happens only when an error occurs in
netinet/ip_output.c::ip_output()
or netinet6/ip6_output::ip6_output() but in head, R249372
( https://svnweb.freebsd.org/base?view=revisionrevision=249372 ) now allows
the same behaviour if an ENOBUFS error occurs in netinet/tcp_output.c
Tentative solutions would be either to remove the back out of the sequence
number advance completely and to treat transient error cases like real lost
packets
--- netinet/tcp_output.c
+++ netinet/tcp_output.c
@@ -1435,8 +1435,7 @@
tp-sackhint.sack_bytes_rexmit -= len;
KASSERT(tp-sackhint.sack_bytes_rexmit = 0,
(sackhint bytes rtx = 0));
- } else
- tp-snd_nxt -= len;
+ }
}
SOCKBUF_UNLOCK_ASSERT(so-so_snd); /* Check gotos. */
switch (error) {
or to decrease the sequence number advance by 1 if a FIN flag was sent.
--- netinet/tcp_output.c
+++ netinet/tcp_output.c
@@ -1435,8 +1435,11 @@
tp-sackhint.sack_bytes_rexmit -= len;
KASSERT(tp-sackhint.sack_bytes_rexmit = 0,
(sackhint bytes rtx = 0));
- } else
+ } else {
tp-snd_nxt -= len;
+ if (flags TH_FIN)
+ tp-snd_nxt--;
+ }
}
SOCKBUF_UNLOCK_ASSERT(so-so_snd); /* Check gotos. */
switch (error) {
Jean-François Hren
ASQ Team Member
http://www.stormshield.eu
STORMSHIELD
Parc Scientifique de la Haute Borne
Parc Horizon - Bâtiment 6
Avenue de l'Horizon
59650 Villeneuve d'Ascq
France
___
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 200379] SCTP stack is not FIB aware
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379 --- Comment #14 from Michael Tuexen tue...@freebsd.org --- (In reply to Alan Somers from comment #13) I think interfaces can assign fibs to packets, it is a field in the mbuf packet header. It makes sense to use this information in case you have no socket to get the fib from (for example when receiving a TCP SYN and you have no listening socket). An SCTP end-point can have multiple IP addresses. When using multihoming you use multiple local and remote IP-addresses to provide network fault tolerant. So you use multiple local interfaces and route traffic on all of them to be able to fail over in case of network problems. Of course you can setup this in a single routing table and have a socket in a single fib. I'm tending to implement it this way. This also means that for response packets (like acks for data) use the socket's fib, not the one from the incoming packet. At least this is conceptually simpler. Codewise it doesn't make much of a difference. Thanks for your feedback. Best regards Michael -- You are receiving this mail because: You are on the CC list 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: oce(4) promiscous mode bug(?)
On Jun 17, 2015, at 2:58 PM, Sergey Akhmatov wrote: I've tried 10.1-RELEASE, then 10-STABLE and finaly 11-CURRENT with the same result. Sorry, in that case I don't know what it might be. Have you tried disabling adapter intelligence? rxcsum, txcsum, lro, etc? Borja. ___ 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: oce(4) promiscous mode bug(?)
Tried disabling all offloadings available, doesn't help. Sorry, in that case I don't know what it might be. Have you tried disabling adapter intelligence? rxcsum, txcsum, lro, etc? ___ 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 200379] SCTP stack is not FIB aware
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379 --- Comment #15 from Alan Somers asom...@freebsd.org --- (In reply to Michael Tuexen from comment #14) You're right about the interface FIB. It will take incoming packets with a certain FIB. But it's not completely general; it's possible to have outbound traffic use multiple FIBs on a single interface. The part about multihoming is more interesting. Can you use SCTP to failover from one ISP to another? Different ISPs require different gateways, and hence different routing tables. In that case, a single fib per SCTP socket wouldn't be sufficient. We would need to set the FIB separately for each local IP address of the SCTP socket. -- You are receiving this mail because: You are on the CC list 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: oce(4) promiscous mode bug(?)
It sounds like a promisc bug in the driver, just as you say, but just to test it some more: I see that you are running both in PPROMISC and PROMISC. What happen if you remove the PPROMISC and only let tcpdump set it's own PROMISC? Running in monitor mode is the correct way to sniff traffic. But just to rule out errors in the oce driver, what happen if you do not run in monitor mode? Do 'netstat -in' show the same input errors as your sysctl counter? (I assume you're running tcpdump with no bpf filter at all) What do a couple of 'netstat -B' say while tcpdump is running? /Elof On Wed, 17 Jun 2015, Sergey Akhmatov wrote: Tried disabling all offloadings available, doesn't help. Sorry, in that case I don't know what it might be. Have you tried disabling adapter intelligence? rxcsum, txcsum, lro, etc? ___ 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
