[Bug 217871] sys/netinet/fibs_test;slaac_on_nondefault_fib6 fails when run twice

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217871 Alan Somers changed: What|Removed |Added Summary|SLAAC on a newly created

[Bug 217871] sys/netinet/fibs_test;slaac_on_nondefault_fib6 fails when run twice

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217871 --- Comment #5 from commit-h...@freebsd.org --- A commit references this bug: Author: asomers Date: Mon Mar 20 23:07:35 UTC 2017 New revision: 315656 URL: https://svnweb.freebsd.org/changeset/base/315656 Log: Fix back-to-back runs of

[Bug 217871] sys/netinet/fibs_test;slaac_on_nondefault_fib6 fails when run twice

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217871 Alan Somers changed: What|Removed |Added Status|New |In Progress

[Bug 217871] sys/netinet/fibs_test;slaac_on_nondefault_fib6 fails when run twice

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217871 Alan Somers changed: What|Removed |Added Assignee|freebsd-net@FreeBSD.org

[Bug 213015] openvswitch and vnet jails - panic when bridge is destroyed and recreated

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213015 --- Comment #11 from commit-h...@freebsd.org --- A commit references this bug: Author: ae Date: Mon Mar 20 08:10:58 UTC 2017 New revision: 315624 URL: https://svnweb.freebsd.org/changeset/base/315624 Log: MFC r315192: Ignore ifnet

[Bug 213015] openvswitch and vnet jails - panic when bridge is destroyed and recreated

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213015 Andrey V. Elsukov changed: What|Removed |Added CC|

[Bug 217871] SLAAC on a newly created epair sometimes fails to add routes

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217871 --- Comment #3 from Alan Somers --- In https://reviews.freebsd.org/D9451, jhujhiti noticed that the IFDISABLED flag doesn't get added to epair0b immediately upon creation, but shortly after. He suspected that was the

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #69 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #68) > Hmm. My understanding is that TCP provides a reliable bi-directional > byte-stream. > This means that no user data is lost in any of the two

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #71 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #70) RFC: "An acknowledgment by TCP does not guarantee that the data has been delivered to the end user, but only that the receiving TCP has taken the

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #68 from Michael Tuexen --- (In reply to slw from comment #67) > Loss of sended application data caused by close() before incoming user > data arrived? Realy? TCP don't have such claim. Hmm. My understanding

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #72 from Michael Tuexen --- (In reply to slw from comment #71) I'm not arguing the semantic of the TCP level ACKs. I'm saying that if a TCP stack knows that some user data can not be delivered to its

Re: [Bug 203735] Transparent interception of ipv6 with squid and pf causes panic

On 21 Mar 2017, at 11:24, Ermal Luçi wrote: On Sun, Mar 19, 2017 at 9:41 PM, wrote: + m->m_flags |= M_SKIP_FIREWALL | M_FASTFWD_OURS; I am not sure this is really what is happening here. Can you provide more data from your analysis? In

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #74 from Mike Karels --- In responding to an earlier comment directed to me, and to the comments since: This connection is dead. Only an RST and CLOSED state apply. Data cannot be delivered to the

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #70 from Michael Tuexen --- (In reply to slw from comment #69) > "Lost" in this context is "not delivered to remote IP stack". > Not application, IP stack. The semantic of an ACK is "delivered to the remote

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #73 from Sepherosa Ziehau --- (In reply to Michael Tuexen from comment #72) IMO, transition from {FIN-WAIT-1,FIN-WAIT-2,CLOSING} to TIME_WAIT instead of CLOSED upon receiving data from a closed socket can

Re: [Bug 203735] Transparent interception of ipv6 with squid and pf causes panic

On Sun, Mar 19, 2017 at 9:41 PM, wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203735 > > Kristof Provost changed: > >What|Removed |Added >

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #45 from s...@zxy.spb.ru --- (In reply to Alexandre martins from comment #43) Can you do additional tests in this setup? 1. Lost DATA from server, FIN and first RST 2. Lost DATA from server, FIN and TWO first RST -- You are

Re: Are ./valte-ctl and ./bridge friends or competitors?

2017-03-20 10:51 GMT+01:00 Harry Schmalzbauer : > Bezüglich Vincenzo Maffione's Nachricht vom 18.03.2017 09:29 (localtime): > >… > >>> Actually, there is pending work on bhyve and netmap, that is going to > be > >>> merged soon, available at

Re: Are ./valte-ctl and ./bridge friends or competitors?

Bezüglich Vincenzo Maffione's Nachricht vom 18.03.2017 09:29 (localtime): >… >>> Actually, there is pending work on bhyve and netmap, that is going to be >>> merged soon, available at https://github.com/vmaffione/freebsd/ in >>> branch ptnet-head. >>> >>> If you are interested, here there is some

[Bug 217862] ixgbe broken after 315333

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217862 --- Comment #2 from la...@fit.vutbr.cz --- Fix is ok, can be closed. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list

[Bug 217606] Bridge stops working after some days

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217606 Fabian Keil changed: What|Removed |Added CC|

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #43 from Alexandre martins --- I tested on Linux. Its TCP stack just continue to reset the connection by increment its sequence. -> SYN (seq 1) <- SYN/ACK (seq 80 ACK 1) -> ACK (seq 1 ACK 81)

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Vincenzo Maffione's Nachricht vom 17.03.2017 22:28 (localtime): > Two things here: > > - We pushed an important fix to stable/11 1-2 months ago, that prevents > panic on emulated netmap mode. Maybe you are still getting that panic > because you are using an older stable/11 image, you

[Bug 217606] Bridge stops working after some days

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217606 --- Comment #12 from Aiko Barz --- I am sorry… We had a spontaneous failover[1] at Saturday once more. Since I installed the latest firmware blobs for every piece of hardware, what can I do now? I don't find anything

[Bug 217862] ixgbe broken after 315333

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217862 Eric Joyner changed: What|Removed |Added Status|New |Closed

Re: [panic] netmap(4) and if_lagg(4)

2017-03-20 10:40 GMT+01:00 Harry Schmalzbauer : > Bezüglich Vincenzo Maffione's Nachricht vom 17.03.2017 22:28 (localtime): > > Two things here: > > > > - We pushed an important fix to stable/11 1-2 months ago, that prevents > > panic on emulated netmap mode. Maybe you are

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #50 from Michael Tuexen --- (In reply to Michael Tuexen from comment #49) I have added a packetdrill script to show how Linux handles the reception of data when the user called closed before the data is

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #62 from Michael Tuexen --- (In reply to slw from comment #61) I don't see why just sending a RST is not allowed. The RFC describes a graceful termination of a TCP connection. We are in a situation where it

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #61 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #60) > Well, the server knows that he has to drop incoming data, since the > application > has closed the socket and there is new data to deliver. I guess

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #63 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #62) Accepted RST can cause silent, immediatly closing connection by client. No acknowledged will be sent to server (in case of serevr responce will be

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #47 from Alexandre martins --- Created attachment 180997 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180997=edit Linux server, long delay between header and data Capture using

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #48 from s...@zxy.spb.ru --- (In reply to Mike Karels from comment #41) > Yes, if new data are received after the close, there is no way to deliver > data anywhere. If we ack it, the peer may just keep sending data, the

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #46 from Alexandre martins --- Created attachment 180996 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180996=edit Linux server, short delay between header and data Capture using

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #49 from Michael Tuexen --- Created attachment 180999 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180999=edit packetdrill script to show how Linux handles data on closed socket -- You are

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #52 from Michael Tuexen --- I ran the script on Ubuntu 16.10 (kernel 4.8). Not sure if the behaviour depends on the version... @Alexandre: Can you figure out whether the server calls shutdown() or close()?

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #54 from Michael Tuexen --- (In reply to slw from comment #51) Right. I updated the script. The behaviour hasn't changed. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #55 from Alexandre martins --- (In reply to Michael Tuexen from comment #52) In all of my tests, the server call close() because of the error. I didn't check the shutdown(.., SHUT_WR) case.

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #56 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #54) 1. Linux generated RST w/ ACK. socket don't moved to CLOSED state? 2. This is also wrong behavior: server try to reset connection, client ignore this

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #57 from Michael Tuexen --- (In reply to Alexandre martins from comment #55) Great. That is what I'm also testing. It seems that the trace with the long delay shows the same as my testing. However, the trace

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #58 from Michael Tuexen --- (In reply to slw from comment #56) > 1. Linux generated RST w/ ACK. socket don't moved to CLOSED state? Linux generates a RST, not a RST-ACK. I guess it is moved to the CLOSED

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #59 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #58) > Linux generates a RST, not a RST-ACK. May bad, yes > You are right, user data is lost (the second part of the request). There is > no way around

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #60 from Michael Tuexen --- (In reply to slw from comment #59) > No, different data: server response. And no reasson to not deliver/resend > it to client. Well, the server knows that he has to drop incoming

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #51 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #50) === +0.00 write(4, ..., 395) = 395 +0.00 > P. 1:396(395) ack 46 win 58 +0.00 close(4) = 0 +0.00 > F. 396:396(0) ack 46 win 58 +0.00 < P. 46:54(8) ack

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #53 from Michael Tuexen --- Created attachment 181000 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=181000=edit Updated packetdrill script to show how Linux handled data on closed socket This

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #66 from Michael Tuexen --- (In reply to slw from comment #65) > This is wrong behaviour. This is cause lost of server data. No, the loss of data is caused by the application calling close() *before*

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #64 from Michael Tuexen --- (In reply to slw from comment #63) > Accepted RST can cause silent, immediatly closing connection by client. > No acknowledged will be sent to server (in case of serevr responce

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #65 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #64) > No. The server sends a RST and move the connection to CLOSED. The connection > is > terminated immediately from the server perspective. This is

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #44 from Michael Tuexen --- (In reply to Alexandre martins from comment #43) Please share a .pcap file. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #67 from s...@zxy.spb.ru --- (In reply to Michael Tuexen from comment #66) > No, the loss of data is caused by the application calling close() *before* > incoming user data arrived. Loss of sended application data caused by

Re: Are ./valte-ctl and ./bridge friends or competitors?

Bezüglich Vincenzo Maffione's Nachricht vom 20.03.2017 12:50 (localtime): … >> So to summarize for newbies exploring netmap(4) world in combination >> with physical uplinks and virtual interfaces, it's important to do the >> following uplink NIC configuration (ifconfig(8)): >> -rxcsum -txcsum