Anyone Using an Asus DSL-AC68U

RedBull2k said:
From my experiance with it disbaled, when resetting their tg582n to defaults, my username and password would need completing by myself in the router gui. it would not get my details.

To test to see if TR69 is available on dsl ac68u i will enable it on my plusnet account and see if my details are retrieved automatically.
Click to expand...

You do not need to do that you only have to look though your log files. If you can not see anything on the Asus plug in the TG582 and look through the logs on that. You will need to be connected at least a day to see TR069 entries. If it is fully off then perhaps you could contact plusnet and ask them how DLM interacts with you modem/router cos AFAIK there would be no other way.




@Ixel, Babis3g and other thread regulars

No idea how command line savy you are (though im guessing you have at the least a reasonable idea) or if you used a version of Ubuntu or varient of Redhat but i came across this, which i may have a play with if i can be bothered to put ubuntu on a spare machine...
https://code.google.com/p/firmware-mod-kit/
further info
https://code.google.com/p/firmware-mod-kit/wiki/Documentation?tm=6
In theory if the "tool" for Asus TRX files (mentioned near the bottom of second link) works then you could unpack the current firmwares, swap stuff and recompile.
Some examples would be DSL driver files or Bitswap routines (IE if an earlier DSL driver was better or earlier versions of bitswap were better but other bug fixes are in later firmwares you could have the best of both, take the best from both and mix :D)
Could also remove everything relating to Spectrum from it entirely and then repack, meaning no more having to telnet to kill it each time you reboot or power on :D
On from that can get more adventurous if you are coding familar and even potentially make a complete custom firmware.

If i have time i may play at the weekend, though will have to dig out an old machine from the loft to shove redhat or ubuntu on. If anyone reading has such a system already or a system set up to run Virtual machines and feels adventurous then have a go.
 
Last edited:
That would be embarrassing for Asus if a firmware that fixed the issues this modem was compiled by a OC forum member before they do...
 
Last edited:
bitsNbobs said:
Crosstalk is basically leakage of signal from other connections/wire pairs to yours. The more connections the more noise interferes with the xDSL frequencies in use. Nobody uses your copper per say. To the cabinet there is a big bundle off wires (think of it like a massive network cable) Each user has a set of those wires, the more that are in use the more crosstalk is generated. What makes the matter worse on VDSL is the high frequencies used compared to old dial up and even ADSL. Telephone wires were never designed for high frequencies. If you have ever used your mobile phone near other electronics and heard them (particularly non shielded speakers) make all types of weird clicky, tappy noises then that will give you an idea of what is happening when you shove hundreds of small telephone lines together and shove high frequencies down them.

As to copper length, crosstalk is less of an issue although it still affects long lines. Its less of a worry because the longer the copper line the resistance of the copper wire itself and other kinds of noise play a larger part in your speed being slow. For lines longer than around 1000M even vectoring wont help much if at all. The line has basically reached its limits with regards to electrical resistance and other external noise factors (electrical cables in the ground, such as street lighting, other radio signals it picks up on its way to you and more).

I tried to be accurate but keep things simple i hope that helped.
Click to expand...

Nice and simple. Makes a good read and everything understood. Thanks for taking the time to write it all out.
 
bitsNbobs said:
You do not need to do that you only have to look though your log files. If you can not see anything on the Asus plug in the TG582 and look through the logs on that. You will need to be connected at least a day to see TR069 entries. If it is fully off then perhaps you could contact plusnet and ask them how DLM interacts with you modem/router cos AFAIK there would be no other way.




@Ixel, Babis3g and other thread regulars

No idea how command line savy you are (though im guessing you have at the least a reasonable idea) or if you used a version of Ubuntu or varient of Redhat but i came across this, which i may have a play with if i can be bothered to put ubuntu on a spare machine...
https://code.google.com/p/firmware-mod-kit/
further info
https://code.google.com/p/firmware-mod-kit/wiki/Documentation?tm=6
In theory if the "tool" for Asus TRX files (mentioned near the bottom of second link) works then you could unpack the current firmwares, swap stuff and recompile.
Some examples would be DSL driver files or Bitswap routines (IE if an earlier DSL driver was better or earlier versions of bitswap were better but other bug fixes are in later firmwares you could have the best of both, take the best from both and mix :D)
Could also remove everything relating to Spectrum from it entirely and then repack, meaning no more having to telnet to kill it each time you reboot or power on :D
On from that can get more adventurous if you are coding familar and even potentially make a complete custom firmware.

If i have time i may play at the weekend, though will have to dig out an old machine from the loft to shove redhat or ubuntu on. If anyone reading has such a system already or a system set up to run Virtual machines and feels adventurous then have a go.
Click to expand...
Thanks for the info but not programming skills
If there is a guide i have some free time to start the basics ;)
chriscatt said:
That would be embarrassing for Asus if a firmware that fixed the issues this modem was compiled by a OC forum member before they do...
Click to expand...
I don't think so
With the dsl n55u was a guy which did a slightly different firmware (named bender) & at time many other users was happy about it but the project stopped so no newer updates
https://github.com/matteocrippa/dsl-n55u-bender
 
babis3g said:
Thanks for the info but not programming skills
If there is a guide i have some free time to start the basics ;)
Click to expand...

Ive obviously not looked into great detail yet but, this would appear to be a good starting point...
https://bitsum.com/firmware_mod_kit.htm

From a very quick google this afternoon (i only had 30-45 free mins today :( ) there also appears to be a tool called "binwalk" which may be of use...
http://binwalk.org/
and a couple of additional guides for Firmware mod kit and binwalk both individually and using both combined.

To be honest it does not look that difficult as long as the file extracts properly, the thing which may be the biggest issue to anyone new is the header part of the firmware. Hopefully its not encrypted and the header can be read and rebuilt easily.
 
Last edited:
Bad news so far i can not for some reason get Firmware mod kit to compile properly, i suspect its more to do with me not using Ubuntu for a while rather than an issue itself, ill have another go tomorrow.
 
Just got BT Infinity 2 today, got ASUS DSL-AC68U 2 days before in preparation, at first I had thought I had bought a lemon as on the Zen Internet ADSL it seemed very unstable compared to my Linksys X3500 had to disable far too many settings and lower the SNR by -3db making it slower than it was on the Linksys.

Anyway I saw the post about doing a factory reset once on the latest firmware etc, so I figured I would wait for the switch-over to Infinity.

So switchover happened, did factory reset and connected up, so far has been super stable and amazingly fast.

DSL Firmware Version 1.0.2.1
DSL Driver Version FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
DSL Link Status up
DSL Uptime
0 days 5 hours 46 minutes 40 seconds
DSL modulation
ITU G.993.2(VDSL2)
Annex mode
ANNEX_B
SNR Down
7.4 dB
SNR Up
23.1 dB
Line Attenuation Down
5.3 dB
Line Attenuation Up
8.2 dB
Path Mode
FastPath
Data Rate Down
79999 kbps
Data Rate Up
19999 kbps
MAX Rate Down
98028
MAX Rate Up
36591
POWER Down
12.0 dbm
POWER Up
-4.6 dbm
CRC Down
47
CRC Up
24

Will report what it is like after a week.
 
mjgr33n said:
...
Click to expand...

I see, will be interesting to hear. Don't forget to kill the 'spectrum' process via telnet or you might start suffering instability at some point in the future (at least until ASUS fix that process).

With PuTTY (or another alternative program) connect to the router via telnet and run the following command when logged in:
Code: 
killall -9 spectrum

I wish my line was as stable as yours (it's not a problem with the device here, it's just my line itself). Hoping G.INP will kick in eventually when DLM intervenes with a positive profile change eventually - that should help me avoid the insufferable traditional interleaving.
 
Ok so i think i have some problems.

I have connected my device back up with SRA disabled,Spectrum process killed and TCM turned off

In the router gui i have this
Code: 
DSL Firmware Version 	1.0.2.1
DSL Driver Version 	FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
DSL Link Status 	up
DSL Uptime 	0 days 15 hours 54 minutes 22 seconds
DSL modulation 	ITU G.993.2(VDSL2)
Annex mode 	ANNEX_B
SNR Down 	6.0 dB
SNR Up 	6.6 dB
Line Attenuation Down 	9.2 dB
Line Attenuation Up 	0.1 dB
Path Mode 	FastPath
Data Rate Down 	72421 kbps
Data Rate Up 	20000 kbps
MAX Rate Down 	86500
MAX Rate Up 	23140
POWER Down 	12.5 dbm
POWER Up 	2.1 dbm
CRC Down 	2
CRC Up 	0

and in TC i have this
Code: 
tc>tcapi get Info_Adsl lineState;wan vdsl2 show mgcnt;tcapi show Info_Adsl
up
near-end path0 fec:     20740(16216)
near-end path0 crc:     1089(733)
near-end fec sec:       703(700)
near-end err sec:       525(522)
near-end ses sec:       6(6)
near-end los sec:       0(0)
near-end ua  sec:       0(29)
far-end path0 fec:      140(58539)
far-end path0 crc:      24(326)
far-end fec sec:        44(2799)
far-end err sec:        24(107)
far-end ses sec:        0(0)
far-end los sec:        0(335)
far-end ua  sec:        0(11401)
outDiscards=2806
inDiscards=117
outBytes=2615524524
inBytes=1721996009
outPkts=2487849
inPkts=2194506
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.9 dB
AttenDown=9.2 dB
SNRMarginUp=6.6 dB
AttenUp=0.1 dB
DataRateDown=61079 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=20740
FECUp=140
CRCDown=1089
CRCUp=24
HECDown=0
HECUp=0
ADSLUpTime=15:46, 37 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.6 dbm
PowerUp=2.0 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=23239
AttainDown=70680
ShowtimeStart=19
TotalStart=39
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

Here is a result i get from BTW.
Download speedachieved during the test was - 51.88 Mbps
For your connection, the acceptable range of speedsis 49.07 Mbps-70.1 Mbps

Additional Information:
IP Profile for your line is - 70.1 Mbps

Does anyone here know why i have such a difference?
 
RedBull2k said:
...
Click to expand...

Possibly the issue where when you connect to TC it will generally stop the DSL statistics from updating on the router side (web UI), that would be my guess.

As for your connection's health, interesting. I've left TCM on here as it's made no difference in reality - only reducing the speed did, but my line produces a similar trickle of CRC errors on fastpath on the HG612 when I've used that in the past. Other than that mine is fine, so either your having something strange happening or it was a one off occurrence (or perhaps settings differ somewhat?).

Your line looks like it performs similar to mine if mine were at around 6db to 8dB on fastpath. I generally would get around 700-900 (ES+SES combined) daily, even on the HG612 under similar conditions in the past. I'd also say you've had another line connected in the cab recently, due to the downstream sync rate dropping.

EDIT:
Can you do 'wan vdsl2 show o_tps' in TC and see whether it mentions G.INP at the bottom being something other than '0'? Or paste the result here.
 
Last edited:
Code: 
tc>wan vdsl2 show o_tpss

=== O_TPS Msg ===

--- TPS-TC Capabilities ---

Mapped configurations of DS bearer channels and TPS-TC types
PTM-TC is mapped to DS bearer channel 0
DS bearer channel 1 is inactive

Mapped configurations of US bearer channels and TPS-TC types
PTM-TC is mapped to DS bearer channel 0
DS bearer channel 1 is inactive

Rate adaptation ratio of DS bearer channel 0 = 100
The whole excess capacity is allocated to bearer channel 0

DS bearer channel 0 configuration
Min_net_data_rate                       =    128 kbit/s
Max_net_data_rate                       =  74000 kbit/s
Rederved_net_data_rate                  =      0 kbit/s
Max_interleaving_delay                  =      1 ms
INP_min                                 =      0 symbols
Dynamic interleaver reconfig(amd1)      = N
INP no erasure                          = N
Pre-emption                             = N
Short packet                            = N
CIpolicy(amd1)                          = Mandatory

US bearer channel 0 configuration
Min_net_data_rate                       =    128 kbit/s
Max_net_data_rate                       =  20000 kbit/s
Rederved_net_data_rate                  =      0 kbit/s
Max_interleaving_delay                  =      1 ms
INP_min                                 =      0 symbols
Dynamic interleaver reconfig(amd1)      = N
INP no erasure                          = N
Pre-emption                             = N
Short packet                            = N
CIpolicy(amd1)                          = Mandatory

DS_MDV_BC#0(amd1) = 0.0 ms
ROC(amd3) = disable
SOS(amd3) = disable
tc>exit

In router gui i have g.inp disabled by default.
before my 15hour uptime i was connected via O/R modem tested my BTW and my range was 40 - 68.04 a throughput test was 65.
 
Well on Wednesday I have to hand back the Asus AC68U that was loaned to me. Over the past couple of weeks its been a delight to use compared to the one I had until late October which in comparison was a pig.

Wi-fi is excellent, with great coverage and the VDSL connection better than my Broadcomm and Infineon/ECI devices with a 10 day uptime minimal errors and potentially a much better actual data rate.

So I have a personal dilemma. Would you chaps recommend me buying another now whilst the availability is good or would it be wise to wait until later in the year?
 
Last edited:
simoncraddock said:
Well on Wednesday I have to hand back the Asus AC68U that was loaned to me. Over the past couple of weeks its been a delight to use compared to the one I had until late October which in comparison was a pig.

Wi-fi is excellent, with great coverage and the VDSL connection better than my Broadcomm and Infineon/ECI devices with a 10 day uptime minimal errors and potentially a much better actual data rate.

So I have a personal dilemma. Would you chaps recommend me buying another now whilst the availability is good or would it be wise to wait until later in the year?
Click to expand...

If I was in your shoes I'd buy one, but maybe someone will have a good reason why you shouldn't, who knows. I'm certain ASUS will release a patch for spectrum eventually.
 
The only way I think I would buy one of these now if it was proven to work as good as the BT modem out the box with now messing around killing stuff in the modem to make it stable.
 
If I can do it then I am sure you can, it really is simple and I would certainly recommend this modem now. When Asus get their ass's sorted and actually produce a firmware that has all the fixes that the sterling work of some excellent people have researched in this thread then it will be more or less perfect.
 
You have the option of running the DSL-AC68U as a router only, using a BT OR Modem (cheap - ebay) at the expense of 1 LAN port. If you are 50/50 on the decision then buying both would give you peace of mind that if the DSL-AC6U modem was flakey you can bypass it.

I ran my DSL-AC68U with a BT OR modem before eventually returning it and it was fine, performance was good.

It sounds like the developers are crawling to a solution, so maybe purchasing along with a BT modem wouldn't be the worst idea in the world. It might work fine without the modem who knows, but at least you'd have it there to patch in if needed.
 
FYI, if anybody has this router and got it stock and updated to 3.0.0.4.376_2160 immediately without going to one of the firmwares with the updated DSL drivers in then it might not have updated those drivers. Was quite easy to tell from the files sizes.

ASUS have now released a new version of 3.0.0.4.376_2160 with the DSL drivers in as well called DSL-AC68U_3.0.0.4_376_2160-g7518072_DSL_1.0.2.1.trx.

Can download from http://dlcdnet.asus.com/pub/ASUS/wireless/DSL-AC68U/FW_DSL_AC68U-30043762160.zip

So I suggest anybody having issues try the new file and the Factory Reset, mine still Rock Stable after doing the Factory Reset and I have not had to disable anything yet.
 
mjgr33n said:
FYI, if anybody has this router and got it stock and updated to 3.0.0.4.376_2160 immediately without going to one of the firmwares with the updated DSL drivers in then it might not have updated those drivers. Was quite easy to tell from the files sizes.

ASUS have now released a new version of 3.0.0.4.376_2160 with the DSL drivers in as well called DSL-AC68U_3.0.0.4_376_2160-g7518072_DSL_1.0.2.1.trx.

Can download from http://dlcdnet.asus.com/pub/ASUS/wireless/DSL-AC68U/FW_DSL_AC68U-30043762160.zip

So I suggest anybody having issues try the new file and the Factory Reset, mine still Rock Stable after doing the Factory Reset and I have not had to disable anything yet.
Click to expand...

I see. One question, are you sure that 2160 has a new DSL driver? Reason I ask is it's not mentioned in the changelog and 1.0.2.1 is also in 2158.

Code: 
ASUS DSL-AC68U Firmware version 3.0.0.4.376_2160 (This product supports both Annex A and Annex B)
-Fixed infosvr security issue.
-Fixed Cross-site request forgery security issue

EDIT: Oh, I think I now realise what you're saying. I believe you're saying that in a previous 2160 upload the DSL drivers weren't included in it, just the main router firmware.
 
Ixel said:
EDIT: Oh, I think I now realise what you're saying. I believe you're saying that in a previous 2160 upload the DSL drivers weren't included in it, just the main router firmware.
Click to expand...

Yes, the older file was only about 28Mb rather than the 33.5Mb of the others and did not update my DSL file originally, I had to download an older file then update to 2160, now it appears they have updated the file rather than make a new revision, if you look on there website it says 19th January, yesterday but the 2160 version has in fact been out much longer.
 
I may be being brave or foolish, I'm unsure which. After weeks of stability on the HH5 and getting my DLM profile back to normal I just installed the 2160 FW and fired up the Asus modem. After 18 minutes of uptime I already have 3300 CRC errors, but no disconnects as yet. I've just killed the spectrum process to see if that helps any, but doesnt that just kill the process thats monitoring the stats? So it will be artifically preventing CRCs by just not reporting them?
 
You must log in or register to reply here.
Back
Top Bottom