4.7.7: TCP problem ; 5.3: Kbd problem

[edteach]

Hello.

I got a problem with TCP in TCL 4.7.7. I wrote a network application, but it works wrong on some test stands, so, I decide to explore network state.
I have two machines connected by eth. One running under Win7 and another one under TCL 4.7.7. I use iperf utility to test bandwidth and wireshark to examine network state.
After test running, I got unexpected and incomprehensible results:

from iperf

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.2.12 port 5001 connected with 192.168.2.10 port 2602
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-13.3 sec  1.25 MBytes   786 Kbits/sec

and from wireshark


I've tryed to experiment with some kernel params, but couldn't fix it. So, I've changed 4.7.7 to 5.3 and got normal results:
about 92 Mbits/sec from iperf
and from wireshark


Next, I decide to use TCL 5.3 instead 4.7.7.
BUT! I got a new effect.. I use embedded system w/ two USB ports and when I put my kbd directly to one of them - it don't work.
If I use hub, connect it to USB port, then connect kbd to hub - it works.
Funny, I have no such problem on 4.7.7. Kbd works fine, w/o hub.

Finally, I can't use 4.7.7 because TCP is a problem and i can't use 5.3 because kbd is a problem. And I have no idea how to fix each one.

Please, help!
 
WBR,
Alexander.

[Rich]

Hi edteach

I got a problem with TCP in TCL 4.7.7. I wrote a network application, but it works wrong on some test stands, ....

You don't state what programming language or what task your application is trying to accomplish.

Download the tar file attached to this post:
http://forum.tinycorelinux.net/index.php/topic,16735.msg100524.html#msg100524
Make sure you have the  compiletc  extension installed. Unpack the the file, go into the  findshares  directory and execute:

Code: [Select]

./compilefindsharesAfter it is done compiling, execute:

Code: [Select]

./findsharesThis is a program written in C that finds all the available network connections in a computer and then scans  those connections for any
Windows and NFS directories that other computers on the network are sharing. This should help you to determine whether your problem
is due to a programming error or due to quirky hardware. The program only relies on  /lib/libc.so.6  so once compiled should run as is on
pretty much any Linux with a 2.6 or greater kernel.

[edteach]

Hi, Rich.
Thanks for answer.

You don't state what programming language or what task your application is trying to accomplish.

It doesn't matter. If you want to know, I use C/C# for typical client-server app. But it's another question.
Let's forget about my app and imagine:

1. It is 2 machines with newly installed OS: 1st machine is PC under Win7 and 2nd - embedded system under TCL 4.7.7. Systems are clean and newly installed, I repeat.
2. I download Iperf utility and Wireshark for Windows.
3. Next, I install iperf.tcz on TCL (tce-load -wi iperf, you know).
4. I start wireshark on Windows.
5. I start iperf as server on TCL-machine (iperf -s) and as client on Win-machine (iperf.exe -c <TCL-machine IP>)
6. When data changing starts I see strange things in Wireshark (as on image 1 above) - dup acks, out-of-order packages, etc.
7. When iperf done, I see that bandwidth is low, actually, in 100 times lower than should be.

See, I don't use my program or something else handmade things. Only standard packages and programs. And if I change TCL to 5.3 this effect is gone, like at image 2 above.

Regarding findshares, I tryed it out and got error on line 508. But i think it's some permission troubles, maybe firewall on Win-machine. I'll examine this a bit later.

WBR,
Alexander.

[Rich]

Hi edteach
Sorry, I misunderstood what you were doing in your original post. Not being familiar with iperf I did not realize it was generating the
timing data.

6. When data changing starts I see strange things in Wireshark (as on image 1 above) - dup acks, out-of-order packages, etc.

It's been a while, but I thought TCP doesn't guarantee the order of packets, only that they arrive.

Regarding findshares, I tryed it out and got error on line 508. But i think it's some permission troubles, maybe firewall on Win-machine. I'll examine this a bit later.

The twisted mess which is Windows file sharing requires trying various ports and network connection/query commands depending on
how the Windows machine is set up and which version of Windows is being queried. When a machine fails to respond, an  Error line #
message is spit out indicating where in the sequence of commands it failed, and then proceeds to query any other machines present.