Bekijk de volledige versie : LAN problem: does not work for big files.
Darius_LT
13-06-2007, 12:32
I have a strange problem with my WL700gE. The “wired” connections do not work properly. It looks like a software problem thought. Files, web pages, pictures, anything that is above 10kB cannot be transferred. Only the first data “packet” of such size is transferred, then the connection is stalled.
Problem cases:
File exchange (samba) between rooter and PC by wires (LAN).
FTP access from WAN to the rooter.
Internet access from LAN PC.
There are no problems:
Internet access from WLAN PC.
File exchange (samba) between rooter and WLAN PC.
My rooter is connected to a cable TV modem.
PC is Windows XP notebook.
At the beginning there were no problems. It appeared by it self. The firmware was 1.0.4.6 Yesterday I have installed the custom firmware, still the same problem. :((((((
Any ideas?
I have a strange problem with my WL700gE. The “wired” connections do not work properly. It looks like a software problem thought. Files, web pages, pictures, anything that is above 10kB cannot be transferred. Only the first data “packet” of such size is transferred, then the connection is stalled.
Problem cases:
File exchange (samba) between rooter and PC by wires (LAN).
FTP access from WAN to the rooter.
Internet access from LAN PC.
There are no problems:
Internet access from WLAN PC.
File exchange (samba) between rooter and WLAN PC.
My rooter is connected to a cable TV modem.
PC is Windows XP notebook.
At the beginning there were no problems. It appeared by it self. The firmware was 1.0.4.6 Yesterday I have installed the custom firmware, still the same problem. :((((((
Any ideas?
My bold. Did you by any chance run a Windows update just before "it appeared by it self"?
There are some vested interests in this world who seem to think it is their best interests if samba doesn't work with Windows PCs.
Vista has default settings that make it not work with some versions of samba. You may have got a *cough* helpful "Windows update" that caused this to your XP system ... in the name of Vista compatibility.
Darius_LT
13-06-2007, 12:58
The problem is not there. NOTHING works from LAN side if the data chunk is bigger that ~10kB. Explanation of NOTHING WORKS: E.g. I can connect to FTP or Samba or HTTP, but the transfer is stopped after about first 10kB. Than I can reconnect again and again the same story. Reboot does not help.
The Windows update is out of question. Else I would have the same problem also from WLAN side.
I also have exactly the same problem if I connect to my Asus from WAN (UNIX server at uni).
My bold. Did you by any chance run a Windows update just before "it appeared by it self"?
There are some vested interests in this world who seem to think it is their best interests if samba doesn't work with Windows PCs.
Vista has default settings that make it not work with some versions of samba. You may have got a *cough* helpful "Windows update" that caused this to your XP system ... in the name of Vista compatibility.
The Windows update is out of question. Else I would have the same problem also from WLAN side.
I also have exactly the same problem if I connect to my Asus from WAN (UNIX server at uni).
These two statements seem contradictory.
Either the problem is constrained to one "side" or the other, or it is universal.
If it is universal, then it is doubtless related to the router itself.
If it occurs only on "one side" and you have only Windows machines on that one side, then it could be a problem with Windows rather than the router. Since Windows is regularly updated, and the router is not, and since the problem suddenly "just appeared", then a Windows update is a likely suspect.
If indeed the problem also occurs "from a UNIX system on the WAN", then clearly it is not Windows related, but in that case I can't work out what you could possibly mean by saying "Else I would have the same problem also from WLAN side".
Are you in a position to check NFS access from the LAN? Are you in a position to be able to check the samba server on the router using a Linux samba client on the LAN? Those test may be able to help isolate if the problem is in the clients rather than in the router.
Your problem may not be related to samba, it may lie with tcp/ip and/or firewall software, and once again it is more likely to be the tcp/ip software which changed rather than the tcp/ip software which did not ... which is to say, the most likely suspect IMO is still the Windows client machines.
Darius_LT
13-06-2007, 21:38
I see that you still don't understand the problem description.
The same win XP notebook and the the same Asus router are used for two test:
Test 1. I connect to the router by use of wireless LAN. The HTTP, FTP (Internet and 192.168.1.1) and Samba work without any problem.
Test 2. I connect to the router by use of wired LAN. The HTTP, FTP (Internet and 192.168.1.1) and Samba have problem like specified before.
¨
So yes, it is a software problem in the rooter. I am just a beginner in Linux, so please give me some hints how to narrow down the problem in the box.
These two statements seem contradictory.
Either the problem is constrained to one "side" or the other, or it is universal.
If it is universal, then it is doubtless related to the router itself.
If it occurs only on "one side" and you have only Windows machines on that one side, then it could be a problem with Windows rather than the router. Since Windows is regularly updated, and the router is not, and since the problem suddenly "just appeared", then a Windows update is a likely suspect.
If indeed the problem also occurs "from a UNIX system on the WAN", then clearly it is not Windows related, but in that case I can't work out what you could possibly mean by saying "Else I would have the same problem also from WLAN side".
Are you in a position to check NFS access from the LAN? Are you in a position to be able to check the samba server on the router using a Linux samba client on the LAN? Those test may be able to help isolate if the problem is in the clients rather than in the router.
Your problem may not be related to samba, it may lie with tcp/ip and/or firewall software, and once again it is more likely to be the tcp/ip software which changed rather than the tcp/ip software which did not ... which is to say, the most likely suspect IMO is still the Windows client machines.
Reduce the MTU size on the box that doesn't work. See here for more info:
http://blue-labs.org/howto/mtu-mss.php
Your update might have set up a firewall which blocks ICMP packets.
- K.C.
Darius_LT
14-06-2007, 12:42
Thanks kfurge. I will look into that later. But I have a bad feeling about this one. I don't think it is the MTU. It is the same notebook.
Ogh! I think I already tried this one. The current MTU value is 1300 on all interfaces.
Anyway, wireless LAN is OK and non-wireless LAN is not? I doubt that it is notebook related. The notebook works fine at University etc. (Unix servers, windows workstations, LAN, WLAN, VPN).
I have printed all config data (nvram, iptables, ifconfig). I will examine these ant then I will return with findings or further questions.
Can it be a fault of a somehow broken NAT?
Can any changes from ISP side cause such a problem?
BTW. This morning I did a ping test from PC to router. About 10% of 16000 size pings are lost on LAN. 0% of 1599 size pings are lost. About 20% of 65500 size pings are lost.
Edit: Windows firewall has the same rules for both - LAN and WLAN.
P.S. Right now I use the beta firmware - 2.0.0.7.
Reduce the MTU size on the box that doesn't work. See here for more info:
http://blue-labs.org/howto/mtu-mss.php
Your update might have set up a firewall which blocks ICMP packets.
- K.C.
Thanks kfurge. I will look into that later. But I have a bad feeling about this one. I don't think it is the MTU. It is the same notebook.
Ogh! I think I already tried this one. The current MTU value is 1300 on all interfaces.
Anyway, wireless LAN is OK and non-wireless LAN is not? I doubt that it is notebook related. The notebook works fine at University etc. (Unix servers, windows workstations, LAN, WLAN, VPN).
According to the OSI 7-layer model:
http://en.wikipedia.org/wiki/Seven-layer_OSI_model#Description_of_OSI_layers
... the wireless network stack and the wired LAN network stack for the router should be exactly the same all the way down to layer 2 (in the case of TCP/IP, the "IP" part is layer 3, and the "TCP" part is layer 4).
Typically, part of layer 2 and all of layer 1 would be in the hardware.
If you have a fault that "suddenly appeared" and which affects all TCP/IP communication on the wired LAN but not the wireless LAN, then I'm afraid I would strongly suspect the router has developed a hardware fault associated with the wired LAN ... probably the switch part.
Darius_LT
14-06-2007, 14:11
I am thinking the same way, but I hope it is not case. Anyway it would be quite strange hardware failure.
BTW, some results. nvram and iptables look like correct. ifconfig does not show any errors (except for WLAN (eth1), but this is to be expected due to radio signals).
So my guess is that there is data corruption at HW level and the HW drops packets with bad CRC or what ever it does to overcome the problem. Therefore TCP/IP does not see anything problems except lost packets.
Well, then I must send it back for warranty repair. BTW. It looks like warranty stickers on the harddisk cover were torn by internal tensions (due to temperature???). Have you observed something similar?
According to the OSI 7-layer model:
http://en.wikipedia.org/wiki/Seven-layer_OSI_model#Description_of_OSI_layers
... the wireless network stack and the wired LAN network stack for the router should be exactly the same all the way down to layer 2 (in the case of TCP/IP, the "IP" part is layer 3, and the "TCP" part is layer 4).
Typically, part of layer 2 and all of layer 1 would be in the hardware.
If you have a fault that "suddenly appeared" and which affects all TCP/IP communication on the wired LAN but not the wireless LAN, then I'm afraid I would strongly suspect the router has developed a hardware fault associated with the wired LAN ... probably the switch part.