Linksys has released this firmware as a beta. I would like some imput into its functionality and any issues that you find with it. This thread is not a flame attack on linksys. it is purely to raise issues with the firmware so we can submit our findings to the developing team. There is also no point in asking for new features, since this firmware is beta it will be released as an official release in due time.
Refer to RV082 firmware change: 6. Change the DHCP Server implementation. When the DHCP client requests the IP address of DNS server, RV082 will offer the DNS server address obtained from ISP. (In previous firmware, RV082 offers the DNS server address as RV082’s LAN IP.) Since it doesn't allow DHCP to assign the RV082 LAN IP anymore, shouldn't it at least allow it to be backward compatible with older firmware? It is ignoring the setting in the DNS server fields to set it to the RV082 LAN IP. The internal DNS database is now useless because of this.
can you confirm this is the actual way it handles it? Are the DNS entries in the router's WAN Connection Type now bypassed totally?
Bandwidth Management – works great! I really needed QoS to set high priority for VoIP (such as Skype), IIS server (port 80 upstream), POP3 and SMTP. I use Dual WAN with load balancing (two ADSL lines, 1 and 1.5MBit with 256 and 512kbit upstream). I’ve split the load between the 2 WAN ports using Protocol Binding and as I see from the SNMP (Paessler IPCheck Server Monitor) both WAN ports are in use and they are loaded close to their maximum ~ 80% of the time. The problem I had were torrents and large files downloads… They can easily take over the entire bandwidth and leave my network with no useable internet access. Here is my test: Bandwidth Management: setting GRE, HTTP (port 80), Skye, POP3, SMTP to High priority on both WAN ports. And setting torrents (port 20877, manually set in BitComet) to low on both WAN ports. Then started download of few files (2-3 GB each so I’ll have enough time for the tests) – Download speed ~ 2.2-2.4Mbit/s Upload speed ~ 600Kbit/s. At this point my internet access would be useless, bit now the HTTP request work perfect (both loading web pages and accessing my IIS server), Skype calls are as good as if there were no BitComet running and most important – IPSEC VPN can easily get ~ 300-400Kbit/s upstream (it was impossible before). Also, it fixed one problem I couldn’t solve: Error in the Log file Failed to add rule File exists Failed nat control SIOCADNAT - File exists I’m very satisfied with this Beta version and hope to see the final version soon.
Sorry, I should have clarified that the DNS database still works fine. It's the DHCP part that doesn't allow one to automatically assign your computer to use the router LAN IP as DNS. It's useless in a sense until a user uses manual intervention on their own computer to redirect DNS traffic.
I haven't tested this yet. On 1.3.2, I'd get this error everytime QuickVPN users would try to connect. When did you get these errors? And are you sure it's gone? I know on the old firmware, rebooting/re-firming would make the error go away for a while.
The broken selective ACKs has been fixed in this beta even though the fix is not mentioned in the change log. That was my main problem with 1.3.2. The new Bandwidth Management seems to have eliminated the simple way to set the priority for usage of WAN1 vs. WAN2 by arbitrarily lowering the Maximum Bandwidth setting for one of the WANs that I had previously described for 1.3.2. This new feature is quite complicated and as usual the help file doesn't help much. My limited tests indicate that the use of the Bandwidth Management feature may extract a small penalty off of the maximum bandwith rate.
yeah ALL firmwares afaik had Selective ACKs fixed. any chance of a screenshot of the new bandwidth management? I'll ask the helpfile be updated then for bandwidth management.
Bandwidth management is user selectable either by rate control or by priority. Attached are screen shots of each method with some sample settings selected. The help file at least explains very briefly about the rate control settings, but doesn't say anything about what effect choosing a high vs. low priority level will do.
so my understanding from looking at that is you can have rate controlled services of a guranteed bandwidth. so what happens if you assign 3 or 4 services that have more than the WAN1 WAN2 upstream/downstream settings? looks a nice feature but you'd have to make sure each service when added together did not go over your max bandwidth limit.
This beta firmware does pass SACKs as noted in this thread, and, thereby, allows my cable connection throughput to return to normal, relative to the enormous loss of throughput resulting from the use of firmware 1.3.2.
Hi, new firmware test result for me (compared with previous fw issues for me); - Back to samme throughput as for 1.1.6.14 fw. - Improved VPN functionality for gateway(RV082) to gateway(RV08) where DNS now is forwarded without any manual setting for network adapter. I don't know if this is because of the new NAT-T functionality or the new setting possibilities in DHCP. Have not tested the client to gateway except I managed to connect with the SSH Sentinel client v1.4.1 as before with 1.1.6.14. Looking good so far!
Not a new bug to this beta firmware, but maybe worth mentioning. Setting static entries in DHCP sets the device name to "static-host". It should set it to the name in the static entry database. This impacts some people that need it using RV0xx series. Refer to this thread: click this link
Not sure what you mean by that. Prior to the 1.3.2...it had no place to name your static entries. With 1.3.2..they finally added the feature where you could name your static entry..so that way if you had several reservations..you could easily tell them apart. IE... 192.168.1.20 "Debbie" 192.168.1.50 "HP Color Laser" etc etc. So if you have to change any of them..due to hardware change down the line, easy to pick them out. Prior to that..you'd have to wade through all the MACs and back 'n forth stuff.
the easiest way to look at this pronlem is: In DHCP status Page the Client Host name says "static-host" and not the name you have given in the DHCP static IP settings.
I've installed it and it looks fine so far. Am pleased about the QOS, and web browsing actually seems snappier now too. It also seems to have cured a particularly obscure problem whereby a particular Nokia phone (An E70) couldn't talk to an IMAP server behind the RV082 with port forwarding. Other nokia phones worked fine, and the E70 could talk to other servers not behind the RV082, just not that particular set of specific circumstances. all fixed now which is a big relief. I guess the TCPIP stack has been tweaked in some way.
I just redeployed an RV082 as a segregated lan for my web servers in my enterprise and was haveing a lot of trouble with passive ftp connections. It tured out to be a bug in the nat traslations in the router this firmware updated fixes those issues and it it running great. I coul dnot beleave that this small devise can saturate my T3 connection.
SNMP Oids. It appears that they have changed again. I think back to where they were originally, as they changed for the previous stable release. Andy.
Ah gotcha gotcha...I just remoted into a client and took a peek...yes I see that. Odd glitch. Not a show stopper indeed...since if I needed to refer to find what IP someone was that I created a reservation for..I'd look at the reservation section..but yes..agree it's an odd feature. They're certainly taking their time grooming the DHCP reservations..heck, prior to 1.3.2 you couldn't even name your custom reservations. Now THAT was annoying. I normally have a full Windows server on most clients, hence I use DHCP on the server..but I have a few clients that are peer to peer networks..so I use the DHCP from the router.
Has anyone that was experiencing VPN MTU issues over DSL (shows as problems sending files upstream over the VPN from certain DSL providers) noticed if this is fixed? Prior to this beta I fixed mine by going to v1.1.6.11. I can't test the beta for at least a week from now. My site is busy with an event coming up and can't find a quiet time to test without getting people upset. What I'm reading so far is sounding good.
Well, bad news at one site. I had to revert back to 1.3.2 after 3 days on the beta. The symptom was that PPTP users were not able to access anything on the LAN side. Ping by IP address didn't work for all PPTP users. Everything else was working fine for LAN users. Unfortuneately, I was under the gun and didn't have time to thoroughly trouble-shoot the situation. But, I still wanted to mention this in case anyone else experiences this. I have another RV082 at home which is still working fine on the beta, although there is not much traffic to exercise it.
I have the same problem. Now my computers get the dns ip address of my isp and not of the the RV082. In a sense this is good because I think dns resolution will be faster but the bad part is that all entries that I have defined under "DNS Local Database" are not used anymore.
After a few day with the new FW 1.3.3.4 beta I found it not completely flawless. For instance the VPN tunnel created between two RV082 (both on 1.3.3.4) sometimes lose the DNS for the remote LAN. Ping on IP is still working. If manually disconnect and reconnect the VPN tunnel the DNS is working again. I have enabled NAT-T, Netbios (and Wins) and Keep-Alive together with names in the local and remote RV082 DNS database but still have this problem. It manly exsists after a long inactivity (shut down computers) on the local LAN side. One RV082 is on static IP (DSL) and one on dynamic IP (cable) from ISP.
v1.3.3.4 ==> still excessively Blocking UDP's as SynFlood Greetings; as others note, Selective Acks work now - and that helps me quite a bit, but.. My biggest problem seems to be that UDP traffic somehow triggers my RV082 SynFlood denial-of-service alarm and its blocking response too - the message logged by WallWatcher is: ratelimit: 1 messages of type block-synflood reported 1 second(s) ago (sometimes there are more than 1 messages/seconds, but it's always less than 5 ) My Firewall-page settings are: Firewall - enabled SPI - disabled DOS - disabled <=== !!! Block WAN request - disabled Remote Mgmt - disabled HTTPS - enabled Multicast pass-through - disabled MTU - Manual - 1500 (no Web features are restricted) Anyone interested in reproducing my issue can easily do so by installing http://www.BitComet.com - version 0.70 now - No file transfers required - the Dynamic-Hash-Table network will bring UDP messages that are blocked most of the time - Thank goodness some UDP messages get through, or I wouldn't be able to get my eBook fix from http://www.eBookShare.net Btw; you may have to manually forward a port for bitComet - their UPnP was not working in prior versions and I'm not sure that it's working in 0.70 either. Any correspondence would be greatly appreciated. William Arnold ~ Indianapolis, IN
Sometimes the router seems to stop responding to uPnP requests, and the only way to fix it is a soft reset. Honestly not sure if this is a new problem with this firmware or has been there before, but don't remember seeing it on previous versions. I've also noticed the 'SynFlood denial-of-service alarm', which appears to be a new 'feature' of this version. Seems to be triggered even when DOS is disabled in the firewall.
A little bit more info - We have a dual WAN load balanced setup with two ADSL connections. On the LAN side there are approximately 25 PC's, running a variety of uPnP applications. There will often be 3 or 4 people running uPnP bittorrent clients for for example. Initially I suspected the bittorrent client, but I also ran this: http://noeld.com/programs.asp?cat=dstools#upnptest This finds no trace of the RV082, just the colour printer on our LAN. A soft reset and the RV082 appears again. when upgrading I did a full factory reset btw.
Thanks for getting involved here, Toxic & morpheme! My bitComet P2P client happens to be at a static-IP machine on a NAT subnet with DHCP managed by the RV082. Trillian gets its UPnP ports just fine on another Dynamic-IP machine - but, bitComet has trouble getting UPnP up on the static-IP machine - Fyi, bitComet has documented UPnP troubles in previous releases and I haven't been able to rely on it in the latest release either. Btw; my RV082 announces UPnP every 60 seconds or so ~ I see this by watching (ip.dst == 239.255.255.250) && (udp.port == 1900) with Ethereal ( http://www.ethereal.com ) and I've never seen this announce stop, here anyway. Let me know what I can do to reproduce morpheme's UPnP issue here - I don't have dual-WAN capability tho. Respectfully Yours, William Arnold ~ Indianapolis, IN
Clients are on dynamic IP's, but not allocated by the RV082 - given out by a linux box. DHCP is disabled on the RV082 I've specifically noticed the problem with Azureus, but as I mentioned before, upnptest.exe doesn't seem to find the RV082 either
Here's a tcpdump: proxy# tcpdump | grep 239.255.255.250 tcpdump: listening on eth0 14:40:06.821707 OKI-Laser.morphemeinternal.1900 > 239.255.255.250.1900: udp 285 [ttl 1] 14:40:06.861538 OKI-Laser.morphemeinternal.1900 > 239.255.255.250.1900: udp 251 [ttl 1] 14:40:06.901618 OKI-Laser.morphemeinternal.1900 > 239.255.255.250.1900: udp 287 [ttl 1] 14:40:57.849403 Matt-Spall.morphemeinternal.8008 > 239.255.255.250.1900: udp 101 14:41:57.854322 Matt-Spall.morphemeinternal.8008 > 239.255.255.250.1900: udp 101 14:42:57.859240 Matt-Spall.morphemeinternal.8008 > 239.255.255.250.1900: udp 101 14:43:07.444837 OKI-Laser.morphemeinternal.1900 > 239.255.255.250.1900: udp 260 [ttl 1] 14:43:07.484811 OKI-Laser.morphemeinternal.1900 > 239.255.255.250.1900: udp 285 [ttl 1] 14:43:07.524786 OKI-Laser.morphemeinternal.1900 > 239.255.255.250.1900: udp 251 [ttl 1] 14:43:07.544900 OKI-Laser.morphemeinternal.1900 > 239.255.255.250.1900: udp 287 [ttl 1] ----- RV082 Rebooted here ------------------------------ 14:44:55.962125 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 269 (DF) 14:44:55.962999 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 341 (DF) 14:44:55.963998 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 263 (DF) 14:44:55.964998 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 333 (DF) 14:44:55.965872 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 317 (DF) 14:44:55.966872 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 263 (DF) 14:44:55.967871 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 349 (DF) 14:44:55.968871 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 337 (DF) 14:44:55.969746 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 263 (DF) 14:44:56.000101 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 331 (DF) 14:44:56.000102 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 317 (DF) 14:44:56.000103 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 263 (DF) 14:44:56.000103 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 349 (DF) 14:44:56.000226 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 337 (DF) 14:44:56.000227 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 263 (DF) 14:44:56.000228 gateway-net.morphemeinternal.1900 > 239.255.255.250.1900: udp 331 (DF) Between 14:40 and 14:44 there was no uPnP from the RV082, just from OKI-Laser and Matt-Spall. Just did a soft reset and the RV082 suddenly sprang back into life at 14:44:55. At some stage inthe future uPnP will again stop, and only a soft reset appears to restore it again.
Dear Morpheme; I respectfully suggest that you capture all the UPnP notifications over a period of time and see what is going on just before your RV082 goes awol. For Ethereal; you can use a capture filter to limit the file I/O to just UPnP notifications. Good Luck, Sincerely, William Arnold ~ Indianapolis
what i need to know right now is is this a problem new to the 1.3.3.4 beta or did v1.3.2 also have this issue. morpheme. I dont have a rv082, however my rv042 handles a number of pcs without problem using Azureus, however static dhcp is issued by the rv unit. I'll pass this extra info on to my contacts.
I'm glad to reply, Simon! My only confirmed issue regards UDP & SynFlood blocking, therof - that was new in 1.3.2 and continues in 1.3.3.4 I have not been able to reproduce morpheme's UPnP issue and personally believe that the different UPnP issue I'm having faults within my bitComet P2P application and not my RV082. On-the-other-hand; morpheme seems to be loosing the UPnP feature at the RV082 - I can't see that (s)he said if this happened in 1.3.2 or not - morpheme? Simon; does your network have any UPnP hosts other than your RV042? - IMHO, this might be a nasty interaction between morpheme's RV and the other hosts there. Thanks in advance for shepherding this, William ~ Indianapolis, IN
I finally had the chance to try the beta. I held my breath and did the upgrade from 1.1.6.11. My main concern with 1.3.2 was an MTU problem on VPNs over DSL that worked better with the 1.1x firmware. This version seems to be much better. My VPNs are up and so far are stable. Much better. I can't say much about better speed since I was already getting full speed and that hasn't changed. The additional IPSEC options are a welcome addition. Not much else appears to be new for my needs. But the VPN/DSL issue was the biggie and that is now better. So far so good!
Beware - Armchair expert's thoughts re: UPnP at morpheme follow.. Background: UPnP notifications are sent via UDP packets to IP 239.255.255.250:1900 ~ while, UPnP Hosts & Clients listen "promisciously" for these packets to come and, somehow, connections are negotiated. The RV082 and RV042 are switches - that is; they attempt to send only traffic destined for the machine on a particular loop - specifically; the machine IP plus all multicast broadcasts.. Multicast Broadcasts are commonly inferred as IP 255.255.255.255, but, the RFC's clearly state that *any* address from 224.0.0.0 thru 255.255.255.255 can be used for multicast - So, UPnP is just using 239.255.255.250 for it's multicast.. Anyway; I'm just wondering if version 1.3.2 and/or 1.3.3.4-beta are getting confused about switching 239.255.255.250 because the RV is not the only UPnP device on the lan - And, I'll bet it typically is. Switching may not be the problem; but my huge gut feeling is that it has *something* to do with having several UPnP devices talking together on morpheme's LAN. Morpheme; you might also verify that there's no ARP traffic re: 239.255.255.250 too - but, if there was; that would be really a bad thing to find because it would be like ARP spoofing. Again; this is just a armchair expert rant - Your Mileage May Varry ;-) I hope this gives someone a clue regarding morpheme's UPnP issue. Sincerely, William ~ Indianapolis P.S. Don't forget *my* issue: excessive blocking of UDP as SynFlood attack - ;-)
^ I don't pretend to understand most of the UPnP and it is turned off on my router. On another note which may not be part of the beta but is on my wish list. Customized dynamic DNS. The ability to configure a service that isn't in the drop down list. The one I'd like to use is part of my registrar (EasyDNS) which has dynamic DNS but so far no router has support for it. I can use it from a stand alone machine by only changing the settings of a typical DynDNS config. So instead of trying to support all the obscure systems out there it would be nice to be able to change the URL for the service since some (mine) are apparently using the same protocols as some that are on the list.
I understand where yoru comming from but, sorry to say this but the thread is for reporting bugs, and we all wish for more features. However, wish lists will be on a low priority (if any) for beta firmware to become an official firmware. if you add more features now to a beta, you end up with more problems.
I know. i know. However, it is more of a slight config change than a feature request. The Custom DNS added for DynDNS in this beta was more of a feature change than what I'm hoping for. The URL field is already in the config file so adding it as an editable field isn't a long stretch. But this thread isn't about that, I know. I'm just happy to see the bugs I was concerned with being addressed. That was definitely a bug and I'm relieved to see it much better. My critical feature is a stable IPSEC VPN over a variety of common ISPs. I'm still testing but so far it is far better than before. Tonight I'm looking at the bandwidth management. That will be potentially useful. Sorry to mention "features" like dynamic DNS, and I won't mention src/des features on port forwarding and bandwidth management...
Firmware 1.3.3.4 allows remote management of the router through a VPN even when the WAN remote management control is disabled. I don't know if this is a feature or a bug or if it was allowed in prior firmwares. The SX41 couldn't do this. Frankly I think it is a nice feature, but I see how some sites might want to be able to disable this control from their VPN users.
^It might be useful to selectively prevent remote VPN access to the interface. I'm the one that *needs* access to the remote RVs but that also means the remote end can see mine. However I'm pretty sure the previous version worked the same way. I can see a remote unit that is still on 1.3.2 and I can see mine on the beta even though I have remote access disabled. As long as WAN side access is NOT open I'm not too worried. But a good point. An update. I tested VPN and priority Bandwidth Management. I have a VPN to one location (linux IPSEC router) and a point-point OpenVPN connection via port forwarding to another location. (OpenVPN is also firewalled at the RV to a single destination IP; not sure if that rule comes before the port forwarding rule...) I then enabled OpenVPN to have high priority upstream over WAN1. That would be most useful to this connection (email server on the RV side). While sending a large compressible file upstream (SFTP) over each connection it seemed that the bandwidth management kept the OpenVPN from slowing down much. However the SFTP over OpenVPN channel would randomly stall (the OpenVPN was still alive). After deactivating the bandwidth management config the stalls were less frequent. It isn't a definitive test and I might have OpenVPN issues. No complaints from the users so it might only be related to trying to manage a saturated channel. The stalls were absent if I didn't saturate the DSL to other locations at the same time. Normal web/email was still active so it is already good enough to put live. Overall it is working well enough to actually use the RV on the DSL line that v1.3.2 wouldn't.
I have been able to aceess remote management over VPN to the VPN-RV082-server on all firmware I have used (1.1.6.11, 1.1.6.14, 1.3.2 and 1.3.3.4-beta). Not to client even if there also have been a RV082 and I do not understand why. WAN remote access has always been disabled. I have previously made some complaints about the VPN stability in this thread, this problem might have been a 3Com switch which now is put aside.
From my point of view I would like to keep this feature. Isn't it safer to access the management pages through a VPN connection compared to open up for remote access directly from the WAN port? I never have the remote access enabled and it have saved me a lot of traveling to be able to access the router over VPN.
I have not asked for its removal, but an addition of the feature to have an Enable/Disable button on the firewall page. That would then be adventageous to all.
since your having the problem with linux and the RV082 i will start a new thread ith your postings. this is due to no one else experiencing this problem and it maybe fedora as well conflicting.
413 Request Entity Too Large When I try to install the beta I get the error. 413 Request Entity Too Large The length is too large. Any ideas? I have 1.3.2 on my RV082 now. TIA. O
I don't understand the advantage of this change. I would think that the setting on the DHCP tab should take precidence. As a network admin, we run our own internal DNS and need to have the DHCP server allocate what I want. I found that if I set the ISP DNS values to 0.0.0.0, then it will honor the DHCP values to the client. But then the RV082 cannot do any fallback DNS or resolve addresses itself. Perhaps Linksys should allocate the DHCP Server values to the client unless they do not exist...then hand out the ISP DNS values. Just a thought.
the bandwith management is the same as SMC's SMCBR24Q dual wan router. i think there are same manifacuture, check accton or http://www.smc-asia.com/ , same processor and same RAM.
yup although it doesn't have IPS vpn tunneling but i believe they are using same chipset or come from same manifacuturer, so if we load in the same function will be possible?
Solution found for linux kernel 2.6.17 since this kernel all "windows size" are increased and window scaling negotiation activated i'ts usefull for large bindwith and big latency it's seem that in FW 1.3.3.4 windows scaling negociation is activated but don't understand value so connection can very very slow ( like web site not responding) in 1.1.6.xx all work fine certainly because windows scaling negociation was disable ... Quick ( but not so good) solution for linux kernel 2.6.17-xx is to disable windows scaling add this "net.ipv4.tcp_window_scaling = 0" in /etc/sysctl.conf
Bandwith management doesn't apply into VPN Hello we have a visio-conf system that work through a VPN between France and Danemark I was happy to see bandwith Maganement in 1.3.3.4 but after tests ... Bandwith Management doesn't work through VPN :frown:
I just spent the whole morning troubleshooting a issue where a RDP session could not stay connected over a QuickVPN connection with version 1.3.2 I even tried working with TechSupport with no luck. I then found and installed this beta and it fixed my issues.
looks like I spoke too soon. It is still working with me but I had another person connect using a Westell router with no luck. I had to have them use PPTP instead.
Had to dust off my RV082 and bring it out of retirement to fiddle with this firmware at home....retire my linux router for a while (Endian). Would love to see more documentation on the bandwidth management page...curious why it defaults to only 1/2 meg on the WAN.
I'm trying on just the WAN interface...running several speed tests...I'm not seeing any difference wether I leave it at 512...or bump it up to 50 megs...I still bang around 30 megs throughput. Just using the bursting ability of Comcasts PowerBoost..while not a valid test...if it throttled according to what you set it at..then I shouldn't be able to bench past that. Supposed could do a more formal test with Ixia...
ok i did some test myself chanigng the max BW seen to drop the disconect/reconect the wan connexion. If i put the max bw to 250, my max download speed drop to that. Priority seen to work too cause i can still browse normaly if i saturate the connexion with ftp. too bad my max BW is dynamic... i'll have to chose a max number pretty low to have priority work fine
Where to find the firmware Dear all, Because I have a RV082 firmware 1.3.2, I have problems with PPTP and DNS. The DNS given is the IP of the router. What I need is that the DNS given can be defined in the router. The best way for me is that I can put the DNS of my network. So the IP parameters for PPTP client should include a DNS entrie and a WINS entrie. Waiting for a reply, Laurent.
I did a upgrade from 1.3.2 to 1.3.3.4 and my server wasn't visiable anymore from the outsite. So the www and mail was also not working anymore. The forward rules where still there. And i can still internet from the server. Idea anyone?
Bug Report: - enter a user to the PPTP Server - hit 'Save Settings' everything OK now: - enter another user to the PPTP Server - hit 'Save Settings' - Router crashes and reboots now: - delete all users from PPTP Server - hit 'Save Settings' - add a user to PPTP Server - add a user to PPTP Server - hit 'Save Settings' everything ok --> conslusion: PPTP Server doesn't seem to accept adding users (not just in this firmware version, also happens in previous version)
^Interesting. Haven't used PPTP so didn't notice that one. Mine may or may not be a bug. On two machines I occasionaly get partial graphics when pulling up an image by itself (in Firefox). A normal web page seems fine, only when pulling up a single .jpg. I've seen this a number of times when browsing directly and when using a proxy server. It makes little sense but since it happens on two OS's (dual boot Linux + Windows) and never happened before I thought I'd mention it. Any word on how it is going with the devel? The beta is working better than the latest stable so I'm happy so far and look forward to the fine tuning.
I was just wondering, when useing the dual wan, when you pick say wan1 as primary it picks up an ip but wan2 does not. It waits until wan1 is disconnected before it will pick up an ip. Personally I think it would be better that it pick up an ip when wan2 is picked up so that it is ready to go and does not have to wait to get an ip... that and you have an idea of what the secondary ip is if the system does fail over. It picks up the second ip fine when it is in load balancing. I was looking at possibly that when the second wan has a connection on it to use the bandwidth management to divert traffic for one ip to that second wan, but if it does not grab an ip till the first one fails then that is kind of pointless. I was just wondering if people see this as a flaw or if this is the way things should be working, because to me it is a flaw that could be better implemented.
I don't think there is a firmware problem with that. A factory reset and config from scratch is where I'd start if the config appears correct. The beta is significant so a fresh config is wise. (and decide if you want it to be "ping visible" on the WAN side, I don't) I still think that this is the correct way for fault tolerant to work however it would be really nice if a 3rd option was available that allowed static route usage of the failover port while we wait for it to be the default route.. That is trickier to do than it seems. You can do this with two fault tolerant devices, that's fun to play with.
