Posts made by Paul Miller

@Himura-Kazuto agreed. I'm sure this worked at one point … a while later, I discovered it nolonger worked, or I imagined it or something. Maybe I was on a different firmware version (and have no idea which)? Who knows.

I shelved the omega2. It's a pile. It's neat as a novelty, but overall it's a pile. I'm using other devices instead.

@Kit-Bishop said in OpenWRT on the Omega 2(+):

@luz Quite agree with all this.

It is a repeat of the situation with the Omega1 - despite frequent multiple requests for a copy of their repository for OpenWrt to enable us to deal with issues with that (probably most notably the recurrent kernel version mismatch issues for many packages) there never was any response - and probably now never will be

That's actionable … has anyone contacted FSF or EFF?

I think the omega2+ I got is pretty slick, and all these expansion boards are neat, but if I knew they were reluctant to publish their GPL code, I never would have bought in.

OTOH, I never looked, maybe openwrt isn't GPL, in which case, this is what you get.

After further testing, it appears still to be working... so I went source diving and found mainly the problem is in the /lib/wifi/ralink.sh -- it seems intentionally or by bug to lookup the apcli0 channel and overwrite whatever you put in wireless.ra0.channel -- or possibly looks up the channel of the AP the client connects to and overwrites the AP channel with that (for whatever reason).

But the client works fine on channel 0 iff you set only the ra0 channel to 0.

So I made a new setting and kludged it in rudely just above the part where it sets the channel for the ra0 dev with iwpriv.

Note that applying this patch, while allowing uci set wireless.ra0.ra0_only_channel 0, will also prevent opkg from being able to update the ralink-wifi-mt76x8 package; possibly leaving you with no ralink drivers installed. Be sure to copy the ipk to /root/ if you plan to use this patch so you can rescue the system over serial... or just factory reset or whatever, that seems pretty painless.

--- ralink.sh-orig  2017-02-14 17:43:04.885469047 -0500
+++ ralink.sh-mine  2017-02-14 17:50:07.826365772 -0500
@@ -598,8 +598,15 @@
             
                set_wifi_up "$vif" "$ifname"
        done
-   
-   [ "$channel" != "auto" ] && iwpriv $device set Channel=$channel
+
+   # I made a slightly difference settings space so I could have a
+   # different channel for each device.
+   # 
+   # use uci set wireless.ra0.ra0_only_channel 0 to disable AP
+
+   config_get ${device}_only_channel $device mah_only_channel $channel
+
+   [ "$channel" != "auto" ] && iwpriv $device set Channel=$mah_only_channel
        iwpriv $device set MaxStaNum=$maxassoc
 }

@Zheng-Han hiding the AP doesn't really do anything. You can still see the signal and the wifi mac and proceed with attacks as usuall, but more concerning, it's using up that valuable wifi spectrum for no reason.
I can see all my neighbor's hidden ssids, wmacs and all with an app on my phone. Mine's a $2 app called WiFi Analyzer --- but there's free ones.

Whatever.

Requires further testing, but I seemed to have killed the AP with:

iwpriv ra0 set Channel=0 # dead now

I wonder if it's a hidden driver setting or a bug or something; but it seems to have worked.

note that uci set wireless.ra0.channel=0 does NOT work. You have to iwpriv or the channel seems to be hardcoded at 11...