Gargoyle Forum

Hi Eric, i tried the same simple procedure to upgrade my WRT54GL to the 1.3.11 version with the TFTP method and after that i changed some ip settings manually it finally respond now. I had always issues to try this with version 1.3.10, but now i change the settings and saving them and now it replies. So it looks to be good news for me to try again continuing testing with this new version. I will try the coming days to change it and using it again as a router and also a bridge combined. I keep you informed about my progress. Thanks

After restarting the router( power off/on) it didn't respond anymore. Pffff i stay with 1.3.9...

The sysupgrade command didn't work for me to go from 1.3.10 to 1.3.11. It seemed like nothing happened beyond the router rebooting. The mtd write method worked, after a manual power cycling.

I backed up and restored my 1.3.10 settings. Would there be any issues with that, as there were from 1.3.9 to 1.3.10? Everything seems to work and the settings look correct, but I thought I'd double check.

Hi there,

Here's my scenario, after assigning static ip addresses paired with specific mac addresses, and with the "Block MAC addresses assigned a static ip that connect from a different ip" box ticked, in order to enforce quota for each specfic users.

The problem is that if a user manually changes his ip address, he/she can still connect to the router and therefore bypass the quota system. Is this a bug?

Anyone having the same problem? Workarounds?

Thanks!!!

REQUEST:

May we please, please, please add the option to select clients from the already populated DHCP table when adding QOS destination rules?

Sucks to have to enter all the clients in the DHCP and then manually have to type in all of their IP addresses again..

Thank you

iamedmond wrote:Hi there,

Here's my scenario, after assigning static ip addresses paired with specific mac addresses, and with the "Block MAC addresses assigned a static ip that connect from a different ip" box ticked, in order to enforce quota for each specfic users.

The problem is that if a user manually changes his ip address, he/she can still connect to the router and therefore bypass the quota system. Is this a bug?

Anyone having the same problem? Workarounds?

Thanks!!!

Thats why I specified a range for quota to use in general, and then kept a small part of the addresses left over in that subnet for my static dhcp connections. Keeping it MAC linked for dhcp won't help, even if they can't change IP. He could change the mac address in the bios or driver and get a new address from dhcp!

Something is wrong with this version.
Making changes twice , to Qos , Wifi, static ips causes router to reboot.
It's annoying especially when testing different QoS configurations, making changes and router restarts every 2 pressed "Save Changes".
Sometimes it even reboots twice before back to normal operation
Configuration is saved and applied after reboot.
I have WR1043ND , clean configuration without restoring backups from earlier versions.

Mitar: That definitely sounds like a serious bug! I didn't notice anything like this when testing, but I will test again on my 1043ND tonight. It might help to replicate (and therefore identify) the problem if you could provide more information about how you have your router configured.

keelerds: Shouldn't be a problem -- there were no major config file changes in this release like in 1.3.9->1.3.10

fine , I begin configuration from setting custom MAC address for WAN, also custom MTU. then changed default router LAN ip address, added 3 custom dns servers and used "force clients to use router dns servers". After that enabled wifi , changed channel width to 40 Mhz, transmit power to 16 and set encryption WPA2 PSK.
Thats all after this pressed "Save changes" and router rebooted.
Then I added few static ips addresses , pressed "save changes" and it rebooted again . also added some qos rules and it rebooted again.

I noticed after I reset the router to defaults, and set the NTP time to update every 12 hours, the 12 hours doesn't seem the stick in the web interface. I think if I pick a different number than 12 though it seems to work fine. Also, if I pick a number other than 12, save it, then switch it again to 12, it seems to work. The NTP client according to top doesn't change either... It seems to update after I restart the router though. I'm not really sure how this was intended to operate.