OpenWrt Forum Archive

Topic: Support for Marvell 88F5xx81 based routers

The content of this topic has been archived between 18 Jan 2014 and 6 May 2018. Unfortunately there are posts – most likely complete pages – missing.

maddes has released a new build (17986) 3 days ago. I did a sysupgrade on my router  (which went very well by the way) but unfortunately I was unable to get wifi working with that build.
So another sysuprgade later I was back with build 17650 and wifi working again.
Anyone with a similar experience (or a working wifi with maddes build 17986) ?

fatbob wrote:

Currently I'm looking at a D-Link DWA-547 PCI card (Atheros AR5416 chipset 802.11b/g/n) which suspiciously looks like it has an oversized mini-pci card under the cover. I haven't yet found a way to confirm this though... What do you think?

It's not a mini-pci card on the above mentioned card. Found an FCC ID and the internal photos show this: https://fjallfoss.fcc.gov/prod/oet/form … or_pdf=pdf

If you want to go for a new build/revision for the wrt350n v2.x, then remember that you can test without flashing via tftpboot, if you have serial access to router.
With a ramdisk image you can test boot, wlan/wifi and lan, which should be the first checks for a newly used build.
Use uci commands to set your desired configuration (you have documented your setup, haven't you?), then restart the network via the init.d script, after that check all possible connections/devices.

(Last edited by maddes.b on 11 Oct 2009, 15:30)

fatbob wrote:

Instead I bought a cheap Edup PCI card off Ebay with a mini-pci on it. My research indicated it would be a bcm4306 chipset which should work fine but when I opened it up it was a bcm4318 sad  Sadly, the card seem to work fine but fails totally when running it as AP with hostapd. I have read reports that 4318 is unstable in AP-mode but should be better after some DMA-poisoning patches was added. This is worse and the AP doesn't even show up when doing 'iwlist wlan0' scan from a nearby computer.

Sorry for going a bit off-topic here, but I just want to report that the Broadcom 4318 mini-pci works just fine now as AP on my WNR854T. For some reason I can't think of it started working when I installed hostapd-full instead of hostapd-mini. Could be a fluke as I haven't tried to go back to hostapd-mini after it started working...

operron wrote:

maddes has released a new build (17986) 3 days ago. I did a sysupgrade on my router  (which went very well by the way) but unfortunately I was unable to get wifi working with that build.
So another sysuprgade later I was back with build 17650 and wifi working again.
Anyone with a similar experience (or a working wifi with maddes build 17986) ?

Ok, we've got now the wifi working again...
We found the culprit: changeset 17821 introduced the capability to specify several wlan cards and the key to identify each of the card is obviously the mac address.
So, there is now a macaddr parameter for the wireless configuration and this parameter is absolutely mandatory !

If you boot on a fresh post 17821 openwrt image, you get a default wireless configuration that looks like this:

wireless.wifi0=wifi-device
wireless.wifi0.type=mac80211
wireless.wifi0.channel=5
[b]wireless.wifi0.macaddr=00:00:xx:xx:xx:xx[/b]
wireless.wifi0.hwmode=11ng
wireless.wifi0.disabled=0
wireless.@wifi-iface[0]=wifi-iface
wireless.@wifi-iface[0].device=wifi0
wireless.@wifi-iface[0].network=lan
wireless.@wifi-iface[0].mode=ap
wireless.@wifi-iface[0].ssid=OpenWrt
wireless.@wifi-iface[0].encryption=none

with the macaddr parameter already setup with your wifi mac address.

One can tweak this default configuration to adapt to ones wishes, but remember to keep that macaddr parameter (with the real mac address of you card) or the wlan will stop working.

For example, my own configuration looks like that:

wireless.wifi0=wifi-device
wireless.wifi0.type=mac80211
wireless.wifi0.country=FR
wireless.wifi0.disabled=0
wireless.wifi0.hwmode=11ng
wireless.wifi0.channel=7
wireless.wifi0.txpower=20
wireless.wifi0.macaddr=00:00:xx:xx:xx:xx
wireless.@wifi-iface[0]=wifi-iface
wireless.@wifi-iface[0].device=wifi0
wireless.@wifi-iface[0].network=lan
wireless.@wifi-iface[0].mode=ap
wireless.@wifi-iface[0].ssid=My_Own_SSID
wireless.@wifi-iface[0].encryption=psk2
wireless.@wifi-iface[0].hidden=1
wireless.@wifi-iface[0].key=my_very_long_secret_key_in_hexa

You can also note that the "wifi0" string is used to identify the card inside the wireless structure wereas we were used to use a "wlan0" string before... I'm not sure this makes a big difference, but who knows ?

I can't find any information on configuring the switch in the wrt350n. Specifically I want to adjust which port is on which vlan (and set up one or two trunked ports). swconfig can't communicate with the switch at all.

It seems to work, though I've not tested it thoroughly, to use vconfig to add vlans to the lan[1-4], but even if it does this seems somehow wrong.

Hello everybody,

I own a linkys wrt350n v2 router. I would like to install the wrt firmware because of the connection lost problems.
I have read this very long thread.. pfff.. and i am convinced that it's possible.
But before i do something stupid (yes i am a newbie in this kind of installs) i would like to get it right.

Which web-update image should i use now?
I have found this (ftp://ftp.maddes.net/openwrt/kamikaze/o … /squashfs/) page but there are so many builds i am afraid to use the wrong one.

Could please somebody point me to the right on?

thanks in advantage, Kees.

If you start new, then take the lastest one. Right now build 18148 is available on my ftp.
For the case you have connection problems revert back to build 17264 (use sysupgrade info from #376)

Remember this is all BETA and it is recommended to keep a copy of the repository you installed from.
Also you if you have a serial connection to your WRT350Nv2, then you can test with a ramdisk image without flashing (see #554).

(Last edited by maddes.b on 7 Apr 2010, 21:36)

maddes.b, thank you for compiling new builds into images.
But still which to use for if you have a stock firmware on your WRT350n v2

NOT_FOR_NEWBIES_openwrt-wrt350nv2-squashfs-webupgrade.img ?

And i understand there is no webbased interface? how to add this easily?

@Xavalon:
According to your question it seems that you are a newbie to OpenWrt .
I strongly recommend to check out the OpenWrt docs, wiki and forum about how to handle OpenWrt in general, configuration via uci (especially your internet connection), installing packages via opkg, etc.
Hope you have some Linux knowledge too.

And to answer your WRT350Nv2 questions:
1. Yes, that's the correct file. Use at your own risk (=only flash if you can live with your router getting inoperable).
2. Setup internet connection, then install via opkg. Either package "webif" or luci packages "luci-admin-full" and "luci-theme-openwrt" (check this thread for more information).

Best wishes.

(Last edited by maddes.b on 17 Jan 2010, 19:44)

Upgrade time for WNR854T users?: kmod-libertas_2.6.30.8+2009-10-09-1_orion.ipk seen on xwrt repo

Package: kmod-libertas
Version: 2.6.30.8+2009-10-09-1
Depends: kernel (=2.6.30.8-1), kmod-mac80211, kmod-usb-core
Provides:
Source: package/mac80211
Section: kernel
Priority: optional
Maintainer: OpenWrt Developers Team <openwrt-devel@openwrt.org>
Architecture: orion
Installed-Size: 263217
Filename: kmod-libertas_2.6.30.8+2009-10-09-1_orion.ipk
Size: 138181
MD5Sum: 7a73d55f1c48645e6de1312ef3a20284
Description:  Marvell 88W8015 Wireless Driver

(Last edited by Nilfred on 26 Oct 2009, 05:11)

after upgrading to the latest release I noticed that there is something funky going on with the MAC addresses:

 ifconfig
br-lan    Link encap:Ethernet  HWaddr 00:00:00:00:51:81

eth0      Link encap:Ethernet  HWaddr 00:00:00:00:51:81

lan1      Link encap:Ethernet  HWaddr 00:00:00:00:51:81

lan2      Link encap:Ethernet  HWaddr 00:00:00:00:51:81

lan3      Link encap:Ethernet  HWaddr 00:00:00:00:51:81

lan4      Link encap:Ethernet  HWaddr 00:00:00:00:51:81

wan       Link encap:Ethernet  HWaddr 00:00:00:00:51:81

I am not sure, but this does not look like a "valid" MAC address (the manufacturer prefix seems weird).

Cheers,

Greg

Do not try to change MAC addresses, brick is always the result.
Use serial console to revert if already bricked:

ifconfig br-lan hw ether 00:00:00:00:51:81

@drizzt81: same thing for me (maddes build 18148). However the router seems happy with that and works OK.
Just one note: this isn't something I have really focused on in the past, so I can't tell since when the mac addresses are like these ones.

NEWBIES: Skip this post

fatbob wrote:

1) Do _not_ change the MAC address from the default 00:00:00:00:51:81 from WebIf if you don't have serial access. It will make the router inaccessible from the network (brick it) and requires a serial console to restore.

Analysis: Setting MAC address on the LAN interface in /etc/config/network will only set the adress on eth0 interface. The lan1, lan2, lan3 and lan4 interfaces will still have 00:00:00:00:51:81. I tried to decode /lib/network/config.sh which is responsible for setting the MAC address but failed to find out a way to modify it to do the right thing. I ended up setting the MAC address on the lanN interfaces one by one in /etc/init.d/network

Please post the resulting /etc/init.d/network
I will try to export your findings to /etc/config/network via UCI more or less this way:

uci set network.lan1=interface
uci set network.lan1.ifname=lan1
uci set network.lan1.macaddr=00:1B:2F:xx:xx:xx
uci set network.lan2=interface
uci set network.lan2.ifname=lan2
uci set network.lan2.macaddr=00:1B:2F:xx:xx:xx
uci set network.lan3=interface
uci set network.lan3.ifname=lan3
uci set network.lan3.macaddr=00:1B:2F:xx:xx:xx
uci set network.lan4=interface
uci set network.lan4.ifname=lan4
uci set network.lan4.macaddr=00:1B:2F:xx:xx:xx
uci set network.lan.macaddr=00:1B:2F:xx:xx:xx
uci set network.eth0.macaddr=00:1B:2F:xx:xx:xx

uci commit network

Not sure of bold ones, your /etc/init.d/network is the key.

Edit: Bricked many times.

net eth0: received packet spanning multiple descriptors
user.err kernel: net eth0: received packet spanning multiple descriptors

Can get it to work with same MAC on br-lan and lan1 (lanN whichever you connect to)
No lanN gets configured via UCI
Reverted to default 00:00:00:00:51:81

uci delete network.lan1
uci delete network.lan2
uci delete network.lan3
uci delete network.lan4
uci delete network.eth0.macaddr
uci set network.lan.macaddr=
uci commit network

(Last edited by Nilfred on 26 Oct 2009, 22:30)

Nilfred wrote:

NEWBIES: Skip this post

fatbob wrote:

1) Do _not_ change the MAC address from the default 00:00:00:00:51:81 from WebIf if you don't have serial access. It will make the router inaccessible from the network (brick it) and requires a serial console to restore.

Analysis: Setting MAC address on the LAN interface in /etc/config/network will only set the adress on eth0 interface. The lan1, lan2, lan3 and lan4 interfaces will still have 00:00:00:00:51:81. I tried to decode /lib/network/config.sh which is responsible for setting the MAC address but failed to find out a way to modify it to do the right thing. I ended up setting the MAC address on the lanN interfaces one by one in /etc/init.d/network

Please post the resulting /etc/init.d/network

I just added:

ifconfig lan1 hw ether <MAC addr>
ifconfig lan2 hw ether <MAC addr>
...etc...

to boot() start() and restart() in /etc/init.d/network. It's an ugly hack, yes.
I think a proper way to do it is to modify /lib/network/config.sh to apply the MAC addr to eth0, br-lan and lanN interfaces.

I'm using build 17562 on my router, there it is also HWaddr 00:00:00:00:51:81.
And if I remember correctly it was this way when I started building images roughly a year ago (build 14xxx).
So I would guess that it is this way at least since Kamikaze 8.09

Just my two cents
Maddes

@someone who needs a changed MAC:
Please create a ticket for this problem.
Do not forget to state...
a) your real name
b) your real mail address
c) used build
d) used hardware
e) what you want
f) what you did to get it
g) what you got

Then finally post the link to the new ticket here smile

Another option is one of the OpenWrt mailing list or forum, as these seems to be a general issue and not a Marvell specific one.

(Last edited by maddes.b on 28 Oct 2009, 00:00)

Does always badly brick saveenv in uboot?
Is the same MAC that come from uboot environment.
Someone equipped with JTAG adapter could possible test if can change MAC from there?
saveenv is reportedly bricker command, do not try without you JTAG adapter in handy.

No, "saveenv" in uboot does not brick your router, but it can if you changed something to a bad value and save these changes to the flash with "saveenv".
So not "saveenv" itself is the problem but the settings you change wrongly.
As always change U-Boot settings on your own risk (You saved a log of "printenv", didn't you? You know what you are changing, don't you?).

Note that for some temporary changes you do not even need to save them to the flash, e.g. temporary ip address changes for tfpboot.

(Last edited by maddes.b on 28 Oct 2009, 01:53)

maddes.b wrote:

@someone who needs a changed MAC:
Please create a ticket for this problem.
Then finally post the link to the new ticket here smile

Found related:
#1014 new method to set MAC address in /etc/config/network
#1321 patch: extend network/config.sh to support mtu and mac per bridge member
#1348 redundant calls to setup_interface() at bridge creation
#1428 Change MAC address causes interface to not respond to pings, etc.
#4021 No more access to LAN iface when change MAC...
Changeset 16269 network: prevent unnecessary interface down/up cycles if no mac address change is requested

Peeking around /lib/network/config.sh:
I think isn't honor macaddr when protocol=none only for protocol=static
br-somethin is left to brctl config so it don't touch bridged interfaces nor change MAC address.
I also think I will been up saying "there is nothing wrong with config.sh" Must see...

line 83 wrote:

# Create the interface, if necessary.
# Return status 0 indicates that the setup_interface() call should continue
# Return status 1 means that everything is set up already.

prepare_interface() {
    local iface="$1"
    local config="$2"
    local vifmac="$3"

    # if we're called for the bridge interface itself, don't bother trying
    # to create any interfaces here. The scripts have already done that, otherwise
    # the bridge interface wouldn't exist.

    [ "br-$config" = "$iface" -o -e "$iface" ] && return 0;

    ifconfig "$iface" 2>/dev/null >/dev/null && {
        local proto
        config_get proto "$config" proto

        # make sure the interface is removed from any existing bridge and deconfigured,
        # (deconfigured only if the interface is not set to proto=none)

        unbridge "$iface"
        [ "$proto" = none ] || ifconfig "$iface" 0.0.0.0

        # Change interface MAC address if requested
        [ -n "$vifmac" ] && {
            ifconfig "$iface" down
            ifconfig "$iface" hw ether "$vifmac" up
        }
    }

There is a ugly hack that bring up the interface early without setting the MAC (hope DaBigMac could see the difference in red color)

line 233 wrote:

setup_interface() {
    local iface="$1"
    local config="$2"
    local proto="$3"
    local vifmac="$4"

    [ -n "$config" ] || {
        config=$(find_config "$iface")
        [ "$?" = 0 ] || return 1
    }

    prepare_interface "$iface" "$config" "$vifmac" || return 0

    [ "$iface" = "br-$config" ] && {
        # need to bring up the bridge and wait a second for
        # it to switch to the 'forwarding' state, otherwise
        # it will lose its routes...

        ifconfig "$iface" up
        sleep 1
    }

    # Interface settings
    grep "$iface:" /proc/net/dev > /dev/null && {
        local mtu macaddr
        config_get mtu "$config" mtu
        config_get macaddr "$config" macaddr
        [ -n "$macaddr" ] && $DEBUG ifconfig "$iface" down
        $DEBUG ifconfig "$iface" ${macaddr:+hw ether "$macaddr"} ${mtu:+mtu $mtu} up
    }
    set_interface_ifname "$config" "$iface"

So the patch should be:

line 250 @ r17427 wrote:

-        ifconfig "$iface" up
+        ifconfig "$iface" ${vifmac:+hw ether "$vifmac"} up

Someone wiling to test? Going to sleep now. Also test if mtu is honored for br-lan will get 2 birds in one shot.

(Last edited by Nilfred on 28 Oct 2009, 17:53)

Will be back home in 2.5 weeks. If no one has tested after I return, then I will do some more tests (check U-Boot mac address, check LinkSys stock FW mac address, check your change)

Any tips on enabling 40mhz/300mbps connections? I've blindly stabbed in the dark and gotten 11n @ 130mbps going OK, and it is performing faster than 11g

Nilfred wrote:

There is a ugly hack that bring up the interface early without setting the MAC (hope DaBigMac could see the difference in red color)

tongue

One more change to /lib/network/config.sh

line 133 wrote:

-                    $DEBUG ifconfig "br-$config" up
+                    $DEBUG ifconfig "br-$config" ${vifmac:+hw ether "$vifmac"} up

Fingers crossed...

Sorry, posts 576 to 575 are missing from our archive.