476 (edited by hnyman 2011-02-01 12:27:26)

Re: WNDR3700 exploration

Comitizer wrote:

What are the ramifications of switching from wpad-mini to wpad?

Both wpad and wpad-mini are just wrappers around 'hostapd' with support packages.
https://dev.openwrt.org/browser/trunk/p … d/Makefile

-'wpad-mini' is the base system with only WPA(2)-PSK authentication.
- full 'wpad' supports IEEE 802.1x/WPA/EAP/RADIUS (adds the 'WPA supplicant' package with OpenSSL library)

The 'hostapd-utils' just adds a small hostapd_cli command line tool for messaging with the daemon.

Firmware size grows maybe 100 kB.

(Of course, in home usage the EAP/RADIUS functionality is not needed for anything, but the additional SSL encryption support seems to come with it. So thatswhy it is needed for the WPS to function.)

Re: WNDR3700 exploration

Hi guys!
Would someone be so kind to share caldata dump (mdr8 area) from wndr3700NA?
Thanks!

Re: WNDR3700 exploration

Netgear seems to be introducing a new version of WNDR3700, the WNDR3700v3.
It is already presented on their support website, but status is still "Coming soon".
http://support.netgear.com/app/products … a_id/19278

Info and pics at the FCC regulator site:
https://fjallfoss.fcc.gov/oetcf/eas/rep … 1200166%27

That v3 version will be different than v1 or v2 in major way, as the Atheros chip architecture is changed to Broadcom. So, v3 will have almost nothing in common with the v1 and v2.
http://www.wikidevi.com/wiki/Netgear_WNDR3700v3
CPU1: Broadcom BCM4718A1
Based on the specs there, the flash memory will be back to 8 MB.
(So, for anybody interested in the 16 MB v2 version, now is the time to make purchase, as long as they are available...)

I have added a reference to WNDR3700v3 to the Openwrt wiki article, but I have no idea when somebody will conjure up the needed configuration and build script...

Re: WNDR3700 exploration

I wish they called that model something else than WNDR:(.., something which would clearly tell us firmware enthusiasts even in our dreams.. That it’s a different beast altogether.

Anyway thanks for your update.. heads-up

WRT54GLv 1.1, WRT160NL, E2100L
Netgear WNDR3700, Dlink - DIR XX, Soekris 4511, VmWare -x86, UML, Ubiquiti

480 (edited by Borromini 2011-08-29 18:10:22)

Re: WNDR3700 exploration

Won't the switch to Broadcom pretty much mean OpenWrt won't support the device? Or am I too pessimistic? Broadcom 802.11abgn support is already in staging, but the stability and reliability of brcmscmac leaves a lot to be desired, especially if you'd want to use it as an AP...

LEDE 17.01 RC2+ on D-Link DIR-860L B1 :: Netgear WNDR3700 v1 (2x) & v2 (1x) :: PC Engines APU2 :: Ubiquiti Unifi AC Pro (2x) :: TP-Link TL-WR1043ND v1 (1x) & v2 (4x) :: TL-WR841N (2x) :: LEDE trunk on Asus WL-500W (wl) :: OpenWrt Attitude Adjustment 12.09.1 on Asus WL-500G Deluxe

481 (edited by hnyman 2014-11-09 12:55:37)

Re: WNDR3700 exploration

I noticed an interesting question in Arokh's thread and I wrote the needed hotplug script, so I am copying that also here:

avbohemen wrote:

What is correct configuration to make the WAN/eth1 LED work like the LAN switch LEDs (orange on 100Mbps, green on 1000Mbps)?

The script monitors 'ifup' actions from 'wan' interface, then queries the link speed and sets the wan LED to green if speed=1000, otherwise to yellow.

Place this into a new file named  /etc/hotplug.d/iface/99-wanspeed and it should work:

#!/bin/sh

if [ "$ACTION" = ifup ]; then
        if [ "$INTERFACE" = "wan" ] ; then
                SPEED=$(cat /sys/class/net/eth1/speed)
                if [ "$SPEED" = "1000" ] ; then
                        logger "ifup $INTERFACE, speed $SPEED: set wan LED to green"
                        echo "1" > /sys/class/leds/netgear\:green\:wan/brightness
                else
                        logger "ifup $INTERFACE, speed $SPEED: set wan LED to yellow"
                        echo "0" > /sys/class/leds/netgear\:green\:wan/brightness
                fi
        fi
fi

EDIT 9.11.2014: LED name change from wndr3700 to netgear, as BB and trunk use that name.

Re: WNDR3700 exploration

I've been running SVN r26387 for quite some time now (almost a year now) on my first gen WNDR3700.  So far everything runs very well, but as it's been quite some time I was wondering if there's any significant reason to upgrade to a more recent release (I just pulled r30857)?

Re: WNDR3700 exploration

SDNick484 wrote:

I was wondering if there's any significant reason to upgrade to a more recent release (I just pulled r30857)?

Probably nothing significant, unless you need newly added functionalities like jumbo frames etc.

However, there have been somewhat meaningful changes to firewall defaults etc., and those might make it worthwhile to update, especially if you use IPv6 to any extent. Maybe QoS has also improved somewhat thanks to options included in newer kernels.

484

Re: WNDR3700 exploration

There's been tons of development in the ath9k driver, so you might experience better wireless performance.

Re: WNDR3700 exploration

Thanks for the responses.  I don't have a need for Jumbo Frames (in my experience they cause more headaches than they solve), and I'm not currently leveraging QoS (although if I add a VoIP for the house, this may be interesting).  I'm pretty satisfied with my current WiFi performance, but if I do upgrade it's due to those ath9k changes.  I have to say I'm still very impressed with this router.  I frequently have 6-10 WiFi clients (including four behind a bridge) and it keeps up without issue.  I plan to add a wired switch to get more gigabit ports this weekend.

Re: WNDR3700 exploration

Hi,
I've just successfully installed OpenWRT on my Netgear R3700 v1, to secure the bridge connection with WPA, since this is not possible with the original firmware.

However, while configuring it, I've realized that this is just to much for my skills.

So now I'm trying to restore the router's default settings, through LuCi web panel, and on System>Backup/Firmware>Flash Operations (Actions): Restore Backup, I can upload a configuration file.

I have the original Netgear configuration file (NETGEAR_WNDR3700.cfg), but can I restore the backup this easily?
Is it as simple as it was to upload and install OpenWRT?

Here's the printscreen of the menu.
http://ep1.pinkbike.org/p5pb11153817/p5pb11153817.jpg

Re: WNDR3700 exploration

joao.sousa wrote:

I'm trying to restore the router's default settings, through LuCi web panel, and on System>Backup/Firmware>Flash Operations (Actions): Restore Backup, I can upload a configuration file.

I have the original Netgear configuration file (NETGEAR_WNDR3700.cfg), but can I restore the backup this easily?

If you want to return to original Netgear firmware and settings, you need to follow the TFTP recovery flash advice.
http://wiki.openwrt.org/toh/netgear/wnd … lsafe.mode

Re: WNDR3700 exploration

Thank you! This was pretty easy actually!

Re: WNDR3700 exploration

Hi,

I have to configure cat /etc/hotplug.d/button/00-wps file for following condition:
if [ "$BUTTON" = "BTN_2" ] && [ "$ACTION" = "pressed" ]; then

I have to check eth0.1 if link is up then have ON status led otherwise OFF.

Could you please reply, how i can add such condition in that file.

hnyman wrote:

I wanted to make the OpenWrt build for WNDR3700 more "feature-complete", so I searched for information enabling the two buttons on the WNDR3700. Here are short explanations, how to enable the WiFi button and the WPS button. I have done the work on Backfire 10.03.1-SVN branch, but there shouldn't be difference to Kamikaze/trunk.

Based on SVN revision: r25261 Backfire
Build examples and SVN diffs: http://koti.welho.com/hnyman1/Openwrt/
Build process and included features explained here: https://forum.openwrt.org/viewtopic.php?id=28392

Buttons have different names in Backfire and in Kamikaze/trunk:

Backfire:  reset=BTN_0,  wps=BTN_1,  wifi=BTN_2
trunk:  reset=reset,  wps=wps,  wifi=BTN_2

Note: I added a logger line to the scripts, so that each button event gets noted in Syslog.

WiFi button:

The button automatics is pretty much already in place. It only requires hotplugging the button event to the '/sbin/wifi' script.
- The button toggles WiFi off, it at least one radio was on.
- And if both radios were off, it toggles WiFi on according to the specs set in normal Wifi config.

The simple button script just requires adding a file '/etc/hotplug.d/button/10-radio-toggle'.

root@OpenWrt:/# cat /etc/hotplug.d/button/10-radio-toggle

#!/bin/sh
if [ "$BUTTON" = "BTN_2" ] && [ "$ACTION" = "pressed" ]; then
    if [ -d /var/run/hostapd-phy0 -o -d /var/run/hostapd-phy1 ]; then
        logger "WiFi button used: WiFi down"
        /sbin/wifi down
    else
        logger "WiFi button used: WiFi up"
        /sbin/wifi up
    fi
fi

WPS button:

If you have a WPS-enabled network device (like a modern USB dongle) supporting Wi-Fi Protected Setup (WPS), you can negotiate joining the router's Wifi network without manually entering SSID & passkey. You just initiate "WPS authentication" by pushing the similar WPS button on the device (or launching the process by its driver/control software). After the device has initiated the authentication process, you can accept the transaction by using the WPS button on WNDR3700. The connection should then get negotiated, and in most cases in future your PC should remember the received network settings from then on.

After finding the information and browsing the hostapd package sourcecode, the needed actions for enabling the WPS button are pretty simple:

1) Using WPS authentication requires replacing the default 'wpad-mini' package with 'wpad' and 'hostapd-utils'. The reason is that the tool "hostapd_cli" and some needed support functions are not included in 'wpad-mini'.

WPS authentication itself is launched with a command: hostapd_cli -p /var/run/hostapd-phy0 wps_pbc

It tells the running hostapd daemon to participate in ongoing WPS authentication sequence. It needs to be run separately for each radio (= each existing hostapd process).

2) And it only works if the '/etc/config/wireless' has been modified to include info about WPS authentication being allowed by adding the option 'wps_pushbutton' '1' to the wifi-iface section of (each) radio. Additionally, the encryption should be WPA2-PSK (or maybe WPA-PSK is enough, I haven't tested).
(Looks like the version of hostapd scripts in OpenWrt does not support the full scope of hostapd's capabilities, so many of the config options documented in hostapd docs are left unused.)

That config file is read when radios are turned on, so after editing the config, restart the radios in WNDR3700.
At this point, you should be able to test it by running it from command line. If the message gets passed to hostapd, you should see there result 'OK' there. Otherwise the result is 'FAIL'.
> root@OpenWrt:~# hostapd_cli -p /var/run/hostapd-phy0 wps_pbc
> Selected interface 'wlan0'
> OK
> root@OpenWrt:~#

3) Add a hotplug button event script to launch the process.

I modified directly the hostapd package source ( /package/hostapd/files/wps-hotplug.sh ), as the hotplug script gets automatically installed to '/etc/hotplug.d/button/50-wps' with the package.  See below.

The script launches hostapd_cli for each radio and lights the WPS led for 10 seconds. There is no monitoring of the result, or anything like that. It is just a dumb script using the hostapd_cli command to pass the message to the hostapd daemon.
Remember to check the button name: Backfire:  wps="BTN_1",  trunk:  wps="wps"

root@OpenWrt:/# cat /etc/hotplug.d/button/50-wps

if [ "$ACTION" = "pressed" -a "$BUTTON" = "BTN_1" ]; then
        echo "255" > /sys/devices/platform/leds-gpio/leds/wndr3700:green:wps/brightness
        for dir in /var/run/hostapd-*; do
                [ -d "$dir" ] || continue
                logger "WPS button active: $dir"
                hostapd_cli -p "$dir" wps_pbc
        done
        sleep 10
        echo "0" > /sys/devices/platform/leds-gpio/leds/wndr3700:green:wps/brightness
fi
root@OpenWrt:/# cat /etc/config/wireless
...
config 'wifi-iface'
        option 'device' 'radio0'
        option 'network' 'lan'
        option 'mode' 'ap'
        option 'ssid' 'public'
        option 'encryption' 'psk2'
        option 'key' 'SecretKey'
        option 'wps_pushbutton' '1'
...

If everything goes ok, you should see in Syslog not only the button events, but also succesful WPS authentication:

Jan 31 21:11:09 OpenWrt user.notice root: WiFi button used: WiFi up
Jan 31 21:11:09 OpenWrt user.info kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jan 31 21:11:09 OpenWrt user.info kernel: device wlan0 entered promiscuous mode
Jan 31 21:11:09 OpenWrt user.info kernel: br-lan: port 2(wlan0) entering forwarding state
...
Jan 31 21:12:00 OpenWrt user.notice root: WPS button active: /var/run/hostapd-phy0
Jan 31 21:12:00 OpenWrt user.notice root: WPS button active: /var/run/hostapd-phy1
Jan 31 21:12:03 OpenWrt daemon.info hostapd: wlan0: STA 1c:af:f7:f6:11:dc IEEE 802.11: authenticated
Jan 31 21:12:03 OpenWrt daemon.info hostapd: wlan0: STA 1c:af:f7:f6:11:dc IEEE 802.11: associated (aid 1)
Jan 31 21:12:04 OpenWrt daemon.warn hostapd: wlan0: STA 1c:af:f7:f6:11:dc IEEE 802.1X: authentication failed - EAP type: 0 ((null))
Jan 31 21:12:04 OpenWrt daemon.info hostapd: wlan0: STA 1c:af:f7:f6:11:dc IEEE 802.1X: Supplicant used different EAP type: 254 ((null))
Jan 31 21:12:04 OpenWrt daemon.info hostapd: wlan0: STA 1c:af:f7:f6:11:dc IEEE 802.11: disassociated
Jan 31 21:12:05 OpenWrt daemon.info hostapd: wlan0: STA 1c:af:f7:f6:11:dc IEEE 802.11: deauthenticated due to inactivity
Jan 31 21:12:17 OpenWrt daemon.info hostapd: wlan0: STA 1c:af:f7:f6:11:dc IEEE 802.11: authenticated
Jan 31 21:12:17 OpenWrt daemon.info hostapd: wlan0: STA 1c:af:f7:f6:11:dc IEEE 802.11: associated (aid 1)
Jan 31 21:12:17 OpenWrt daemon.info hostapd: wlan0: STA 1c:af:f7:f6:11:dc RADIUS: starting accounting session 4D47094D-00000000
Jan 31 21:12:17 OpenWrt daemon.info hostapd: wlan0: STA 1c:af:f7:f6:11:dc WPA: pairwise key handshake completed (RSN)
Jan 31 21:12:29 OpenWrt daemon.info dnsmasq-dhcp[1855]: DHCPREQUEST(br-lan) 192.168.1.190 1c:af:f7:f6:11:dc 
Jan 31 21:12:29 OpenWrt daemon.info dnsmasq-dhcp[1855]: DHCPACK(br-lan) 192.168.1.190 1c:af:f7:f6:11:dc HNH57JG

EDIT: added a note about the correct button names in Backfire and trunk.
If you want to check the button names on your system, you can use the following hotplug script that just logs the button 'pressed' actions into system log:

root@OpenWrt:/etc/config# cat /etc/hotplug.d/button/02-log
#!/bin/sh
if [ "$ACTION" = "pressed" ]; then
        logger "button: "$BUTTON
fi