Menu
▾
▴
Re: [tipc-discussion] TIPC 2.0.0 packets not being transmitted
|
From: Matthew C. <lin...@gm...> - 2014-10-22 16:58:25
|
Jon, I'm running in little endian. SSH, http and NFS work fine, so I'm more than puzzled why they work fine and TIPC doesn't. Matt On Wed, Oct 22, 2014 at 10:01 AM, Jon Maloy <jon...@er...> wrote: > ARM Cortex 9, as well as Zynq, can be run both as little-endian and > big-endian. > > Which one are you using? Of course TIPC should work on both, but I suspect > > testing on big-endian is done less frequently. > > > > ///jon > > > > > > > > *From:* Matthew Clark [mailto:lin...@gm...] > *Sent:* October-22-14 9:15 AM > *To:* Erik Hugne > *Cc:* Jon Maloy; tip...@li... > > *Subject:* Re: [tipc-discussion] TIPC 2.0.0 packets not being transmitted > > > > Erik, > > > > The Zynq is based on a dual-core ARM Cortex-A9 with some FPGA fabric. > Both the ZC706 and Zedboard have one and the Zedboard runs TIPC fine, > albeit with an older kernel. > > > > Dmesg on Node4 (an ARM cortex A9) shows the following. This was the only > TIPC related messages it logged. > > [54305.337134] tipc: Activated (version 2.0.0) > > [54305.342407] NET: Registered protocol family 30 > > [54305.348292] tipc: Started in single node mode > > [54305.374682] tipc: Started in network mode > > [54305.378620] tipc: Own node address <1.1.4>, network identity 1227 > > [54305.385623] tipc: Enabled bearer <eth:eth0>, discovery domain <1.1.0>, > priority 10 > > > > === > > > > Ying, > > > > I used tcpdump to capture the following packets. They kept repeating, so > I only captured one set. Also, I added another board, 1.1.2 to show Node3 > can establish a TPIC link. From what I can tell, neither Node2 or 3 > receives anything from Node4. It suggests that while Node4 thinks it's > sending packets, neither Node2 nor 3 receives anything. But where would I > even being to diagnose that? > > > > Matt > > > > === > > > > > > From Node2 (a Gumstix Overo (single core Cortex A8, runnign a 3.5 kernel) > > > > 13:12:38.396703 TIPC v2.0 1.1.2 > 1.1.3, headerlength 40 bytes, > MessageSize 56 bytes, Link State Protocol internal, messageType CONN_MSG > (0x00000000) > > Previous Node 1.1.2, Session No. 60777, Broadcast Ack 0, > Sequence Gap 0, Broadcast Gap After 2, Broadcast Gap To 32769, Last Sent > Packet No. 0, Next sent Packet No. 2, Transport Sequence 0, msg_count 0, > Link Tolerance 0 > > 0x0000: 4f40 0038 0000 0000 0002 8001 0100 1002 O@.8 > ............ > > 0x0010: 0000 0002 ed69 00a1 0100 1002 0100 1003 > .....i.......... > > 0x0020: 0000 0000 0000 0000 6574 6830 0000 0000 > ........eth0.... > > 0x0030: 0000 0000 0000 0000 ........ > > 13:12:38.396855 TIPC v2.0 1.1.3 > 1.1.2, headerlength 40 bytes, > MessageSize 56 bytes, Link State Protocol internal, messageType CONN_MSG > (0x00000000) > > Previous Node 1.1.3, Session No. 62897, Broadcast Ack 0, > Sequence Gap 0, Broadcast Gap After 1, Broadcast Gap To 32770, Last Sent > Packet No. 0, Next sent Packet No. 3, Transport Sequence 0, msg_count 0, > Link Tolerance 0 > > 0x0000: 4f40 0038 0000 0000 0001 8002 0100 1003 O@.8 > ............ > > 0x0010: 0000 0003 f5b1 00a0 0100 1003 0100 1002 > ................ > > 0x0020: 0000 0000 0000 0000 6574 6830 0000 0000 > ........eth0.... > > 0x0030: 0000 0000 0000 0000 ........ > > > > ---- > > > > From Node3 (the zedboard/zynq that's working, running a 3.8 kernel) > > > > 09:05:41.697681 TIPC v2.0 1.1.2 > 1.1.3, headerlength 40 bytes, > MessageSize 56 bytes, Link State Protocol internal, messageType CONN_MSG > (0x00000000) > > Previous Node 1.1.2, Session No. 60777, Broadcast Ack 0, > Sequence Gap 0, Broadcast Gap After 2, Broadcast Gap To 32769, Last Sent > Packet No. 0, Next sent Packet No. 2, Transport Sequence 0, msg_count 0, > Link Tolerance 0 > > 0x0000: 4f40 0038 0000 0000 0002 8001 0100 1002 O@.8 > ............ > > 0x0010: 0000 0002 ed69 00a0 0100 1002 0100 1003 > .....i.......... > > 0x0020: 0000 0000 0000 0000 6574 6830 0000 0000 > ........eth0.... > > 0x0030: 0000 0000 0000 0000 ........ > > 09:05:42.280580 TIPC v2.0 1.1.2 > 1.1.3, headerlength 40 bytes, > MessageSize 56 bytes, Link State Protocol internal, messageType CONN_MSG > (0x00000000) > > Previous Node 1.1.2, Session No. 60777, Broadcast Ack 0, > Sequence Gap 0, Broadcast Gap After 2, Broadcast Gap To 32769, Last Sent > Packet No. 0, Next sent Packet No. 2, Transport Sequence 0, msg_count 0, > Link Tolerance 0 > > 0x0000: 4f40 0038 0000 0000 0002 8001 0100 1002 O@.8 > ............ > > 0x0010: 0000 0002 ed69 00a1 0100 1002 0100 1003 > .....i.......... > > 0x0020: 0000 0000 0000 0000 6574 6830 0000 0000 > ........eth0.... > > 0x0030: 0000 0000 0000 0000 ........ > > > > ---- > > > > From Node4 (the zc706/zynq that's not working running a 3.14 kernel) > > > > 09:05:35.132403 TIPC v2.0 1.1.4 > 1.1.0, headerlength 40 bytes, > MessageSize 40 bytes, Neighbor Detection Protocol internal, messageType > Link request > > NodeSignature 4944, network_id 1227, media_id 1 > > 0x0000: 5b50 0028 0000 1350 0100 1000 0100 1004 > [P.(...P........ > > 0x0010: 0000 04cb 0000 0001 0000 0000 0000 0000 > ................ > > 0x0020: 0000 0000 0000 0000 ........ > > 09:05:35.282382 TIPC v2.0 1.1.4 > 1.1.3, headerlength 40 bytes, > MessageSize 56 bytes, Link State Protocol internal, messageType MCAST_MSG > (0x20000000) > > Previous Node 1.1.4, Session No. 4944, Broadcast Ack 0, Sequence > Gap 0, Broadcast Gap After 65535, Broadcast Gap To 32768, Last Sent Packet > No. 0, Next sent Packet No. 1, Transport Sequence 0, msg_count 375, Link > Tolerance 1500 > > 0x0000: 4f40 0038 2000 0000 ffff 8000 0100 1004 O@.8 > ............ > > 0x0010: 0000 0001 1350 00a0 0100 1004 0100 1003 > .....P.......... > > 0x0020: 0000 0000 0177 05dc 6574 6830 0000 0000 > .....w..eth0.... > > 0x0030: 0000 0000 0000 0000 ........ > > 09:05:35.452403 TIPC v2.0 1.1.4 > 1.1.2, headerlength 40 bytes, > MessageSize 56 bytes, Link State Protocol internal, messageType MCAST_MSG > (0x20000000) > > Previous Node 1.1.4, Session No. 4944, Broadcast Ack 0, Sequence > Gap 0, Broadcast Gap After 65535, Broadcast Gap To 32768, Last Sent Packet > No. 0, Next sent Packet No. 1, Transport Sequence 0, msg_count 375, Link > Tolerance 1500 > > 0x0000: 4f40 0038 2000 0000 ffff 8000 0100 1004 O@.8 > ............ > > 0x0010: 0000 0001 1350 00a0 0100 1004 0100 1002 > .....P.......... > > 0x0020: 0000 0000 0177 05dc 6574 6830 0000 0000 > .....w..eth0.... > > 0x0030: 0000 0000 0000 0000 ........ > > > > > > > > > > > > > > > > On Wed, Oct 22, 2014 at 3:45 AM, Erik Hugne <eri...@er...> > wrote: > > I've never worked with a zynq board before, but i do have a small > beaglebone black > cluster on my desk. > From your wireshark trace it seems that 1.1.4 is receiving the ndisc > request and > is responding to this. 1.1.3 is then expected to reply with a LINK_RESET, > followed > by a LINK_ACTIVATE from 1.1.4. This reset/activate never happens. > Maybe it would help if you can provide us with a .pcap file for the failed > link > setup? > > Also, do you have any suspicious logs from tipc in dmesg? > > //E > > > On Tue, Oct 21, 2014 at 10:48:34AM -0400, Matthew Clark wrote: > > Hi All, > > > > Did my info reveal anything? I'm trying to get some middleware built on > > these zynq boards and TIPC is a dependency, so I really need it working. > > Thanks. > > > > Matt > > > > > > On Fri, Oct 17, 2014 at 12:54 PM, Matthew Clark <lin...@gm... > > > > wrote: > > > > > Hi, Jon, > > > > > > Here's how I configured the zc706's. And how I'm checking what's > going on > > > > > > # ifconfig eth0 192.168.100.193 > > > # modprobe tipc > > > # tipc-config -netid=1227 -addr=1.1.3 -be=eth:eth0/1.1.0 > > > > > > --- > > > > > > # ifconfig eth0 192.168.100.194 > > > # modprobe tipc > > > # tipc-config -netid=1227 -addr=1.1.4 -be=eth:eth0/1.1.0 > > > > > > # tipc-config -n > > > Neighbors: > > > <1.1.3>: down > > > > > > # tcpdump not port 22 > > > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode > > > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 > bytes > > > 16:52:45.644933 TIPC v2.0 1.1.4 > 1.1.3, headerlength 40 bytes, > > > MessageSize 56 bytes, Link State Protocol internal, > > > messageType MCAST_MSG (0x20000000) > > > 16:52:45.734227 TIPC v2.0 1.1.3 > 1.1.0, headerlength 40 bytes, > > > MessageSize 40 bytes, Neighbor Detection Protocol internal, > > > messageType Link request > > > 16:52:45.734286 TIPC v2.0 1.1.4 > 1.1.3, headerlength 40 bytes, > > > MessageSize 40 bytes, Neighbor Detection Protocol internal, > > > messageType Link response > > > 16:52:45.864952 TIPC v2.0 1.1.4 > 1.1.0, headerlength 40 bytes, > > > MessageSize 40 bytes, Neighbor Detection Protocol internal, > > > messageType Link request > > > > > > # tipc-config -ls > > > Link statistics: > > > Link <broadcast-link> > > > Window:20 packets > > > RX packets:0 fragments:0/0 bundles:0/0 > > > TX packets:0 fragments:0/0 bundles:0/0 > > > RX naks:0 defs:0 dups:0 > > > TX naks:0 acks:0 dups:0 > > > Congestion link:0 Send queue max:0 avg:0 > > > > > > Link <1.1.4:eth0-1.1.3:unknown> > > > DEFUNCT MTU:1500 Priority:10 Tolerance:1500 ms Window:50 packets > > > RX packets:0 fragments:0/0 bundles:0/0 > > > TX packets:0 fragments:0/0 bundles:0/0 > > > TX profile sample:0 packets average:0 octets > > > 0-64:0% -256:0% -1024:0% -4096:0% -16384:0% -32768:0% -66000:0% > > > RX states:0 probes:0 naks:0 defs:0 dups:0 > > > TX states:0 probes:0 naks:0 acks:0 dups:0 > > > Congestion link:0 Send queue max:0 avg:0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 17, 2014 at 11:16 AM, Jon Maloy <jon...@er...> > > > wrote: > > > > > >> > > >> > > >> > -----Original Message----- > > >> > From: Matthew Clark [mailto:lin...@gm...] > > >> > Sent: October-17-14 10:31 AM > > >> > To: Ying Xue > > >> > Cc: tip...@li... > > >> > Subject: Re: [tipc-discussion] TIPC 2.0.0 packets not being > transmitted > > >> > > > >> > > > > >> > > > > >> > > On Thu, Oct 16, 2014 at 9:41 PM, Ying Xue <yin...@wi... > > > > >> > wrote: > > >> > > > I'm trying to get a TIPC cluster using a variety of ARM based > > >> > > > processors, but I'm having issues with some zc706 Zynq boards > > >> > > > running a Yocto-built kernel 3.14.2. Some see its neighbors > perfect > > >> > > > well, but the zc706 boards can't be seen by anyone and think > > >> > > > everyone else is down. I ran wireshark and from what I can > tell, the > > >> > > > ZC706 boards simply aren't broadcasting any packets. I see TIPC > > >> > > > packets flying around from the overos and zedboard, > > >> > > but > > >> > > > nothing from the zynqs. > > >> > > > > > >> > > > Can anyone help me debug this? I'm at a bit of a loss to > explain the > > >> > > > behavior. Thanks! > > >> > > > > > >> > > It sounds like a new bug. > > >> > > I saw the two important changes were recently made on tipc > neighbour > > >> > > discovery protocol: > > >> > > c82910e2a8d6fc9dd321a1f30dd4e89fb779cfe1 (tipc: clean up neigbor > > >> > > discovery message reception) > > >> > > 38504c28a201a80d12a6a0f821fecb331cb1f223 (tipc: improve and extend > > >> > > media address conversion functions) Can you please confirm whether > > >> > > above two patches are merged into 3.14.2 tree? > > >> > > If yes, please try to revert them and verify again. > > >> > > Regards, > > >> > > Ying > > >> > > > > >> > > > >> > Hi, Ying, > > >> > > > >> > I'm building from the latest meta-xilinx layer for Yocto, which > calls > > >> in commit > > >> > > > >> > https://github.com/Xilinx/linux- > > >> > xlnx/commit/2b48a8aeea7367359f9eebe55c4a09a05227f32b > > >> > > > >> > This was committed back in April 25, where the commits you reference > > >> > above are dated mid-May. I checked my discover.c and the changes > the > > >> > commits above reference are not included. Should I try them? > > >> > > >> Those commits were not intended to fix any problems; just to make > > >> the code and algorithm more comprehensible. I doubt it will make any > > >> difference. > > >> > > >> When you have configured the zc706, can you confirm that it actually > > >> has the correct address, and that the correct interface(s) is enabled? > > >> If so, and everything is correct, you may have to instrument the code > > >> and look at what is happening in the discovery logics (discover.c) > > >> We can help you out with the latter, if you are positive that the > > >> configuraton > > >> is ok, and the discovery broadcast actually don't go to the wrong > > >> interface. > > >> > > >> Regards > > >> ///jon > > >> > > >> > > > >> > Matt > > >> > > > >> > ------------------------------------------------------------------------------ > > >> > Comprehensive Server Monitoring with Site24x7. > > >> > Monitor 10 servers for $9/Month. > > >> > Get alerted through email, SMS, voice calls or mobile push > > >> notifications. > > >> > Take corrective actions from your mobile device. > > >> > http://p.sf.net/sfu/Zoho > > >> > _______________________________________________ > > >> > tipc-discussion mailing list > > >> > tip...@li... > > >> > https://lists.sourceforge.net/lists/listinfo/tipc-discussion > > >> > > > > > > > > > ------------------------------------------------------------------------------ > > Comprehensive Server Monitoring with Site24x7. > > Monitor 10 servers for $9/Month. > > Get alerted through email, SMS, voice calls or mobile push notifications. > > Take corrective actions from your mobile device. > > http://p.sf.net/sfu/Zoho > > _______________________________________________ > > tipc-discussion mailing list > > tip...@li... > > https://lists.sourceforge.net/lists/listinfo/tipc-discussion > > > |
