* [Query]: DSA Understanding @ 2018-07-25 8:39 Lad, Prabhakar 2018-07-25 16:19 ` Andrew Lunn 0 siblings, 1 reply; 28+ messages in thread From: Lad, Prabhakar @ 2018-07-25 8:39 UTC (permalink / raw) To: netdev Hi, We are trying to integrate a MAC to an external switch as following: +-------------------+ +------------------+ | | RGMII | | | +------------+ KSZ9897 +------ 1000baseT MDI ("LAN1") | | PORT 6 | 7-port +------ 1000baseT MDI ("LAN2") | AM572x | | Ethernet +------ 1000baseT MDI ("LAN3") | CPSW |MIImgmt | switch +------ 1000baseT MDI ("LAN4") | +-------------+ +------ 1000baseT MDI ("LAN5") | | SPI | | | | | | | | | +------ 1000baseT MII ("LAN7") | | | | +------------------+ +------------------+ I have done all the configuration required for the MAC controller and enabled the KSZ driver in the kernel, I can see the following: ~$ ip link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7e brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff 4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 5: lan1@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7e brd ff:ff:ff:ff:ff:ff 6: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7e brd ff:ff:ff:ff:ff:ff 7: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7e brd ff:ff:ff:ff:ff:ff 8: lan4@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7e brd ff:ff:ff:ff:ff:ff 9: lan5@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7e brd ff:ff:ff:ff:ff:ff 10: lan7@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7e brd ff:ff:ff:ff:ff:ff When I connect port 1 and port 5 to two different devices I can ping across them. But I am not able to ping the host/cpu port (eth0) from other ports. Do I need to create a bridge and then talk to host port ? Should CPU port come up as a different interface as cpu5 or should it remain eth0 itself ? When I get the port 1 up (ifconfig lan0 up), the device connected on other end of port1 says link is down, whereas the are connected. >> Log on host machine where switch is connected ~$ ifconfig lan0 up [ 3720.547985] ksz9477-switch spi3.0 lan0: Link is Down >> Log on device connected to port 1 [ 3629.045242] cpsw 48484000.ethernet eth0: Link is Down [ 3629.112376] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready Is the above behaviour expected ? Basically I want all the ports to talk to each other, should I be using DSA or look into swicthdev or something else. Could someone point me in the right direction. Cheers, --Prabhakar Lad ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-07-25 8:39 [Query]: DSA Understanding Lad, Prabhakar @ 2018-07-25 16:19 ` Andrew Lunn 2018-07-26 7:38 ` Lad, Prabhakar 0 siblings, 1 reply; 28+ messages in thread From: Andrew Lunn @ 2018-07-25 16:19 UTC (permalink / raw) To: Lad, Prabhakar; +Cc: netdev On Wed, Jul 25, 2018 at 09:39:50AM +0100, Lad, Prabhakar wrote: > Hi, > > We are trying to integrate a MAC to an external switch as following: > > +-------------------+ +------------------+ > | | RGMII | | > | +------------+ KSZ9897 +------ 1000baseT MDI ("LAN1") > | | PORT 6 | 7-port +------ 1000baseT MDI ("LAN2") > | AM572x | | Ethernet +------ 1000baseT MDI ("LAN3") > | CPSW |MIImgmt | switch +------ 1000baseT MDI ("LAN4") > | +-------------+ +------ > 1000baseT MDI ("LAN5") > | | SPI | | > | | | | > | | | +------ > 1000baseT MII ("LAN7") > | | | | > +------------------+ +------------------+ Please use a fixed size font, otherwise this is unreadable. > > I have done all the configuration required for the MAC controller and > enabled the KSZ driver in the kernel, I can see the following: > ~$ ip link show > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > mode DEFAULT group default qlen 1000 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state > DOWN mode DEFAULT group default qlen 1000 eth0 is you master device. NO-CARRIER is bad, since that means you cannot send/receive from from the switch. Are you using a fixed phy on the CPSW? What does your device tree look like? Andrew ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-07-25 16:19 ` Andrew Lunn @ 2018-07-26 7:38 ` Lad, Prabhakar 2018-07-26 14:08 ` Andrew Lunn 0 siblings, 1 reply; 28+ messages in thread From: Lad, Prabhakar @ 2018-07-26 7:38 UTC (permalink / raw) To: Andrew Lunn; +Cc: netdev Hi Andrew, Thanks for the reply. On Wed, Jul 25, 2018 at 5:19 PM, Andrew Lunn <andrew@lunn.ch> wrote: > On Wed, Jul 25, 2018 at 09:39:50AM +0100, Lad, Prabhakar wrote: >> Hi, >> >> We are trying to integrate a MAC to an external switch as following: >> >> +-------------------+ +------------------+ >> | | RGMII | | >> | +------------+ KSZ9897 +------ 1000baseT MDI ("LAN1") >> | | PORT 6 | 7-port +------ 1000baseT MDI ("LAN2") >> | AM572x | | Ethernet +------ 1000baseT MDI ("LAN3") >> | CPSW |MIImgmt | switch +------ 1000baseT MDI ("LAN4") >> | +-------------+ +------ >> 1000baseT MDI ("LAN5") >> | | SPI | | >> | | | | >> | | | +------ >> 1000baseT MII ("LAN7") >> | | | | >> +------------------+ +------------------+ > > Please use a fixed size font, otherwise this is unreadable. > sorry about that, Ill take care of it henceforth. >> >> I have done all the configuration required for the MAC controller and >> enabled the KSZ driver in the kernel, I can see the following: >> ~$ ip link show >> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN >> mode DEFAULT group default qlen 1000 >> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >> 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state >> DOWN mode DEFAULT group default qlen 1000 > > eth0 is you master device. NO-CARRIER is bad, since that means you > cannot send/receive from from the switch. Are you using a fixed phy on > the CPSW? What does your device tree look like? > With my earlier post, the dsa was linking to eth0, which is incorrect as the switch is connected to eth1. I had to patch the dsa to pickup eth1 instead of eth0. CPSW can support two ports internally one port is connected to KSZ9031 phy chip which is eth0 and the other port is connected to KSZ9897 chip eth1, following is the ip link dump with my patch applied. ~$ ip link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7e brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff 4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 5: lan0@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff 6: lan1@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff 7: lan2@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff 8: lan3@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff 9: lan4@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff 10: lan6@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether c4:f3:12:08:fe:7f brd ff:ff:ff:ff:ff:ff ~$ Yes I am using fixed phy on slave1, following is my dts: ethernet@48484000 { compatible = "ti,dra7-cpsw", "ti,cpsw"; ti,hwmods = "gmac"; clocks = <0x124 0x125>; clock-names = "fck", "cpts"; cpdma_channels = <0x8>; ale_entries = <0x400>; bd_ram_size = <0x2000>; mac_control = <0x20>; slaves = <0x2>; active_slave = <0x0>; cpts_clock_mult = <0x784cfe14>; cpts_clock_shift = <0x1d>; reg = <0x48484000 0x1000 0x48485200 0x2e00>; #address-cells = <0x1>; #size-cells = <0x1>; ti,no-idle; interrupts = <0x0 0x14e 0x4 0x0 0x14f 0x4 0x0 0x150 0x4 0x0 0x151 0x4>; ranges; syscon = <0x8>; status = "okay"; pinctrl-names = "default", "sleep"; pinctrl-0 = <0x126 0x127>; pinctrl-1 = <0x128 0x129>; dual_emac; linux,phandle = <0x500>; phandle = <0x500>; mdio@48485000 { compatible = "ti,cpsw-mdio", "ti,davinci_mdio"; #address-cells = <0x1>; #size-cells = <0x0>; ti,hwmods = "davinci_mdio"; bus_freq = <0xf4240>; reg = <0x48485000 0x100>; status = "okay"; pinctrl-names = "default", "sleep"; pinctrl-0 = <0x12a>; pinctrl-1 = <0x12b>; ethernet-phy@1 { reg = <0x1>; linux,phandle = <0x12c>; phandle = <0x12c>; }; }; slave@48480200 { mac-address = [00 00 00 00 00 00]; status = "okay"; phy-handle = <0x12c>; phy-mode = "rgmii"; dual_emac_res_vlan = <0x1>; }; slave@48480300 { mac-address = [00 00 00 00 00 00]; status = "okay"; phy-mode = "rgmii"; dual_emac_res_vlan = <0x2>; linux,phandle = <0xf3>; phandle = <0xf3>; fixed-link { speed = <0x3e8>; full-duplex; }; }; cpsw-phy-sel@4a002554 { compatible = "ti,dra7xx-cpsw-phy-sel"; reg = <0x4a002554 0x4>; reg-names = "gmii-sel"; }; }; spi@480ba000 { compatible = "ti,omap4-mcspi"; reg = <0x480ba000 0x200>; interrupts = <0x0 0x2b 0x4>; #address-cells = <0x1>; #size-cells = <0x0>; ti,hwmods = "mcspi4"; ti,spi-num-cs = <0x1>; dmas = <0xb2 0x46 0xb2 0x47>; dma-names = "tx0", "rx0"; status = "okay"; ti,pindir-d0-out-d1-in; ksz9477@0 { compatible = "microchip,ksz9477"; reg = <0x0>; spi-max-frequency = <0x2dc6c00>; spi-cpha; spi-cpol; ports { #address-cells = <0x1>; #size-cells = <0x0>; port@0 { reg = <0x0>; label = "lan0"; }; port@1 { reg = <0x1>; label = "lan1"; }; port@2 { reg = <0x2>; label = "lan2"; }; port@3 { reg = <0x3>; label = "lan3"; }; port@4 { reg = <0x4>; label = "lan4"; }; port@5 { reg = <0x5>; label = "cpu"; ethernet = <0x500>; }; port@6 { reg = <0x6>; label = "lan6"; }; }; }; }; Where port 6 of ksz9897 chip is connected to slave 1 (eth1) of cpsw via rgmii interface. Following is the dmesg log: [ 2.596958] Microchip KSZ9477 dsa-0.0:00: attached PHY driver [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:00, irq=POLL) [ 2.714959] Microchip KSZ9477 dsa-0.0:01: attached PHY driver [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:01, irq=POLL) [ 2.832958] Microchip KSZ9477 dsa-0.0:02: attached PHY driver [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:02, irq=POLL) [ 2.950960] Microchip KSZ9477 dsa-0.0:03: attached PHY driver [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:03, irq=POLL) [ 3.068958] Microchip KSZ9477 dsa-0.0:04: attached PHY driver [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:04, irq=POLL) [ 3.080953] Generic PHY dsa-0.0:06: attached PHY driver [Generic PHY] (mii_bus:phy_addr=dsa-0.0:06, irq=POLL) Cheers, --Prabhakar ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-07-26 7:38 ` Lad, Prabhakar @ 2018-07-26 14:08 ` Andrew Lunn 2018-07-26 15:20 ` Lad, Prabhakar 0 siblings, 1 reply; 28+ messages in thread From: Andrew Lunn @ 2018-07-26 14:08 UTC (permalink / raw) To: Lad, Prabhakar; +Cc: netdev > Yes I am using fixed phy on slave1, following is my dts: Posting the original DTS file is better, not the decompiled version. > > ethernet@48484000 { > compatible = "ti,dra7-cpsw", "ti,cpsw"; > ti,hwmods = "gmac"; > clocks = <0x124 0x125>; > clock-names = "fck", "cpts"; > cpdma_channels = <0x8>; > ale_entries = <0x400>; > bd_ram_size = <0x2000>; > mac_control = <0x20>; > slaves = <0x2>; > active_slave = <0x0>; > cpts_clock_mult = <0x784cfe14>; > cpts_clock_shift = <0x1d>; > reg = <0x48484000 0x1000 0x48485200 0x2e00>; > #address-cells = <0x1>; > #size-cells = <0x1>; > ti,no-idle; > interrupts = <0x0 0x14e 0x4 0x0 0x14f 0x4 0x0 0x150 0x4 > 0x0 0x151 0x4>; > ranges; > syscon = <0x8>; > status = "okay"; > pinctrl-names = "default", "sleep"; > pinctrl-0 = <0x126 0x127>; > pinctrl-1 = <0x128 0x129>; > dual_emac; > linux,phandle = <0x500>; > phandle = <0x500>; So here is 0x500 > > mdio@48485000 { > compatible = "ti,cpsw-mdio", "ti,davinci_mdio"; > #address-cells = <0x1>; > #size-cells = <0x0>; > ti,hwmods = "davinci_mdio"; > bus_freq = <0xf4240>; > reg = <0x48485000 0x100>; > status = "okay"; > pinctrl-names = "default", "sleep"; > pinctrl-0 = <0x12a>; > pinctrl-1 = <0x12b>; > > ethernet-phy@1 { > reg = <0x1>; > linux,phandle = <0x12c>; > phandle = <0x12c>; > }; > }; > > slave@48480200 { > mac-address = [00 00 00 00 00 00]; > status = "okay"; > phy-handle = <0x12c>; > phy-mode = "rgmii"; > dual_emac_res_vlan = <0x1>; > }; > > slave@48480300 { > mac-address = [00 00 00 00 00 00]; > status = "okay"; > phy-mode = "rgmii"; > dual_emac_res_vlan = <0x2>; > linux,phandle = <0xf3>; > phandle = <0xf3>; This is the actual interface you are using and it has a phandle of 0xf3. > > fixed-link { > speed = <0x3e8>; > full-duplex; > }; > }; > > cpsw-phy-sel@4a002554 { > compatible = "ti,dra7xx-cpsw-phy-sel"; > reg = <0x4a002554 0x4>; > reg-names = "gmii-sel"; > }; > }; > > spi@480ba000 { > compatible = "ti,omap4-mcspi"; > reg = <0x480ba000 0x200>; > interrupts = <0x0 0x2b 0x4>; > #address-cells = <0x1>; > #size-cells = <0x0>; > ti,hwmods = "mcspi4"; > ti,spi-num-cs = <0x1>; > dmas = <0xb2 0x46 0xb2 0x47>; > dma-names = "tx0", "rx0"; > status = "okay"; > ti,pindir-d0-out-d1-in; > > ksz9477@0 { > compatible = "microchip,ksz9477"; > reg = <0x0>; > spi-max-frequency = <0x2dc6c00>; > spi-cpha; > spi-cpol; > > ports { > #address-cells = <0x1>; > #size-cells = <0x0>; > > port@0 { > reg = <0x0>; > label = "lan0"; > }; > > port@1 { > reg = <0x1>; > label = "lan1"; > }; > > port@2 { > reg = <0x2>; > label = "lan2"; > }; > > port@3 { > reg = <0x3>; > label = "lan3"; > }; > > port@4 { > reg = <0x4>; > label = "lan4"; > }; > > port@5 { > reg = <0x5>; > label = "cpu"; > ethernet = <0x500>; So here you are pointing to the container node, not the actual interface. You talk of having to patch DSA. That i would say is wrong. You should be using the phandle of the actual interface. > }; > > port@6 { > reg = <0x6>; > label = "lan6"; > }; > }; > }; > }; > > Where port 6 of ksz9897 chip is connected to slave 1 (eth1) of cpsw > via rgmii interface. Following is the dmesg log: > > [ 2.596958] Microchip KSZ9477 dsa-0.0:00: attached PHY driver > [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:00, irq=POLL) > [ 2.714959] Microchip KSZ9477 dsa-0.0:01: attached PHY driver > [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:01, irq=POLL) > [ 2.832958] Microchip KSZ9477 dsa-0.0:02: attached PHY driver > [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:02, irq=POLL) > [ 2.950960] Microchip KSZ9477 dsa-0.0:03: attached PHY driver > [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:03, irq=POLL) > [ 3.068958] Microchip KSZ9477 dsa-0.0:04: attached PHY driver > [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:04, irq=POLL) > [ 3.080953] Generic PHY dsa-0.0:06: attached PHY driver [Generic > PHY] (mii_bus:phy_addr=dsa-0.0:06, irq=POLL) You might also need a fixed-link for the cpu port of the switch. What do the statistics counters show? Is it trying to send/receiver frames out eth1? Are bad frames received? Maybe you need to set rgmii delays? Andrew ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-07-26 14:08 ` Andrew Lunn @ 2018-07-26 15:20 ` Lad, Prabhakar 2018-07-26 15:39 ` Andrew Lunn 0 siblings, 1 reply; 28+ messages in thread From: Lad, Prabhakar @ 2018-07-26 15:20 UTC (permalink / raw) To: Andrew Lunn; +Cc: netdev On Thu, Jul 26, 2018 at 3:08 PM, Andrew Lunn <andrew@lunn.ch> wrote: >> Yes I am using fixed phy on slave1, following is my dts: > > Posting the original DTS file is better, not the decompiled version. > My bad will take care of it next time. >> >> ethernet@48484000 { >> compatible = "ti,dra7-cpsw", "ti,cpsw"; >> ti,hwmods = "gmac"; >> clocks = <0x124 0x125>; >> clock-names = "fck", "cpts"; >> cpdma_channels = <0x8>; >> ale_entries = <0x400>; >> bd_ram_size = <0x2000>; >> mac_control = <0x20>; >> slaves = <0x2>; >> active_slave = <0x0>; >> cpts_clock_mult = <0x784cfe14>; >> cpts_clock_shift = <0x1d>; >> reg = <0x48484000 0x1000 0x48485200 0x2e00>; >> #address-cells = <0x1>; >> #size-cells = <0x1>; >> ti,no-idle; >> interrupts = <0x0 0x14e 0x4 0x0 0x14f 0x4 0x0 0x150 0x4 >> 0x0 0x151 0x4>; >> ranges; >> syscon = <0x8>; >> status = "okay"; >> pinctrl-names = "default", "sleep"; >> pinctrl-0 = <0x126 0x127>; >> pinctrl-1 = <0x128 0x129>; >> dual_emac; >> linux,phandle = <0x500>; >> phandle = <0x500>; > > So here is 0x500 > >> >> mdio@48485000 { >> compatible = "ti,cpsw-mdio", "ti,davinci_mdio"; >> #address-cells = <0x1>; >> #size-cells = <0x0>; >> ti,hwmods = "davinci_mdio"; >> bus_freq = <0xf4240>; >> reg = <0x48485000 0x100>; >> status = "okay"; >> pinctrl-names = "default", "sleep"; >> pinctrl-0 = <0x12a>; >> pinctrl-1 = <0x12b>; >> >> ethernet-phy@1 { >> reg = <0x1>; >> linux,phandle = <0x12c>; >> phandle = <0x12c>; >> }; >> }; >> >> slave@48480200 { >> mac-address = [00 00 00 00 00 00]; >> status = "okay"; >> phy-handle = <0x12c>; >> phy-mode = "rgmii"; >> dual_emac_res_vlan = <0x1>; >> }; >> >> slave@48480300 { >> mac-address = [00 00 00 00 00 00]; >> status = "okay"; >> phy-mode = "rgmii"; >> dual_emac_res_vlan = <0x2>; >> linux,phandle = <0xf3>; >> phandle = <0xf3>; > > This is the actual interface you are using and it has a phandle of > 0xf3. > The dsa of_find_net_device_by_node() looks for ethernet device node, but the above node is for the cpsw slave. I tried adding 0xf3 and got probe defer, that is the reason I added 0x500 (mdio) reference to cpu switch and patched to pick up eth1 instead of eth0. >> >> fixed-link { >> speed = <0x3e8>; >> full-duplex; >> }; >> }; >> >> cpsw-phy-sel@4a002554 { >> compatible = "ti,dra7xx-cpsw-phy-sel"; >> reg = <0x4a002554 0x4>; >> reg-names = "gmii-sel"; >> }; >> }; >> >> spi@480ba000 { >> compatible = "ti,omap4-mcspi"; >> reg = <0x480ba000 0x200>; >> interrupts = <0x0 0x2b 0x4>; >> #address-cells = <0x1>; >> #size-cells = <0x0>; >> ti,hwmods = "mcspi4"; >> ti,spi-num-cs = <0x1>; >> dmas = <0xb2 0x46 0xb2 0x47>; >> dma-names = "tx0", "rx0"; >> status = "okay"; >> ti,pindir-d0-out-d1-in; >> >> ksz9477@0 { >> compatible = "microchip,ksz9477"; >> reg = <0x0>; >> spi-max-frequency = <0x2dc6c00>; >> spi-cpha; >> spi-cpol; >> >> ports { >> #address-cells = <0x1>; >> #size-cells = <0x0>; >> >> port@0 { >> reg = <0x0>; >> label = "lan0"; >> }; >> >> port@1 { >> reg = <0x1>; >> label = "lan1"; >> }; >> >> port@2 { >> reg = <0x2>; >> label = "lan2"; >> }; >> >> port@3 { >> reg = <0x3>; >> label = "lan3"; >> }; >> >> port@4 { >> reg = <0x4>; >> label = "lan4"; >> }; >> >> port@5 { >> reg = <0x5>; >> label = "cpu"; >> ethernet = <0x500>; > > So here you are pointing to the container node, not the actual > interface. You talk of having to patch DSA. That i would say is > wrong. You should be using the phandle of the actual interface. > As mentioned due to above reason. agreed the patch is wrong. >> }; >> >> port@6 { >> reg = <0x6>; >> label = "lan6"; >> }; >> }; >> }; >> }; >> >> Where port 6 of ksz9897 chip is connected to slave 1 (eth1) of cpsw >> via rgmii interface. Following is the dmesg log: >> >> [ 2.596958] Microchip KSZ9477 dsa-0.0:00: attached PHY driver >> [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:00, irq=POLL) >> [ 2.714959] Microchip KSZ9477 dsa-0.0:01: attached PHY driver >> [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:01, irq=POLL) >> [ 2.832958] Microchip KSZ9477 dsa-0.0:02: attached PHY driver >> [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:02, irq=POLL) >> [ 2.950960] Microchip KSZ9477 dsa-0.0:03: attached PHY driver >> [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:03, irq=POLL) >> [ 3.068958] Microchip KSZ9477 dsa-0.0:04: attached PHY driver >> [Microchip KSZ9477] (mii_bus:phy_addr=dsa-0.0:04, irq=POLL) >> [ 3.080953] Generic PHY dsa-0.0:06: attached PHY driver [Generic >> PHY] (mii_bus:phy_addr=dsa-0.0:06, irq=POLL) > > You might also need a fixed-link for the cpu port of the switch. > > What do the statistics counters show? Is it trying to send/receiver > frames out eth1? Are bad frames received? Maybe you need to set rgmii > delays? > Yes I can see the statistics, I was sending dhcp requests from the devices connected on lan0 and lan4 ports. ~$ ifconfig eth0 Link encap:Ethernet HWaddr C4:F3:12:08:FE:7E UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:102 eth1 Link encap:Ethernet HWaddr C4:F3:12:08:FE:7F inet6 addr: fe80::c6f3:12ff:fe08:fe7f%lo/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:879 errors:0 dropped:0 overruns:0 frame:0 TX packets:171 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:389836 (380.6 KiB) TX bytes:23128 (22.5 KiB) lan0 Link encap:Ethernet HWaddr C4:F3:12:08:FE:7F UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:660 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:336530 (328.6 KiB) TX bytes:0 (0.0 B) lan3 Link encap:Ethernet HWaddr C4:F3:12:08:FE:7F UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lan4 Link encap:Ethernet HWaddr C4:F3:12:08:FE:7F inet6 addr: fe80::c6f3:12ff:fe08:fe7f%lo/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:219 errors:0 dropped:0 overruns:0 frame:0 TX packets:85 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:36605 (35.7 KiB) TX bytes:11732 (11.4 KiB) ~$ I am bit confused on how dsa needs to be actually working, Q's 1] should I be running a dhcp server on eth1 (where switch is connected) so that devices connected on lan* devices get an ip ? 2] From the device where switch is connected if the cpu port wants to send any data to any other user ports lan* how do i do it (just open socket on eth1 or lan*) ? I wrote a simple C code to dump some data onto port with lan0 but couldn’t see anything on the device where lan0 is connected (using tcpdump). I also tried sending data from lan0 to lan4 but I couldnt see anything on tcpdump but I can ping lan0 and lan4. (I have set lan0 and lan4 as local link only) 3] What is the ideal setup for dsa to work Cheers, --Prabhakar ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-07-26 15:20 ` Lad, Prabhakar @ 2018-07-26 15:39 ` Andrew Lunn 2018-08-02 8:13 ` Lad, Prabhakar 0 siblings, 1 reply; 28+ messages in thread From: Andrew Lunn @ 2018-07-26 15:39 UTC (permalink / raw) To: Lad, Prabhakar; +Cc: netdev > I am bit confused on how dsa needs to be actually working, > Q's > 1] should I be running a dhcp server on eth1 (where switch is connected) > so that devices connected on lan* devices get an ip ? Nope. You need eth1 up, but otherwise you do not use it. Use the lanX interfaces like normal Linux interfaces. Run your dhclient on lanX, etc. > > 2] From the device where switch is connected if the cpu port wants to send > any data to any other user ports lan* how do i do it (just open > socket on eth1 or lan*) ? Just treat the lanX interfaces as normal Linux interfaces. Andrew ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-07-26 15:39 ` Andrew Lunn @ 2018-08-02 8:13 ` Lad, Prabhakar 2018-08-02 14:45 ` Andrew Lunn 0 siblings, 1 reply; 28+ messages in thread From: Lad, Prabhakar @ 2018-08-02 8:13 UTC (permalink / raw) To: Andrew Lunn; +Cc: netdev Hi Andrew, Thank for your reply. On Thu, Jul 26, 2018 at 4:39 PM, Andrew Lunn <andrew@lunn.ch> wrote: >> I am bit confused on how dsa needs to be actually working, >> Q's >> 1] should I be running a dhcp server on eth1 (where switch is connected) >> so that devices connected on lan* devices get an ip ? > > Nope. You need eth1 up, but otherwise you do not use it. Use the lanX > interfaces like normal Linux interfaces. Run your dhclient on lanX, etc. >> >> 2] From the device where switch is connected if the cpu port wants to send >> any data to any other user ports lan* how do i do it (just open >> socket on eth1 or lan*) ? > > Just treat the lanX interfaces as normal Linux interfaces. > I have some more query’s on DSA. I have manged to get the TI's cpsw slave1 connected to ksz9897 Ethernet switch chip partially working, I have PC connected to lan4(ip = 169.254..126.126) and the PC ip is 169.254.78.251, but when I ping from PC to lan4 I get Destination Host Unreachable, but where as I can see that in the tcpdump log for lan4 it does reply back, but it doesn’t reach the PC, Is there I am missing something here ? Log from the device on which switch is present: =================================== ~$ ifconfig eth0 Link encap:Ethernet HWaddr C4:F3:12:08:FE:7E UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:102 eth1 Link encap:Ethernet HWaddr C4:F3:12:08:FE:7F inet6 addr: fe80::c6f3:12ff:fe08:fe7f%lo/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:436 errors:0 dropped:0 overruns:0 frame:0 TX packets:516 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:37254 (36.3 KiB) TX bytes:51585 (50.3 KiB) lan4 Link encap:Ethernet HWaddr C4:F3:12:08:FE:7F inet addr:169.254.126.126 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::c6f3:12ff:fe08:fe7f%lo/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:436 errors:0 dropped:0 overruns:0 frame:0 TX packets:444 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:28970 (28.2 KiB) TX bytes:35214 (34.3 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1%1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:67 errors:0 dropped:0 overruns:0 frame:0 TX packets:67 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:6618 (6.4 KiB) TX bytes:6618 (6.4 KiB) ~$ tcpdump -i lan4 -v [ 661.057166] device lan4 entered promiscuous mode [ 661.061814] device eth1 entered promiscuous mode tcpdump: listening on lan4, link-type EN10MB (Ethernet), capture size 262144 bytes 07:40:20.255355 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000 tell tango-charlie.local, length 46 07:40:20.255393 ARP, Ethernet (len 6), IPv4 (len 4), Reply VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 07:40:20.360936 IP6 (flowlabel 0x970aa, hlim 255, next-header UDP (17) payload length: 53) VB4-SN00000000.mdns > ff02::fb.mdns: [udp sum o) 07:40:20.361085 IP (tos 0x0, ttl 255, id 17259, offset 0, flags [DF], proto UDP (17), length 73) VB4-SN00000000.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.78.254.169.in-addr.arpa. (45) 07:40:20.361848 IP (tos 0x0, ttl 255, id 1808, offset 0, flags [DF], proto UDP (17), length 100) tango-charlie.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 251.78.254.169.in-addr.arpa. (Cache flush) PTR tango-charlie.local. (72) 07:40:20.465933 IP6 (flowlabel 0x970aa, hlim 255, next-header UDP (17) payload length: 98) VB4-SN00000000.mdns > ff02::fb.mdns: [udp sum o) 07:40:20.466124 IP (tos 0x0, ttl 255, id 17288, offset 0, flags [DF], proto UDP (17), length 118) VB4-SN00000000.mdns > 224.0.0.251.mdns: 0 PTR (QM)? b.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.f.f.ip6.arpa. (90) 07:40:21.254161 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000 tell tango-charlie.local, length 46 07:40:21.254181 ARP, Ethernet (len 6), IPv4 (len 4), Reply VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 07:40:25.470288 IP6 (flowlabel 0x970aa, hlim 255, next-header UDP (17) payload length: 50) VB4-SN00000000.mdns > ff02::fb.mdns: [udp sum o) 07:40:31.301929 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000 tell tango-charlie.local, length 46 07:40:31.301957 ARP, Ethernet (len 6), IPv4 (len 4), Reply VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 07:40:32.319104 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000 tell tango-charlie.local, length 46 07:40:32.319131 ARP, Ethernet (len 6), IPv4 (len 4), Reply VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 07:40:33.317874 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000 tell tango-charlie.local, length 46 07:40:33.317900 ARP, Ethernet (len 6), IPv4 (len 4), Reply VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 07:40:34.317840 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000 tell tango-charlie.local, length 46 07:40:34.317866 ARP, Ethernet (len 6), IPv4 (len 4), Reply VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 ~$ ethtool -S eth1 NIC statistics: Good Rx Frames: 715 Broadcast Rx Frames: 553 Multicast Rx Frames: 162 Pause Rx Frames: 0 Rx CRC Errors: 0 Rx Align/Code Errors: 0 Oversize Rx Frames: 0 Rx Jabbers: 0 Undersize (Short) Rx Frames: 0 Rx Fragments: 0 Rx Octets: 63055 Good Tx Frames: 812 Broadcast Tx Frames: 34 Multicast Tx Frames: 283 Pause Tx Frames: 0 Deferred Tx Frames: 0 Collisions: 0 Single Collision Tx Frames: 0 Multiple Collision Tx Frames: 0 Excessive Collisions: 0 Late Collisions: 0 Tx Underrun: 0 Carrier Sense Errors: 0 Tx Octets: 85250 Rx + Tx 64 Octet Frames: 0 Rx + Tx 65-127 Octet Frames: 1287 Rx + Tx 128-255 Octet Frames: 168 Rx + Tx 256-511 Octet Frames: 72 Rx + Tx 512-1023 Octet Frames: 0 Rx + Tx 1024-Up Octet Frames: 0 Net Octets: 148305 Rx Start of Frame Overruns: 0 Rx Middle of Frame Overruns: 0 Rx DMA Overruns: 0 Rx DMA chan 0: head_enqueue: 1 Rx DMA chan 0: tail_enqueue: 813 Rx DMA chan 0: pad_enqueue: 0 Rx DMA chan 0: misqueued: 0 Rx DMA chan 0: desc_alloc_fail: 0 Rx DMA chan 0: pad_alloc_fail: 0 Rx DMA chan 0: runt_receive_buf: 0 Rx DMA chan 0: runt_transmit_bu: 0 Rx DMA chan 0: empty_dequeue: 0 Rx DMA chan 0: busy_dequeue: 668 Rx DMA chan 0: good_dequeue: 686 Rx DMA chan 0: requeue: 0 Rx DMA chan 0: teardown_dequeue: 0 Tx DMA chan 0: head_enqueue: 812 Tx DMA chan 0: tail_enqueue: 0 Tx DMA chan 0: pad_enqueue: 0 Tx DMA chan 0: misqueued: 0 Tx DMA chan 0: desc_alloc_fail: 0 Tx DMA chan 0: pad_alloc_fail: 0 Tx DMA chan 0: runt_receive_buf: 0 Tx DMA chan 0: runt_transmit_bu: 502 Tx DMA chan 0: empty_dequeue: 812 Tx DMA chan 0: busy_dequeue: 0 Tx DMA chan 0: good_dequeue: 812 Tx DMA chan 0: requeue: 0 Tx DMA chan 0: teardown_dequeue: 0 p05_rx_hi: 0 p05_rx_undersize: 0 p05_rx_fragments: 0 p05_rx_oversize: 0 p05_rx_jabbers: 0 p05_rx_symbol_err: 0 p05_rx_crc_err: 0 p05_rx_align_err: 0 p05_rx_mac_ctrl: 0 p05_rx_pause: 0 p05_rx_bcast: 34 p05_rx_mcast: 283 p05_rx_ucast: 495 p05_rx_64_or_less: 0 p05_rx_65_127: 675 p05_rx_128_255: 87 p05_rx_256_511: 50 p05_rx_512_1023: 0 p05_rx_1024_1522: 0 p05_rx_1523_2000: 0 p05_rx_2001: 0 p05_tx_hi: 0 p05_tx_late_col: 0 p05_tx_pause: 0 p05_tx_bcast: 553 p05_tx_mcast: 165 p05_tx_ucast: 0 p05_tx_deferred: 0 p05_tx_total_col: 0 p05_tx_exc_col: 0 p05_tx_single_col: 0 p05_tx_mult_col: 0 p05_rx_total: 85250 p05_tx_total: 63473 p05_rx_discards: 505 p05_tx_discards: 0 ~$ ~$ ethtool -S lan4 NIC statistics: tx_packets: 736 tx_bytes: 59572 rx_packets: 701 rx_bytes: 45521 rx_hi: 0 rx_undersize: 0 rx_fragments: 0 rx_oversize: 0 rx_jabbers: 0 rx_symbol_err: 0 rx_crc_err: 0 rx_align_err: 0 rx_mac_ctrl: 0 rx_pause: 0 rx_bcast: 602 rx_mcast: 448 rx_ucast: 495 rx_64_or_less: 562 rx_65_127: 742 rx_128_255: 169 rx_256_511: 72 rx_512_1023: 0 rx_1024_1522: 0 rx_1523_2000: 0 rx_2001: 0 tx_hi: 0 tx_late_col: 0 tx_pause: 0 tx_bcast: 582 tx_mcast: 376 tx_ucast: 0 tx_deferred: 0 tx_total_col: 0 tx_exc_col: 0 tx_single_col: 0 tx_mult_col: 0 rx_total: 148965 tx_total: 104929 rx_discards: 505 tx_discards: 0 ~$ Logs from the PC: =================================== prabhakar@tango-charlie:~/Desktop/test$ ifconfig enx00e04c68c229 enx00e04c68c229 Link encap:Ethernet HWaddr 00:e0:4c:68:c2:29 inet addr:169.254.78.251 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::7cd0:12d6:d4bb:fc8b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:209 errors:0 dropped:0 overruns:0 frame:0 TX packets:842 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:38308 (38.3 KB) TX bytes:60751 (60.7 KB) prabhakar@tango-charlie:~/Desktop/test$ ping -I enx00e04c68c229 169.254.126.126 PING 169.254.126.126 (169.254.126.126) from 169.254.78.251 enx00e04c68c229: 56(84) bytes of data. >From 169.254.78.251 icmp_seq=1 Destination Host Unreachable >From 169.254.78.251 icmp_seq=2 Destination Host Unreachable >From 169.254.78.251 icmp_seq=3 Destination Host Unreachable >From 169.254.78.251 icmp_seq=4 Destination Host Unreachable >From 169.254.78.251 icmp_seq=5 Destination Host Unreachable >From 169.254.78.251 icmp_seq=6 Destination Host Unreachable ^C --- 169.254.126.126 ping statistics --- 8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 6999ms pipe 4 prabhakar@tango-charlie:~/Desktop/test$ sudo tcpdump -i enx00e04c68c229 -v [sudo] password for prabhakar: tcpdump: listening on enx00e04c68c229, link-type EN10MB (Ethernet), capture size 262144 bytes 09:09:39.692909 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000.local tell tango-charlie, length 28 09:09:39.794135 IP6 (flowlabel 0xaf44f, hlim 255, next-header UDP (17) payload length: 54) tango-charlie.mdns > ff02::fb.mdns: [bad udp cksum 0x5fb4 -> 0x8657!] 0 PTR (QM)? 126.126.254.169.in-addr.arpa. (46) 09:09:39.794196 IP (tos 0x0, ttl 255, id 32415, offset 0, flags [DF], proto UDP (17), length 74) tango-charlie.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 126.126.254.169.in-addr.arpa. (46) 09:09:39.795280 IP (tos 0x0, ttl 255, id 37104, offset 0, flags [DF], proto UDP (17), length 102) VB4-SN00000000.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 126.126.254.169.in-addr.arpa. (Cache flush) PTR VB4-SN00000000.local. (74) 09:09:40.692890 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000.local tell tango-charlie, length 28 09:09:41.710153 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000.local tell tango-charlie, length 28 09:09:42.708884 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000.local tell tango-charlie, length 28 09:09:43.708884 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000.local tell tango-charlie, length 28 09:09:44.726124 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000.local tell tango-charlie, length 28 09:09:45.724892 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000.local tell tango-charlie, length 28 09:09:46.724887 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000.local tell tango-charlie, length 28 ^C 11 packets captured 11 packets received by filter 0 packets dropped by kernel Cheers, --Prabhakar ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-02 8:13 ` Lad, Prabhakar @ 2018-08-02 14:45 ` Andrew Lunn 2018-08-02 14:58 ` Lad, Prabhakar 0 siblings, 1 reply; 28+ messages in thread From: Andrew Lunn @ 2018-08-02 14:45 UTC (permalink / raw) To: Lad, Prabhakar; +Cc: netdev > I have PC connected to lan4(ip = 169.254..126.126) and the PC ip is > 169.254.78.251, > but when I ping from PC to lan4 I get Destination Host Unreachable, > but where as I can see > that in the tcpdump log for lan4 it does reply back, but it doesn’t > reach the PC, Is there I am missing > something here ? > > ~$ tcpdump -i lan4 -v > [ 661.057166] device lan4 entered promiscuous mode > [ 661.061814] device eth1 entered promiscuous mode > 07:40:21.254161 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > VB4-SN00000000 tell tango-charlie.local, length 46 > 07:40:21.254181 ARP, Ethernet (len 6), IPv4 (len 4), Reply > VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 Having names here does not help when you gave IP addresses above. Am i reading this correct? The PC is ARPing the switch device. The switch device is replying? What does tcpdump on the PC show? Are the ARP replies getting to it? Is the PC dropping the ARP replies? If the PC is dropping the ARP replies, take a look at the checksums. Wireshark is good at that. If the ARP replies are not making it to the PC, look at the switch statistics. ethtool -S lan4. Are the TX counts going up? Any error counts going up? Andrew ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-02 14:45 ` Andrew Lunn @ 2018-08-02 14:58 ` Lad, Prabhakar 2018-08-02 16:05 ` Andrew Lunn 0 siblings, 1 reply; 28+ messages in thread From: Lad, Prabhakar @ 2018-08-02 14:58 UTC (permalink / raw) To: Andrew Lunn; +Cc: netdev Hi Andrew, On Thu, Aug 2, 2018 at 3:45 PM, Andrew Lunn <andrew@lunn.ch> wrote: >> I have PC connected to lan4(ip = 169.254..126.126) and the PC ip is >> 169.254.78.251, >> but when I ping from PC to lan4 I get Destination Host Unreachable, >> but where as I can see >> that in the tcpdump log for lan4 it does reply back, but it doesn’t >> reach the PC, Is there I am missing >> something here ? >> >> ~$ tcpdump -i lan4 -v >> [ 661.057166] device lan4 entered promiscuous mode >> [ 661.061814] device eth1 entered promiscuous mode > >> 07:40:21.254161 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has >> VB4-SN00000000 tell tango-charlie.local, length 46 >> 07:40:21.254181 ARP, Ethernet (len 6), IPv4 (len 4), Reply >> VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 > > Having names here does not help when you gave IP addresses above. > Sorry about that. VB4-SN00000000 is the switch device and tango-charlie.local is the PC. > Am i reading this correct? The PC is ARPing the switch device. The > switch device is replying? > Yes the PC is ARPing to the switch device and from the tcpdump on swicth device lan4 I can see that its trying to send Reply ~$ tcpdump -i lan4 -v [ 1675.526326] device lan4 entered promiscuous mode [ 1675.531503] device eth1 entered promiscuous mode tcpdump: listening on lan4, link-type EN10MB (Ethernet), capture size 262144 bytes 07:57:06.133853 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000 tell tango-charlie.local, length 46 07:57:06.133893 ARP, Ethernet (len 6), IPv4 (len 4), Reply VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 07:57:07.151100 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000 tell tango-charlie.local, length 46 07:57:07.151133 ARP, Ethernet (len 6), IPv4 (len 4), Reply VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 07:57:07.703063 IP (tos 0x0, ttl 64, id 41824, offset 0, flags [DF], proto UDP (17), length 224) tango-charlie.local.netbios-dgm > 169.254.255.255.netbios-dgm: NBT UDP PACKET(138) 07:57:07.804780 IP6 (flowlabel 0x42aaa, hlim 255, next-header UDP (17) payload length: 54) VB4-SN00000000.mdns > ff02::fb.mdns: [udp sum o) 07:57:07.804961 IP (tos 0x0, ttl 255, id 13070, offset 0, flags [DF], proto UDP (17), length 74) ^C VB4-SN00000000.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.255.[ 1689.046815] device lan4 left promiscuous mode 254.169.in-addr.arpa. (46) 7 packets captured 53 packets rec[ 1689.055592] device eth1 left promiscuous mode eived by filter 40 packets dropped by kernel > What does tcpdump on the PC show? Are the ARP replies getting to it? > Is the PC dropping the ARP replies? > I dont see any Reply's on the PC with tcpdump on PC > If the PC is dropping the ARP replies, take a look at the > checksums. Wireshark is good at that. > Nor do I see anything in the wireshark. > If the ARP replies are not making it to the PC, look at the switch > statistics. ethtool -S lan4. Are the TX counts going up? Any error > counts going up? > Yes the Tx counts are going up, without any errors, following is the log: ~$ ethtool -S lan4 NIC statistics: tx_packets: 499 tx_bytes: 37105 rx_packets: 462 rx_bytes: 34138 rx_hi: 0 rx_undersize: 0 rx_fragments: 0 rx_oversize: 0 rx_jabbers: 0 rx_symbol_err: 0 rx_crc_err: 0 rx_align_err: 0 rx_mac_ctrl: 0 rx_pause: 0 rx_bcast: 402 rx_mcast: 69 rx_ucast: 0 rx_64_or_less: 361 rx_65_127: 45 rx_128_255: 34 rx_256_511: 31 rx_512_1023: 0 rx_1024_1522: 0 rx_1523_2000: 0 rx_2001: 0 tx_hi: 0 tx_late_col: 0 tx_pause: 0 tx_bcast: 14 tx_mcast: 196 tx_ucast: 0 tx_deferred: 0 tx_total_col: 0 tx_exc_col: 0 tx_single_col: 0 tx_mult_col: 0 rx_total: 43248 tx_total: 33759 rx_discards: 0 tx_discards: 0 Cheers, --Prabhakar ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-02 14:58 ` Lad, Prabhakar @ 2018-08-02 16:05 ` Andrew Lunn 2018-08-02 16:24 ` Florian Fainelli 2018-08-09 11:31 ` Lad, Prabhakar 0 siblings, 2 replies; 28+ messages in thread From: Andrew Lunn @ 2018-08-02 16:05 UTC (permalink / raw) To: Lad, Prabhakar; +Cc: netdev > I dont see any Reply's on the PC with tcpdump on PC So try ethool -S on the PC. Any packets dropped because of errors? Try turning off hardware checksums on the switch. ethtool -K. Andrew ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-02 16:05 ` Andrew Lunn @ 2018-08-02 16:24 ` Florian Fainelli 2018-08-09 11:33 ` Lad, Prabhakar 2018-08-09 11:31 ` Lad, Prabhakar 1 sibling, 1 reply; 28+ messages in thread From: Florian Fainelli @ 2018-08-02 16:24 UTC (permalink / raw) To: Andrew Lunn, Lad, Prabhakar; +Cc: netdev On 08/02/2018 09:05 AM, Andrew Lunn wrote: >> I dont see any Reply's on the PC with tcpdump on PC > > So try ethool -S on the PC. Any packets dropped because of errors? > > Try turning off hardware checksums on the switch. ethtool -K. Also make sure that cpsw is properly sending 64 bytes (including FCS) packets to the switch, some switches will just discard packets when packets are RUNT -- Florian ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-02 16:24 ` Florian Fainelli @ 2018-08-09 11:33 ` Lad, Prabhakar 2018-08-09 12:08 ` Andrew Lunn 0 siblings, 1 reply; 28+ messages in thread From: Lad, Prabhakar @ 2018-08-09 11:33 UTC (permalink / raw) To: Florian Fainelli; +Cc: Andrew Lunn, netdev Hi Florain, Thanks for your reply. On Thu, Aug 2, 2018 at 5:24 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > > > > On 08/02/2018 09:05 AM, Andrew Lunn wrote: > >> I dont see any Reply's on the PC with tcpdump on PC > > > > So try ethool -S on the PC. Any packets dropped because of errors? > > > > Try turning off hardware checksums on the switch. ethtool -K. > > Also make sure that cpsw is properly sending 64 bytes (including FCS) > packets to the switch, some switches will just discard packets when > packets are RUNT how can I dump the FCS from the switch (can I use tshark ?) Cheers, --Prabhakar Lad ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-09 11:33 ` Lad, Prabhakar @ 2018-08-09 12:08 ` Andrew Lunn 0 siblings, 0 replies; 28+ messages in thread From: Andrew Lunn @ 2018-08-09 12:08 UTC (permalink / raw) To: Lad, Prabhakar; +Cc: Florian Fainelli, netdev On Thu, Aug 09, 2018 at 12:33:30PM +0100, Lad, Prabhakar wrote: > Hi Florain, > > Thanks for your reply. > > On Thu, Aug 2, 2018 at 5:24 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > > > > > > > > On 08/02/2018 09:05 AM, Andrew Lunn wrote: > > >> I dont see any Reply's on the PC with tcpdump on PC > > > > > > So try ethool -S on the PC. Any packets dropped because of errors? > > > > > > Try turning off hardware checksums on the switch. ethtool -K. > > > > Also make sure that cpsw is properly sending 64 bytes (including FCS) > > packets to the switch, some switches will just discard packets when > > packets are RUNT > > how can I dump the FCS from the switch (can I use tshark ?) tskark running on the target will not show you the FCS. The Ethernet hardware should calculate that as it sends the packet. Wireshark on the PC might, but some Ethernet cards strip off the FCS before passing it to the stack. What is important here is the idea of a runt packet. You appear to be receiving some packets at the PC, if we can trust the statistics you showed. Are those received packets all big? Are the small ARP replies missing? Andrew ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-02 16:05 ` Andrew Lunn 2018-08-02 16:24 ` Florian Fainelli @ 2018-08-09 11:31 ` Lad, Prabhakar 2018-08-09 12:01 ` Andrew Lunn 1 sibling, 1 reply; 28+ messages in thread From: Lad, Prabhakar @ 2018-08-09 11:31 UTC (permalink / raw) To: Andrew Lunn; +Cc: netdev Hi Andrew, On Thu, Aug 2, 2018 at 5:05 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > I dont see any Reply's on the PC with tcpdump on PC > > So try ethool -S on the PC. Any packets dropped because of errors? > I dont see any drops/errors on the PC, following is the dump from PC: sudo ethtool -S enx00e04c68c229 [sudo] password for prabhakar: NIC statistics: tx_packets: 1659 rx_packets: 485 tx_errors: 0 rx_errors: 0 rx_missed: 0 align_errors: 0 tx_single_collisions: 0 tx_multi_collisions: 0 rx_unicast: 18 rx_broadcast: 295 rx_multicast: 172 tx_aborted: 0 tx_underrun: 0 > Try turning off hardware checksums on the switch. ethtool -K. > Following is the dump from the switch, the checksums are off ~$ ethtool -k eth1 Features for eth1: Cannot get device udp-fragmentation-offload settings: Operation not supported rx-checksumming: off [fixed] tx-checksumming: off tx-checksum-ipv4: off [fixed] tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: off [fixed] tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] scatter-gather: off tx-scatter-gather: off [fixed] tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: off tx-tcp-segmentation: off [fixed] tx-tcp-ecn-segmentation: off [fixed] tx-tcp-mangleid-segmentation: off [fixed] tx-tcp6-segmentation: off [fixed] udp-fragmentation-offload: off generic-segmentation-offload: off [requested on] generic-receive-offload: on large-receive-offload: off [fixed] rx-vlan-offload: off [fixed] tx-vlan-offload: off [fixed] ntuple-filters: off [fixed] receive-hashing: off [fixed] highdma: off [fixed] rx-vlan-filter: on [fixed] vlan-challenged: off [fixed] tx-lockless: off [fixed] netns-local: off [fixed] tx-gso-robust: off [fixed] tx-fcoe-segmentation: off [fixed] tx-gre-segmentation: off [fixed] tx-gre-csum-segmentation: off [fixed] tx-ipxip4-segmentation: off [fixed] tx-ipxip6-segmentation: off [fixed] tx-udp_tnl-segmentation: off [fixed] tx-udp_tnl-csum-segmentation: off [fixed] tx-gso-partial: off [fixed] tx-sctp-segmentation: off [fixed] tx-esp-segmentation: off [fixed] fcoe-mtu: off [fixed] tx-nocache-copy: off loopback: off [fixed] rx-fcs: off [fixed] rx-all: off [fixed] tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: off [fixed] l2-fwd-offload: off [fixed] hw-tc-offload: off [fixed] esp-hw-offload: off [fixed] esp-tx-csum-hw-offload: off [fixed] rx-udp_tunnel-port-offload: off [fixed] Tshark dump on the switch: ~$ tshark -i lan4 Running as user "root" and group "root". This could be dangerous. Capturing on 'lan4' [ 1482.987520] device lan4 entered promiscuous mode [ 1482.992169] device eth1 entered promiscuous mode 1 0.000000000 RealtekS_68:c2:29 ��→ Broadcast ARP 60 Who has 169.254.126.126? Tell 169.254.78.251 2 0.000062952 c4:f3:12:08:fe:7f ��→ RealtekS_68:c2:29 ARP 42 169.254.126.126 is at c4:f3:12:08:fe:7f 3 0.997115432 RealtekS_68:c2:29 ��→ Broadcast ARP 60 Who has 169.254.126.126? Tell 169.254.78.251 4 0.997142272 c4:f3:12:08:fe:7f ��→ RealtekS_68:c2:29 ARP 42 169.254.126.126 is at c4:f3:12:08:fe:7f 5 1.997036539 RealtekS_68:c2:29 ��→ Broadcast ARP 60 Who has 169.254.126.126? Tell 169.254.78.251 6 1.997063379 c4:f3:12:08:fe:7f ��→ RealtekS_68:c2:29 ARP 42 169.254.126.126 is at c4:f3:12:08:fe:7f 7 3.014232032 RealtekS_68:c2:29 ��→ Broadcast ARP 60 Who has 169.254.126.126? Tell 169.254.78.251 8 3.014252528 c4:f3:12:08:fe:7f ��→ RealtekS_68:c2:29 ARP 42 169.254.126.126 is at c4:f3:12:08:fe:7f 9 4.013008290 RealtekS_68:c2:29 ��→ Broadcast ARP 60 Who has 169.254.126.126? Tell 169.254.78.251 10 4.013031064 c4:f3:12:08:fe:7f ��→ RealtekS_68:c2:29 ARP 42 169.254.126.126 is at c4:f3:12:08:fe:7f 11 5.012951194 RealtekS_68:c2:29 ��→ Broadcast ARP 60 Who has 169.254.126.126? Tell 169.254.78.251 12 5.012970552 c4:f3:12:08:fe:7f ��→ RealtekS_68:c2:29 ARP 42 169.254.126.126 is at c4:f3:12:08:fe:7f 13 6.030173853 RealtekS_68:c2:29 ��→ Broadcast ARP 60 Who has 169.254.126.126? Tell 169.254.78.251 14 6.030192234 c4:f3:12:08:fe:7f ��→ RealtekS_68:c2:29 ARP 42 169.254.126.126 is at c4:f3:12:08:fe:7f 15 7.028911559 RealtekS_68:c2:29 ��→ Broadcast ARP 60 Who has 169.254.126.126? Tell 169.254.78.251 16 7.028947183 c4:f3:12:08:fe:7f ��→ RealtekS_68:c2:29 ARP 42 169.254.126.126 is at c4:f3:12:08:fe:7f ^C[ 1494.020087] device lan4 left promiscuous mode [ 1494.024475] device eth1 left promiscuous mode 16 packets captured Seems like the packet is not being transmitted from the switch at all ? (as ping from switch lan4 to PC fails) ~$ ping -I lan4 169.254.78.251 PING 169.254.78.251 (169.254.78.251): 56 data bytes ^C --- 169.254.78.251 ping statistics --- 24 packets transmitted, 0 packets received, 100% packet loss Cheers, --Prabhakar ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-09 11:31 ` Lad, Prabhakar @ 2018-08-09 12:01 ` Andrew Lunn 2018-08-09 12:45 ` Lad, Prabhakar 0 siblings, 1 reply; 28+ messages in thread From: Andrew Lunn @ 2018-08-09 12:01 UTC (permalink / raw) To: Lad, Prabhakar; +Cc: netdev On Thu, Aug 09, 2018 at 12:31:31PM +0100, Lad, Prabhakar wrote: > Hi Andrew, > > On Thu, Aug 2, 2018 at 5:05 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > > I dont see any Reply's on the PC with tcpdump on PC > > > > So try ethool -S on the PC. Any packets dropped because of errors? > > > I dont see any drops/errors on the PC, following is the dump from PC: > > sudo ethtool -S enx00e04c68c229 > [sudo] password for prabhakar: > NIC statistics: > tx_packets: 1659 > rx_packets: 485 > tx_errors: 0 > rx_errors: 0 > rx_missed: 0 > align_errors: 0 > tx_single_collisions: 0 > tx_multi_collisions: 0 > rx_unicast: 18 > rx_broadcast: 295 > rx_multicast: 172 > tx_aborted: 0 > tx_underrun: 0 So there are received packets at the PC. Not many unicast, mostly broadcast, which fits with ARP. What does wireshark tell you about these received packets? Are they ARP replies? Are they something else? If they are ARP replies, why are they being ignored? I don't know if tshark will show you CRC problems. Wireshark does, when you unfold a packet, and look at the fields in detail. > Seems like the packet is not being transmitted from the switch at all > ? (as ping from switch lan4 to PC fails) I don't think you can make that conclusion yet. The PC is receiving something, rx_packets=485. What are those packets? Look at the statistics along the chain, from the target to the PC. Look at the master device, lan4 and the PC. You should see about one packet per second transmitted on the master device. One packet per second transmitted on lan4, and one packet per second received on the PC. Where does this break down. Andrew ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-09 12:01 ` Andrew Lunn @ 2018-08-09 12:45 ` Lad, Prabhakar 2018-08-09 12:56 ` Andrew Lunn 0 siblings, 1 reply; 28+ messages in thread From: Lad, Prabhakar @ 2018-08-09 12:45 UTC (permalink / raw) To: Andrew Lunn; +Cc: netdev On Thu, Aug 9, 2018 at 1:02 PM Andrew Lunn <andrew@lunn.ch> wrote: > > On Thu, Aug 09, 2018 at 12:31:31PM +0100, Lad, Prabhakar wrote: > > Hi Andrew, > > > > On Thu, Aug 2, 2018 at 5:05 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > > > > I dont see any Reply's on the PC with tcpdump on PC > > > > > > So try ethool -S on the PC. Any packets dropped because of errors? > > > > > I dont see any drops/errors on the PC, following is the dump from PC: > > > > sudo ethtool -S enx00e04c68c229 > > [sudo] password for prabhakar: > > NIC statistics: > > tx_packets: 1659 > > rx_packets: 485 > > tx_errors: 0 > > rx_errors: 0 > > rx_missed: 0 > > align_errors: 0 > > tx_single_collisions: 0 > > tx_multi_collisions: 0 > > rx_unicast: 18 > > rx_broadcast: 295 > > rx_multicast: 172 > > tx_aborted: 0 > > tx_underrun: 0 > > So there are received packets at the PC. Not many unicast, mostly > broadcast, which fits with ARP. What does wireshark tell you about > these received packets? Are they ARP replies? Are they something else? > If they are ARP replies, why are they being ignored? I don't know if > tshark will show you CRC problems. Wireshark does, when you unfold a > packet, and look at the fields in detail. > > > Seems like the packet is not being transmitted from the switch at all > > ? (as ping from switch lan4 to PC fails) > > I don't think you can make that conclusion yet. The PC is receiving > something, rx_packets=485. What are those packets? > The received packets captured on the PC are MDNS and DHPC, these MDNS are causing the rx packet counter go up: 685 682.956266963 0.0.0.0 255.255.255.255 DHCP 422 DHCP Discover - Transaction ID 0x9d832fac 550 555.543322200 0.0.0.0 255.255.255.255 DHCP 422 DHCP Discover - Transaction ID 0x9d832fac 572 576.738682378 fe80::2f12:3d45:7cca:57fa ff02::fb MDNS 136 Standard query 0x0000 AAAA VB4-SN00000000.local, "QM" question SRV VB4-SN00000000._sftp-ssh._tcp.local, "QM" question 630 630.706578680 169.254.126.126 224.0.0.251 MDNS 168 Standard query response 0x0000 AAAA, cache flush fe80::c6f3:12ff:fe08:fe7f SRV, cache flush 0 0 22 VB4-SN00000000.local A, cache flush 169.254.126.126 732 728.982449369 169.254.78.251 224.0.0.251 MDNS 122 Standard query 0x0000 AAAA VB4-SN00000000.local, "QM" question A VB4-SN00000000.local, "QM" question SRV VB4-SN00000000._sftp-ssh._tcp.local, "QM" question 733 728.983534948 169.254.126.126 224.0.0.251 MDNS 168 Standard query response 0x0000 SRV, cache flush 0 0 22 VB4-SN00000000.local AAAA, cache flush fe80::c6f3:12ff:fe08:fe7f A, cache flush 169.254.126.126 > Look at the statistics along the chain, from the target to the PC. > Look at the master device, lan4 and the PC. You should see about one > packet per second transmitted on the master device. One packet per > second transmitted on lan4, and one packet per second received on the > PC. Where does this break down. > I don’t see any packets reaching the PC for the ping request. I can see the RX and TX on the switch for lan4 increasing every second. seems like the switch itself is consuming it and not forwarding(but then lan4 TX shouldn’t have incremented ?). any thoughts where I could focusing on the switch or cpsw ? Cheers, --Prabhakar Lad ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-09 12:45 ` Lad, Prabhakar @ 2018-08-09 12:56 ` Andrew Lunn 2018-08-09 15:07 ` Lad, Prabhakar 0 siblings, 1 reply; 28+ messages in thread From: Andrew Lunn @ 2018-08-09 12:56 UTC (permalink / raw) To: Lad, Prabhakar; +Cc: netdev On Thu, Aug 09, 2018 at 01:45:52PM +0100, Lad, Prabhakar wrote: > On Thu, Aug 9, 2018 at 1:02 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > On Thu, Aug 09, 2018 at 12:31:31PM +0100, Lad, Prabhakar wrote: > > > Hi Andrew, > > > > > > On Thu, Aug 2, 2018 at 5:05 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > > > > > > I dont see any Reply's on the PC with tcpdump on PC > > > > > > > > So try ethool -S on the PC. Any packets dropped because of errors? > > > > > > > I dont see any drops/errors on the PC, following is the dump from PC: > > > > > > sudo ethtool -S enx00e04c68c229 > > > [sudo] password for prabhakar: > > > NIC statistics: > > > tx_packets: 1659 > > > rx_packets: 485 > > > tx_errors: 0 > > > rx_errors: 0 > > > rx_missed: 0 > > > align_errors: 0 > > > tx_single_collisions: 0 > > > tx_multi_collisions: 0 > > > rx_unicast: 18 > > > rx_broadcast: 295 > > > rx_multicast: 172 > > > tx_aborted: 0 > > > tx_underrun: 0 > > > > So there are received packets at the PC. Not many unicast, mostly > > broadcast, which fits with ARP. What does wireshark tell you about > > these received packets? Are they ARP replies? Are they something else? > > If they are ARP replies, why are they being ignored? I don't know if > > tshark will show you CRC problems. Wireshark does, when you unfold a > > packet, and look at the fields in detail. > > > > > Seems like the packet is not being transmitted from the switch at all > > > ? (as ping from switch lan4 to PC fails) > > > > I don't think you can make that conclusion yet. The PC is receiving > > something, rx_packets=485. What are those packets? > > > The received packets captured on the PC are MDNS and DHPC, these MDNS > are causing the rx > packet counter go up: And where are these packets coming from? The target device? Or some other device on your network? > I don’t see any packets reaching the PC for the ping request. I can see the > RX and TX on the switch for lan4 increasing every second. seems like the > switch itself is consuming it and not forwarding(but then lan4 TX > shouldn’t have incremented ?). Which lan4 counters are going up? tx_packets, rx_packets, tx_errors, rx_errors are software counters, and are incremented by the DSA core. Other counters are hardware counters, and the DSA driver will read them from the actual switch port. If the hardware counters show packets are being transmitted, then the packets are probably on the cable. Andrew ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-09 12:56 ` Andrew Lunn @ 2018-08-09 15:07 ` Lad, Prabhakar 2018-08-09 15:35 ` Andrew Lunn 0 siblings, 1 reply; 28+ messages in thread From: Lad, Prabhakar @ 2018-08-09 15:07 UTC (permalink / raw) To: Andrew Lunn; +Cc: netdev Hi, On Thu, Aug 9, 2018 at 1:56 PM Andrew Lunn <andrew@lunn.ch> wrote: > > On Thu, Aug 09, 2018 at 01:45:52PM +0100, Lad, Prabhakar wrote: > > On Thu, Aug 9, 2018 at 1:02 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > > > On Thu, Aug 09, 2018 at 12:31:31PM +0100, Lad, Prabhakar wrote: > > > > Hi Andrew, > > > > > > > > On Thu, Aug 2, 2018 at 5:05 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > > > > > > > > I dont see any Reply's on the PC with tcpdump on PC > > > > > > > > > > So try ethool -S on the PC. Any packets dropped because of errors? > > > > > > > > > I dont see any drops/errors on the PC, following is the dump from PC: > > > > > > > > sudo ethtool -S enx00e04c68c229 > > > > [sudo] password for prabhakar: > > > > NIC statistics: > > > > tx_packets: 1659 > > > > rx_packets: 485 > > > > tx_errors: 0 > > > > rx_errors: 0 > > > > rx_missed: 0 > > > > align_errors: 0 > > > > tx_single_collisions: 0 > > > > tx_multi_collisions: 0 > > > > rx_unicast: 18 > > > > rx_broadcast: 295 > > > > rx_multicast: 172 > > > > tx_aborted: 0 > > > > tx_underrun: 0 > > > > > > So there are received packets at the PC. Not many unicast, mostly > > > broadcast, which fits with ARP. What does wireshark tell you about > > > these received packets? Are they ARP replies? Are they something else? > > > If they are ARP replies, why are they being ignored? I don't know if > > > tshark will show you CRC problems. Wireshark does, when you unfold a > > > packet, and look at the fields in detail. > > > > > > > Seems like the packet is not being transmitted from the switch at all > > > > ? (as ping from switch lan4 to PC fails) > > > > > > I don't think you can make that conclusion yet. The PC is receiving > > > something, rx_packets=485. What are those packets? > > > > > The received packets captured on the PC are MDNS and DHPC, these MDNS > > are causing the rx > > packet counter go up: > > And where are these packets coming from? The target device? Or some > other device on your network? > AFIK, MDNS is also kind of a bcast its sending MDNS requests and receiving itself, that’s the reason rx packets are incrementing (correct me if I am wrong) On the PC where lan4 is connected , tx has high count because of ping requests prabhakar@tango-charlie:~/Desktop/test$ ifconfig enx00e04c68c229 enx00e04c68c229 Link encap:Ethernet HWaddr 00:e0:4c:68:c2:29 inet addr:169.254.78.251 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::2f12:3d45:7cca:57fa/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:502 errors:0 dropped:0 overruns:0 frame:0 TX packets:4811 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:79843 (79.8 KB) TX bytes:252647 (252.6 KB) > > I don’t see any packets reaching the PC for the ping request. I can see the > > RX and TX on the switch for lan4 increasing every second. seems like the > > switch itself is consuming it and not forwarding(but then lan4 TX > > shouldn’t have incremented ?). > > Which lan4 counters are going up? tx_packets, rx_packets, tx_errors, > rx_errors are software counters, and are incremented by the DSA > core. Other counters are hardware counters, and the DSA driver will > read them from the actual switch port. If the hardware counters show > packets are being transmitted, then the packets are probably on the > cable. > I can see the RX and TX incrementing every second, no errors counters go up $ watch -n1 ifconfig lan4 lan4 Link encap:Ethernet HWaddr C4:F3:12:08:FE:7F inet addr:169.254.126.126 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::18b9:d16c:7ff:ab73%3201178264/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2168 errors:0 dropped:0 overruns:0 frame:0 TX packets:1724 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:117816 (115.0 KiB) TX bytes:99940 (97.5 KiB) ~$ ethtool -S eth1 NIC statistics: Good Rx Frames: 800 Broadcast Rx Frames: 729 Multicast Rx Frames: 71 Pause Rx Frames: 0 Rx CRC Errors: 0 Rx Align/Code Errors: 0 Oversize Rx Frames: 0 Rx Jabbers: 0 Undersize (Short) Rx Frames: 0 Rx Fragments: 0 Rx Octets: 65472 Good Tx Frames: 369 Broadcast Tx Frames: 16 Multicast Tx Frames: 139 Pause Tx Frames: 0 Deferred Tx Frames: 0 Collisions: 0 Single Collision Tx Frames: 0 Multiple Collision Tx Frames: 0 Excessive Collisions: 0 Late Collisions: 0 Tx Underrun: 0 Carrier Sense Errors: 0 Tx Octets: 40990 Rx + Tx 64 Octet Frames: 0 Rx + Tx 65-127 Octet Frames: 1031 Rx + Tx 128-255 Octet Frames: 73 Rx + Tx 256-511 Octet Frames: 65 Rx + Tx 512-1023 Octet Frames: 0 Rx + Tx 1024-Up Octet Frames: 0 Net Octets: 106462 Rx Start of Frame Overruns: 0 Rx Middle of Frame Overruns: 0 Rx DMA Overruns: 0 Rx DMA chan 0: head_enqueue: 1 Rx DMA chan 0: tail_enqueue: 918 Rx DMA chan 0: pad_enqueue: 0 Rx DMA chan 0: misqueued: 0 Rx DMA chan 0: desc_alloc_fail: 0 Rx DMA chan 0: pad_alloc_fail: 0 Rx DMA chan 0: runt_receive_buf: 0 Rx DMA chan 0: runt_transmit_bu: 0 Rx DMA chan 0: empty_dequeue: 0 Rx DMA chan 0: busy_dequeue: 772 Rx DMA chan 0: good_dequeue: 791 Rx DMA chan 0: requeue: 0 Rx DMA chan 0: teardown_dequeue: 0 Tx DMA chan 0: head_enqueue: 369 Tx DMA chan 0: tail_enqueue: 0 Tx DMA chan 0: pad_enqueue: 0 Tx DMA chan 0: misqueued: 0 Tx DMA chan 0: desc_alloc_fail: 0 Tx DMA chan 0: pad_alloc_fail: 0 Tx DMA chan 0: runt_receive_buf: 0 Tx DMA chan 0: runt_transmit_bu: 221 Tx DMA chan 0: empty_dequeue: 369 Tx DMA chan 0: busy_dequeue: 0 Tx DMA chan 0: good_dequeue: 369 Tx DMA chan 0: requeue: 0 Tx DMA chan 0: teardown_dequeue: 0 p05_rx_hi: 0 p05_rx_undersize: 0 p05_rx_fragments: 0 p05_rx_oversize: 0 p05_rx_jabbers: 0 p05_rx_symbol_err: 0 p05_rx_crc_err: 0 p05_rx_align_err: 0 p05_rx_mac_ctrl: 0 p05_rx_pause: 0 p05_rx_bcast: 651 p05_rx_mcast: 208 p05_rx_ucast: 214 p05_rx_64_or_less: 593 p05_rx_65_127: 343 p05_rx_128_255: 73 p05_rx_256_511: 64 p05_rx_512_1023: 0 p05_rx_1024_1522: 0 p05_rx_1523_2000: 0 p05_rx_2001: 0 p05_tx_hi: 0 p05_tx_late_col: 0 p05_tx_pause: 0 p05_tx_bcast: 744 p05_tx_mcast: 177 p05_tx_ucast: 0 p05_tx_deferred: 0 p05_tx_total_col: 0 p05_tx_exc_col: 0 p05_tx_single_col: 0 p05_tx_mult_col: 0 p05_rx_total: 99380 p05_tx_total: 86102 p05_rx_discards: 224 p05_tx_discards: 0 ~$ ethtool -S lan4 NIC statistics: tx_packets: 563 tx_bytes: 41522 rx_packets: 1010 rx_bytes: 61155 rx_hi: 0 rx_undersize: 0 rx_fragments: 0 rx_oversize: 0 rx_jabbers: 0 rx_symbol_err: 0 rx_crc_err: 0 rx_align_err: 0 rx_mac_ctrl: 0 rx_pause: 0 rx_bcast: 958 rx_mcast: 222 rx_ucast: 214 rx_64_or_less: 898 rx_65_127: 350 rx_128_255: 80 rx_256_511: 66 rx_512_1023: 0 rx_1024_1522: 0 rx_1523_2000: 0 rx_2001: 0 tx_hi: 0 tx_late_col: 0 tx_pause: 0 tx_bcast: 749 tx_mcast: 212 tx_ucast: 0 tx_deferred: 0 tx_total_col: 0 tx_exc_col: 0 tx_single_col: 0 tx_mult_col: 0 rx_total: 121503 tx_total: 92530 rx_discards: 224 tx_discards: 0 Only weird thing I notice on target, when its replying for ping requests ( (oui Unknown) is that something which is causing issues ? 08:11:20.230704 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000 tell tango-charlie.local, length 46 08:11:20.230749 ARP, Ethernet (len 6), IPv4 (len 4), Reply VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 08:11:21.230629 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000 tell tango-charlie.local, length 46 08:11:21.230657 ARP, Ethernet (len 6), IPv4 (len 4), Reply VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 08:11:22.247831 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has VB4-SN00000000 tell tango-charlie.local, length 46 08:11:22.247857 ARP, Ethernet (len 6), IPv4 (len 4), Reply VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 Cheers, --Prabhakar ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-09 15:07 ` Lad, Prabhakar @ 2018-08-09 15:35 ` Andrew Lunn 2018-08-09 16:03 ` Lad, Prabhakar 0 siblings, 1 reply; 28+ messages in thread From: Andrew Lunn @ 2018-08-09 15:35 UTC (permalink / raw) To: Lad, Prabhakar; +Cc: netdev > > > The received packets captured on the PC are MDNS and DHPC, these MDNS > > > are causing the rx > > > packet counter go up: > > > > And where are these packets coming from? The target device? Or some > > other device on your network? > > > AFIK, MDNS is also kind of a bcast its sending MDNS requests and > receiving itself, > that’s the reason rx packets are incrementing (correct me if I am wrong) Your Ethernet device should not be receiving its own transmissions. Looping back for broadcast and multicast packets happens higher up in the network stack. Look at the source MAC address for these packets. Where are the coming from? > ~$ ethtool -S lan4 > NIC statistics: ... > tx_hi: 0 > tx_late_col: 0 > tx_pause: 0 > tx_bcast: 749 > tx_mcast: 212 This suggest the switch is putting packets onto the wire. > Only weird thing I notice on target, when its replying for ping > requests ( (oui Unknown) is that something which is causing issues ? These are not ping requests. These are ARP requests/replies. > 08:11:20.230704 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > VB4-SN00000000 tell tango-charlie.local, length 46 > 08:11:20.230749 ARP, Ethernet (len 6), IPv4 (len 4), Reply > VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 > 08:11:21.230629 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > VB4-SN00000000 tell tango-charlie.local, length 46 > 08:11:21.230657 ARP, Ethernet (len 6), IPv4 (len 4), Reply > VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 > 08:11:22.247831 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > VB4-SN00000000 tell tango-charlie.local, length 46 > 08:11:22.247857 ARP, Ethernet (len 6), IPv4 (len 4), Reply > VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 c4:f3:12 is the OUI. It is actually registers to TI: https://aruljohn.com/mac/C4F312 But tcpdump probably does not know this, or the build you have has the oui table removed to keep the binary small. Andrew ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-09 15:35 ` Andrew Lunn @ 2018-08-09 16:03 ` Lad, Prabhakar 2018-08-09 17:23 ` Andrew Lunn 0 siblings, 1 reply; 28+ messages in thread From: Lad, Prabhakar @ 2018-08-09 16:03 UTC (permalink / raw) To: Andrew Lunn; +Cc: netdev [-- Attachment #1: Type: text/plain, Size: 2567 bytes --] Hi Andrew, Thanks for your support. On Thu, Aug 9, 2018 at 4:35 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > > The received packets captured on the PC are MDNS and DHPC, these MDNS > > > > are causing the rx > > > > packet counter go up: > > > > > > And where are these packets coming from? The target device? Or some > > > other device on your network? > > > > > AFIK, MDNS is also kind of a bcast its sending MDNS requests and > > receiving itself, > > that’s the reason rx packets are incrementing (correct me if I am wrong) > > Your Ethernet device should not be receiving its own > transmissions. Looping back for broadcast and multicast packets > happens higher up in the network stack. > > Look at the source MAC address for these packets. Where are the coming > from? > Its coming from the switch lan4 I have attached the png, where C4:F3:12:08:FE:7F is the mac of lan4, which is broadcast to ff:ff:ff:ff:ff:ff, which is causing rx counter on PC to go up. > > ~$ ethtool -S lan4 > > NIC statistics: > ... > > tx_hi: 0 > > tx_late_col: 0 > > tx_pause: 0 > > tx_bcast: 749 > > tx_mcast: 212 > > This suggest the switch is putting packets onto the wire. > > > Only weird thing I notice on target, when its replying for ping > > requests ( (oui Unknown) is that something which is causing issues ? > > These are not ping requests. These are ARP requests/replies. > Yes my bad. > > 08:11:20.230704 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > VB4-SN00000000 tell tango-charlie.local, length 46 > > 08:11:20.230749 ARP, Ethernet (len 6), IPv4 (len 4), Reply > > VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 > > 08:11:21.230629 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > VB4-SN00000000 tell tango-charlie.local, length 46 > > 08:11:21.230657 ARP, Ethernet (len 6), IPv4 (len 4), Reply > > VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 > > 08:11:22.247831 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > VB4-SN00000000 tell tango-charlie.local, length 46 > > 08:11:22.247857 ARP, Ethernet (len 6), IPv4 (len 4), Reply > > VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28 > > c4:f3:12 is the OUI. It is actually registers to TI: > > https://aruljohn.com/mac/C4F312 > > But tcpdump probably does not know this, or the build you have has the > oui table removed to keep the binary small. > Yes I built it on yocto, probably to reduce they have small build. Cheers, --Prabhakar [-- Attachment #2: frame.png --] [-- Type: image/png, Size: 1281475 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-09 16:03 ` Lad, Prabhakar @ 2018-08-09 17:23 ` Andrew Lunn 2018-08-10 11:26 ` Lad, Prabhakar 0 siblings, 1 reply; 28+ messages in thread From: Andrew Lunn @ 2018-08-09 17:23 UTC (permalink / raw) To: Lad, Prabhakar; +Cc: netdev > Its coming from the switch lan4 I have attached the png, where > C4:F3:12:08:FE:7F is > the mac of lan4, which is broadcast to ff:ff:ff:ff:ff:ff, which is > causing rx counter on > PC to go up. So, big packets are making it from the switch to the PC. But the small ARP packets are not. This is what Florian was suggesting. ARP packets are smaller than 64 bytes, which is the minimum packet size for Ethernet. Any packets smaller than 64 bytes are called runt packets. They have to be padded upto 64 bytes in order to make them valid. Otherwise the destination, or any switch along the path, might throw them away. What could be happening is that the CSPW driver or hardware is padding the packet to 64 bytes. But that packet has a DSA header in it. The switch removes the header, recalculate the checksum and sends the packet. It is now either 4 or 8 bytes smaller, depending on what DSA header was used. It then becomes a runt packet. Florian had to fix this problem recently. http://patchwork.ozlabs.org/patch/836534/ You probably need something similar for the cpsw. Andrew ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-09 17:23 ` Andrew Lunn @ 2018-08-10 11:26 ` Lad, Prabhakar 2018-08-10 17:36 ` Florian Fainelli 0 siblings, 1 reply; 28+ messages in thread From: Lad, Prabhakar @ 2018-08-10 11:26 UTC (permalink / raw) To: Andrew Lunn; +Cc: netdev Hi Andrew, On Thu, Aug 9, 2018 at 6:23 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > Its coming from the switch lan4 I have attached the png, where > > C4:F3:12:08:FE:7F is > > the mac of lan4, which is broadcast to ff:ff:ff:ff:ff:ff, which is > > causing rx counter on > > PC to go up. > > So, big packets are making it from the switch to the PC. But the small > ARP packets are not. > > This is what Florian was suggesting. > > ARP packets are smaller than 64 bytes, which is the minimum packet > size for Ethernet. Any packets smaller than 64 bytes are called runt > packets. They have to be padded upto 64 bytes in order to make them > valid. Otherwise the destination, or any switch along the path, might > throw them away. > > What could be happening is that the CSPW driver or hardware is padding > the packet to 64 bytes. But that packet has a DSA header in it. The > switch removes the header, recalculate the checksum and sends the > packet. It is now either 4 or 8 bytes smaller, depending on what DSA > header was used. It then becomes a runt packet. > Thank you for the clarification, this really helped me out. > Florian had to fix this problem recently. > > http://patchwork.ozlabs.org/patch/836534/ > But seems like this patch was never accepted, instead brcm_tag_xmit_ll() does it if I am understanding it correctly. similarly to this ksz_xmit() is taking care of padding. > You probably need something similar for the cpsw. > looking at the tag_ksz.c in xmit function this is taken care of /* For Ingress (Host -> KSZ), 2 bytes are added before FCS. * --------------------------------------------------------------------------- * DA(6bytes)|SA(6bytes)|....|Data(nbytes)|tag0(1byte)|tag1(1byte)|FCS(4bytes) * --------------------------------------------------------------------------- * tag0 : Prioritization (not used now) * tag1 : each bit represents port (eg, 0x01=port1, 0x02=port2, 0x10=port5) * * For Egress (KSZ -> Host), 1 byte is added before FCS. * --------------------------------------------------------------------------- * DA(6bytes)|SA(6bytes)|....|Data(nbytes)|tag0(1byte)|FCS(4bytes) * --------------------------------------------------------------------------- * tag0 : zero-based value represents port * (eg, 0x00=port1, 0x02=port3, 0x06=port7) */ #define KSZ_INGRESS_TAG_LEN 2 #define KSZ_EGRESS_TAG_LEN 1 static struct sk_buff *ksz_xmit(struct sk_buff *skb, struct net_device *dev) { struct dsa_slave_priv *p = netdev_priv(dev); struct sk_buff *nskb; int padlen; u8 *tag; padlen = (skb->len >= ETH_ZLEN) ? 0 : ETH_ZLEN - skb->len; if (skb_tailroom(skb) >= padlen + KSZ_INGRESS_TAG_LEN) { /* Let dsa_slave_xmit() free skb */ if (__skb_put_padto(skb, skb->len + padlen, false)) return NULL; nskb = skb; } else { nskb = alloc_skb(NET_IP_ALIGN + skb->len + padlen + KSZ_INGRESS_TAG_LEN, GFP_ATOMIC); if (!nskb) return NULL; skb_reserve(nskb, NET_IP_ALIGN); skb_reset_mac_header(nskb); skb_set_network_header(nskb, skb_network_header(skb) - skb->head); skb_set_transport_header(nskb, skb_transport_header(skb) - skb->head); skb_copy_and_csum_dev(skb, skb_put(nskb, skb->len)); /* Let skb_put_padto() free nskb, and let dsa_slave_xmit() free * skb */ if (skb_put_padto(nskb, nskb->len + padlen)) return NULL; consume_skb(skb); } tag = skb_put(nskb, KSZ_INGRESS_TAG_LEN); tag[0] = 0; tag[1] = 1 << p->dp->index; /* destination port */ return nskb; } Cheers, --Prabhakar Lad ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-10 11:26 ` Lad, Prabhakar @ 2018-08-10 17:36 ` Florian Fainelli 2018-08-13 11:06 ` Lad, Prabhakar 0 siblings, 1 reply; 28+ messages in thread From: Florian Fainelli @ 2018-08-10 17:36 UTC (permalink / raw) To: Lad, Prabhakar, Andrew Lunn; +Cc: netdev On 08/10/2018 04:26 AM, Lad, Prabhakar wrote: > Hi Andrew, > > On Thu, Aug 9, 2018 at 6:23 PM Andrew Lunn <andrew@lunn.ch> wrote: >> >>> Its coming from the switch lan4 I have attached the png, where >>> C4:F3:12:08:FE:7F is >>> the mac of lan4, which is broadcast to ff:ff:ff:ff:ff:ff, which is >>> causing rx counter on >>> PC to go up. >> >> So, big packets are making it from the switch to the PC. But the small >> ARP packets are not. >> >> This is what Florian was suggesting. >> >> ARP packets are smaller than 64 bytes, which is the minimum packet >> size for Ethernet. Any packets smaller than 64 bytes are called runt >> packets. They have to be padded upto 64 bytes in order to make them >> valid. Otherwise the destination, or any switch along the path, might >> throw them away. >> >> What could be happening is that the CSPW driver or hardware is padding >> the packet to 64 bytes. But that packet has a DSA header in it. The >> switch removes the header, recalculate the checksum and sends the >> packet. It is now either 4 or 8 bytes smaller, depending on what DSA >> header was used. It then becomes a runt packet. >> > Thank you for the clarification, this really helped me out. > >> Florian had to fix this problem recently. >> >> http://patchwork.ozlabs.org/patch/836534/ >> > But seems like this patch was never accepted, instead > brcm_tag_xmit_ll() does it if I am understanding it correctly. > similarly to this ksz_xmit() is taking care of padding. net/dsa/tag_brcm.c ended up doing the padding because that was a more generic and central location: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/net/dsa/tag_brcm.c#n73 > >> You probably need something similar for the cpsw. >> > looking at the tag_ksz.c in xmit function this is taken care of 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? > > /* For Ingress (Host -> KSZ), 2 bytes are added before FCS. > * --------------------------------------------------------------------------- > * DA(6bytes)|SA(6bytes)|....|Data(nbytes)|tag0(1byte)|tag1(1byte)|FCS(4bytes) > * --------------------------------------------------------------------------- > * tag0 : Prioritization (not used now) > * tag1 : each bit represents port (eg, 0x01=port1, 0x02=port2, 0x10=port5) > * > * For Egress (KSZ -> Host), 1 byte is added before FCS. > * --------------------------------------------------------------------------- > * DA(6bytes)|SA(6bytes)|....|Data(nbytes)|tag0(1byte)|FCS(4bytes) > * --------------------------------------------------------------------------- > * tag0 : zero-based value represents port > * (eg, 0x00=port1, 0x02=port3, 0x06=port7) > */ > > #define KSZ_INGRESS_TAG_LEN 2 > #define KSZ_EGRESS_TAG_LEN 1 > > static struct sk_buff *ksz_xmit(struct sk_buff *skb, struct net_device *dev) > { > struct dsa_slave_priv *p = netdev_priv(dev); > struct sk_buff *nskb; > int padlen; > u8 *tag; > > padlen = (skb->len >= ETH_ZLEN) ? 0 : ETH_ZLEN - skb->len; > > if (skb_tailroom(skb) >= padlen + KSZ_INGRESS_TAG_LEN) { > /* Let dsa_slave_xmit() free skb */ > if (__skb_put_padto(skb, skb->len + padlen, false)) > return NULL; > > nskb = skb; > } else { > nskb = alloc_skb(NET_IP_ALIGN + skb->len + > padlen + KSZ_INGRESS_TAG_LEN, GFP_ATOMIC); > if (!nskb) > return NULL; > skb_reserve(nskb, NET_IP_ALIGN); > > skb_reset_mac_header(nskb); > skb_set_network_header(nskb, > skb_network_header(skb) - skb->head); > skb_set_transport_header(nskb, > skb_transport_header(skb) - skb->head); > skb_copy_and_csum_dev(skb, skb_put(nskb, skb->len)); > > /* Let skb_put_padto() free nskb, and let dsa_slave_xmit() free > * skb > */ > if (skb_put_padto(nskb, nskb->len + padlen)) > return NULL; > > consume_skb(skb); > } > > tag = skb_put(nskb, KSZ_INGRESS_TAG_LEN); > tag[0] = 0; > tag[1] = 1 << p->dp->index; /* destination port */ > > return nskb; > } > > Cheers, > --Prabhakar Lad > -- Florian ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-10 17:36 ` Florian Fainelli @ 2018-08-13 11:06 ` Lad, Prabhakar 2018-08-13 13:38 ` Andrew Lunn 0 siblings, 1 reply; 28+ messages in thread From: Lad, Prabhakar @ 2018-08-13 11:06 UTC (permalink / raw) To: Florian Fainelli; +Cc: Andrew Lunn, netdev Hi Florian, On Fri, Aug 10, 2018 at 6:36 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > > On 08/10/2018 04:26 AM, Lad, Prabhakar wrote: > > Hi Andrew, > > > > On Thu, Aug 9, 2018 at 6:23 PM Andrew Lunn <andrew@lunn.ch> wrote: > >> > >>> Its coming from the switch lan4 I have attached the png, where > >>> C4:F3:12:08:FE:7F is > >>> the mac of lan4, which is broadcast to ff:ff:ff:ff:ff:ff, which is > >>> causing rx counter on > >>> PC to go up. > >> > >> So, big packets are making it from the switch to the PC. But the small > >> ARP packets are not. > >> > >> This is what Florian was suggesting. > >> > >> ARP packets are smaller than 64 bytes, which is the minimum packet > >> size for Ethernet. Any packets smaller than 64 bytes are called runt > >> packets. They have to be padded upto 64 bytes in order to make them > >> valid. Otherwise the destination, or any switch along the path, might > >> throw them away. > >> > >> What could be happening is that the CSPW driver or hardware is padding > >> the packet to 64 bytes. But that packet has a DSA header in it. The > >> switch removes the header, recalculate the checksum and sends the > >> packet. It is now either 4 or 8 bytes smaller, depending on what DSA > >> header was used. It then becomes a runt packet. > >> > > Thank you for the clarification, this really helped me out. > > > >> Florian had to fix this problem recently. > >> > >> http://patchwork.ozlabs.org/patch/836534/ > >> > > But seems like this patch was never accepted, instead > > brcm_tag_xmit_ll() does it if I am understanding it correctly. > > similarly to this ksz_xmit() is taking care of padding. > > net/dsa/tag_brcm.c ended up doing the padding because that was a more > generic and central location: > > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/net/dsa/tag_brcm.c#n73 > > > > >> You probably need something similar for the cpsw. > >> > > looking at the tag_ksz.c in xmit function this is taken care of > > 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) Cheers, --Prabhakar ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-13 11:06 ` Lad, Prabhakar @ 2018-08-13 13:38 ` Andrew Lunn 2018-08-13 15:58 ` Lad, Prabhakar 0 siblings, 1 reply; 28+ messages in thread From: Andrew Lunn @ 2018-08-13 13:38 UTC (permalink / raw) To: Lad, Prabhakar; +Cc: Florian Fainelli, netdev > > 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. Andrew ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-13 13:38 ` Andrew Lunn @ 2018-08-13 15:58 ` Lad, Prabhakar 2018-08-13 18:57 ` Florian Fainelli 0 siblings, 1 reply; 28+ messages in thread From: Lad, Prabhakar @ 2018-08-13 15:58 UTC (permalink / raw) To: Andrew Lunn; +Cc: Florian Fainelli, netdev Hi Andrew/Florain, On Mon, Aug 13, 2018 at 2:38 PM Andrew Lunn <andrew@lunn.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 ? [1] https://lore.kernel.org/patchwork/patch/851457/ Cheers, --Prabhakar Lad ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-13 15:58 ` Lad, Prabhakar @ 2018-08-13 18:57 ` Florian Fainelli 2018-08-14 11:49 ` Lad, Prabhakar 0 siblings, 1 reply; 28+ messages in thread From: Florian Fainelli @ 2018-08-13 18:57 UTC (permalink / raw) To: Lad, Prabhakar, Andrew Lunn; +Cc: netdev 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@lunn.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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Query]: DSA Understanding 2018-08-13 18:57 ` Florian Fainelli @ 2018-08-14 11:49 ` Lad, Prabhakar 0 siblings, 0 replies; 28+ messages in thread From: Lad, Prabhakar @ 2018-08-14 11:49 UTC (permalink / raw) To: Florian Fainelli; +Cc: Andrew Lunn, netdev Hi Florian, On Mon, Aug 13, 2018 at 7:57 PM Florian Fainelli <f.fainelli@gmail.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@lunn.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 ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2018-08-14 14:37 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-07-25 8:39 [Query]: DSA Understanding Lad, Prabhakar 2018-07-25 16:19 ` Andrew Lunn 2018-07-26 7:38 ` Lad, Prabhakar 2018-07-26 14:08 ` Andrew Lunn 2018-07-26 15:20 ` Lad, Prabhakar 2018-07-26 15:39 ` Andrew Lunn 2018-08-02 8:13 ` Lad, Prabhakar 2018-08-02 14:45 ` Andrew Lunn 2018-08-02 14:58 ` Lad, Prabhakar 2018-08-02 16:05 ` Andrew Lunn 2018-08-02 16:24 ` Florian Fainelli 2018-08-09 11:33 ` Lad, Prabhakar 2018-08-09 12:08 ` Andrew Lunn 2018-08-09 11:31 ` Lad, Prabhakar 2018-08-09 12:01 ` Andrew Lunn 2018-08-09 12:45 ` Lad, Prabhakar 2018-08-09 12:56 ` Andrew Lunn 2018-08-09 15:07 ` Lad, Prabhakar 2018-08-09 15:35 ` Andrew Lunn 2018-08-09 16:03 ` Lad, Prabhakar 2018-08-09 17:23 ` Andrew Lunn 2018-08-10 11:26 ` Lad, Prabhakar 2018-08-10 17:36 ` Florian Fainelli 2018-08-13 11:06 ` Lad, Prabhakar 2018-08-13 13:38 ` Andrew Lunn 2018-08-13 15:58 ` Lad, Prabhakar 2018-08-13 18:57 ` Florian Fainelli 2018-08-14 11:49 ` Lad, Prabhakar
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.