OpenWrt Forum Archive

Topic: davidc502 1900ac 3200acm builds

The content of this topic has been archived between 26 Feb 2018 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

feche1320 wrote:
davidc502 wrote:
feche1320 wrote:

So which chip is the correct one to use? Can I use both at the same time with the same SSID?
If the 2nd chip is disabled, wifi strenght is going to be weaker versus stock firmware?
Thanks

Disable the one that should say "Radio2" Radio2 is used for DFS purposes, and if you try to use it for regular Wifi, the router will have issues over time.

Wifi signal strength will be the same.

With issues do you mean hardware issues or just software/drivers issues?

Driver issues.

davidc502 wrote:
feche1320 wrote:
davidc502 wrote:

Disable the one that should say "Radio2" Radio2 is used for DFS purposes, and if you try to use it for regular Wifi, the router will have issues over time.

Wifi signal strength will be the same.

With issues do you mean hardware issues or just software/drivers issues?

Driver issues.

Is it going to be stable sometime?
BTW how to donate? big_smile

Hi all guys,
i would just let you know that flashing the latest release and starting from scratch solved the problem of the weird ip on the interface
The packages installation and configuration recovery was pretty easy and quickly all was up&running again
Thank you all for your suggestions and ideas. smile

Now i'm going back in the thread, looking for dnscrypt and other infos

p.s. as d4niel said, when we're behind a bridged modem, using ppoe connection, we need a dedicated interface to get there from lan

feche1320 wrote:
davidc502 wrote:
feche1320 wrote:

With issues do you mean hardware issues or just software/drivers issues?

Driver issues.

Is it going to be stable sometime?
BTW how to donate? big_smile

No, it should never be stable.

*EDIT

Donations?   https://dev.openwrt.org/wiki/SupportDonate

(Last edited by davidc502 on 20 Jun 2017, 19:06)

david were you able to start dnscrypt-resolver?
The default config file dosen't work for me, looks like syntax it's wrong
I'm trying to debug it

EDIT: Ok config debugged. i go on to test it

EDIT2: My mystake. I misunderstood a bit how did it work.
looks like i've been able to let it go

(Last edited by komodo_1 on 20 Jun 2017, 21:23)

Brewder wrote:
davidc502 wrote:
Brewder wrote:

Hello - I'm new to OpenWRT and am running Davidc502 Lede Reboot SNAPSHOT r4323-1898f73 / LuCI Master (git-17.152.82962-a9e8376) with the 4.4.70 Kernel on my WRT1900ACv1.

I'm curious why when I set my 5Ghz channel to 149 it actually runs on 153?  I can confirm by checking connected devices who also report being on channel 153...

For fun, I configured my 5GHz to use channel 161 and everything reported in LuCI and on my devices as 161....

Only seems the 149 channel is odd... am I doing something wrong?

//Brew

Most run 5Ghz in 80Mhz width, and 80Mhz covers roughly 4 channels. So, the channel the devices choose isn't necessarily the same channel chosen in LuCi. However, it will be within the width chosen.

Hi David - thanks for the response and yes I understand.  I guess I found it more interesting that my SSID is configured for the channel I want, but the interface is reporting something different on the router itself...  and my connected clients match what the interface says.  I don't know how to post pictures here, or I could more easily show you what I'm talking about.

//Brew

This happens to me occasionally also.  I keep mine set for channel 157, but sometimes on boot, it will boot on channel 161, instead.  If you check the system log, you will see it says something to the effect of "Another BSS identified on primary channel, swapping primary channel with secondary channel"

However, since we are using 80MHz, there is no primary channel and secondary channel (or upper and lower channel) as there is with 40MHz.  So the message is meaningless (probably shouldn't even be displayed), and regardless and most importantly, if your router is set to channel 149, 153, 157, or 161 (and you are using 80MHz), the router is really set/centered at channel 155.  On some newer routers (not sure if in LEDE or not, but definitely in stock firmware), if you select 80MHz, it will only allow you to choose 155.

So in reality, your router is set to channel 155 if you are at 80MHz and set to channel 149, 153, 157, or 161.  There are two SSH commands which will show you this.  I can't remember the better one at the moment (it actually says channel 155), but if you do:

iw dev wlan0 info

You'll see the center frequency is 5775MHz (which corresponds to channel 155, you can google it), and it will remain  5775MHz regardless if you select channels 149, 153, 157, and 161.  This is because at 80MHz, the router is using all of those channels.

If I can remember the other command which actually says channel 155 in it's output, I'll update my post.  Hope that helps clear things up!

Edit: I thought the second method was easier, which most likely means there is a third method also smile  But to actually show you center channel instead of the center frequency you can do:

cat /var/run/hostapd-phy0.conf

There is alot of info in there, but in the second "paragraph," you'll see an entry for vht_oper_centr_freq_seg0_idx=  That will display your center channel.

Here is a snippet of my hostapd-phy0.conf file.  You can see the channel I have set and the actual center channel because AP is set at 80MHz.


hw_mode=a
beacon_int=100
channel=157


ieee80211n=1
ht_coex=0
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40]
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=155

(Last edited by starcms on 22 Jun 2017, 08:12)

feche1320 wrote:
davidc502 wrote:
feche1320 wrote:

Hi, thanks for your reply.
I just installed the latest firmware from your page, everything seems OK but the only issue (?) is that I see three wifi radios in the wifi configuration page, I enabled the abgn radio but I cannot see the SSID, is this normal or I did something wrong?
PS: I have WRT3200ACM

The 3200acm leverages a 3rd wifi chip, and it's okay to just go ahead and disable it.  That should be your acbgn radio.

So which chip is the correct one to use? Can I use both at the same time with the same SSID?
If the 2nd chip is disabled, wifi strenght is going to be weaker versus stock firmware?
Thanks

As @david had said, on the 3200ACM, in addition to radio0 (the 4x4:3 5GHz radio) and radio1 (the 4x4:3 2.4GHz radio), there is a radio2.  Radio2 is meant only to be used for DFS (radar) detection.  It is a 1x1:1 5GHz radio.

For proper operation, radio2 should be disabled, and use radio0 as your 5GHz AP and radio1 as your 2.4GHz AP.  (This is how the stock firmware also has the radios configured; it simply hides radio2).

(Last edited by starcms on 20 Jun 2017, 20:17)

d4niel_p wrote:
starcms wrote:

Why do you do this?  My cable modem is also reachable at 192.168.100.1 and is reachable using the default settings; no additional interfaces need to be created...

As 192.168.100.1 is not in the default subnet of the default IP of the router (255.255.255.0 and 192.168.1.1), the router simply interprets 192.168.100.1 as any WAN IP address and connects perfectly fine.  No "modem" interface is required.

Afaik, this will work on DOCSIS modem, most probably will not work on fiber-optic (it doesn't on HG8247H), definitely won't work on PPPoE/A modem in bridge mode. When my modem is in bridge mode and there's no extra interface on router, modem is completely transparent from LAN, I cannot reach or ping it whether its address is in the same subnet or not.

Ah, ok.  Thanks for clearing that up!

Attention: Public Service Advisory:

To those who have changed their distros to point to the LEDE snapshot server in order to get the latest version of packages between @david's releases, please be sure to enter the following command line before upgrading any more packages.  The updates for these were released yesterday I believe; they are pre-reqs for one another; and if you update any or all of them, the router gets stuck in a boot-loop and/or won't boot fully (trust me, I learned from experience.  Luckily I was able to download the original versions from @david's distro using my cell-phone as a wifi hotspot, put the router into recovery mode, use winscp to push them onto the router, and install them using opkg --force-downgrade).

opkg flag hold netifd procd libubox libjson-script jshn

This way if you are using the script or command which updates all available packages, it won't update these and soft-brick your router.

That is all.

(Last edited by starcms on 21 Jun 2017, 04:24)

starcms wrote:
feche1320 wrote:
davidc502 wrote:

The 3200acm leverages a 3rd wifi chip, and it's okay to just go ahead and disable it.  That should be your acbgn radio.

So which chip is the correct one to use? Can I use both at the same time with the same SSID?
If the 2nd chip is disabled, wifi strenght is going to be weaker versus stock firmware?
Thanks

As @david had said, on the 3200ACM, in addition to radio0 (the 4x4:3 5GHz radio) and radio1 (the 4x4:3 2.4GHz radio), there is a radio2.  Radio2 is meant only to be used for DFS (radar) detection.  It is a 1x1:1 5GHz radio.

For proper operation, radio2 should be disabled, and use radio0 as your 5GHz AP and radio1 as your 2.4GHz AP.  (This is how the stock firmware also has the radios configured; it simply hides radio2).

Thanks for the info.

Is it normal that if I select 160mhz I cannot see the wifi ssid? My guess is that this is becouse my notebook doesn't support 160mhz, but on stock firmware if I select 160mhz I can see the network.

feche1320 wrote:
starcms wrote:
feche1320 wrote:

So which chip is the correct one to use? Can I use both at the same time with the same SSID?
If the 2nd chip is disabled, wifi strenght is going to be weaker versus stock firmware?
Thanks

As @david had said, on the 3200ACM, in addition to radio0 (the 4x4:3 5GHz radio) and radio1 (the 4x4:3 2.4GHz radio), there is a radio2.  Radio2 is meant only to be used for DFS (radar) detection.  It is a 1x1:1 5GHz radio.

For proper operation, radio2 should be disabled, and use radio0 as your 5GHz AP and radio1 as your 2.4GHz AP.  (This is how the stock firmware also has the radios configured; it simply hides radio2).

Thanks for the info.

Is it normal that if I select 160mhz I cannot see the wifi ssid? My guess is that this is becouse my notebook doesn't support 160mhz, but on stock firmware if I select 160mhz I can see the network.

This is posted on the mwlwifi (wifi driver for the router) readme:

Hostpad must include following commit for 160 MHz operation:

commit 03a72eacda5d9a1837a74387081596a0d5466ec1 Author: Jouni Malinen jouni@qca.qualcomm.com Date: Thu Dec 17 18:39:19 2015 +0200

VHT: Add an interoperability workaround for 80+80 and 160 MHz channels

Number of deployed 80 MHz capable VHT stations that do not support 80+80 and 160 MHz bandwidths seem to misbehave when trying to connect to an AP that advertises 80+80 or 160 MHz channel bandwidth in the VHT Operation element. To avoid such issues with deployed devices, modify the design based on newly proposed IEEE 802.11 standard changes.

This allows poorly implemented VHT 80 MHz stations to connect with the AP in 80 MHz mode. 80+80 and 160 MHz capable stations need to support the new workaround mechanism to allow full bandwidth to be used. However, there are more or less no impacted station with 80+80/160 capability deployed.

Signed-off-by: Jouni Malinen jouni@qca.qualcomm.com

Note: After hostapd package 2016-06-15, this commit is already included.

So it sounds like at some point, devices (VHT stations) that only supported 80MHz wouldn't work if the 3200ACM was set to 80+80MHz or 160MHz.  However, according to that, the issue has been corrected since hostapd version 2016-06-15, and @david's latest build (and for quite a while) includes version 2016-12-19 of hostapd-common.

I don't have a 3200ACM, but I believe you should be able to set it at 160MHz, and all your 80MHz (and 40MHz and 20MHz) devices should be able to connect perfectly fine.  Hopeone someone with a 3200acm will tune in with if they can.

Just curious, can you also set it for 80+80 instead of 160MHz?  If so, have you tried that to see if you devices can see the AP?

Edit: And just to make sure, you are setting 160MHz on radio0, not on radio2, correct?  And you have radio2 disabled?

(Last edited by starcms on 22 Jun 2017, 07:37)

I observe the same issue as feche1320. Setting 160MHz on radio0 makes the router "invisible" to any device I have...

Radio 2 is disabled, I never touched the country code settings. Everything else is pretty much untouched. AC only, Channel 36, 20db tx power.

EDIT: The 2.4G net remains operational.

(Last edited by multiduplikator on 22 Jun 2017, 12:51)

starcms wrote:
feche1320 wrote:
starcms wrote:

As @david had said, on the 3200ACM, in addition to radio0 (the 4x4:3 5GHz radio) and radio1 (the 4x4:3 2.4GHz radio), there is a radio2.  Radio2 is meant only to be used for DFS (radar) detection.  It is a 1x1:1 5GHz radio.

For proper operation, radio2 should be disabled, and use radio0 as your 5GHz AP and radio1 as your 2.4GHz AP.  (This is how the stock firmware also has the radios configured; it simply hides radio2).

Thanks for the info.

Is it normal that if I select 160mhz I cannot see the wifi ssid? My guess is that this is becouse my notebook doesn't support 160mhz, but on stock firmware if I select 160mhz I can see the network.

This is posted on the mwlwifi (wifi driver for the router) readme:

Hostpad must include following commit for 160 MHz operation:

commit 03a72eacda5d9a1837a74387081596a0d5466ec1 Author: Jouni Malinen jouni@qca.qualcomm.com Date: Thu Dec 17 18:39:19 2015 +0200

VHT: Add an interoperability workaround for 80+80 and 160 MHz channels

Number of deployed 80 MHz capable VHT stations that do not support 80+80 and 160 MHz bandwidths seem to misbehave when trying to connect to an AP that advertises 80+80 or 160 MHz channel bandwidth in the VHT Operation element. To avoid such issues with deployed devices, modify the design based on newly proposed IEEE 802.11 standard changes.

This allows poorly implemented VHT 80 MHz stations to connect with the AP in 80 MHz mode. 80+80 and 160 MHz capable stations need to support the new workaround mechanism to allow full bandwidth to be used. However, there are more or less no impacted station with 80+80/160 capability deployed.

Signed-off-by: Jouni Malinen jouni@qca.qualcomm.com

Note: After hostapd package 2016-06-15, this commit is already included.

So it sounds like at some point, devices (VHT stations) that only supported 80MHz wouldn't work if the 3200ACM was set to 80+80MHz or 160MHz.  However, according to that, the issue has been corrected since hostapd version 2016-06-15, and @david's latest build (and for quite a while) includes version 2016-12-19 of hostapd-common.

I don't have a 3200ACM, but I believe you should be able to set it at 160MHz, and all your 80MHz (and 40MHz and 20MHz) devices should be able to connect perfectly fine.  Hopeone someone with a 3200acm will tune in with if they can.

Just curious, can you also set it for 80+80 instead of 160MHz?  If so, have you tried that to see if you devices can see the AP?

Edit: And just to make sure, you are setting 160MHz on radio0, not on radio2, correct?  And you have radio2 disabled?

Radio2 only has 20/40/80mhz, 160mhz is not listed, and it is disabled of course
Radio0 has 20/40/80/160mhz options, there is no 80+80 option
After some tinkering I got to the conclusion that running on 160mhz mode it will only work with 160mhz devices, but I think this is a bug since on stock firmware it is working correctly. (If I set it to 160mhz I can see it with my notebook/cellphone)
I know that there is currently no device with 160mhz capability but I plan on getting a 160mhz device for my notebook and I would like this issue to be solved when I get the upgrade.
Thanks

(Last edited by feche1320 on 22 Jun 2017, 17:24)

I was thinking, but could be wrong, that you needed a tri-band capable device?

Would anyone have a link to a super simple VPN setup on this build? Something that would allow me to login to my home network from a hotel or similar.

Thanks.

OpenVPN is on the build - that is as simple as it gets for VPN.

Otherwise, you do SSH to router and use remote/local/dynamic port forwarding as you need it...

(Last edited by multiduplikator on 22 Jun 2017, 18:13)

davidc502 wrote:

I was thinking, but could be wrong, that you needed a tri-band capable device?

The bad part is that there is no 160mhz capable device so it is hard to debug, but in stock firmware selecting 160mhz I can see the SSID with my phone/notebook
In OpenWRT selecting 160mhz the SSID dissapears

multiduplikator wrote:

OpenVPN is on the build - that is as simple as it gets for VPN.

Otherwise, you do SSH to router and use remote/local/dynamic port forwarding as you need it...

Right I know that. I guess I was looking for a quick guide on creating user keys etc.

What about
OpenVPN Setup Guide for Beginners on the openwrt wiki

You just need to skip some sections.

And then there was
Setup OpenVPN using OpenWRT
From Robert Kehoe. Works with the Luci GUI to do the job.

(Last edited by multiduplikator on 22 Jun 2017, 20:07)

Have r4323 installed on my wrt3200acm. I keep seeing the following messages over and over in the system log.
Thu Jun 22 14:44:51 2017 user.warn igmpproxy[3182]: The source address 169.254.116.28 for group 239.255.255.250, is not in any valid net for upstream VIF.
Thu Jun 22 14:44:57 2017 user.warn igmpproxy[3182]: The source address 169.254.243.68 for group 239.255.255.250, is not in any valid net for upstream VIF.
Thu Jun 22 14:45:01 2017 user.warn igmpproxy[3182]: The source address 169.254.116.28 for group 239.255.255.250, is not in any valid net for upstream VIF.
Thu Jun 22 14:45:07 2017 user.warn igmpproxy[3182]: The source address 169.254.243.68 for group 239.255.255.250, is not in any valid net for upstream VIF.
Thu Jun 22 14:45:18 2017 user.warn igmpproxy[3182]: The source address 169.254.243.68 for group 239.255.255.250, is not in any valid net for upstream VIF.
Thu Jun 22 14:45:20 2017 user.warn igmpproxy[3182]: The source address 169.254.116.28 for group 239.255.255.250, is not in any valid net for upstream VIF.

The 169.254.243.68, etc are normally private network addresses. I did not see these until I had Xfinity (Comcast) cable installed on last Monday. The modem is set to bridge mode and I am getting a public IP address. Not sure where these are coming from as I have not added anything to the network, such as a new PC or tablet.

Any ideas. Looks like it has to do with igmpproxy which I would not normally be using. Is this something new in this build that needs configured or stopped? I see "/usr/sbin/igmpproxy /var/etc/igmpproxy.conf" in processes. Should I kill this to prevent these messages?

bill1228 wrote:

Have r4323 installed on my wrt3200acm. I keep seeing the following messages over and over in the system log.
Thu Jun 22 14:44:51 2017 user.warn igmpproxy[3182]: The source address 169.254.116.28 for group 239.255.255.250, is not in any valid net for upstream VIF.
Thu Jun 22 14:44:57 2017 user.warn igmpproxy[3182]: The source address 169.254.243.68 for group 239.255.255.250, is not in any valid net for upstream VIF.
Thu Jun 22 14:45:01 2017 user.warn igmpproxy[3182]: The source address 169.254.116.28 for group 239.255.255.250, is not in any valid net for upstream VIF.
Thu Jun 22 14:45:07 2017 user.warn igmpproxy[3182]: The source address 169.254.243.68 for group 239.255.255.250, is not in any valid net for upstream VIF.
Thu Jun 22 14:45:18 2017 user.warn igmpproxy[3182]: The source address 169.254.243.68 for group 239.255.255.250, is not in any valid net for upstream VIF.
Thu Jun 22 14:45:20 2017 user.warn igmpproxy[3182]: The source address 169.254.116.28 for group 239.255.255.250, is not in any valid net for upstream VIF.

The 169.254.243.68, etc are normally private network addresses. I did not see these until I had Xfinity (Comcast) cable installed on last Monday. The modem is set to bridge mode and I am getting a public IP address. Not sure where these are coming from as I have not added anything to the network, such as a new PC or tablet.

Any ideas. Looks like it has to do with igmpproxy which I would not normally be using. Is this something new in this build that needs configured or stopped? I see "/usr/sbin/igmpproxy /var/etc/igmpproxy.conf" in processes. Should I kill this to prevent these messages?

Looks like iptv broadcasts..  igmpproxy is now installed by default.  Try removing it and see if you're still getting the same messages.

feche1320 wrote:
davidc502 wrote:

I was thinking, but could be wrong, that you needed a tri-band capable device?

The bad part is that there is no 160mhz capable device so it is hard to debug, but in stock firmware selecting 160mhz I can see the SSID with my phone/notebook
In OpenWRT selecting 160mhz the SSID dissapears

Using the stock firmware @160mhz, can you also connect besides see? If yes, then it appears to be a possible problem with the current driver.

davidc502 wrote:
feche1320 wrote:
davidc502 wrote:

I was thinking, but could be wrong, that you needed a tri-band capable device?

The bad part is that there is no 160mhz capable device so it is hard to debug, but in stock firmware selecting 160mhz I can see the SSID with my phone/notebook
In OpenWRT selecting 160mhz the SSID dissapears

Using the stock firmware @160mhz, can you also connect besides see? If yes, then it appears to be a possible problem with the current driver.

Yes, I can see the SSID and connect to it

Linksys 1900ac Can't revert to factory firmware :
I'm trying to do some comparison testing of OpenWRT DD vs the factory firmware on the 1900ac .
i wanted to switch back to OEM  or dd wrt,
+ The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform.+
- and i truy flash some image bin but can't please someone can help me now i been
davidc502 based on kernel version 4.9.20.

(Last edited by babyrooney9 on 23 Jun 2017, 03:05)

upload the Linksys firmware to the router using Winscp to the /tmp directory and run the following command from ssh.

sysupgrade -F /tmp/FirmwareName.img

Sorry, posts 2426 to 2425 are missing from our archive.