From: "M. Braun"
Given the following bridge rules:
1. ip protocol icmp accept
2. ether type vlan vlan type ip ip protocol icmp accept
The are currently both dumped by "nft list ruleset" as
1. ip protocol icmp accept
2. ip protocol icmp accept
Though, the netlink code actually is different
brid
From: Michael Braun
When using jumbo packets and overrunning rx queue with napi enabled,
the following sequence is observed in gfar_add_rx_frag:
| lstatus | | skb |
t | lstatus, size, flags| first | len, data_len, *ptr |
From: Michael Braun
When using jumbo packets and overrunning rx queue with napi enabled,
the following sequence is observed in gfar_add_rx_frag:
| lstatus | | skb |
t | lstatus, size, flags| first | len, data_len, *ptr |
Am 04.03.2021 21:17, schrieb Vladimir Oltean:
Just for my understanding, do you have a reproducer for the issue?
I notice you haven't answered Claudiu's questions posted on v1.
On LS1021A I cannot trigger this apparent hardware issue even if I
force
RX overruns (by reducing the ring size). Judgi
Hi,
sorry I missed the mail.
Am 04.03.2021 11:05, schrieb Claudiu Manoil:
Could you help provide some context, e.g.:
On what board/soc were you able to trigger this issue?
I have an OpenWRT running on P1020WLAN boards and have IPsec for some
gretap tunnel configured.
I run iperf3 -s on the A
Am 07.05.2020 13:06, schrieb Nikolay Aleksandrov:
That isn't correct, have you tested with a recent kernel?
After:
commit 804b854d374e
Author: Nikolay Aleksandrov
Date: Fri Mar 30 13:46:19 2018 +0300
Thanks for pointing out, I'm sorry my test kernel was too old.
Regards,
Michael
Am 09.01.2017 13:15, schrieb Johannes Berg:
That is bridge fdb entries (need to) expire so the bridge might
"forget" a still-connected station not sending but only consuming
broadcast traffic.
Ok, that I don't know. Somehow if you address a unicast packet there
the bridge has to make a decision
Please ignore this patch, something went wrong.
Regards,
M. Braun
Am 25.09.2016 20:52, schrieb Michael Braun:
Adjusting iproute2 utility to support new macvlan link type mode called
"source".
Example of commands that can be applied:
ip link add link eth0 name macvlan0 type macvlan mode sourc
Am 05.10.2016 12:19, schrieb Johannes Berg:
on both ends. Furthermore, I've seen a few mobile phone stations
locally that indicate qos support but won't complete DHCP if their
broadcasts are encapsulated as A-MSDU. Though they work fine with
this series approach.
Presumably those phones also do
Am 05.10.2016 13:58, schrieb Johannes Berg:
Anyway, perhaps this needs to change to take DMS/per-station into
account?
Then again, this kind of setting - global multicast-to-unicast -
fundamentally *cannot* be done on a per-station basis, since if you
enable it for one station and not for anoth
10 matches
Mail list logo
