Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[davevt31]

Hi,

As a follow up to my earlier post about the Schedules Issue, it now seems as tho not only can you not edit an existing schedule, but the existing schedule, seemingly once editied "incorrectly" is now out of synch with the time clock of the router.

The item in question here was set to run from 10:15 PM to 10:30 AM and block access for a couple stations during that time.  Tonite when those stations were trying to go online at 8:10 PM, they were fully blocked.  In order for them to get online, I had to disable the Access Control item for that Policy.

Has anybody else seen this ?

SD1

I don't use any policies, but I do remember seeing a thread around here that said to try setting a policies so that they don't overlap midnight.  So maybe you could try to set one to run from 10:15 PM - 12:00 AM and then a second one to run from 12:00 AM - 10:30 AM.

[EddieZ]

The other thing I noticed is I no longer connect at 300mbit.  Prior to the upgrade from 1.11 to 1.20b7, I was connected at 300mbit/100% quality.  I'm using a DWA-652 wireless adapter.  The other fun tidbit is I was running the router on Low wireless power and getting that result.  But now I've bumped it up to High power and have no better result.  It's like something disabled the 40mhz channel.  I'm stuck at 130mbit.

[edit]  To give more information.  I'm in 802.11g/n mode, WPA2/AES encryption, the only wireless device on my network is a DWA-652, auto channel, auto transmission mode, no guest network, and I did verify all 3 of the antennae are properly screwed in.

My 655 is HW A2, FW 1.20b7.

I found this text in one of the beta packages:

Here are some reasons according to our understanding of the Wifi standard of why you may not be able to
see 40mhz as easy as before.
 
1)If an AP is booting up, it will cause all existing AP’s to go back to 20Mhz for at least 30 minutes

2)If an AP detects a Beacon from an AP with 40Mhz Intolerant Bit Set. An AP will set this bit if they
  have a legacy client. AP will go to 20mhz.
a.This basically means if there is a single legacy client connecting to an AP, it will kill all AP’s
  within its range to go to 20mhz.

3)If a AP receives a message from its client with 40Mhz Intolerant Bit Set. AP will go to 20mhz.

4)If there is legacy or 20mhz only AP in the extension sensitive channel. AP will go to 20mhz.

5)If there is noise on the extension channel. If the noise is above certain threshold, the channel will
  not be used. AP will go to 20mhz.

[ttmcmurry]

So then the question is, why when I revert to v1.11 firmware does the 300mbit data rate work?  I wonder if it's something that was accidentally changed or broken in one of the beta builds.  I'm using a DWA-652 Wireless-N PC-Card.  The other thing that bothers me is the quality of the reception also has decreased from 100%/300mbit (v1.11) to 76%/130mbit (v1.20b7).  A downgrade improves both quality and speed.  Mind you I'm ~6 feet from the router in a direct line-of-sight.

I tested a FTP upload to a DNS-323 with 5 simultaneous uploads and got 66.5 Mbit/sec (8.3 MB/Sec or 51% utilization) throughput on a 130mbit connection.  Not bad at all, eh? 

Methinks there is still work to be done before this can be a final release.

[edit]
When reverting back to v1.11, I get 300Mbit/100% Quality.  Tested the same five simultaneous uploads and got 84 Mbit/sec (10.5 MB/Sec or 29% utilization).  I'd like to know what's up with the beta code.
[/edit]

[EddieZ]

According to the router connection is at 70% with the new beta firmaewware, but the laptop still gives 99%, connectiong @130 (intel :-( ) So no actual degrading.

[ttmcmurry]

[edit]

The issue I experienced is not related to the DIR-655.  After further investigation, a piece of software that was installed on my computer (without my knowledge) a la the Bittorrent setup package.  Apparently it installs something called "DNA" which sends UPnP info to the router even when bittorrent (or utorrent) is not running, and makes connections to other peers on the internet, supposedly with the goal of speeding up everything from web browsing to video streaming.  Remove it if you find it, it really seemed to tax the router.   

Once DNA runs, it opens the port on the router and you can't stop it easily.  Even if you kill the DNA service, the ports on the router stay open and it accepts the connections, a reboot of the router was necessary for me after uninstalling DNA. 

Ugh.
[/edit]

[EddieZ]

[edit]

The issue I experienced is not related to the DIR-655.  After further investigation, a piece of software that was installed on my computer (without my knowledge) a la the Bittorrent setup package.  Apparently it installs something called "DNA" which sends UPnP info to the router even when bittorrent (or utorrent) is not running, and makes connections to other peers on the internet, supposedly with the goal of speeding up everything from web browsing to video streaming.  Remove it if you find it, it really seemed to tax the router.   

Once DNA runs, it opens the port on the router and you can't stop it easily.  Even if you kill the DNA service, the ports on the router stay open and it accepts the connections, a reboot of the router was necessary for me after uninstalling DNA. 

Ugh.
[/edit]

This is DNA: http://torrentfreak.com/bittorrent-dna-vulnerable-to-remote-hijack-080103/comment-page-2/

[Ra1z3r]

Went from 1.12 to 1.20b07 and it's working great. I backed-up my configuration and was able to successfully restore it on 1.20.

My SIP clients are all able to successfully register with my SIP service provider as well as make and receive audio/video calls. Here is a list of my SIP clients:

• eyeBeam client version 1.5.19
• Nortel i2004 running software version 2007-11-27-1021
• Nortel PC Client version 4.1.560
• Tandberg 150MXP running software version L5.1

My H.323 endpoint, a Tandberg 1700MXP running software version F7, is able able to successfully register with it's border controller. I'm able to successfully make and receive calls with it.

Everything else also works great so far.

[bspvette86]

I do not understand what D-Link is thinking with this bass ackwards release strategy of Major release, then immediately issuing beta releases.  Come on D-Link, we all want STABLE major releases rather than this perpetual beta cycle to fix the issues created by the major releases...  More frequent patch cycles with fewer changes... etc.... yada yada yada.

Regards,
BV

[EddieZ]

I do not understand what D-Link is thinking with this bass ackwards release strategy of Major release, then immediately issuing beta releases.  Come on D-Link, we all want STABLE major releases rather than this perpetual beta cycle to fix the issues created by the major releases...  More frequent patch cycles with fewer changes... etc.... yada yada yada.

Regards,
BV

AFAIK 1.20 has not officially been released, only beta. In a way you are speaking contradictions. You might also celebrate the speed of their update strategy. My Linksys/KiSS device gets an update once a year and even then there's a reasonable change it don't work, no in between beta's to discuss. So quality and major updates are not really related...

[bspvette86]

AFAIK 1.20 has not officially been released, only beta. In a way you are speaking contradictions.

Not officially released?  Are you kidding?  http://support.dlink.com/products/view.asp?productid=DIR%2D655
This is the exact same thing that happened with 1.11.  Released it, then the following week the B version(s) arrived.  We all sat on 1.11B## until 1.20 came out months later...

No contradictions here.   

BV

[EddieZ]

Yep,you're right. Strange to see this. According to my info should not even be up there...