Printable View
Yes, you've reached the maximum number of concurrent IP connections over the router. New connections are being refused -> dropped. This mostly happens when you're using P2P software. By default the router can handle 1024 concurrent connections. You can set this to a higher number like 2048 or 4096. This has been described in this forum before.Quote:
Originally Posted by MSG
Firstly, Thanks for the reply~~=)Quote:
Originally Posted by Styno
In my case, I've set my p2p client to accept no more than 80 connections at a time for each transfer concerned, and it shouldn't have more than 200 connections at a certain time since I don't do multi transfers often, then how come I manage to get more than 1024 concurrent connections? I'm quite puzzled about this. Also, could this be related to why my PPPoE connection drops off??
I've done a search in how to set my concurrent connection to a higher number, but since I'm now using the new firmware of 1.8.1.7-1, is it still the same? and do I just execute them in the web interface?
nvram set bootCmdXXX="echo 4096 > /proc/sys/net/ipv4/ip_conntrack_max"
nvram commit
Thanks
Are you using Azureus? If so I will post my example for you:Quote:
Originally Posted by MSG
I am NOT using PPPoE, just a plain LAN ADSL 2048/256 connnection
I have set in Cinfiguration / Transfer the following:
Azureus ver. 2.1.0.4 official.
Max # of connections per torrent: 80
Max # of connections globally: 500
Default max uploads slots per torerent: 3
When doing multidownloads of popular torrents I have checked in Netlimiter 1.30 (excelent not only for bandwidth shaping but for the statistics that it gives you, recommended) and I have found that active connections number made from Azureus can go higher than the max global # of 500. It has been sometimes as high as 800, but never reaching the 1024 limit. This has been downloading from a known and popular torrent site and usually having 5-6 active torrents (2 seeding, 4 downloading). I recommend you checking the real actual connection # with any program that gives you this info, remember that it is not only Azureus using your connection at a given time, there are other apps doing it also. If you find that it is not Azureus then I recommend you checking against spyware or other nasties if you have not yet done so.
FYI bootCmdX does NOT work anymore in custom 1.8.x.x related firmwares it's obsolote, for more info: read the thread where you got the custom firmware from.Quote:
Originally Posted by MSG
i've tested the 1.8.1.x for a month. (1.8.1.9 and 1.8.1.7-2a)
The disconnect problem is sitll occurred when i was using Bit Torrent. I'm not sure that what will cause it happen. Sometimes it can run it for a day. Sometimes it runs couple mins then it will disconnect. I guess the problem may caused by when too many connection and a higher transfer occurr at the same time then the connection will be disconnected
The following are the Log after disconnect from firmware 1.8.1.7-2a
Quote:
Jan 1 09:29:27 smallkeung-nas user.warn klogd: Adpt 0 c000
Jan 1 09:29:28 smallkeung-nas user.warn klogd: Link up c000 8100
Jan 1 09:29:28 smallkeung-nas user.warn klogd: Adpt ffffffff 8100
Jan 1 14:25:44 smallkeung-nas user.warn klogd: Link down c033
Jan 1 14:26:07 smallkeung-nas local2.notice pppd[87]: Serial link appears to be disconnected.
Jan 1 14:26:07 smallkeung-nas local2.warn pppd[87]: Couldn't increase MTU to 1500
Jan 1 14:26:07 smallkeung-nas local2.err pppd[87]: Couldn't increase MRU to 1500
Jan 1 14:26:08 smallkeung-nas user.emerg PPPoE: Disconnected
Jan 1 14:26:13 smallkeung-nas local2.notice pppd[87]: Connection terminated.
Jan 1 14:26:13 smallkeung-nas local2.warn pppd[87]: Doing disconnect
Jan 1 14:26:20 smallkeung-nas user.warn klogd: Adpt 2 c000
Jan 1 14:26:21 smallkeung-nas user.warn klogd: Adpt 1 c000
Jan 1 14:26:22 smallkeung-nas user.warn klogd: Adpt 0 c000
Jan 1 14:26:23 smallkeung-nas user.warn klogd: Link up c000 8100
Jan 1 14:26:23 smallkeung-nas user.warn klogd: Adpt ffffffff 8100
Jan 1 14:26:43 smallkeung-nas local2.err pppd[87]: invalid packet
Jan 1 14:26:43 smallkeung-nas local2.err pppd[87]: Failed to negotiate PPPoE connection: 9 Bad file descriptor
Jan 1 14:26:43 smallkeung-nas daemon.err pppoe-relay[82]: PADO packet from 00:e0:fc:10:29:48 on interface eth1 does not have Relay-Session-Id tag
I've a stupid question. What's the meaning for the WAN port die are you guys talking? At the beginning, i upgraded to 1.8.1.x from 1.7.1.x The Router can't connect to the internet. Then i discovered that the WAN port light didn't on. Finally, I changed the Port from auto to 10mb Full. This problem is fixed. I never see the WAN port light off.Quote:
Oct 28 21:21:38 smallkeung-nas user.emerg ntp client: time is synchronized to asia.pool.ntp.org
Oct 28 22:53:09 smallkeung-nas user.warn klogd: Link down c033
Oct 28 22:53:13 smallkeung-nas local2.notice pppd[87]: Serial link appears to be disconnected.
Oct 28 22:53:13 smallkeung-nas local2.warn pppd[87]: Couldn't increase MTU to 1500
Oct 28 22:53:13 smallkeung-nas local2.err pppd[87]: Couldn't increase MRU to 1500
Oct 28 22:53:14 smallkeung-nas user.emerg PPPoE: Disconnected
Oct 28 22:53:19 smallkeung-nas local2.notice pppd[87]: Connection terminated.
Oct 28 22:53:19 smallkeung-nas local2.warn pppd[87]: Doing disconnect
Oct 28 22:53:20 smallkeung-nas user.warn klogd: Adpt 2 c000
Oct 28 22:53:21 smallkeung-nas user.warn klogd: Adpt 1 c000
Oct 28 22:53:22 smallkeung-nas user.warn klogd: Adpt 0 c000
Oct 28 22:53:23 smallkeung-nas user.warn klogd: Link up c000 8100
Oct 28 22:53:23 smallkeung-nas user.warn klogd: Adpt ffffffff 8100
Oct 28 22:53:49 smallkeung-nas local2.err pppd[87]: invalid packet
Oct 28 22:53:49 smallkeung-nas local2.err pppd[87]: Failed to negotiate PPPoE connection: 9 Bad file descriptor
Oct 28 22:53:49 smallkeung-nas daemon.err pppoe-relay[82]: PADO packet from 00:e0:fc:12:f4:ca on interface eth1 does not have Relay-Session-Id tag
Oct 28 22:53:49 smallkeung-nas daemon.err pppoe-relay[82]: PADO packet from 00:e0:fc:0f:39:d8 on interface eth1 does not have Relay-Session-Id tag
Oct 28 22:53:49 smallkeung-nas daemon.err pppoe-relay[82]: PADO packet from 00:e0:fc:10:29:48 on interface eth1 does not have Relay-Session-Id tag
If this kind of problem is the WAN port die issue of you guys talking, then my problem is another disconnect problem.
I can't seem to work out how I can set the ip_conntrack value to a higher value, can someone please teach me the steps I should take (for new firmware 1.8.1.7-1) to set it higher?Quote:
Originally Posted by Antiloop
Also, can someone tell me the command I should use to disconnect and connect when I use telnet or through the web manager interface?
Thanks
Have you tried the webinterface? If it does not work, you can also try to figure out what that options does in the source of the page and try to debug it.Quote:
Originally Posted by MSG
1.8.1.7-2a has "maximum connections to track in the web iface"Quote:
Originally Posted by MSG
1.8.1.7-2a has "maximum connections to track in the web iface"Quote:
Originally Posted by MSG
Hi everyone!!
My wan port is still not working properly. I've tried fws 1.8.1.9, 1.8.2.4 and 9.8.2.1 and wan is going down.
I've also tried all the port speeds and the results were'nt good.
speed auto
RESULT: Takes a lot of time to connect(WAN dies in a few hours)
speed full10
RESULT: doesn't work at all (WAN light doesn't even go on)
speed half10
RESULT: doesn't work at all (WAN light doesn't even go on)
speed full100
RESULT: Takes a lot of time to connect(WAN dies in a few hours)
et -i eth1 speed half100
RESULT: Takes a lot of time to connect(WAN dies in a few hours)
My modem is a dlink dcm-200, could it be modem's problem????
I donīt know what to do!!! :confused: :mad:
Now running FW 1.8.2.4, and WAN port doesn't die anymore :cool:
My WL-500G is in AP mode, and now connection to first router (also Linux :D ) can stay in the WAN port :)
Hello.
Setting my Asus 500g to 100MBps fixed speed the WAN die problem has totaly disappeared. This was a major problem for me bacause I have a 10mbps/10mbps internet connection, and you can imagine how few bytes you can transfer before the WAN died.
edit: used with success with 1.8.1.7-1, -2a and -3
I have 5 units in my wifi network, and EVERY 500g have problem when speed reach more than 2 MB/s
especialy if you connect two 500G, one from LAN to another WAN port.
Just for few second after booting, WAN LED just turns off and on non stop if there is any kind of more speedy transfer. If it reach 2 MB/s or more, port dies.
I tryed to fix speed on all speeds, but it wont work because it just stops to work within 1 or 2 seconds.
I tryed every useable firmware revisions, but everything is the same.
I found 1.8.2.4 BETA on asus site, where they wrote that they fixed WAN problem, but after uplaoding, WAN is completly DOWN...
I saw that if ASUS and unit on the other WAN side are connected over SWITCH (10/100 with shorter cables) it dies but after 2-3 hours of continous 3-4 MB/s transfer
This is a problem, big one... other bugs are cosmetic-like
Have you tried resetting to defaults after firmware upgrade? This might solve your problem...
yes, I tryed everything, with and without reset, with different UTP cables,models of switch,with other units (linksys wrtg54g,pheenet 118G,dlink dwl2000+)
and result is the same,if transfer reach 2,5 MB/s and more, dies within a 10-20 sec