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) ?

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, 13:30)

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...

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, 19: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, 18:44)

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

(Last edited by Nilfred on 26 Oct 2009, 04: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:

@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

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:

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

Edit: Bricked many times.

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

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

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

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 27 Oct 2009, 23: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, 00:53)

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...

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

So the patch should be:

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, 16: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

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

Fingers crossed...