Hi,
On Thu, Aug 9, 2018 at 1:56 PM Andrew Lunn <and...@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 <and...@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 <and...@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
