[Bug 200836] iovctl(8): Return descriptions in the returned schema reported by iovctl -S

2024-10-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200836 Mark Linimon changed: What|Removed |Added Flags|mfc-stable13?, | |mfc-stable12?

[Bug 256579] arp(8) -S doesn't honour "blackhole" keyword

2024-10-02 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256579 Mark Linimon changed: What|Removed |Added Flags|mfc-stable13?, | |mfc-stable12?,

[Bug 280110] [dummynet] pipe config bw parameter limited to 4Gbits/s (due to uint32)

2024-07-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280110 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiv

[Bug 264428] tcp: Crash in sbsndptr: panic: "%s: sockbuf %p and mbuf %p clashing" .. in sbsndptr (...) at /root/open_source/uinet/sys/kern/uipc_sockbuf.c:1025

2022-11-07 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264428 Gleb Smirnoff changed: What|Removed |Added Status|Open|Closed Resolution|---

[Bug 264428] tcp: Crash in sbsndptr: panic: "%s: sockbuf %p and mbuf %p clashing" .. in sbsndptr (...) at /root/open_source/uinet/sys/kern/uipc_sockbuf.c:1025

2022-06-06 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264428 --- Comment #2 from Gleb Smirnoff --- It looks like you are talking about some other project based on FreeBSD. In FreeBSD we don't have M_HOLE flag. Can you please tell what project/version are we talking about? -- You are receiving this

[Bug 264428] tcp: Crash in sbsndptr: panic: "%s: sockbuf %p and mbuf %p clashing" .. in sbsndptr (...) at /root/open_source/uinet/sys/kern/uipc_sockbuf.c:1025

2022-06-03 Thread bugzilla-noreply
: ||panic: "%s: sockbuf %p and ||mbuf %p clashing" .. in ||sbsndptr (...) at ||/root/open_source

[Bug 200836] iovctl(8): Return descriptions in the returned schema reported by iovctl -S

2022-05-29 Thread bugzilla-noreply
||iovctl -S Flags||maintainer-feedback?(rstone ||@FreeBSD.org), ||mfc-stable13?, ||mfc-stable12? Assignee|b

[Bug 232451] [igb] I210 NIC can not send more than ~670Mbit/s with flow control enabled.

2021-10-18 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232451 Kevin Bowling changed: What|Removed |Added Resolution|--- |FIXED Status|New

[Bug 232451] [igb] I210 NIC can not send more than ~670Mbit/s with flow control enabled.

2021-10-18 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232451 --- Comment #5 from Lev A. Serebryakov --- Looks like latest stable12 doesn't have this problem. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2021-10-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Kristof Provost changed: What|Removed |Added Resolution|--- |FIXED Status|In Prog

[Bug 256579] arp(8) -S doesn't honour "blackhole" keyword

2021-09-30 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256579 Kubilay Kocak changed: What|Removed |Added URL||https://reviews.freebsd.org

[Bug 256579] arp(8) -S doesn't honour "blackhole" keyword

2021-09-30 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256579 Alexander V. Chernikov changed: What|Removed |Added Status|New |In Progress --- Comment #

[Bug 232451] [igb] I210 NIC can not send more than ~670Mbit/s with flow control enabled.

2021-09-30 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232451 --- Comment #4 from Lev A. Serebryakov --- (In reply to Kevin Bowling from comment #3) I'll rebuild stable12 at this weekend and try. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 232451] [igb] I210 NIC can not send more than ~670Mbit/s with flow control enabled.

2021-09-30 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232451 --- Comment #3 from Kevin Bowling --- (In reply to Lev A. Serebryakov from comment #2) The most recent snapshots (2021-Sep-30) of stable12+ or main should all be pretty close with respect to igb(4). -- You are receiving this mail because:

[Bug 232451] [igb] I210 NIC can not send more than ~670Mbit/s with flow control enabled.

2021-09-30 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232451 --- Comment #2 from Lev A. Serebryakov --- (In reply to Kevin Bowling from comment #1) Should it be CURRENT or stable (12? 13?) is enough? -- You are receiving this mail because: You are the assignee for the bug.

[Bug 256579] arp(8) -S doesn't honour "blackhole" keyword

2021-09-30 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256579 Alexander V. Chernikov changed: What|Removed |Added Assignee|b...@freebsd.org|melif...@freebsd.org

[Bug 232451] [igb] I210 NIC can not send more than ~670Mbit/s with flow control enabled.

2021-09-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232451 Kevin Bowling changed: What|Removed |Added CC||kbowl...@freebsd.org --- Comment #

[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2021-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Kubilay Kocak changed: What|Removed |Added CC||a...@freebsd.org Statu

[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2021-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 --- Comment #23 from Kristof Provost --- (In reply to Kubilay Kocak from comment #22) That works for me. I have no plans to work on increasing this limit, but ae@ is working on a new and improved dummynet version which will no doubt also a

[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2021-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Kubilay Kocak changed: What|Removed |Added Flags||mfc-stable13? -- You are receivin

[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2021-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Kubilay Kocak changed: What|Removed |Added Flags|maintainer-feedback?(loos@F |maintainer-feedback?(kp@fre

[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2021-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Kristof Provost changed: What|Removed |Added CC||k...@freebsd.org --- Comment #21

[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2021-09-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 --- Comment #20 from Franco Fichtner --- Is bumping the limit from 2 to 4 Gbit/s really a solution? Wouldn't it have been better to use a 32 bit approximation using a float type? -- You are receiving this mail because: You are on t

[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2021-09-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Ozkan KIRIK changed: What|Removed |Added CC||ozkan.ki...@gmail.com --- Comment #1

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 --- Comment #15 from e94pa...@yahoo.com --- @Franco, would you be able to help to find the file equivalent to /etc/rc.conf on regular Freebsd on opnsense? I also tried to execute a NAT speed test but failed unfortunately. @Franco do you ha

[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2021-08-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Kubilay Kocak changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 Kubilay Kocak changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 --- Comment #13 from Kevin Bowling --- (In reply to e94pasch from comment #12) Thanks, this actually looks ok in both cases and the fact that it is on Chelsio eliminates a lot of other concerns one might have in the data path. I am wonderi

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 --- Comment #12 from e94pa...@yahoo.com --- Created attachment 227385 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=227385&action=edit top with PSH flags shaper off -- You are receiving this mail because: You are the assignee f

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 --- Comment #11 from e94pa...@yahoo.com --- Created attachment 227384 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=227384&action=edit top with PSH flags shaper on -- You are receiving this mail because: You are the assignee fo

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 --- Comment #10 from Kevin Bowling --- (In reply to Franco Fichtner from comment #7) We all have to work together somehow. I don't particularly care about the past or downstream project business concerns as long as everyone is doing good w

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 --- Comment #9 from Kevin Bowling --- (In reply to e94pasch from comment #8) Thanks, can you do 'top -PSH' instead? I will explain my reasoning so you can follow along. A stream is ordered and transcends the network stack on one core. Th

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-22 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 --- Comment #8 from e94pa...@yahoo.com --- Created attachment 227369 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=227369&action=edit Logs, Info and Screen shots Hello, please take a look at the information attached. Thanks! --

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-22 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 --- Comment #7 from Franco Fichtner --- As far as Kristof's line of argumentation is concerned I'll take note of the hostility that has (elsewhere) never sparked any useful result in the past. I don't blame him and I know where this is com

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-22 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 Kevin Bowling changed: What|Removed |Added CC||kbowl...@freebsd.org --- Comment #

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-22 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 --- Comment #5 from Kristof Provost --- (In reply to Franco Fichtner from comment #4) I'm sorry, but we don't support anything other than FreeBSD here. A quick diff between FreeBSD and Opnsense (I assume, I have no idea how your branching

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-22 Thread bugzilla-noreply
first time and don't know what qualifies as a good and informative report yet. We all have to deal with this situation possibly on a daily basis. I can tell you that panics exist in WFQ scheduler that haven't been worked on in years. I can also tell you that the MBPS calculation is off

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-22 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 --- Comment #3 from Kristof Provost --- (In reply to Franco Fichtner from comment #2) Franco, I can't even tell if this is a dummynet or an ALTQ problem from this report. There's nothing that can be done based on this information. Moreover

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-22 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 Franco Fichtner changed: What|Removed |Added CC||fra...@opnsense.org --- Comment

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-22 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 Kristof Provost changed: What|Removed |Added Resolution|--- |Not Enough Information

[Bug 257989] Traffic shaper unable to perform beyond 1Gbit/s limit

2021-08-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiv

[Bug 256579] arp(8) -S doesn't honour "blackhole" keyword

2021-06-13 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256579 Marek Zarychta changed: What|Removed |Added Keywords||regression CC|

Re: Multicast: membership to (*, G) group after leaving a (S, G) group

2020-07-08 Thread Fabrice Colliot
> > Can you try 12.0 using a 12-stable kernel and see if there are any > differences? > I've updated my system to 12-stable and the behavior is exactly the same. Just in case, this is what uname -a returns (I'm not that familiar with FreeBSD versioning and building): FreeBSD freebsd 12.1-STABLE F

Re: Multicast: membership to (*, G) group after leaving a (S, G) group

2020-07-07 Thread Hans Petter Selasky
On 2020-07-07 13:55, Fabrice Colliot wrote: Sorry, I forgot to mention it. I've tried on FreeBSD 11.3 and FreeBSD 12.0. Can you try 12.0 using a 12-stable kernel and see if there are any differences? --HPS ___ freebsd-net@freebsd.org mailing list

Re: Multicast: membership to (*, G) group after leaving a (S, G) group

2020-07-07 Thread Fabrice Colliot
group 224.0.0.1 mode exclude > > mcast-macaddr 01:00:5e:00:00:01 > > > > At this point, I expected to have no membership left on em1 for > 224.0.55.55 > > but ifmcstat shows that the interface is still a member of the group but > in > > unde

Re: Multicast: membership to (*, G) group after leaving a (S, G) group

2020-07-07 Thread Hans Petter Selasky
xpected to have no membership left on em1 for 224.0.55.55 but ifmcstat shows that the interface is still a member of the group but in undefined mode. I was wondering if anybody could tell me why the group membership seems to be transitioned to a (*, G) membership when all the (S, G) memberships a

Multicast: membership to (*, G) group after leaving a (S, G) group

2020-07-07 Thread Fabrice Colliot
t ifmcstat shows that the interface is still a member of the group but in undefined mode. I was wondering if anybody could tell me why the group membership seems to be transitioned to a (*, G) membership when all the (S, G) memberships are removed. Thank

[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2020-01-24 Thread bugzilla-noreply
] pipe config bw |dummynet(4): pipe config bw |parameter limited to|parameter limited to |2Gbits/s (signed integer|2Gbits/s (signed integer |limit) |limit) --- Comment #18 from Kubilay Kocak --- Thank you for

[Bug 194453] [dummynet] pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2020-01-02 Thread bugzilla-noreply
to (I'm making an example) 1Gb/s it's linear, and then it's some other curve. I'm sorry I can't find it in lists archives so we could have a proper reference. I might be wrong about the exact proposals, so don't trust me blindly, but the overall idea of the two prop

[Bug 194453] [dummynet] pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2020-01-02 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 --- Comment #16 from Andriy Gapon --- While increasing the limit from 2 Gbps to 4 Gbps is certainly an improvement, it's not a complete solution to the the problem. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 194453] [dummynet] pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2020-01-02 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 --- Comment #15 from Dani --- Created attachment 210384 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210384&action=edit Make the bandwidth internal storage an unsigned int in IPFW dummynet Patch from pfSense[1] adjusted and ap

[Bug 194453] [dummynet] pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2020-01-02 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Kubilay Kocak changed: What|Removed |Added CC||a...@freebsd.org --- Comment #14 f

[Bug 194453] [dummynet] pipe config bw parameter limited to 2Gbits/s (signed integer limit)

2020-01-02 Thread bugzilla-noreply
Summary|[dummynet] pipe config bw |[dummynet] pipe config bw |parameter is limited to |parameter limited to |2Gbits per second (signed |2Gbits/s (signed integer |integer limit) |limit) Flags

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-10-22 Thread Andriy Gapon
w libraries to, likewise, understand DN_LINK64 on > queries, and issue > DN_LINK64 when bw requests do not fit on 31 bits (on failure). > > An alternate, hack-ish approach would be to encode high speeds with > coarse granularity, > say speed 0x7fnn with n = 0.. 0xe repres

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Michael Sierchio
On Wed, Sep 25, 2019 at 7:10 AM Luigi Rizzo wrote: > ... > An alternate, hack-ish approach would be to encode high speeds with > coarse granularity, > say speed 0x7fnn with n = 0.. 0xe representing speed in > Mbits/s (so that would give > you up to 16 Pbit/s) and

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Eugene Grosbein
On 25.09.2019 20:53, Andrey V. Elsukov wrote: > On 25.09.2019 16:51, Eugene Grosbein wrote: >>> Will this break upgrades with freebsd-update? On a major upgrade, >>> it will first install the new kernel and require a reboot before >>> you run freebsd-update again to install the rest. >> >> So it w

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Luigi Rizzo
On Mon, Sep 23, 2019 at 10:43 PM Andriy Gapon wrote: > > > It seems that the userland component of ipfw/dummynet uses int for the > bandwidth > represented in bit/s. Also, int is used for passing that value from the > userland to the kernel. > > What would be the best wa

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Andrey V. Elsukov
On 25.09.2019 16:51, Eugene Grosbein wrote: >> Will this break upgrades with freebsd-update? On a major upgrade, >> it will first install the new kernel and require a reboot before >> you run freebsd-update again to install the rest. > > So it will run without dummynet pipes (traffic shaping) conf

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Eugene Grosbein
On 25.09.2019 17:27, John Hay wrote: > > > On Wed, 25 Sep 2019 at 11:16, Eugene Grosbein > wrote: > > On 25.09.2019 05:19, Rodney W. Grimes wrote: > > >> AFAIK, we never had any public ABI or stable KBI interface announced > to userland or in-kernel consumer

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Andrey V. Elsukov
On 24.09.2019 08:42, Andriy Gapon wrote: > > It seems that the userland component of ipfw/dummynet uses int for the > bandwidth > represented in bit/s. Also, int is used for passing that value from the > userland to the kernel. > > What would be the best way to extend this

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Andriy Gapon
On 25/09/2019 13:27, John Hay wrote: > > > On Wed, 25 Sep 2019 at 11:16, Eugene Grosbein > wrote: > > On 25.09.2019 05:19, Rodney W. Grimes wrote: > > >> AFAIK, we never had any public ABI or stable KBI interface announced to > userland or in-kernel consu

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread John Hay
On Wed, 25 Sep 2019 at 11:16, Eugene Grosbein wrote: > On 25.09.2019 05:19, Rodney W. Grimes wrote: > > >> AFAIK, we never had any public ABI or stable KBI interface announced to > userland or in-kernel consumers > >> and had no consumers of dummynet other than ipfw(8) binary. Just > increase typ

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Eugene Grosbein
On 25.09.2019 05:19, Rodney W. Grimes wrote: >> AFAIK, we never had any public ABI or stable KBI interface announced to >> userland or in-kernel consumers >> and had no consumers of dummynet other than ipfw(8) binary. Just increase >> type. > > Any attempt to mfc this would break KABI/userland

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-24 Thread Rodney W. Grimes
> On 24.09.2019 12:42, Andriy Gapon wrote: > > > It seems that the userland component of ipfw/dummynet uses int for the > > bandwidth > > represented in bit/s. Also, int is used for passing that value from the > > userland to the kernel. > > > >

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-24 Thread Eugene Grosbein
On 24.09.2019 12:42, Andriy Gapon wrote: > It seems that the userland component of ipfw/dummynet uses int for the > bandwidth > represented in bit/s. Also, int is used for passing that value from the > userland to the kernel. > > What would be the best way to extend this? &

dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-23 Thread Andriy Gapon
It seems that the userland component of ipfw/dummynet uses int for the bandwidth represented in bit/s. Also, int is used for passing that value from the userland to the kernel. What would be the best way to extend this? Just use a larger type? Or maybe add another field to try to preserve KBI

[Bug 233015] arp -s weird error with non-local IPs

2018-11-08 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233015 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiv

[Bug 232451] [igb] I210 NIC can not send more than ~670Mbit/s with flow control enabled.

2018-10-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232451 Lev A. Serebryakov changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are

Re: netstat(1) -s -f is broken

2018-05-29 Thread Sean Bruno
On 05/03/18 15:32, Dieter BSD wrote: > FreeBSD 10.3-RELEASE > > The fine man page promises: > netstat -i | -I interface -s [-46] [-f protocol_family | -p protocol] > [-M core] [-N system] > Display per-interface statistics for each netwo

Re: netstat(1) -s -f is broken

2018-05-05 Thread 神明達哉
At Fri, 4 May 2018 13:19:57 +0300, "Andrey V. Elsukov" wrote: > > Doesn't work with -p either. > > netstat -I lo0 -s -p udp > > :udp: no per-interface stats routine > > > > It would be very useful if this actually worked. > Only IPv6 and ICMP

Re: netstat(1) -s -f is broken

2018-05-04 Thread Andrey V. Elsukov
On 04.05.2018 00:32, Dieter BSD wrote: > Doesn't work with -p either. > netstat -I lo0 -s -p udp > :udp: no per-interface stats routine > > It would be very useful if this actually worked. Only IPv6 and ICMPv6 have per-interface statistics counters. Other protocols don

netstat(1) -s -f is broken

2018-05-03 Thread Dieter BSD
FreeBSD 10.3-RELEASE The fine man page promises: netstat -i | -I interface -s [-46] [-f protocol_family | -p protocol] [-M core] [-N system] Display per-interface statistics for each network protocol, for a particular protocol_family, or for a single

Re: Closed port RST: Any way to find out what port(s)?

2016-05-16 Thread Larry Rosenman
On 2016-05-16 12:36, Gary Palmer wrote: On Mon, May 16, 2016 at 12:31:02PM -0500, Larry Rosenman wrote: I'm seeing tons of: Limiting closed port RST response from 201 to 200 packets/sec in my log. Is there any way to see what port(s) are being pounded? sysctl net.inet.tcp.log_in_vain

Re: Closed port RST: Any way to find out what port(s)?

2016-05-16 Thread Gary Palmer
On Mon, May 16, 2016 at 12:31:02PM -0500, Larry Rosenman wrote: > I'm seeing tons of: > Limiting closed port RST response from 201 to 200 packets/sec > in my log. Is there any way to see what port(s) are being pounded? sysctl net.inet.tcp.log_in_vain=1 I expect you would get a to

Closed port RST: Any way to find out what port(s)?

2016-05-16 Thread Larry Rosenman
I'm seeing tons of: Limiting closed port RST response from 201 to 200 packets/sec in my log. Is there any way to see what port(s) are being pounded? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail:

[Bug 196252] [patch] show tcp hostcache usage in netstat -s -p tcp

2016-01-22 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196252 Marcelo Araujo changed: What|Removed |Added Assignee|freebsd-net@FreeBSD.org |ara...@freebsd.org

[Bug 202907] 10.2 on SolarFlare SFN5162F 10Gb/s NIC missing out traffic

2015-09-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202907 Andrew Rybchenko changed: What|Removed |Added Assignee|freebsd-net@FreeBSD.org |arybc...@freebsd.org -- You ar

[Bug 202907] 10.2 on SolarFlare SFN5162F 10Gb/s NIC missing out traffic

2015-09-08 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202907 --- Comment #4 from Andrew Rybchenko --- That's my fault. Since statistics support differs in HEAD (if_get_counter) and earlier stable branches (periodic update of counters in ifnet). I've forgotten to merge stable/10-specific patch. I'll c

[Bug 202907] 10.2 on SolarFlare SFN5162F 10Gb/s NIC missing out traffic

2015-09-07 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202907 --- Comment #3 from pres...@spi.net.pl --- Hi, sfxge1: flags=8843 metric 0 mtu 1500 options=6c07ab ether 00:0f:53:08:48:89 inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 nd6 options=29 me

[Bug 202907] 10.2 on SolarFlare SFN5162F 10Gb/s NIC missing out traffic

2015-09-06 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202907 Garrett Cooper,425-314-3911 changed: What|Removed |Added CC||n...@freebsd.org ---

[Bug 202907] 10.2 on SolarFlare SFN5162F 10Gb/s NIC missing out traffic

2015-09-06 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202907 --- Comment #1 from Garrett Cooper,425-314-3911 --- Not on net, but I figured this bug needs more information before it can be appropriately triaged. Please provide... - ... the ifconfig output for em0/sfxge1. - ... the output of `sysctl h

[Bug 202907] 10.2 on SolarFlare SFN5162F 10Gb/s NIC missing out traffic

2015-09-06 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202907 Mark Linimon changed: What|Removed |Added Component|tests |kern Assignee|freebsd-tes

[Bug 196252] [patch] show tcp hostcache usage in netstat -s -p tcp

2015-07-07 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196252 Glen Barber changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org -- You are

Re: Patch to reduce use of global IP ID value(s) to avoid leaking information

2015-04-13 Thread Emeric POUPON
> I'm talking about sampling the IP ID value you get in return from a PING > response. A firewall typically has multiple ports. If pinging the > gateway from any of these ports cause an increment of a shared IP ID > value, then anyone that can ping the common firewall will see the IP ID > updat

Re: Patch to reduce use of global IP ID value(s) to avoid leaking information

2015-04-12 Thread grenville armitage
On 04/05/2015 14:39, Ian Smith wrote: On Sat, 4 Apr 2015 18:11:55 +0100, Robert N. M. Watson wrote: > On 4 Apr 2015, at 16:59, Hans Petter Selasky wrote: Thankyou Robert for this most interesting dissertation. And thanks Hans for the provocation to draw it forth .. cheers from the peanut

Re: Patch to reduce use of global IP ID value(s) to avoid leaking information

2015-04-04 Thread Ian Smith
On Sat, 4 Apr 2015 18:11:55 +0100, Robert N. M. Watson wrote: > On 4 Apr 2015, at 16:59, Hans Petter Selasky wrote: Thankyou Robert for this most interesting dissertation. And thanks Hans for the provocation to draw it forth .. cheers from the peanut gallery, Ian _

Re: Patch to reduce use of global IP ID value(s) to avoid leaking information

2015-04-04 Thread Robert N. M. Watson
On 4 Apr 2015, at 19:24, Hans Petter Selasky wrote: > The IPv4 protocol was intentionally designed to be such, that in any ways > trying to make it more secure, will require additional CPU overhead, like > keeping track of 2-tuples for generating per-stream IP IDs, that it will not > be feasib

Re: Patch to reduce use of global IP ID value(s) to avoid leaking information

2015-04-04 Thread Hans Petter Selasky
Hi Robert, On 04/04/15 19:11, Robert N. M. Watson wrote: and it's not clear it will offer practical benefit nor allow the implementation to be at all efficient -- which is far more important to most FreeBSD users Then what Putin stated public last year is absolutely true: http://www.theguard

Re: Patch to reduce use of global IP ID value(s) to avoid leaking information

2015-04-04 Thread Robert N. M. Watson
On 4 Apr 2015, at 16:59, Hans Petter Selasky wrote: > I think you confuse what I'm trying to explain to you from the responses I > get. I'm not talking about putting data into the IP ID field or other IP > fields, which then someone at the receiving end picks out and stores. This is > well kno

Re: Patch to reduce use of global IP ID value(s) to avoid leaking information

2015-04-04 Thread Hans Petter Selasky
On 04/04/15 16:13, Hans Petter Selasky wrote: Hi Robert, On 04/04/15 14:54, Robert N. M. Watson wrote: Covert and side channels are inherent to the design of contemporary processors and operating systems -- via caches, memory bandwidth, OS scheduling, statistics, clock drift due to temperature,

Re: Patch to reduce use of global IP ID value(s) to avoid leaking information

2015-04-04 Thread Hans Petter Selasky
Hi Robert, On 04/04/15 14:54, Robert N. M. Watson wrote: Covert and side channels are inherent to the design of contemporary processors and operating systems -- via caches, memory bandwidth, OS scheduling, statistics, clock drift due to temperature, protocol counters, rate limiters, etc. The inh

Re: Patch to reduce use of global IP ID value(s) to avoid leaking information

2015-04-04 Thread Robert N. M. Watson
On 4 Apr 2015, at 09:40, Hans Petter Selasky wrote: >> On 04/03/15 23:36, Gleb Smirnoff wrote: >> The documentation on net.inet.ip.random_id is solid and doesn't need the >> text from your commit. > > Let me detail a bit more. The old text describing "random_id" clearly gives > the wrong impres

Re: Patch to reduce use of global IP ID value(s) to avoid leaking information

2015-04-04 Thread Hans Petter Selasky
Hi Gleb, On 04/03/15 23:36, Gleb Smirnoff wrote: The documentation on net.inet.ip.random_id is solid and doesn't need the text from your commit. Let me detail a bit more. The old text describing "random_id" clearly gives the wrong impression. It says that information is only leaking one way.

Re: Patch to reduce use of global IP ID value(s) to avoid leaking information

2015-04-03 Thread Hans Petter Selasky
about this one. P.S. Let me notice again, that you give 1 hour and 40 minutes for review. Why so impatient? The paragraph was sitting there without modification for a decade. Can it wait for at least a day? Let's talk this over at the coming BSD conference(s) face to face. I'm fine

Re: Patch to reduce use of global IP ID value(s) to avoid leaking information

2015-04-03 Thread Gleb Smirnoff
Hans, On Fri, Apr 03, 2015 at 11:16:58PM +0200, Hans Petter Selasky wrote: H> > What the hell? At Fri, 3 Apr 2015 15:41:21 +0300 (MSK) you ask: H> H> An expression like that requires a good answer. I've pulled together H> some parts and pieces from some existing code to make a test applicatio

Patch to reduce use of global IP ID value(s) to avoid leaking information

2015-04-03 Thread Hans Petter Selasky
Hi, Moving this discussion away from the committers list, like requested by Gorge N. On 04/03/15 17:14, Gleb Smirnoff wrote:>Hans, > > What the hell? At Fri, 3 Apr 2015 15:41:21 +0300 (MSK) you ask: An expression like that requires a good answer. I've pulled together some parts and piece

Re: Tov?bb?t?s: [Ipsec-tools-users] freebsd & linux setup question

2013-01-25 Thread VANHULLEBUS Yvan
tools 0.8.0 (http://ipsec-tools.sourceforge.net) > >>> > >>>Compiled with: > >>>- OpenSSL 0.9.8x 10 May 2012 (http://www.openssl.org/) > >>>- Dead Peer Detection > >>>- IKE fragmentation > >>>- Hybrid authentication > >&g

Re: Tov?bb?t?s: [Ipsec-tools-users] freebsd & linux setup question

2013-01-24 Thread Richard Kojedzinszky
76859998(0x0494ca5e) reqid=0(0x) E: rijndael-cbc 1c80b80d b006e3a3 772c2a9b 5c475213 A: hmac-md5 d43ff29c 034c896a fb2e7d1c 95f73ff5 seq=0x replay=4 flags=0x state=mature created: Jan 21 17:03:39 2013 current: Jan 21 17:05:54 2013

Re: Tov?bb?t?s: [Ipsec-tools-users] freebsd & linux setup question

2013-01-22 Thread Richard Kojedzinszky
d5 d43ff29c 034c896a fb2e7d1c 95f73ff5 seq=0x replay=4 flags=0x state=mature created: Jan 21 17:03:39 2013 current: Jan 21 17:05:54 2013 diff: 135(s)hard: 14400(s) soft: 11520(s) last: hard: 0(s) soft: 0(s)

Re: Tov?bb?t?s: [Ipsec-tools-users] freebsd & linux setup question

2013-01-22 Thread VANHULLEBUS Yvan
ent from my private network to A: > # setkey -D > A B > esp mode=tunnel spi=76859998(0x0494ca5e) reqid=0(0x) > E: rijndael-cbc 1c80b80d b006e3a3 772c2a9b 5c475213 > A: hmac-md5 d43ff29c 034c896a fb2e7d1c 95f73ff5 > seq=0x replay=4 flags=0x

  1   2   3   >