Anyone Using an Asus DSL-AC68U

[bitsNbobs]

The problem is, that it's not actually possible to test the hardware without the software...and while I agree that the standard safety testing stuff, EM/RFI compliance will have been done to death, any modem testing in the UK was clearly inadequate.

I posted a link earlier that shows the modem hardware has been fully tested.
http://www.prnewswire.co.uk/news-re...trac-broadband-test-laboratory-231716931.html
THis testing is basically the same any device goes through including BTs. (which isnt even BTs but another manufacturer in a BT branded case)

If the the whole ASUS modem router platform was compliance tested in the UK, there is clearly a problem with the compliance test.

No it would have met ITU requirements, whether it was tested here or elsewhere. http://www.itu.int/en/about/Pages/overview.aspx makes no difference. You can not find a problem in hardware testing if there is no problem.

The stability of the modem on release was diabolical and although it has got better, the connection speed issues are still a problem.

Its got better because it is SOFWARE RELATED not hardware. If it were hardware which was the issue it would had not improved.

I would hope that if BT did the testing

BT do not do testing they have a SIN sheet for recommendations to other providers (ISPs) and what their gear should support for the wholesale network. Nothing more.

then it would reflect the real world conditions or the worst case conditions for a UK phone line....but this doesn't seem to be the case

Again BT dont test they just have a SIN sheet, no routers are tested by BT, the openreach modems just went through the same tests as ASUS gear nothing more. The Huawei vesion of the Openreach modem you can buy worldwide, you dont think BT tested a Huawei device for the worldwide market do you? The only different with the full on Huawei branded version is the case, the circuit board and the firmware it can take is EXACTLY the same. AND I MEAN EXACTLY NO IFS OR BUTS.

Still, nobody except ASUS and Mediatek actually know if the problem is software or hardware.

If its hardware what do you actually think the issue is? Its software its obvious its software related the reliability alters depending on software version the hardware dont change.

You may make an educated guess that it is software,

There is nothing to guess.

but you cannot know. The reason I've taken issue with you stating that it is definitely software is simply that if it is the case, then it can be fixed. While we equally cannot know if this is a hardware issue, we have to entertain the notion that ASUS may not ever be able to provide a fix.

Its software and until they find the issues in the software then no it wont work to its full potential its that simple, i have no idea why you keep thinking its hardware when this device along with every other EU device meets the same ITU specs. Has undergone the same testing and so much more. Its Asus at fault with the software, its nothing to do with the hardware inside.

What they should have done is issue a UK only firmware version and work from that point forward with settings applicable to the UK only. Things like USPBO, Bitswap etc should not be configurable when they are a requirement.

Then they can start adding the extras as and when the UK VDSL spec changes such as G.INP and Vectoring with a good base firmware to work from.

Whilst mine is now stable, having to kill processes to maintain a steady connection makes Asus look unprofessional, lethargic at responding and somewhat carefree.

Exactly this would be the ideal solution, however for whatever reason they have not taken it. Personally i think a lot of the software needs a full rewrite or extrenulous bits of it (like the spectrum page) just removed entirely. Its certainly not hardware, even more so when the bulk of the complaints are from UK VDSL users. The fact yours also suddenly becomes stable just by stopping a bit of the software running also shows its software issues, i have no idea why he thinks its hardware or where or why he thinks BT should be testing it. Its patently obvious the software is at fault especially when ASUS have had issues with ADSL and VDSL side of things in prior devices, so unless all those were dodgy hardware, its again obviously its Asus and their software.

 

[simoncraddock]

Again BT dont test they just have a SIN sheet, no routers are tested by BT, the openreach modems just went through the same tests as ASUS gear nothing more. The Huawei vesion of the Openreach modem you can buy worldwide, you dont think BT tested a Huawei device for the worldwide market do you? The only different with the full on Huawei branded version is the case, the circuit board and the firmware it can take is EXACTLY the same.

Thats not true, BT do test equipment but they don't release the findings to the public. I was given this reply by Billion.

http://www.billion.uk.com/forum/viewtopic.php?f=19&t=3424#p10400

 

[Ixel]

Regarding my Fritz!Box 7490 progress, I've discovered that there's no option to disable NAT - making my multiple public static IP setup useless. As a result I may unfortunately have a router that's of no use to me .

 

[simoncraddock]

Regarding my Fritz!Box 7490 progress, I've discovered that there's no option to disable NAT - making my multiple public static IP setup useless. As a result I may unfortunately have a router that's of no use to me .

On earlier versions like the 7390 there's an option to disable NAT located under IP settings IN EXPERT MODE, but you would need an external firewall which you should be able to pick up cheap enough. Have you asked AVM?

 

[Ixel]

On earlier versions like the 7270 there's an option to disable NAT located under IP settings, but you would need an external firewall which you should be able to pick up cheap enough. Have you asked AVM?

I see, not yet. I did do some Googling to find that such an option for disabling NAT did exist a while back but AVM removed it over security concerns apparently (to the consumer who didn't quite understand the result of disabling NAT - which would also disable the firewall).

If I can't find a way to manually disable NAT and it does indeed interfere with incoming connections to the public static IP's on the network then I'll try emailing AVM in hope they can provide a solution, otherwise it might unfortunately be wasted money despite the bargain I got. I've noticed some settings in the ar7 cfg which may turn NAT off but for some reason I'm not able to import the changes afterwards.

EDIT: Worked it out. Needed to modify a few things in /var/flash/ar7.cfg to make it work, specifically:

no_firewall = yes;
no_masquerading = yes;
internet_in_nat_rules_enabled = no;
internet_out_nat_rules_enabled = no;

All working fine at the moment, just need to wait until DLM relieves my banding and high INP back from the days of playing around with the ASUS. One last problem is to figure out how to prevent the above settings being changed back anytime I change a setting on the web interface (or possibly even reboot).

Comparing the ECI /r SNRM, this seems to be achieving around 2-3dB higher. Line attenuation is roughly the same on both devices. Can't unfortunately compare power output although interestingly in the ar7.cfg you can modify the 'power cut back' (pcb) offset on both downstream and upstream.

 

[bitsNbobs]

Thats not true, BT do test equipment but they don't release the findings to the public. I was given this reply by Billion.

http://www.billion.uk.com/forum/viewtopic.php?f=19&t=3424#p10400

LOL go back and ask what "BTs" findings were. Ask him why it was not submitted for this (*cough*) imaginary testing before they released it, also ask what exact testing is being done.

That thread is also another example of SOFTWARE making a difference considering both the Billion and the Zyxel mentioned are broadcom chipsets.

There is no "BT tested and approved" third party devices on the market not a single one. If there were manufacturers would plaster their device had passed BT tests all over the box.

Im actually shocked at that from Billion.

BT have a SIN sheet for devices and what they should be capable of.....
www.sinet.bt.com/sinet/SINs/pdf/498v6p0.pdf

Which unless im mistaken the Billion 8800NL already fails at because (I think im right in this) it does not support G.998.4 (AKA G.INP) as per page 37 of that BT SIN sheet. Also unless im wrong it does not support Vectoring either does it?

So dunno what "tests" BT are doing the device already does not meet laid down BT spec.


@Ixel Nice new toy you got there, did you manage to get a bargain or was it the near £200 they normally go for? What type of speed and error rates you getting thus far?

 

[Ixel]

@Ixel Nice new toy you got there, did you manage to get a bargain or was it the near £200 they normally go for? What type of speed and error rates you getting thus far?

For some reason stats on the GUI are frozen this morning (might've been my fault as I was trying a number of things last night - especially to disable NAT), but I'm stuck with a high INP and low banding due to playing with the ASUS in the past so got to wait for the caution counter to drop before I can make a good comparison. Last night I had no errors but with an INP of 8 I wouldn't expect any. Upstream is fastpath thankfully. SNRM is also higher than the ASUS by an equivalent of 2-3 dB when comparing the same sync rate. Might just be a higher downstream and upstream power though.

I got it for around £160 including postage as a bid on the famous auction website a few days ago.

http://i.imgur.com/fhqrsRm.png
http://i.imgur.com/4WjVDF1.png

 

[simoncraddock]

EDIT: Worked it out. Needed to modify a few things in /var/flash/ar7.cfg to make it work, specifically:

no_firewall = yes;
no_masquerading = yes;
internet_in_nat_rules_enabled = no;
internet_out_nat_rules_enabled = no;

All working fine at the moment, just need to wait until DLM relieves my banding and high INP back from the days of playing around with the ASUS. One last problem is to figure out how to prevent the above settings being changed back anytime I change a setting on the web interface (or possibly even reboot).

http://freetz.org/wiki/help/howtos/security/switch_config#Anpassungeninderar7.cfg

Not sure if this is related? Google does a reasonable job of translating.

 

[Ixel]

http://freetz.org/wiki/help/howtos/security/switch_config#Anpassungeninderar7.cfg

Not sure if this is related? Google does a reasonable job of translating.

Nice find but unfortunately I did follow something identical to that for modifying the ar7.cfg and then saving it. But it seems as if certain settings might be changed by something else on the device, most likely to protect it from getting into either a potentially dangerous or bad configuration. I might email AVM but given I don't have an official warranty as I bought it used from eBay I'm not expecting I'll get much co-operation regarding permanently setting no NAT. I did try setting this up in bridge mode (modem only basically) by also modifying the ar7.cfg but while I managed to get a sync I couldn't get PPPoE on my ASUS RT-AC68U, my guess is that I wasn't setting the VLAN ID in the right place on the ar7.cfg though.

I've read that the general consensus seems to be a very stable device compared to the early days of the FB 7390 (which I owned, occasional crashes resulting in a reboot). So, if I keep this plugged into a UPS and perform updates manually instead of automatically I should be alright for now. I just need to reboot it later today and re-apply the changes for no NAT in order to get the DSL information to become unfrozen. I might try dsl_pipe to see if I can current stats from there in the meantime.

I don't plan to sell my ASUS DSL-AC68U at the moment, but might later on. It's the only device which can override DLM's sometimes harsh settings on the downstream - but at the same time it's not as stable as either the ECI /r (if stats output is right, but past indications must be that ES is very low as DLM eventually performs positive changes when I use it) or so far the Fritz!Box 7490 which uses pretty much the same chipset as the ECI /r. The only thing I can't see on the web UI is FEC, but that should be fetchable from dsl_pipe.

 

[simoncraddock]

The only thing I can't see on the web UI is FEC, but that should be fetchable from dsl_pipe.

Which lends to the theory that FEC is unimportant and generally only CRC/ES/SES are key figures.

For now decided to stick with the OpenReach ECI/r modem and my ZyXel.
I've had a bit of a clear out, gone is my Billion 8800nl, Asus AC68U and HG612 all sold in a matter of hours last night.

With the ECI/r I'm getting 62/20 and I'm perfectly happy with it.

 

[Ixel]

Yes, FEC is an important figure in my opinion. Sadly I can't run the Fritz!Box 7490 anymore today, it has crashed (rebooted) twice, by looks to possibly be caused by a high CPU usage - by what process I can't seem to tell but I'm guessing it's related to me trying to turn off NAT manually. To prevent possible intervention I've gone back to the ECI /r via ASUS RT-AC68U for the rest of today and will try again tomorrow. I might email AVM in the meantime to see if they can provide a solution.

EDIT: My solution might be to put it into 'full bridge' mode, again via the ar7.cfg. I've finally found how to set a VLAN ID on the WAN connection on the ASUS RT-AC68U, so theoretically I should be able to make the Fritz!Box run in a modem only state (like the ECI /r) and have the ASUS RT-AC68U PPPoE connect through that with VLAN ID 101. The settings don't appear to get lost (changing the mode to full bridge that is) and so hopefully that will also stop the random crash/reboot which I think disabling NAT is causing.

 

[simoncraddock]

Surely VLAN should be provided by the modem.
The ASUS when switched into Ethernet WAN only provides the login details for your Internet connection.

 

[Ixel]

Surely VLAN should be provided by the modem.
The ASUS when switched into Ethernet WAN only provides the login details for your Internet connection.

I tried setting what I thought was the VLAN ID for bridge mode manually but it didn't seem to work, just PADO packets timing out .

You can apparently set the (on the RT-AC68U anyway, not sure about DSL-AC68U) VLAN ID for the WAN to 101 by going to 'LAN > IPTV > First dropdown set to manual > Internet VID: 101, PRIO: 0'. I haven't tested this yet but this is what I read. I hope to test this after midnight tonight when DLM hopefully considers that a new day.

This obviously is only useful for modems which don't do the VLAN for you, in which case the Fritz!Box 7490 won't when I set it to dsldmode_full_bridge tonight - so the ASUS must do it.

 

[bitsNbobs]

Sounds like a nightmare to set up, i wonder why a lot of these options are not in the interface, especially NAT stuff.

With regards to the config file you are altering Ixel is there any way to set it as "read only"? That 'may' stop alterations you make being altered by the device.

Either way hopefully it performs well once you get the teething issues sorted

 

[Ixel]

Well here's the good news.

The solution to stopping the ar7.cfg changing appears to have been not to run 'ar7cfgchanged' in telnet after the changes have been saved to /var/flash/ar7.cfg, instead just do 'reboot' and the changes seem to persist between reboots or power failures on the device. I haven't tried updating any settings in the web UI to see if the changes also persist when doing that, but I imagine they might.

Also, I think the device is now stable here. The solution to running no NAT is far simpler than I first thought, I just set the following only:

no_firewall = yes;
no_masquerading = yes;

Changing the internet_nat... settings weren't necessary and may have been causing the crashes I was experiencing. It's been running for over 7 hours at the moment so hopefully it won't crash again. The web UI is responding quickly and the DSL information/statistics are still updating.

Now to wait for DLM to increase my banding and reduce my INP and delay.

 

[simoncraddock]

Don't suppose you have tried the DECT system and call handling? This was a feature that I liked the look of in the reviews.

 

[Ixel]

Don't suppose you have tried the DECT system and call handling? This was a feature that I liked the look of in the reviews.

Unfortunately I haven't. Unlike the 7390's issues (ghost calling sometimes during the early hours and potential call quality issues apparently), the 7490 I've read seems to have a good quality DECT this time (just like the modem is supposed to be much better - but I won't know that until DLM eventually returns me to fastpath).

I will most likely be trying the DECT with my Gigaset phones at some point though.

I haven't managed to get the dsl_pipe stuff to respond via telnet yet, so I must not be doing it right.

 

[simoncraddock]

Unfortunately I haven't. Unlike the 7390's issues (ghost calling sometimes during the early hours and potential call quality issues apparently), the 7490 I've read seems to have a good quality DECT this time (just like the modem is supposed to be much better - but I won't know that until DLM eventually returns me to fastpath).

I will most likely be trying the DECT with my Gigaset phones at some point though.

I haven't managed to get the dsl_pipe stuff to respond via telnet yet, so I must not be doing it right.

I like the look of the Fritz and its All-IN-ONE approach but it looks overly complicated...

I presume you've been googling and found this?

http://www.wehavemorefun.de/fritzbox/Dsl_pipe

Maybe this? dsl_pipe pmlsc15mg, dsl_pipe pmlsctg

 

[Ixel]

I like the look of the Fritz and its All-IN-ONE approach but it looks overly complicated...

I presume you've been googling and found this?

http://www.wehavemorefun.de/fritzbox/Dsl_pipe

Maybe this? dsl_pipe pmlsc15mg, dsl_pipe pmlsctg

Thanks, I didn't actually see that page - must've missed it. I see it's for the 7570 but given Lantiq is used in the 7490 it should still work. Hopefully contains virtually identical commands as there's some I see which might infact override the maximum sync rate (like on the ASUS) as well the INP and delay, possibly in both directions too.

I'll edit this post shortly with my findings.

P.S. Should I perhaps make a new thread or stick to this one?

EDIT: Blank responses when trying various things such as 'dsl_pipe fpsg 0 0 0'. Either the output is being redirected to somewhere else, or it's not right.

 

[simoncraddock]

Thanks, I didn't actually see that page - must've missed it. I see it's for the 7570 but given Lantiq is used in the 7490 it should still work. Hopefully contains virtually identical commands as there's some I see which might infact override the maximum sync rate (like on the ASUS) as well the INP and delay, possibly in both directions too.

I'll edit this post shortly with my findings.

P.S. Should I perhaps make a new thread or stick to this one?

A new thread might be better as its no longer ASUS related
If you can over ride the DSLAM I guess its bye bye DSL-AC68U lol