mojolacerator

dlangs point is it's very difficult to tell whether you get a genuine FTDI chip or some counterfeit as there is a lot of incentive to produce low quality clones and sell them as FTDI. Those clones are very common and can very well be worse (to the extent of damaging your hardware) than the somewhat cheap, not fully featured yet still popular Prolific one. So if you go for FTDI carefully chose your source.

PS: I even managed to shorten an FTDI chip once (electric arc) and got away without any damage to the chip nor the usb port which the cable was connected to.

@sera

Point taken, but that is true with anything a person buys.

actually, I've never heard of a fake/clone/counterfit FTDI chip damaging your hardware, just being damaged by the ftdi drivers.

To be clear, I am opposed to counterfit chips (things made by someone else marked as being from the manufacturer), but work-alike or clone chips (sold as being compatible with or a plug-in substatute for a particular chip, but with a different part number) are perfectly legit (IMHO) and there is a long history of such chips, many of which ended up being improvements over the original, others were cheaper because they left out features that it turned out people didn't use in practice or implemented the logic in a different way. They don't violate the IP of the original because APIs can't be copyrighted, so someone can implement a chip that responds to the same API without violating your IP rights at all.

in terms of serial interfaces, we saw this happen on PCs where the original serial interface chip was cloned, and the clones were faster and included a buffer so they could operate identically to the original, or have the buffering turned on to go faster with less CPU overhead. Eventually the clone was both faster and cheaper than the original and pretty much replaced it (it was a drop-in replacement, pin compatible)

One can avoid buying counterfeit microchips, cables, wifi cards, etc. by simply being smart consumers...

• buy from reputable businesses (Mouser, DigiKey, etc. if buying TTL products),

• find out what the nominal price is for an item and don't buy a product simply because it's the cheapest
  

  • if it's too good to be true, it likely is

• don't buy from a seller or business in a country that has lax or non-existent anti-trust and patent enforcement (China for instance, India, etc.), etc.

Even if a person does all the above, there's still a chance one will end up with a counterfeit product, however it greatly reduces the minor chance one would end up with one.

It's highly doubtful FTDI makes their own chips, or if they do, it's likely in negligible amounts, as they likely employ the same strategy as Qualcomm, where the chip schematics are licensed to manufacturers of which pay a licensing fee on every chip produced.  If counterfeit FTDI chips are common, it's a good bet they'll have a page on their website on how to identify whether or not one has a product with a counterfeit chip, and if they don't, contacting them via phone or email should garnish how to do so. 

• For example, there was a page on Intel's site on how to identify counterfeited AC wifi cards, and Monster has a page on how to identify counterfeited Monster HDMI cables.

(Last edited by JW0914 on 7 Jun 2017, 04:27)

dlang,

as long as the clone uses a different usbid I don't count it as a counterfeit. Talk about not violating IP is hair splitting. The Linux driver is open source and if another vendor wants to use it with it's own VID that's perfectly legit. But better just comply to the CDC standard and you don't need a specific / proprietary driver in the first place.

I read up on the breaking hardware by the official driver you stated. It just changes PID and it's trivial for the tech safey to change it back or force load an official FTDI driver with the new PID. It's not much different than breaking hardware as LEDE does with not accepting OEM firmware via GUI.

swrt-2017-06-07
---------------

There is a mac address listed in the devinfo partition and a couple more in
u_env. Those in u_env might or might not be globaly unique. Eitherway, the one
in devinfo in all likelyhood is. So I use that one for the wan port and just
increment it for ports lan 1-4. That way all devices have a stable and unique
wan mac address and at least stable and likely unique mac addresses for the lan
ports. If that leads to conflicts with other devices in the lan at least the
uci entries are predefined to make changing easy. The brige br-lan inherits the
mac address of the first interface enslaved, by default lan1.

The last patch of the Rango series wrt clocks made it into next as well. So
everything will be in 4.13. So except for the musl hacks everything else will
be OpenWrt specific. As an aside mwlwifi is still lacking support for 4.12+
upstream.

Also bump mwlwifi to the latest commit which should fix sta mode.

Then bump dnsmasq and drop all patches except the one which should be trivial
to upstream.

@sera thnx, and please explon further this:
" be in 4.13. So except for the musl hacks everything else will
be OpenWrt specific. As an aside mwlwifi is still lacking support for 4.12+
upstream."

I read this forum but i think there is no anwser for the problem: wlan1 (2.4Ghz) signal drops randomly.

Model: WRT1200ac V2
Firmware: Lede Reboot SNAPSHOT r4222-7142cb4 / LuCI Master (git-17.145.19303-ee6110b)

system log

Wed Jun  7 16:28:44 2017 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 00:4f:78:01:e8:16
Wed Jun  7 16:28:44 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: disassociated
Wed Jun  7 16:28:45 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Jun  7 16:29:29 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: authenticated
Wed Jun  7 16:29:29 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: associated (aid 2)
Wed Jun  7 16:29:30 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 00:4f:78:01:e8:16
Wed Jun  7 16:29:30 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 RADIUS: starting accounting session 483F85DE27B868DD
Wed Jun  7 16:29:30 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 WPA: pairwise key handshake completed (RSN)
Wed Jun  7 16:29:52 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 WPA: group key handshake completed (RSN)
Wed Jun  7 16:29:52 2017 daemon.info hostapd: wlan1: STA 20:82:c0:3f:27:47 WPA: group key handshake completed (RSN)
Wed Jun  7 16:31:14 2017 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 00:4f:78:01:e8:16
Wed Jun  7 16:31:14 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: disassociated
Wed Jun  7 16:31:15 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Jun  7 16:32:04 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: authenticated
Wed Jun  7 16:32:04 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: associated (aid 2)
Wed Jun  7 16:32:04 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 00:4f:78:01:e8:16
Wed Jun  7 16:32:04 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 RADIUS: starting accounting session B14B7DB15180E11A
Wed Jun  7 16:32:04 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 WPA: pairwise key handshake completed (RSN)

Kernel Log

[ 5149.572385] br-lan: port 3(wlan1) entered blocking state
[ 5149.577739] br-lan: port 3(wlan1) entered disabled state
[ 5149.583228] device wlan1 entered promiscuous mode
[ 5154.588516] ieee80211 phy1: change: 0x100
[ 5154.601575] ieee80211 phy1: change: 0x40
[ 5154.775071] ieee80211 phy1: change: 0x40
[ 5154.945073] ieee80211 phy1: change: 0x40
[ 5155.115076] ieee80211 phy1: change: 0x40
[ 5155.285063] ieee80211 phy1: change: 0x40
[ 5155.455116] ieee80211 phy1: change: 0x40
[ 5155.625070] ieee80211 phy1: change: 0x40
[ 5155.795057] ieee80211 phy1: change: 0x40
[ 5155.965057] ieee80211 phy1: change: 0x40
[ 5156.135054] ieee80211 phy1: change: 0x40
[ 5156.305050] ieee80211 phy1: change: 0x40
[ 5156.475066] ieee80211 phy1: change: 0x100
[ 5156.552999] ieee80211 phy1: change: 0x100
[ 5156.565046] ieee80211 phy1: change: 0x42
[ 5156.687082] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 5156.693534] br-lan: port 3(wlan1) entered blocking state
[ 5156.698880] br-lan: port 3(wlan1) entered forwarding state
[ 5560.231540] device wlan0 left promiscuous mode
[ 5560.236068] br-lan: port 2(wlan0) entered disabled state
[ 5560.427289] ieee80211 phy0: change: 0x40
[ 5560.497253] ieee80211 phy0: change: 0x100
[ 5560.987295] ieee80211 phy0: change: 0xffffffff
[ 5561.066451] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 5561.073825] br-lan: port 2(wlan0) entered blocking state
[ 5561.079179] br-lan: port 2(wlan0) entered disabled state
[ 5561.084739] device wlan0 entered promiscuous mode
[ 5561.089527] br-lan: port 2(wlan0) entered blocking state
[ 5561.094889] br-lan: port 2(wlan0) entered forwarding state
[ 5561.520470] br-lan: port 2(wlan0) entered disabled state
[ 5566.101077] ieee80211 phy0: change: 0x100
[ 5566.114166] ieee80211 phy0: change: 0x40
[ 5566.310125] ieee80211 phy0: change: 0x40
[ 5566.490131] ieee80211 phy0: change: 0x100
[ 5566.568697] ieee80211 phy0: change: 0x100
[ 5566.580126] ieee80211 phy0: change: 0x42
[ 5566.717136] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 5566.723606] br-lan: port 2(wlan0) entered blocking state
[ 5566.728945] br-lan: port 2(wlan0) entered forwarding state
[ 5927.475841] device wlan1 left promiscuous mode
[ 5927.480357] br-lan: port 3(wlan1) entered disabled state
[ 5927.550783] ieee80211 phy1: change: 0x40
[ 5927.604784] ieee80211 phy1: change: 0x100
[ 5929.107729] ieee80211 phy1: change: 0xffffffff
[ 5929.171949] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 5929.178967] br-lan: port 3(wlan1) entered blocking state
[ 5929.184309] br-lan: port 3(wlan1) entered disabled state
[ 5929.189825] device wlan1 entered promiscuous mode
[ 5934.260786] ieee80211 phy1: change: 0x100
[ 5934.273845] ieee80211 phy1: change: 0x42
[ 5934.395650] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 5934.402112] br-lan: port 3(wlan1) entered blocking state
[ 5934.407468] br-lan: port 3(wlan1) entered forwarding state

Some info about wlan1:

config wifi-device 'radio1'
        option type 'mac80211'
        option hwmode '11g'
        option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
        option country 'CL'
        option channel '6'
        option htmode 'HT20'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option mode 'ap'
        option macaddr '62:38:e0:06:35:7c'
        option ssid 'GuaiFai'
        option encryption 'psk2+ccmp'
        option key '**************************'
        option network 'lan'
        option disassoc_low_ack '0'

gsustek,

maybe distribution specific is a better word, can't be upstreamed yet. First the patch adding the powertables for mwlwifi can't be upstreamed until the mwlwifi driver is mainlined, then the swconfig patch is inherently OpenWrt specific but there is the better option of DSA anyway so distributions have little use for that one. Most distros are also using glibc which means the musl compat patches can be ignored by them as well. So if it weren't for mwlwifi a vanilla kernel 4.13 could be used just fine. Meaning you can use pretty much any Linux distribution out of the box. For 4.11 I still carry some 30 additional patches on top.

Unpatched mwlwifi is only compatible with kernels up to 4.11, I filed bugs for that one. Once mwlwifi is mainlined Linksys' "opensource ready" becomes "opensource supported".

I was working in the console because of a bad firmware flash. At some point my computer BSOD'ed and now when I try to read off the router I get

ÂÆ9JÂ
      @ìB
         )& B×BÊBi¥
                   "w¡Â¾B®ÿNÅôHðBÅF
                                   BÿîÿÀä&ÄI
                                            ÎI1·èFÿN(C!eÄBÄƺ!ÂbÎÙBøÂÂ~lpÀ)!ʬF¨Î1
  B
    ÿ@Èr
R(d
   &Á

     ÊFîFÌ@J#  nÈóÄH;ìá´JÊÔFGnJÈJþºFÜú§áoã@ÈåçAøÎÿ
                                                  ¿FæüD

I am using the cable correctly, everything was working before the computer BSOD'ed. Also when I type things I also get scrambled letters

Did I totally brick the router? If not how can I resolve this issue?

(Last edited by Red_Baran on 8 Jun 2017, 17:02)

@Red_Baran Unless you issued more than the normal ipaddr, netmask, run and reset commands, it's not likely you corrupted the bootloader.  I would verify the connection at the serial header, and if it's okay, reinstall the drivers for the cable, then reboot the PC

(Last edited by JW0914 on 8 Jun 2017, 17:06)

I appreciate your reply. I totally remove the drivers, reboot, reinstalled the drivers, rebooted, hooked it back up and got the same strange letters.

Any additional ideas?

Update
Just tried another computer, I get the same results.
Maybe the cable is shot?

(Last edited by Red_Baran on 8 Jun 2017, 18:25)

@Red_Baran
What does the power indicator (LED) show after the router is turned on?

Its flashing and port 1 is also flashing (connected to my pc)

Are you using a USB-sercom (TTL) cable?

As not to have to play ping pong

What OS you are using? Guess Windows (due to BSOD). Already tried from a Linux host?
What brand of usb2tll cable? Can you easily try a different one?
Did you verify the  settings still are correct? (baud, parity, etc.)
Which exact router model shows the issue?
What did you do in the console when the BSOD occurred? Was the system booted? Did you write to flash via uboot prompt?
Do you have a backup of your bootloader which you could boot via kwboot?

Garbled output usually means bad contact or wrong baud. Chances for recovery are good. You really need to damage the hardware which you pretty much can only do with over-current via uart.

8.1 I have not. I will give that a shot, it was working on windows though.
Armorview PL2303HX (according to reviews it might be a clone). No but I just placed an order for a different model
Its a WRT1900AC V1
I was in the process of rebooting the router via a reset command, before I sent the reset command I sent a flash_pri_image command while trying to load a factory image.
Unfortunately no

I am pretty new to this, I have many many years flashing phones but routers are pretty new for me.

Are there anything in those cables that can become corrupted?

Hello everyone , FNG on here and just picked up an WRT1900AC V1. It was on clearance at Walmart for $60 so I couldn't just pass on the deal. So a friend recommended I install OpenWRT on this router so I did some looking around the interweb. Came across this forum and thread. Unfortunately it's almost 600 pages deep and I just can't find myself reading through all 600. Lazy? Maybe but some of the posts were just not significant to what I'm researching into. So that leads me to ask. Are there any known issues to the firmware should I decide to flash OpenWRT on this said model? Another person I know who has the ACS version said that my model has been know to have issues and I wanted to come in here to maybe get confirmation. I'm mostly intending to use this just exclusively for wifi devices and streaming Netflix and such. No gaming as I have another router for that in my home network. Who knows if I find it to be stable I may end up using it for gaming as well since I've heard some high praise for SQM. So that's my story pretty much. In conclusion I want to find out really the stability of the firmware ( latest or old ). Looking forward to y'all replies and I'm happy to be apart of this community. Thank you for your time.

@R3MIX Have you had a chance to read the WRT AC Series Wiki (see signature)?  If not, I'd recommend to start there. 

• There's no major bugs with the 1900v1 I've experienced, so if you're asking whether or not OpenWrt is stable or not on any of the WRT series (except the 3200ACM - WiFi driver issues), the answer is yes, it's stable.
  

  • You'll see this in bold red in the heading of the wiki, but prior to flashing any 3rd party firmware, please buy a USB-TTL cable. 
    

    • Without a way to access the serial header, should one make a mistake and accidentally brick one's router [both primary and alternate partitions], it's impossible to un-brick it without a USB-TTL cable, break out board, etc., of which is also covered in the wiki.

• I personally recommend building your own firmware images, however there are multiple flavors of prebuilt images in the Wiki.  If you choose to build your own firmware, I created a script a while back which automates the buildroot setup (a few of the variables will need to be customized to your environment: Lines 11, 33-39)

Since this forum does not support thread search, it's recommended to skim the last page or two, and if you can't find anything relevant to what you need, simply post a message.

(Last edited by JW0914 on 9 Jun 2017, 16:53)

Red_Baran,

A quick search says not supported under Windows 8, see http://www.prolific.com.tw/US/ShowProdu … mp;pcid=41 So a Linux only cable by now. Why it worked before don't ask me . Causing a BSOD is particularly nasty thou.

If you need a new bootloader you are in luck, you can get one for Mamba from nitroshift's github account.

Wiki Question.  I've been on here for a while, but still running 15.01.5 because I wanted something really stable, (and normally I usually get 20 days or so before a lock up/reboot) ... but lately its almost everyday (not sure what has changed) but decided to look at what the new "stable" release was, and according to the wiki its still 15.01.5 ... is that right?  There has been so many builds lately that I thought there was definitely something newer/stablier?  With the talk of LEDE and OpenWRT merging .... is a new "stable" on the horizon?   

BTW: running WRT1900AC (mamba)

(Last edited by IvanRaide on 9 Jun 2017, 19:47)

Thnx, sera....  so when mwlwifi becomes opensource supported, eg. upstreamed, and that kernel version(without patches) will be open highway for all distros that we like:-)

(Last edited by gsustek on 9 Jun 2017, 22:53)

@IvanRaide A build is only officially considered "Stable" when OpenWrt formally offers that version as the main firmware version [CC]... something that requires whatever version is the "Stable" version to be production ready (i.e. it can be ran in a production environment w/o fear of instability).

• This doesn't mean the development branch [DD] isn't a stable firmware version to run, but that it isn't the official stable branch of OpenWrt.  DD is also built nightly by buildbot, something CC only does when packages must be updated to comply with a specific kernel version update or a critical patch must be applied.

Hi, I'm sure this question was discussed before but I can't find it, can you please explain it?

I use OpenWrt Chaos Calmer 15.05.1 on WRT1900AC but ping over wireless connection is too big.

If I ping directly from the router host it is 8 ms, if I ping over wireless it is 32ms.
Previously I used Gargoyle firmware and its wireless ping was also 8ms

How can I get maximum performance in Chaos Calmer firmware? Or what other Openwrt branches may you recommend? I need IP6 so Gargoyle doesn't suite me.

Thanks

(Last edited by hyppo on 10 Jun 2017, 15:21)

Hi mate try LEDE the 17.1.2 build is being put out today. It has the new wifi driver.