matrix_df hotmail wrote: > Hello Jan > >> So, it seems that this "B" comes from a misalignment or >> misinterpretation of the frame. It's likely the length low-byte: 66. >> >> Please also capture stage-1 frames on your boxes (master and slave) and >> either look for differences or post the files to the list. > > Yes, I can see the same "B" phenomenon on the ethernet, captured on > master and slave. > > ON MASTER: > ######################################################################## > Frame 1 (93 bytes on wire, 93 bytes captured) > Arrival Time: Jan 1, 1970 05:37:14.826591000 > Time delta from previous packet: 0.000000000 seconds > Time since reference or first frame: 0.000000000 seconds > Frame Number: 1 > Packet Length: 93 bytes > Capture Length: 93 bytes > No. Time Source Destination Protocol > Info > 1 0.000000 Intel_71:70:ea Broadcast RTcfg > Stage 1 > Config > > Frame 1 (93 bytes on wire, 93 bytes captured) > Arrival Time: Jan 1, 1970 05:37:14.826591000 > Time delta from previous packet: 0.000000000 seconds > Time since reference or first frame: 0.000000000 seconds > Frame Number: 1 > Packet Length: 93 bytes > Capture Length: 93 bytes > Protocols in frame: eth:rtcfg > Ethernet II, Src: Intel_71:70:ea (00:90:27:71:70:ea), Dst: Broadcast > (ff:ff:ff:f > f:ff:ff) > Destination: Broadcast (ff:ff:ff:ff:ff:ff) > Source: Intel_71:70:ea (00:90:27:71:70:ea) > Type: Real-Time Configuration Protocol (0x9022) > RTcfg, Version 0, Stage 1 Config > Version and ID: 0x00 > 000. .... = Version: 0 > ...0 0000 = ID: Stage 1 Config (0x00) > Address Type: IP (1) > Client IP Address: 10.0.0.2 (10.0.0.2) > Server IP Address: 10.0.0.1 (10.0.0.1) > Stage 2 Burst Rate: 4 > Stage 1 Config Length: 66 > Config Data: 2454444D414346472072746574683020736C6F7420302032... > > 0000 ff ff ff ff ff ff 00 90 27 71 70 ea 90 22 00 01 ........'qp..".. > 0010 0a 00 00 02 0a 00 00 01 04 00 42 24 54 44 4d 41 ..........B$TDMA > 0020 43 46 47 20 72 74 65 74 68 30 20 73 6c 6f 74 20 CFG rteth0 slot > 0030 30 20 32 30 30 3b 69 66 63 6f 6e 66 69 67 20 76 0 200;ifconfig v > 0040 6e 69 63 30 20 75 70 20 24 49 50 41 44 44 52 20 nic0 up $IPADDR > 0050 24 4e 45 54 4d 41 53 4b 5f 4f 50 54 0a $NETMASK_OPT. > [EMAIL PROTECTED] rtnet]# > > ON SLAVE: > ######################################################################## > > 0.859983 Intel_71:70:ea -> Broadcast RTcfg Stage 1 Config > > 0000 ff ff ff ff ff ff 00 90 27 71 70 ea 90 22 00 01 ........'qp..".. > 0010 0a 00 00 02 0a 00 00 01 04 00 42 24 54 44 4d 41 ..........B$TDMA > 0020 43 46 47 20 72 74 65 74 68 30 20 73 6c 6f 74 20 CFG rteth0 slot > 0030 30 20 32 30 30 3b 69 66 63 6f 6e 66 69 67 20 76 0 200;ifconfig v > 0040 6e 69 63 30 20 75 70 20 24 49 50 41 44 44 52 20 nic0 up $IPADDR > 0050 24 4e 45 54 4d 41 53 4b 5f 4f 50 54 0a $NETMASK_OPT. > ######################################################################## >
But this doesn't explain the wrong data returned by "rtcfg client". All frames are sane, there must be some other issue. Ok, switched to slave mode on my RTAI test box and replayed a few stage-1 frames from another station - same effect here. But before accusing any subsystem, I will have a closer look first... Jan PS: Please use "reply to all" so that your answer make it to the list as well.
signature.asc
Description: OpenPGP digital signature
