sorry ...

this is what i have:

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11a'
        option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'

how did you solve it?

Thanks

@moccolo Thanks! =]

Are you experiencing this issue?  What image are you trying to flash?

This looks like the issue that occurs on builds without the NAND patch, and if so, you're going to need to flash via TFTP [serial], ensuring you either select a build with the NAND patch incorporated if kernel version is <4.4.14 or flash a build with kernel 4.4.14.  If compiling yourself, ensure you update your build environment to the new[er] GitHub repo.

Does anyone know what's going on internally with OpenWrt not renewing their SSL cert?

(Last edited by JW0914 on 25 Jul 2016, 13:38)

Looks like it was renewed yesterday for another year.

It must have been updated in the server in the last few hours then, as it was still listing the old one this morning =]

I'm not sure this site warrants encryption?

thoughts?

It's not so much that the content needs to remain private, it's that any html can be served to you from MITM and you'll never know it didn't come from the web site.

How much of a risk this is, that's for security consultants and researchers to answer but these days it's somewhat lazy to NOT use encryption.

EDIT:  and any page that serves downloads... especially for internet-facing devices... that's a must for SSL/TLS.

(Last edited by InkblotAdmirer on 26 Jul 2016, 01:38)

Well, I suppose that's subjective.  My opinion is no but others may feel differently.

Great points!!

(Last edited by kirkgbr on 26 Jul 2016, 01:40)

Yep, encrypt 100%.

Edit: There was a way around the HSTS Chrome issue that arose with the certificate expiration issue that occurred, but I digress.

(Last edited by anomeome on 26 Jul 2016, 02:32)

Any server that requires a login must utilize SSL/TLS encryption... without it, there'd literally be no point to utilizing a password, thereby doing away with forum logins all together.  Just as with a WebGUI that isn't utilizing https, if you login via a non-encrypted connection, your password is sent in plaintext, readable by anyone else on the network, or anyone sniffing traffic. 

Additionally, certain browsers, such as Chrome, will not allow you to navigate to a webserver's pages if it's SSL cert has expired, which is probably why this thread has seen minimal activity over the past 3 days or so.  As was also mentioned above, you're begging on your hands and knees for a MITM attack if you're not utilizing SSL/TLS encryption.

On a side note, when you buy an SSL cert from a CA, you're not paying for the certificate, you're paying for the management of the CRL.  While businesses & forums must purchase their certificates for chain of trust to be maintained, if you're hosting your own content for yourself/friends/family, creating your own CA via an openssl.cnf and signing certs with it is more than enough due to the small pool of individuals accessing the content.  One simply needs to post their CA.crt.pem on their site for download and installation by those utilizing the site, along with a complex hash (at least SHA256) to verify it hasn't been tampered with

(Last edited by JW0914 on 26 Jul 2016, 02:37)

Hopefully @wigyori will put the expiration on a calendar and renew before this happens again.

LEDE user/builder: There was a patch upstreamed 5 days ago that changes the way LEDE builds the images. Now it builds all of the images even when you select a specific target (I'm going to investigate why). And this seems to have changed the name of the OG WRT1900acv1 from XP (lede-mvebu-armada-xp-linksys-mamba-squashfs-factory.img) to something more conventional lede-mvebu-linksys-wrt1900ac-squashfs-factory.img . Just a heads up!

Does that then build all images with the custom files located within <buildroot>/files?  Or do they only get included in the actual target selected, with all other images being generic?

(Last edited by JW0914 on 26 Jul 2016, 05:30)

@JW0914
I'm still unsure. Glancing over the code and looking at the result It seems to build every target under the architecture which puzzles me since it just adds time to the compiling process.
As to your question: I'm not sure what it does with those custom files since I do not have a folder <buildroot>/files. From the code it seems everything else gets built generic. (It's like they are trying to converge all the target stuff under the architecture's Makefile rather than have them be independent in the original ./profiles folder )

(Last edited by lifehacksback on 26 Jul 2016, 05:41)

Alright new patch was sent upstream and it fixes the issue! Now just the selected profile is built.

@JW0914

This change does not interfere with the <buildroot>/files since the patch has been fixed and is now doing the intended functionality.

hi @ experts :-)
2 questions:

1. all wrt1x00 have 4 antennas; which one is for what? may be 2 for transmit, 2 for receive? may be 2 for 2,4 and 2 for 5? background: i will try "range extending" with antennas, have i replace all 4 antennas or only two? ...

2. if i have connected 3 disc's a) esata, b) usb2 and c) usb3, which one is sda, which one is sdb and which one is sdc? and is this allways the same after reboot? (i have a special adapter to split combi-port usb2/esata to separate usb2 and separate esata)

thanks for your experiences :-)
cu
p.

linux-4.7 was released and pulled last minute the crypto sram and coherency fixes from next, making it a nice choice for this platform. There are relevant fixes all over the place compared to 4.4.

I also made progress on my little project and the status could be considered late beta. There is one patch left I have yet to understand. Can someone tell me why mvebu/102-revert_i2c_delay.patch was added? Neither the commit nor the patch carry any info and unlike many others it's not obvious for me from the code either. Any mamba owner willing to test?

@JW0914
Sorry for the delay in answering you wrt. wiki, the forum was inaccessible over the weekend so I only saw it today. As I can't answer that in a few minutes I further delay it until I have the time to answer properly.

Great points everyone about TLS/SSL.

It's interesting to hear how everyone thinks about web security.

@sera

Please upload your 4.7 patches and I'll fire up a build tomorrow.

nitroshift

According to WikiDevi [cached], the WRT1900AC v2 and WRT1900ACS have the exact same hardware, and while the v2 states it's CPU is clocked at 1.3gHz, in reality it runs at 1.6gHz. 

The FCC ID of the WRT1900ACS is Q87-WRT1900ACV2, of which is the exact same as the WRT1900AC v2.  This would also explain why the OEM default firmware names for each is cobra.imng.

Does anyone know why there's a distinction between the two for images?  Should the WRT1900AC v2 be listed as a separate hardware iteration on the wiki, or should it be specified as a bullet that the v2 and ACS are in fact the same router, with the ACS being a rebrand of the V2?

(Last edited by JW0914 on 26 Jul 2016, 16:20)

To my knowledge just a re-brand, and any on-line information I have read to indicate that to be the case; i.e. smallnetbuilder. Also if you do a diff of the generated images, there isn't. Not sure why owrt/lede generate distinct images though.

(Last edited by Villeneuve on 26 Jul 2016, 16:32)

all 4 antennas work both transmit and receive and both 2.4 and 5GHz, the reason for the multiple antennas is to be able to do the more advanced AC modes (3x3 vs 2x2), the details of how this works are far too messy to try to go into in a post here :-)

disks are named in the order that they are detected. On some systems they will be stable across reboots, on others they won't.

If the USB one is sda and you boot up some time and it doesn't come up, what had been named sdb will now be sda.

This is why many distros default to mounting by UUID instead of disk name.

thank you for explanation
cu
bye

The file extension on the sysupgrade files has also changed...  has always been .tar but now I find .bin

Will sysupgrade work with .bin?

Cheers

I have just flashed this build onto my new WRT1900ACS and all is working fine.

This is my first ever experience with OpenWRT, so I apologize if this is covered elsewhere, but I have an external USB 3.0 HDD which I would like to connect to the router in order to be able to use it as the default location for new software packages (as the router's internal flash memory is limited), as well as a swap file.

Is this possible with this particular build, and if so, could somebody please point me to some information, or preferably, some sort of guide to set it up? I was reading about 'extroot' on the OpenWRT wiki, but I'm not sure if would apply to this particular build?

Thanks in advance!