Hello, We have held argumental conference. Our board is hardware wired in DATA BUS in order to retrieve DATA from MAC in Big Endian form like below. Normal DATA BUS connection SH SMSC(MAC) D15 <------> D15 | | D08 <------> D08 D07 <------> D07 | | D00 <------> D00 Our Board DATA BUS connection SH SMSC(MAC) D15 <------> D07 | | D08 <------> D00 D07 <------> D15 | | D00 <------> D08 I know you will be surprised as much as I did. The trouble is, our company have had already achievements with this design.Our executives are reluctant to change hardware, and I am too weak to change company's decision. After quarrelsome debate, it concluded that my current problem is not concerned with Endian issue.They doubt my configuration. So I beseech you to help me again. I sum up my trouble. After exchanged commands in UDP, host begins to TCP Connect and send SYN packet to our target.Target receives SYN packet and tries to send back SYN-ACK but that packet becomes Malformed packet. SYN-ACK packet is never recieved by host. Please refer to Ethereal txt log file I sent before. I captured TCP connection between Windows PCs, and compared SYN - SYNACK packets between Windows PCs log and host-target log, and I noticed there are some incomprehensible points. Below is from Ethereal Capture log Windows<-->Windows -- no problem PC-client[172.16.1.28]<-->PC-server[172.16.1.21] [172.16.1.28]-->[172.16.1.21] SYN-Packet 00 10 a4 8a 8a ce 00 15 c5 6d 23 f0 08 00 45 00 00 30 30 b8 40 00 80 06 6f be ac 10 01 1c ac 10 01 15 04 c5 04 21 33 5d c7 c1 00 00 00 00 70 02 ff ff 24 c9 00 00 02 04 05 b4 01 01 04 02 [172.16.1.21]-->[172.16.1.28] SYN-ACK-Packet 00 15 c5 6d 23 f0 00 10 a4 8a 8a ce 08 00 45 00 00 30 16 2a 40 00 80 06 8a 4c ac 10 01 15 ac 10 01 1c 04 21 04 c5 20 08 8f 1b 33 5d c7 c2 70 12 44 70 31 24 00 00 02 04 05 b4 01 01 04 02 ========================================================= cygwin<-->eCos -- SYN-ACK [CHECKSUM INCORRECT][Malformed packet] host-client[172.16.1.28]<-->target-server[172.16.1.200] [172.16.1.28]-->[172.16.1.200] SYN-Packet 00 40 31 08 01 00 00 15 c5 6d 23 f0 08 00 45 00 00 30 35 81 40 00 80 06 6a 42 ac 10 01 1c ac 10 01 c8 05 1e 22 42 a6 39 a9 dc 00 00 00 00 70 02 ff ff b0 a4 00 00 02 04 05 b4 01 01 04 02 [172.16.1.200]-->[172.16.1.28] SYN-ACK-Packet 00 15 c5 6d 23 f0 00 40 31 08 01 00 08 00 45 00 00 28 00 02 40 00 40 06 df c9 ac 10 01 c8 ac 10 01 1c 22 42 05 1e 17 7a 85 37 a6 39 a9 dd 60 12 44 70 ec 30 00 00 00 00 00 00 00 00 My incomprehensible points are, about Target's SYN-ACK-Packet, 1. paket length in IP header(=0028 line-2,colum-1,2) indicates length from top of IP header(line-1,colum-15) to last of packet, but 0028(=40d) counts to line-4,colum-6,there are 6 bytes surplus. 2. data offset bits(=6 line-3,colum-15) indicates there are 4*6=24bytes from top of TCP header(line-3,colum-3) to last of packet. But 24 counts to line-4,colum-10,there are 2 bytes surplus. And there is a contradiction between paket length in IP header and TCP data offset bits. 3. option part of SYN packet(00 00 02 04 05 b4 01 01 04 02) changed to (00 00 00 00 00 00 00 00) in Target's SYN-ACK-Packet. Please, could you enlighten me what is cause of this phenomenon ? By the way,I calculated checksum mannually and confirmed they are all correct. I only changed coding in retrieving data in BigEndian as I reported to you. I think others are resolved by Macros of bigendian. Currently when building, Resolve conflicts dialog appears like below. Resolve conflicts Item Conflict Property CYGPKG_POSIX_CLOCKS Unsatisfied Requires CYGBLD_ISO_STRUCTTIMEVAL_HEADER=="" CYGPKG_FILEIO_FNMATCH Unsatisfied Requires CYGBLD_ISO_FNMATCH__HEADER=="" Proposed Solutions: Item Value x CYGBLD_ISO_FNMATCH__HEADER Enabled, x CYGBLD_ISO_STRUCTTIMEVAL_HEADER Enabled, I also send ecc file. Suspicious option is CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE. Now CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE is false Must I make it true ? I am checking myself options, but it is like searching diamond among Pacific Oceans' sands. Could you give me atleast any hints whatsoever ? I look forward for your reply. Thanks in advance. Masahiro Ariga