netdev - Re: [Query]: DSA Understanding

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] [day] [month] [year] [list]

Date:   Tue, 14 Aug 2018 12:49:41 +0100
From:   "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev <netdev@...r.kernel.org>
Subject: Re: [Query]: DSA Understanding

Hi Florian,

On Mon, Aug 13, 2018 at 7:57 PM Florian Fainelli <f.fainelli@...il.com> wrote:
>
> 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.
>
That did the trick thank you, following is my setup
lan0 = 192.168.0.1
PC1 = 192.168.0.10
lan4 = 192.168.0.4
PC2 = 192.168.0.11

route add 192.168.0.11  gw 192.168.0.4
route add 192.168.0.10  gw 192.168.0.1

And now ping works either ways. Is this setup for adding the route a valid way
to do it ? Or is there some standard way I need to follow which I am missing.

> 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.
>
too take care of this now I making sure the skb->len is padded to VLAN_ETH_ZLEN
in tag_ksz.c ksz_xmit() function.

Cheers,
--Prabhakar Lad