OpenWrt Forum Archive

Topic: Fully featured OpenWrt build for the WNDR3700 (NO LONGER MAINTAINED)

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

arokh wrote:

@masta

Polish is welcome, but I don't see why dns queries to localhost should be done through IPv6. You'll have to clarify why it's a good idea smile Added ::1 to hosts.

@ferob

Ok thx, fixed in latest build.

Also switched back to 3.3 kernel, someone posted a fix.

Hey Arkoh about polishing:
You can also change these for alternate version in /etc/config/transmission

    option peer_limit_global 40
    option peer_limit_per_torrent 10

since wndr3700 cannot handle more than that and it will reboot router when the MEM and CPU will reach the top.

ferob wrote:

@arokh

There was some changes (r21211) to minidlna.

I've noticed those changes also yesterday. But does that mean that we will be able to configure minidlna from Luci or what was the uci support added for in general?

It's just UCI support, which would be a prerequisite for adding Luci support. I'll modify the transmission defaults, thx mmhorda.

New build with libnl and luci-app-minidlna coming right up smile

First I just would like to say big thank you to you arokh for putting out these awesome builds.

Now on to my little issue, lol.

Basically I've been getting

our AdvValidLifetime on br-lan for [ipv6 prefix] doesn't agree with [ipv6 address given to modem by default config?]

along with

our AdvPreferredLifetime on br-lan for [ipv6 prefix] doesn't agree with [ipv6 address given to modem by default config?]

Not sure why this warning is spamming the system log. I've searched and most things I seem to find state that this is usually caused by two instances of radvd or radvd and some other ipv6 daemon advertising -- but only one instance of radvd is running and it's a freshly installed build from April 5th. If anyone could point me in the right direction of getting this to stop flooding the system log that'd be much appreciated.

And thanks again arokh.

Probably that you need to enable it, UCI default is off smile

ferob wrote:

@arokh

The wifi is working with the latest build, but there is something wrong with minidlna.


EDIT: No, I tried that after the upgrade.

And there is no default config for it.
I tried to create one manually, but the problem is still the same and it would not start up.

These two lines are missing from your makefile:

$(INSTALL_DIR) $(1)/etc/config
$(INSTALL_BIN) ./files/minidlna.config $(1)/etc/config/minidlna

I am afraid you don't need to create /etc/conf/minidlna
I took a look at /etc/init.d/minidlna and it seems that config is creatied as arokh says in /tmp/minidlna when you enable it in Luci and all the rest of the settings are being stored there.

I will test the build tonight in a few hours smile

Thanks arokh!

PS: @ferob  could you please confirm if it is working or not when you start it in Luci?

(Last edited by mmhorda on 7 Apr 2012, 20:14)

arkoh. ferob is right
I have installed minidlna and luci-minidlna on top of your previous build. I am testing right now the correct settings.
So far i got till here. It appears in luci but i didnt test to start yet as i am a bit busy.  WIll let you know when i finish with tests.

vi /etc/config/minidlna

config minidlna
    option enabled '0'
    option port '8200'
    option interface 'br-lan'
    option friendly_name 'OpenWrt DLNA Server'
    option db_dir '/mnt/sda1/.minidlna'
    option inotify '1'
    option album_art_names 'Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg/AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg/Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg'
    option notify_interval '900'
    option root_container '.'
    option media_dir '/mnt/sda1'

(Last edited by mmhorda on 7 Apr 2012, 22:06)

Ops, fixed in next smile

arokh wrote:

Ops, fixed in next smile

Just wanted to quickly chip in my appreciation for how fast you're responding and fixing stuff cropping up in your builds. smile

arokh wrote:

Ops, fixed in next smile

Arokh. Something  is still wrong with this libnl
wifi seems working good but when i type wifi from command line i can see this:

root@OpenWrt /root# wifi
Failed to read classid file: Object not found
Failed to read classid file: Object not found
root@OpenWrt /root#

It was not happening before.

edit:

SOLUTION:
root@OpenWrt /root# mkdir /etc/libnl
root@OpenWrt /root# touch /etc/libnl/classid
root@OpenWrt /root# wifi
root@OpenWrt /root#

(Last edited by mmhorda on 7 Apr 2012, 23:55)

surtin wrote:

[...]

Basically I've been getting

our AdvValidLifetime on br-lan for [ipv6 prefix] doesn't agree with [ipv6 address given to modem by default config?]

along with

our AdvPreferredLifetime on br-lan for [ipv6 prefix] doesn't agree with [ipv6 address given to modem by default config?]

Not sure why this warning is spamming the system log.

[...]

@Surtin

You might want to take a look at your /etc/config/radvd  settings.

Double check any RA lifetime in luci or in that config file.

I suggest unsettling any values that might have been configured to see if the log msg disappears.

Question: are you accepting RA's from the WAN side of your router, or even from a tunnel interface?

What is your V6 topology? Native, dual stack, tunnel, upstream  DHCPv6  or RA?


I'm just wondering if your RADVD is deviating from what an upstream RA solicitation has provided?

mmhorda wrote:

SOLUTION:
root@OpenWrt /root# mkdir /etc/libnl
root@OpenWrt /root# touch /etc/libnl/classid
root@OpenWrt /root# wifi
root@OpenWrt /root#

Thx, will include those dirs as well.

It would be more worthwhile to fix libnl-tiny instead of evading the problem with full libnl (which is 10x the size).

For a short time fix it's easier to use the full version of libnl. Once libnl-tiny is fixed we can still switch to it :-)

For a short time fix it would be easier to not even use Linux 3.3 - a new, not yet default kernel usually just brings regressions and bloat - otherwise it'd be in use already. Wifi drivers are independant and not affected by the kernel.

jow wrote:

For a short time fix it would be easier to not even use Linux 3.3 - a new, not yet default kernel usually just brings regressions and bloat - otherwise it'd be in use already. Wifi drivers are independant and not affected by the kernel.

I don't really know what is better but I can say that latest build with linux 3.3.1 works great.

So I just built trunk ar71xx with Kernel 3.3 and libnl-tiny and I don't see any wifi issue related to hostapd, so I have no clue what the fuzz is about after all.

jow wrote:

So I just built trunk ar71xx with Kernel 3.3 and libnl-tiny and I don't see any wifi issue related to hostapd, so I have no clue what the fuzz is about after all.

the latest build is also build with libnl-tiny but normal libnl i can find there too.

libnl        3.2.7-1
libnl-tiny    0.1-3

@jow

That's very strange, there is definitely a problem with libnl-tiny and 3.3.x smile


On a different note, changed my build script a little bit to make it easier doing different builds in the future. New builds will have an opkg.conf that pulls packages from the specific build version's packages directory.

Added a 'fat' build, which is basically the alternate build with rsync, tcpdump, lsof and minidlna. Need to come up with good configuration sets and a cleaner way to maintain configs.

Going on vacation again, back in three weeks smile

If there is a problem I'd be grateful about a proper bug report. So far I've only seen vague indications and hand-waving about "something being wrong" with hostapd, libnl-tiny and Linux 3.3. I gave it a quick try here and was able to start and associate to the wifi nromally so I have no idea what to look for. Also note that a critical libnl-tiny issue was fixed with https://dev.openwrt.org/changeset/31155 .

Yes, and its completely incomprehensible.
The cited error constant does not exist in libnl or libnl-tiny and the cited error message is neither found in hostapd nor in libnl.

Sorry, posts 2801 to 2800 are missing from our archive.