lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 13 Aug 2018 11:57:45 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     "Lad, Prabhakar" <prabhakar.csengg@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     netdev <netdev@...r.kernel.org>
Subject: Re: [Query]: DSA Understanding

On 08/13/2018 08:58 AM, Lad, Prabhakar wrote:
> Hi Andrew/Florain,
> 
> On Mon, Aug 13, 2018 at 2:38 PM Andrew Lunn <andrew@...n.ch> wrote:
>>
>>>> I agree, this should be padding packets correctly, can you still
>>>> instrument cpsw to make sure that what comes to its ndo_start_xmit() is
>>>> ETH_ZLEN + tag_len or more?
>>>>
>>> Yes I can confirm the skb->len is always >= 62 (ETH_ZLEN + 2)
>>
>> Which switch are you using?
>>
>> Marvell switches use either 4 or 8 bytes of tag. Broadcom has 4, KSZ
>> has 1 for packets going to the switch, lan9303 has 4, mtd uses 4, qca
>> has 2.
>>
> I am using the KSZ switch. for Ingress it has 1 byte and for Egress it
> has 2 bytes.
> I came across patch [1] and padded 2 more bytes in ksz_xmit() and I was
> successfully able to ping from lan4 to PC. Thank you very much for
> your guidance/support.
> 
> Now I have stumbled into a different issue:
> 
> Case 1 Works:
> =================
> lan0 = 192.168.0.1
> PC1 = 192.168.0.10
> For the above ping works from both directions.
> 
> CASE 2 Doesn’t Work:
> =========================
> lan0 = 192.168.0.1
> PC1 = 192.168.0.10
> lan4 = 192.168.0.4
> PC2 = 192.168.0.11
> 
> Ping from lan0 to PC1 and PC1 to lan0 works
> But ping from PC2 to lan4 and lan4 to PC2 fails.
> 
> CASE 3 Works:
> =========================
> lan0 = 192.168.0.1
> PC1 = 192.168.0.10
> lan4 = 192.168.4.4
> PC2 = 192.168.4.11
> 
> With the above setup ping works.
> 
> [Query] Why does ping fail in case 2. Any thoughts what I am missing here ?
> or is it the expected behaviour ?

For case 2, what I suspect is happening is that the machine that has
lan1/lan4, because you have put lan1/lan4 in the same subnet, does not
know how to respond to PC2 because it is unable to select an appropriate
output interface. In such cases, you might have to add an explicit /32
route that forces telling the kernel that PC2 is accessible via lan2.

Andrew, do you see an other explanation for that?

> 
> [1] https://lore.kernel.org/patchwork/patch/851457/

This patch works, but I think it is still working by "accident" in that
if you have both VLAN tags + KSZ tag, you would likely still be too
short by a few bytes.
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ