I am using "protocol ip" filters in TC to manipulate TC flower
classifiers, which are only available with "protocol ip". However,
I faced an issue that packets sent via raw sockets with ETH_P_ALL
did not match the ip filters even if they did satisfy the condition
(e.g., DHCP offer from dhcpd).
I h
On 16/03/2019 5:58 am, Florian Fainelli wrote:
On 3/15/19 1:52 AM, Phil Reid wrote:
G'day All,
I've just update from kernel 4.19 to 5.0 on a custom board that has a
marvell
dsa mv88e6085 and the phy on the mv88e6085 will only connect at 10Mb/s with
the above mentioned patch applied.
Bisecting
> Can't we use netdev_ops for this ?. That will allow any driver to just
> support this readily.
Hi Roopa
I argued this is a PHY layer status information. We don't really want
to have to modify every MAC driver to call into phylib/phylink. Yes,
we can have a netdev_ops for those drivers which ign
When playing a bit with IPv6 and XFRM I ran into a possible
issue/edge case.
In my testing I used linux 4.14.95, I was planning on testing this
with latest kernel and investigating this a bit more deeply but so
far I've not yet been able to do so... Only reason why I'm already
submitting this mess
After running into some issues with VTI code (see my VTI patches) I
decided to take a peek at the xfrmi code. I believe it has the same
problems as the VTI code for which I submitted patches.
I was planning on testing this with latest kernel but so far I've not
yet been able to do so... Only reas
Bram Yvahk wrote:
> Only send a 'need to frag' ICMP message when the "Don't Fragment" bit
> is set. If it's not set then the packet can/will be fragmented.
>
> This fixes sending an 'need to frag' message on a client that did not
> set the DF bit, i.e.:
>
> $ ping -s 1300 -M dont -c5 192.16
We've experienced an issue with VTI when the path-mtu is smaller than the size
of the "client" packet.
What happens: IPv4 packet from the client (i.e. another system in the LAN)
attempts to transmit some data; IPv4 header shows that 'DF' bit is not set but
still the client receives ICMPv4 "need-to
In the error function the 'nexthdr' of the (original) IPv6 header
was used to check for which protocol it was.
When the (original) IPv6 packet is fragmented however then nexthdr
is set to 'NEXTHDR_FRAGMENT' and this causes the code to return
early and not process the ICMP error.
Signed-off-by: Br
Only send a 'need to frag' ICMP message when the "Don't Fragment" bit
is set. If it's not set then the packet can/will be fragmented.
This fixes sending an 'need to frag' message on a client that did not
set the DF bit, i.e.:
$ ping -s 1300 -M dont -c5 192.168.235.2
PING 192.168.2
On Fri, Mar 15, 2019 at 10:56 AM Petr Machata wrote:
>
> In general, after a port is put administratively up, certain handshake
> protocols have to finish successfully, otherwise the port is left in a
> NO-CARRIER or DORMANT state. When that happens, it would be useful to
> communicate the reasons
On 17.03.2019 16:41, VDR User wrote:
> A quick comment on patch 1:
>
>> @@ -1294,6 +1295,7 @@ static void rtl_ack_events(struct rtl8169_private *tp,
>> u16 bits)
>> static void rtl_irq_disable(struct rtl8169_private *tp)
>> {
>> RTL_W16(tp, IntrMask, 0);
>> + tp->irq_enabled = 0;
A quick comment on patch 1:
> @@ -1294,6 +1295,7 @@ static void rtl_ack_events(struct rtl8169_private *tp,
> u16 bits)
> static void rtl_irq_disable(struct rtl8169_private *tp)
> {
> RTL_W16(tp, IntrMask, 0);
> + tp->irq_enabled = 0;
> }
This function is slightly different in th
> Below are two patches. The first removes an extra PCI register read in the
> interrupt handler, the second one just adds some tracing for debugging.
>
> Interesting would be whether patch 1 has an impact on the issue, and the
> trace output of patch 2 after the issue occurred (w/ or w/o patch 1).
On 16.03.2019 15:38, VDR User wrote:
>> Part of the issue though is that we don't know how reliable that test
>> was. I believe Derek he hasn't had any crashes, but he wasn't confident
>> that it had actually resolved the issue.
>
> Previously I thought I could easily & consistently reproduce the
On 16.03.2019 18:08, Alexander Duyck wrote:
> On Sat, Mar 16, 2019 at 8:12 AM Heiner Kallweit wrote:
>>
>> On 16.03.2019 15:38, VDR User wrote:
Part of the issue though is that we don't know how reliable that test
was. I believe Derek he hasn't had any crashes, but he wasn't confident
>>
15 matches
Mail list logo
