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

[Matthew C. <lin...@gm...>]

Erik,

How would I do that?  Unload TIPC and reload it?

You should also know, I rolled the zc706 boards to 3.8.11-xilinx from the
linux-xlnx kernel and the TIPC cluster formed fine.  Also, I took a
zedboard to the same 3.14.2 that gave the zc706 heartburn and it too works.
   I don't know, though, if the zed uses the same ethernet driver as the
706.  How can I tell?

Matt

On Fri, Oct 24, 2014 at 4:22 AM, Erik Hugne <eri...@er...> wrote:

> 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
> > >>
> > >>
>
>
>
>