[Bug 253836] ifconfig reports 2x actual received bytes with em / igb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253836 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org Keywords||IntelNetworking -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 233072] ipfw table 1 create type number: Table creation failed: Operation not supported
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233072 Andrey V. Elsukov changed: What|Removed |Added CC||a...@freebsd.org --- Comment #3 from Andrey V. Elsukov --- Created attachment 222815 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=222815&action=edit proposed patch Can you test this patch? -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 253836] ifconfig reports 2x actual received bytes with em / igb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253836 Andrey V. Elsukov changed: What|Removed |Added Resolution|--- |DUPLICATE CC||a...@freebsd.org Status|New |Closed --- Comment #1 from Andrey V. Elsukov --- *** This bug has been marked as a duplicate of bug 253583 *** -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 233072] ipfw table 1 create type number: Table creation failed: Operation not supported
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233072 --- Comment #4 from Eugene Grosbein --- (In reply to Andrey V. Elsukov from comment #3) I've just tested it with my 11.4-STABLE/amd64 workstation. The patch works just fine, please commit. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 233072] ipfw table 1 create type number: Table creation failed: Operation not supported
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233072 --- Comment #5 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=13ad237a19b7368124483d9d1dc3258c27880fef commit 13ad237a19b7368124483d9d1dc3258c27880fef Author: Andrey V. Elsukov AuthorDate: 2021-02-25 13:57:47 + Commit: Andrey V. Elsukov CommitDate: 2021-02-25 13:57:47 + ipfw: make algo name argument optional for some table types Most of table types currently supported by ipfw have only one algorithm implementation. When user creates such tables, allow to omit algo name in arguments. E.g. now it is possible: ipfw table T1 create type number ipfw table T2 create type iface ipfw table T3 create type flow PR: 233072 MFC after: 1 week Sponsored by: Yandex LLC sbin/ipfw/tables.c | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 233072] ipfw table 1 create type number: Table creation failed: Operation not supported
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233072 Andrey V. Elsukov changed: What|Removed |Added Assignee|i...@freebsd.org|a...@freebsd.org -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: option FIB_ALGO and dpdk_lpm4
W dniu 24.02.2021 o 22:40, Alexander V. Chernikov pisze: > 24.02.2021, 10:50, "Olivier Cochard-Labbé" : >> On Wed, Feb 24, 2021 at 1:22 AM Marek Zarychta < >> zarych...@plan-b.pwste.edu.pl> wrote: >> >>> > >>> >>> Please let me ask only one final question. Does adding: >>> >>> net.route.algo.inet.algo=dpdk_lpm4 >>> net.route.algo.inet6.algo=dpdk_lpm6 >>> >>> to /etc/sysctl.conf make any sense? I see that right FIB_ALGO is >>> automatically picked up when the module is available. >> >> My understanding is the network stack will switch to the optimum algorithm >> regarding the number of routes installed. >> cf "Automatic algorithm selection" chapter here: >> https://reviews.freebsd.org/D27401 >> >> So you don't need to set this sysctl. > To add some points to Olivier's explanation: > indeed, algorithm selection SHOULD happen automatically. > Some things to keep in mind: when the BGP sessions flaps kernel routes may go > from the full-view to near-zero and vice versa. > In that case, automatic selection will switch to lockless_radix for the range > between 10..1000 routes (or similar). Lockless radix schedules rebuild for > every change, so the speed of deleting/adding first 1k routes may be slower > than expected. Hello Olivier and Alexander, thank you for explaining this. As far as I have tested setting this from sysctl.conf works for current fib. So to avoid early switching of route algorithms and speed up initial filling of route tables with 850k+ ip routes and 100k+ ip6 routes I'll keep both those setting in /etc/sysctl.conf. -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
[Bug 218508] Tunneling and aliases using the tun device, reusing a destination address works with IPv4, but not IPv6
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218508
Denton Gentry changed:
What|Removed |Added
CC||de...@geekhold.com
--- Comment #2 from Denton Gentry ---
We've been encountering this in
https://github.com/tailscale/tailscale/issues/1307
The problem occurs because rtrequest1_fib returns EEXIST.
root@freebsd12:~ # dtrace -n 'fbt:::return /(int)arg1 == EEXIST / { stack(); }'
-c "ifconfig tun0 inet6 fd7a:115c:a1e0:ab12:4843:cd96:625c:1f1b
fd7a:115c:a1e0:ab12:4843:cd96:625c:1f1b prefixlen 128"
dtrace: description 'fbt:::return ' matched 29364 probes
ifconfig: ioctl (SIOCAIFADDR): File exists
dtrace: pid 1175 exited with status 1
CPU IDFUNCTION:NAME
1 52657rtrequest1_fib:return
kernel`rtinit+0x421
kernel`in6_update_ifa+0xc6b
kernel`in6_control+0x96f
kernel`ifioctl+0x47f
kernel`kern_ioctl+0x2b7
kernel`sys_ioctl+0xfa
kernel`amd64_syscall+0x387
kernel`0x8106785e
That happens because rn_addroute returns NULL:
rn_addroute(void *v_arg, void *n_arg, struct radix_head *head,
struct radix_node treenodes[2])
...
/*
* Deal with duplicated keys: attach node to previous instance
*/
saved_tt = tt = rn_insert(v, head, &keyduplicated, treenodes);
if (keyduplicated) {
for (t = tt; tt; t = tt, tt = tt->rn_dupedkey) {
#ifdef RADIX_MPATH
/* permit multipath, if enabled for the family */
...
#endif
if (tt->rn_mask == netmask)
return (0);
There is a bunch of code within the #ifdef RADIX_MPATH block above. Enabling
RADIX_MPATH in the kernel config does allow the tun0 address assignment to
succeed, though I haven't fully tested if it works as expected.
It looks like this behavior was understood, in a comment in
sys/netinet6/in6.c:in6_notify_ifa from 2004:
/*
* If a new destination address is specified for a point-to-point
* interface, install a route to the destination as an interface
* direct route.
* XXX: the logic below rejects assigning multiple addresses on a p2p.
* interface that share the same destination.
*/
plen = in6_mask2len(&ia->ia_prefixmask.sin6_addr, NULL); /* XXX */
if (!(ia->ia_flags & IFA_ROUTE) && plen == 128 &&
ia->ia_dstaddr.sin6_family == AF_INET6) {
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: AW: panic: sackhint bytes rtx >= 0
On 24/02/2021 00:40, Scheffenegger, Richard wrote:
> Hi Andriy,
>
> I guess I am currently the person who has the most recent knowledge about that
> part of the base stack…
>
> Do you happen to have more (preceding) information about this, or a way to
> reproduce this?
Unfortunately, no. It "just happened".
There was no unusual activity at the time of the crash.
At least, from a user / administrator perspective.
> Are you running any special stack (RACK, BBR) which may have switched back to
> the base stack in the middle of a loss recovery (I suspected at one point that
> this may cause issues, potentially)?
I do not have any customizations to the network stack, everything at defaults.
> Or was something done with the ipfw that may have temporarily impacted a tcp
> session?
I use pf as a firewall. I did not touch it at the time of the crash.
> The accounting with sack_bytes_rexmit is rather old, and not touched recently
> (but the sackhint struct was changed recently, and other/additional scoreboard
> accounting was added).
>
> (kgdb) p *cur
> $1 = {start = 3846347980, end = 3846352300, rxmit = 3846352300, scblink =
> {tqe_next = 0xf8013da5a220, tqe_prev = 0xf80754818930}}
>
> This indicates, that the current hole in the SACK scoreboard (3 segments of
> size
> 1440 bytes) were retransmitted (rxmit == end), before the current
> acknowledgement came back.
>
> Thus the expectation is, that sackhint.sack_bytes_rexmit also has a value of
> at
> least that number of bytes (4320). It is increased in tcp_output() for each
> packet leaving while performing a retransmission.
>
> But this is the peculiar part:
>
> (kgdb) p tp@entry->sackhint.sack_bytes_rexmit
> $3 = -1440
>
> Indicating negative one packet had been retransmitted before (thus subtracting
> the hole, which was previously retransmitted violates the invariant). And the
> only piece of code decrementing it appears to be in tcp_output() during
> non-permanent error handling…
>
> All updates to sackhint should be protected by the INPLOCK, so even if the rx
> and tx paths are running on different core, the sack_bytes_rexmit should never
> become negative.
>
> The sack blocks returned indicate that (with snd.una as zero baseline, in
> segments) the client knows about segments 2..34 and 35..47.
>
> The first hole has shrunk from the right (unusual; possible when two
> retransmissions were lost again, or the 3 segment originally sent, delayed by
> ~50 segments (unlikely).
>
> Sorry to not being able to spot something obvious right away…
Thank you very much for the response.
Unfortunately, I cannot help much in terms of re-creating the issue as for me it
really "just happened" without me touching anything. There were just some
HTTP(S) and SSH sessions, the usual stuff.
If you need anything else from the crash dump, please let me know.
> *Von:*tue...@freebsd.org
> *Gesendet:* Dienstag, 23. Februar 2021 22:21
> *An:* Richard Scheffenegger
> *Betreff:* Fwd: panic: sackhint bytes rtx >= 0
>
>
>
> *NetApp Security WARNING*: This is an external email. Do not click links or
> open
> attachments unless you recognize the sender and know the content is safe.
>
>
>
> FYI
>
>
>
> Begin forwarded message:
>
>
>
> *From: *Andriy Gapon mailto:a...@freebsd.org>>
>
> *Subject: panic: sackhint bytes rtx >= 0*
>
> *Date: *23. February 2021 at 22:02:20 CET
>
> *To: *FreeBSD Current mailto:curr...@freebsd.org>>,
> n...@freebsd.org
>
>
>
>
> Got this panic on 13.0-STABLE 4b2a20dfde9c using a custom kernel with
> INVARIANTS
> enabled.
> Below is some information from the crash dump.
> If anyone has any clues, suggestions, etc, please help.
> I will try to help you to help me the best I can.
>
> #0 doadump (textdump=textdump@entry=1)
> at /usr/devel/git/trant/sys/kern/kern_shutdown.c:399
> #1 0x808396b2 in kern_reboot (howto=260)
> at /usr/devel/git/trant/sys/kern/kern_shutdown.c:486
> #2 0x80839d07 in vpanic (
> fmt=0x80cbd551 "sackhint bytes rtx >= 0",
> ap=0xfe0120b9e6d0)
> at /usr/devel/git/trant/sys/kern/kern_shutdown.c:919
> #3 0x808398b3 in panic (fmt=)
> at /usr/devel/git/trant/sys/kern/kern_shutdown.c:843
> #4 0x8098a82c in tcp_sack_doack (tp=,
> tp@entry=0xf807548187f0, to=,
> to@entry=0xfe0120b9e780, th_ack=)
> at /usr/devel/git/trant/sys/netinet/tcp_sack.c:691
> #5 0x80983699 in tcp_do_segment (m=0xf8029868ca00,
> m@entry=,
> th=,
> th@entry=,
> so=0xf804e7359b10,
> so@entry=,
> tp=0xf807548187f0,
> tp@entry=,
> drop_hdrlen=60,
> drop_hdrlen@entry=,
> tlen=,
> tlen@entry=,
> iptos=72 'H',
> iptos@entry=)
> at /usr/devel/git/trant/sys/netinet/tcp_input.c:2497
> #6 0x80980d
Re: panic: sackhint bytes rtx >= 0
> On 25. Feb 2021, at 19:08, Andriy Gapon wrote:
>
> On 24/02/2021 00:40, Scheffenegger, Richard wrote:
>> Hi Andriy,
>>
>> I guess I am currently the person who has the most recent knowledge about
>> that
>> part of the base stack…
>>
>> Do you happen to have more (preceding) information about this, or a way to
>> reproduce this?
>
> Unfortunately, no. It "just happened".
> There was no unusual activity at the time of the crash.
> At least, from a user / administrator perspective.
So you did not use specific TCP stacks or congestion control modules?
>
>> Are you running any special stack (RACK, BBR) which may have switched back to
>> the base stack in the middle of a loss recovery (I suspected at one point
>> that
>> this may cause issues, potentially)?
>
> I do not have any customizations to the network stack, everything at defaults.
>
>> Or was something done with the ipfw that may have temporarily impacted a tcp
>> session?
>
> I use pf as a firewall. I did not touch it at the time of the crash.
Does pf change the packets?
>
>> The accounting with sack_bytes_rexmit is rather old, and not touched recently
>> (but the sackhint struct was changed recently, and other/additional
>> scoreboard
>> accounting was added).
>>
>> (kgdb) p *cur
>> $1 = {start = 3846347980, end = 3846352300, rxmit = 3846352300, scblink =
>> {tqe_next = 0xf8013da5a220, tqe_prev = 0xf80754818930}}
>>
>> This indicates, that the current hole in the SACK scoreboard (3 segments of
>> size
>> 1440 bytes) were retransmitted (rxmit == end), before the current
>> acknowledgement came back.
>>
>> Thus the expectation is, that sackhint.sack_bytes_rexmit also has a value of
>> at
>> least that number of bytes (4320). It is increased in tcp_output() for each
>> packet leaving while performing a retransmission.
>>
>> But this is the peculiar part:
>>
>> (kgdb) p tp@entry->sackhint.sack_bytes_rexmit
>> $3 = -1440
>>
>> Indicating negative one packet had been retransmitted before (thus
>> subtracting
>> the hole, which was previously retransmitted violates the invariant). And the
>> only piece of code decrementing it appears to be in tcp_output() during
>> non-permanent error handling…
>>
>> All updates to sackhint should be protected by the INPLOCK, so even if the rx
>> and tx paths are running on different core, the sack_bytes_rexmit should
>> never
>> become negative.
>>
>> The sack blocks returned indicate that (with snd.una as zero baseline, in
>> segments) the client knows about segments 2..34 and 35..47.
>>
>> The first hole has shrunk from the right (unusual; possible when two
>> retransmissions were lost again, or the 3 segment originally sent, delayed by
>> ~50 segments (unlikely).
>>
>> Sorry to not being able to spot something obvious right away…
>
> Thank you very much for the response.
> Unfortunately, I cannot help much in terms of re-creating the issue as for me
> it
> really "just happened" without me touching anything. There were just some
> HTTP(S) and SSH sessions, the usual stuff.
>
> If you need anything else from the crash dump, please let me know.
>
>> *Von:*tue...@freebsd.org
>> *Gesendet:* Dienstag, 23. Februar 2021 22:21
>> *An:* Richard Scheffenegger
>> *Betreff:* Fwd: panic: sackhint bytes rtx >= 0
>>
>>
>>
>> *NetApp Security WARNING*: This is an external email. Do not click links or
>> open
>> attachments unless you recognize the sender and know the content is safe.
>>
>>
>>
>> FYI
>>
>>
>>
>>Begin forwarded message:
>>
>>
>>
>>*From: *Andriy Gapon mailto:a...@freebsd.org>>
>>
>>*Subject: panic: sackhint bytes rtx >= 0*
>>
>>*Date: *23. February 2021 at 22:02:20 CET
>>
>>*To: *FreeBSD Current mailto:curr...@freebsd.org>>,
>>n...@freebsd.org
>>
>>
>>
>>
>>Got this panic on 13.0-STABLE 4b2a20dfde9c using a custom kernel with
>> INVARIANTS
>>enabled.
>>Below is some information from the crash dump.
>>If anyone has any clues, suggestions, etc, please help.
>>I will try to help you to help me the best I can.
>>
>>#0 doadump (textdump=textdump@entry=1)
>> at /usr/devel/git/trant/sys/kern/kern_shutdown.c:399
>>#1 0x808396b2 in kern_reboot (howto=260)
>> at /usr/devel/git/trant/sys/kern/kern_shutdown.c:486
>>#2 0x80839d07 in vpanic (
>> fmt=0x80cbd551 "sackhint bytes rtx >= 0",
>> ap=0xfe0120b9e6d0)
>> at /usr/devel/git/trant/sys/kern/kern_shutdown.c:919
>>#3 0x808398b3 in panic (fmt=)
>> at /usr/devel/git/trant/sys/kern/kern_shutdown.c:843
>>#4 0x8098a82c in tcp_sack_doack (tp=,
>> tp@entry=0xf807548187f0, to=,
>> to@entry=0xfe0120b9e780, th_ack=)
>> at /usr/devel/git/trant/sys/netinet/tcp_sack.c:691
>>#5 0x80983699 in tcp_do_segment (m=0xf8029868ca00,
>> m@entry=,
>> th=,
>> th@entry=,
>> so=0xf804e7359b10,
>>
Re: panic: sackhint bytes rtx >= 0
On 25/02/2021 20:20, Michael Tuexen wrote: >> On 25. Feb 2021, at 19:08, Andriy Gapon wrote: >> >> On 24/02/2021 00:40, Scheffenegger, Richard wrote: >>> Hi Andriy, >>> >>> I guess I am currently the person who has the most recent knowledge about >>> that >>> part of the base stack… >>> >>> Do you happen to have more (preceding) information about this, or a way to >>> reproduce this? >> Unfortunately, no. It "just happened". >> There was no unusual activity at the time of the crash. >> At least, from a user / administrator perspective. > So you did not use specific TCP stacks or congestion control modules? Correct. The default stack and congestion control (if any). >>> Are you running any special stack (RACK, BBR) which may have switched back >>> to >>> the base stack in the middle of a loss recovery (I suspected at one point >>> that >>> this may cause issues, potentially)? >> I do not have any customizations to the network stack, everything at >> defaults. >> >>> Or was something done with the ipfw that may have temporarily impacted a tcp >>> session? >> I use pf as a firewall. I did not touch it at the time of the crash. > Does pf change the packets? Not sure. If only this rule: scrub in all fragment reassemble All others are just block and pass (no NAT even). -- Andriy Gapon ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 253473] Possible bug in iflib, observed with vmxnet3 driver on ESXI servers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253473 --- Comment #4 from commit-h...@freebsd.org --- A commit in branch releng/13.0 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=1eb60112b22ea0d61f0d1ba4ac0cca56a0c034c8 commit 1eb60112b22ea0d61f0d1ba4ac0cca56a0c034c8 Author: Allan Jude AuthorDate: 2021-02-14 18:39:09 + Commit: Allan Jude CommitDate: 2021-02-25 20:41:10 + Use iflib_if_init_locked() during media change instead of iflib_init_locked(). iflib_init_locked() assumes that iflib_stop() has been called, however, it is not called for media changes. iflib_if_init_locked() calls stop then init, so fixes the problem. PR: 253473 Sponsored by: Juniper Networks, Inc., Klara, Inc. Approved by:re (gjb) (cherry picked from commit 922cf8ac43adc9983f9a9e05cfd838306c1ef483) sys/net/iflib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 253488] wg(4) IPv6 endpoints not supported yet
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253488 Yuichiro NAITO changed: What|Removed |Added CC||naito.yuich...@gmail.com --- Comment #1 from Yuichiro NAITO --- Hi, I wrote a patch for this problem. Please review my code. https://reviews.freebsd.org/D28933 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
