tobythetenor wrote: @faris and floobe:

GRE is Cisco proprietary and will only work between Cisco devices.

This is an outbound PPTP VPN which uses protocol 47/GRE. It's not the end of the world but weird why it doesn't work - I'm assuming the Draytek is grabbing the PPTP stuff on the way back in.

This post seems to have been hijacked.

Either way, in case people have not seen from other posts. So far I seem to have been able to resolve my wifi issues along with others using following process:

1) Backup your config file from web ui
2) reset router using 30-30-30 method (while router is on, hold reset button for 30 seconds, keep the reset button on front held in and remove power cable for a further 30 seconds, then insert the power back in leaving the reset button held down for a final 30 seconds.
3) at this state the lights on front are probally flashing quickly. Then use the draytek firmware flashing tools (can find a copy on ftp.draytek.com.tw) to flash the latest non-beta firmware to the device using the default 192.168.1.1 IP and admin as the password. (This failed for me first time using windows 8.1 - seemed to run though fine the second)
4) when router comes back log in and restore backed up settings file.

So far, so good. No more drop-outs on mobile devices in particular.
Seems there may be an issue updating firmware using the web ui from multiple browsers.

I'll wait a bit longer to update their support teams but I suggest you all give this a go!

FazzaUK wrote:
So far, so good. No more drop-outs on mobile devices in particular.
Seems there may be an issue updating firmware using the web ui from multiple browsers.

I'll wait a bit longer to update their support teams but I suggest you all give this a go!

Just done this again, with the *.rst file. 10 mins no drops. Will see how it goes and keep you guys updated.

Just popped back to my thread to see where this issue was going as hadn't received any post notifications for a while... no wonder, it's gone crazy!

Have brought myself up to speed and will be trying the reset fix as suggested. Reporting back soon!!!

Before reading this please know that the advice given to me by tech support was to factory reset and manually reconfigure, so please take their advice or do the 30-30-30 reset over what I have done.

After investigating the issue on my new 2680n+ (upgraded to firmware version 3.7.4.1), it came down to the 2680n+ Address Resolution Cache (ARP) not refreshing correctly on wi-fi (or maybe even VLAN1+???), works perfectly with directly connected devices. My resolution while I await the firmware update was firstly to increase the ARP cache lifetime to 10 minutes (ip arp setCacheLife), as most devices have a default of around 1-2mins, and will refresh their own cache if not already done by the other device. This worked great for newer devices, Nexus 5/7, Windows 8 etc. But on older devices the problem persisted. The second that I'm still using and works completely is to create a static ARP table via Bind IP to MAC for all wireless devices (obviously this would be a pain unless you know what devices will be connecting)... but with it it's been flawless for about a week now with 4 wireless LANs, 2 on VLAN1 (2.4Ghz, 5Ghz) and 2 on VLAN0 with hidden SSIDs again 2.4Ghz and 5Ghz.

ARP Info:
http://en.wikipedia.org/wiki/Address_Resolution_Protocol

Console commands:

Code:

ip arp status

(to see which devices have an ARP entry,.. keep refreshing (Up arrow, then enter) and watch your wireless devices disappear)

Code:

ip arp setCacheLife

(to see how long ARP cache entries will stay alive until they need refreshing)

More info for those interested:
When the ARP cache lifetime expires (or gets close) for a devices IP/MAC Address, normally an ARP request is sent out to the devices MAC address to see if the device still exists and has the same IP. If a reply is received the routers ARP cache entry is updated and the timer reset. If no reply is received then the routers ARP cache entry is removed. This will cause the router to not know where to send any packets it receives for the IP, hence the wireless connection will still be active but no packets will be received. When the device notices that no packets are being received it normally send out it's own ARP request for the default router, this in turn will update the routers ARP cache and restore normal operation... so with default settings, every 1-2 mins or so for a about 10-20 secs, no packets will be received by the device.

If tech support/devs want some winpcap logs, I can reproduce this at will... currently.

I'd send this to support in case it's of use.