Re: [tipc-discussion] TIPC 2.0.0 packets not being transmitted

[Erik H. <eri...@er...>]

Boards 1.1.4 and 1.1.5 are both transmitting TIPC ethernet frames with 
the mac address 00:00:00:00:00:00, and the 'bearer level originating address'
in the TIPC link activate messages from these nodes are also zero, and this is
what's causing the link setup to fail.
The broadcast mac used by these nodes also look quirky (ff:ff:00:00:00:00),
although they are valid since only the bcast bit need to be set.


TIPC fetches the MAC address of an ethernet bearer as:
> [...]
> struct net_device *dev;
> dev = dev_get_by_name(&init_net, driver_name);
>	if (!dev)
>                 return -ENODEV;
> [...]
> b->media->raw2addr(b, &b->addr, (char *)dev->dev_addr);

So one could suspect that the macb driver does not set the struct netdevice dev_addr
correctly or at all. However, we can see in the ip -s -s link output that
it is set to 00:0a:35:02:c6:8c, and you say that ip traffic works so that should
be ok.

I looked at the cadence/macb driver code, but could not find any case where the
netdevice could be brought up with an all-zero MAC address.

What happens if you (on node 1.1.4/1.1.5) disable and enable the bearer again?

//E

On Thu, Oct 23, 2014 at 05:36:08PM -0400, Matthew Clark wrote:
> Hi, Erik,
> 
> As requested, pcap files.  The zc706 board is the problem child.
> 
> Also, I built a 3.14.2 (linux-xlnx tree) for the zedboard and it had no
> problems with TIPC.  In fact, the pcap file for the zedboard is running the
> 3.14.2 kernel.  I'm build a 3.8.x and 3.10.x kernel for the zc706 to see if
> that changes anything
> 
> Matt
> 
> 
> On Thu, Oct 23, 2014 at 4:17 PM, Erik Hugne <eri...@er...> wrote:
> 
> >  Sure, tcpdump -i eth0 ether proto 0x88ca -w dump.pcap
> > Quite a few dropped pkts on that device (but no RX errors..). Almost
> > enough to start suspecting the macb driver..
> > If you can provide the packet dumps, i'll look more on this tomorrow CET.
> >
> > //E
> > On 23 Oct 2014 18:41, Matthew Clark <lin...@gm...> wrote:
> >  Erik,
> >
> >  These are the results.  ethtool -S wasn't supported.  I'm going to try
> > to roll back the zc706 to an earlier kernel and see if that works.
> >
> >  I can save "tcpdump" files and attached them.  Is that as good as pcap?
> >
> >  Matt
> >
> >  --
> >
> >  root@dataproc4:~# ip -s -s link
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
> > DEFAULT group default
> >     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> >     RX: bytes  packets  errors  dropped overrun mcast
> >     1648       17       0       0       0       0
> >     RX errors: length  crc     frame   fifo    missed
> >                0        0       0       0       0
> >     TX: bytes  packets  errors  dropped carrier collsns
> >     1648       17       0       0       0       0
> >     TX errors: aborted fifo    window  heartbeat
> >                0        0       0       0
> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> > state UP mode DEFAULT group default qlen 1000
> >     link/ether 00:0a:35:02:c6:8c brd ff:ff:ff:ff:ff:ff
> >     RX: bytes  packets  errors  dropped overrun mcast
> >     29285720   377843   0       53755   0       15655
> >     RX errors: length  crc     frame   fifo    missed
> >                0        0       0       0       0
> >     TX: bytes  packets  errors  dropped carrier collsns
> >     49704080   652790   0       0       0       0
> >     TX errors: aborted fifo    window  heartbeat
> >                0        0       0       0
> >
> >  root@dataproc4:~# ethtool -S eth0
> > no stats available
> >
> >  root@dataproc4:~# ethtool -i eth0
> > driver: macb
> > version:
> > firmware-version:
> > bus-info: e000b000.ps7-ethernet
> > supports-statistics: no
> > supports-test: no
> > supports-eeprom-access: no
> > supports-register-dump: yes
> > supports-priv-flags: no
> >
> >
> >
> > On Thu, Oct 23, 2014 at 3:45 AM, Erik Hugne <eri...@er...>
> > wrote:
> >
> >> If you can upload a .pcap file somewhere, it would be much easier to
> >> follow the
> >> packet exchange.
> >>
> >> Also, the device counters may tell us something:
> >> ip -s -s link
> >> ethtool -S eth0
> >>
> >> Also, what nic/driver is the zynq board using?
> >> ethtool -i eth0
> >>
> >> //E
> >>
> >>