I've made a serial cable and having a problem with the text showing up in the terminal scrabbled.

Serial Port settings: 115200,8,n,1,n

Is there an encoding I need to use or is an adapter required?

(Last edited by Chadster766 on 18 May 2014, 01:33)

You need to make sure to use a 3.3v adapter (I used my RasPi's GPIO serial connection. But I recently bought a USB -> TTY Serial adapter which does the same). What are you using to hook it up to?

I did end up with garbled text until I hooked up ground as well, so make sure to hook up the ground connection.

The grounds are hooked up between the WRT1900 header pin 5 to the PC com port pin 5.

The WRT1900AC is directly wired to my desktops com1 port pins 5, 3 and 2. I don't know if its 3.3v. I think standard coms is 5v.

I'm going to test with another computer to be sure the cable is transmitting and receiving serial communications RS232

You are probably not going to want to try to use your PCs serial port. Most PC serial ports work on a -12v to 12v scale, while the WRT1900AC expects a 0v - 3.3v scale for serial communication.

What you want is a TTL Serial connection, which will be either 3.3v or 5v. You can buy a USB -> TTL adapter pretty cheap online (I paid $5, though it took 2 weeks to get here).

Thanks I'll look into getting one of those converters

(Last edited by Chadster766 on 18 May 2014, 06:23)

All;....
I've found a way to manually switch the wrt1900ac from a trashed flash, to the secondary flash... It's done as follows:

1. Reset the router by holding the reset button in until the PWR light starts to flash {mine takes about 15 sec's}
2. Once the power light stops flashing, you can power off the router with the power switch.

3. Turn the power back on and the PWR light will light. As soon as any other light turns on, power off the router with the power switch.
4. Turn the power back on and the PWR light will light. As soon as any other light turns on, power off the router with the power switch.
5. Turn the power back on and the PWR light will light. As soon as any other light turns on, power off the router with the power switch.

6. Turn the power back on and the PWR light will light. This time just let the router power all the way up. It should now be on the alternate firmware.

Yes, you will power off three times.
Hope this works for you-all...

~Tim~

(Last edited by edgeman on 18 May 2014, 07:06)

I researched this more and hope I didn't harm my WRT1900AC serial port using RS232, 3 wire communication

Since I'm old school and have done a lot of work over the years with RS232 serial communications I assumed that was also the case with the WRT1900AC serial port. As you informed me this is not the case. The WRT1900 runs a new standard I had not heard of before TLL.

Differences between RS232 and TTL is:

1. Lower voltage 3.3 to 5 volts
2. The signal for a high bit is positive voltage (opposite RS232)

As it was pointed out to me a TTL device is needed to connect to the WRT1900AC

(Last edited by Chadster766 on 18 May 2014, 13:45)

Hey jklap, I see you resolved the issue with the jffs2 throwing errors a lot after the first boot. Could you provide a patch for the changes you've made?

You just need to boot it and use the ubi tools to fix it.

root@ZOMGWTFBBQWIFI:/usr/sbin# ls ub*
ubiattach     ubidetach     ubimkvol      ubinize       ubirmvol      ubiupdatevol
ubicrc32      ubiformat     ubinfo        ubirename     ubirsvol

nyt posted this on the first page

Note too, I would not depend on this-- I've had it fail to work twice. Don't even bother anymore-- a serial call with 'run nandboot' or 'run altnandboot' is quicker and sure-fire!

http://pastebin.com/6G5Q8KNZ

A couple of observations...
* The script nukes the overlay (obviously)... the overlay is where all of your changes to the file system reside... /etc/ changes, packages installed, etc.
* Since I've started watching, the ubifs partition has only ever "corrupted" when switching firmware.

Because of the former, whenever I'm about to flash a new firmware, I always backup /overlay (cd / && tar cf /data/overlay.tar /overlay) -- note I have a USB drive mounted to /data... obviously you'll need to store that tar somewhere. If the ubifs partition is reformatted when switching to the new firmware (seems about 1 out of 4 times I switch) I simply mount the USB drive manually and extract the tar and reboot. Manual, but it works.

Not sure if the use of sysupgrade deals with this but I never use it so not sure

I was wondering why the official firmware never seems to run into this problem-- it looks like they use mtdblock9 (I think-- it's from memory) to store configuration, they don't use an overlay. Would be interesting to see if that could be used for recovery...

Trouble is; nyt's post states to wait at least 15 seconds before turning off. That, does not work.
Doing the exchange as I've stated above, DOES work. The trick is when to turn off those three times, and it's as soon as any other  light lights after the PWR light first turns on.

Thanks for the reply!

~Tim~

(Last edited by edgeman on 19 May 2014, 20:31)

Hey jklap....

A little explanation here...

I hosed my primary and don't have a suitable RS232 unit yet. {ordered one from Dealextreme http://www.dx.com/p/usb-to-uart-5-pin-c … rter-81872 }

So... I HAD to make this work!!

Thanks!

~Tim~

I ordered the same one. Works great under Linux, but not windows 8. I run a VM in virtualbox with USB pass through to use it on my windows box.

I have a MacPro OSX v10.9.3 and a Windows 7 Box. (Also have Vbox and Parallels for OSX) I found what I think are the Updated/correct drivers for this device here: http://www.silabs.com/products/mcu/Page … ivers.aspx
Perhaps you don't have the correct drivers for your Windows box?...

Hope this helps...

~Tim~

I'm not sure which ones I tried, but they were marked as Win 8 compatible, however the manufacturer of the chip used on the adapter states that there are two models that aren't compatible with Windows 8, and the chip I got was one of them.

It works fairly good via VirtualBox running Linux though, just have it setup to always pass through when I boot up the VM.

So, finally had a chance to do some testing with the wireless.

Testing copying a single 1.2GB file, and a combined 5.5GB of files (4 files, 4.3GB, 500MB, 500MB, 173MB) over wifi to a samba share on an external hard drive connected to the router.

Running a custom OpenWRT build (Trunk, r40783) with stock settings, I was getting a drop after ~200 - 500MB no matter which file I was copying (As long as it was larger than a few hundred MB).

Disabled WPA2 (went with no security), tried again, and absolutely no issues, no disconnect. Transferred the 1.2GB file directly followed by the 4 that combine to 5.5GB, transfer speeds of ~23MB/s on the 5GHz.

Tried turning on WEP to see how it faired, and transfer speeds were about 1/10th the speed as they were with no encryption. Odd thing is the CPU idle doesn't really go below 80% during the entire transfer. Didn't get any disconnects with WEP enabled though.

So looks like there might be an issue with the Belkin driver in regards to wireless security.

(Last edited by Drakia on 21 May 2014, 04:51)

All the more reason for them to hurry-up & "pull their finger out" when it comes to opening up the driver (properly).

I had tried the same a while back-- disabling security but still ran into issues. But I had added a MAC filter which it sounds like you had not? So maybe it is anything related to security?

I've also noticed using the git head that I've been running out of memory-- not sure if it was happening with their commit hash and if it was, it wasn't being reported in an obvious way.

And given your consistent drop after some volume of data I wonder if it's related... memory filling up due to something security related, driver runs out of memory and looses it's association-- which from the end point everything seems to be cool-- but any packets coming in are just ignored as the driver doesn't have the association anymore.

I'll give it another test this morning.

I hadn't thought to check RAM usage while testing. I'll look into that tonight.

Seems fine. But I've only been able to trigger one disconnect so far... I've transferred 16GB from client to WRT1900AC (attached USB drive) and tested client to client... from 5GHz to ether, from 2.4GHz to ether, from 5 to 2.4, from 2.4 to 5-- only failure thus far is 2.4GHz on client... which matches my testing a week ago.. I could not get 5Ghz to fail under volume, only 2.4. BUT 5Ghz would fail randomly later-- with little or no volume. And in those cases it seemed to be memory related-- a couple of memory errors on the WRT1900AC. But I wasn't watching memory during the time, just noticed in dmesg.

Looks like I'll be using this as my default router today and see what happens.

Edit: Just got 5Ghz to fail-- 5GB to USB drive on WRT1900AC... 4.49 of 4.59 transferred No memory issue I can see.

(Last edited by jklap on 21 May 2014, 17:00)

Their driver has not changed

'k

Thx!

I purchase an (Add a Fruit) AF-954 USB to TTL cable and I'm in!

(Last edited by Chadster766 on 22 May 2014, 06:54)

How do I change the U-Boot bootargs to get into single user mode on the console?

(Last edited by Chadster766 on 22 May 2014, 14:10)