OpenWrt Forum Archive

Topic: Build for WNDR3700/WNDR3800

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

After a clean install, r35262 works perfectly for me.
Thank you HNyman.

hi,hnyman
I have a wndr3800 running with your build (trunk r35308), for some reasons, I need to change router's wifi transmit power sometimes with my ipad4 or nexus7, but everytime I make a change to the dbm in the luci, for example , from 50mW to 200mW, or from 398mW to  50mW, wifi clients will disconnect from router, the problem is ,ipad or nexus can not connect with wifi anymore, unless I disable and enable  wifi radio with my laptop connected with lan.
is it normal or what, any idea?

kernel log seems ok.here is sys log.

Jan 28 00:22:57 OpenWrt daemon.info dnsmasq-dhcp[14127]: DHCPREQUEST(br-lan) 192.168.1.242 c5:82:59:1e:d5:40 
Jan 28 00:22:57 OpenWrt daemon.info dnsmasq-dhcp[14127]: DHCPACK(br-lan) 192.168.1.242 c5:82:59:1e:d5:40 Janices-Ipad
Jan 28 00:25:36 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: authenticated
Jan 28 00:25:36 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: associated (aid 2)
Jan 28 00:25:36 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b RADIUS: starting accounting session 5104FFEC-0000001A
Jan 28 00:25:36 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b WPA: pairwise key handshake completed (RSN)
Jan 28 00:25:37 OpenWrt daemon.info dnsmasq-dhcp[14127]: DHCPREQUEST(br-lan) 192.168.1.221 88:88:48:eb:04:9b 
Jan 28 00:25:37 OpenWrt daemon.info dnsmasq-dhcp[14127]: DHCPACK(br-lan) 192.168.1.221 88:88:48:eb:04:9b android-4c89fa5e157c4c85
Jan 28 00:32:40 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 WPA: group key handshake completed (RSN)
Jan 28 00:32:49 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: deauthenticated due to local deauth request
Jan 28 00:33:00 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: authenticated
Jan 28 00:33:00 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: associated (aid 2)
Jan 28 00:33:00 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: disassociated
Jan 28 00:33:22 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: authenticated
Jan 28 00:33:22 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: associated (aid 2)
Jan 28 00:33:22 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b RADIUS: starting accounting session 5104FFEC-0000001B
Jan 28 00:33:22 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b WPA: pairwise key handshake completed (RSN)
Jan 28 00:33:23 OpenWrt daemon.info dnsmasq-dhcp[14127]: DHCPREQUEST(br-lan) 192.168.1.221 88:88:48:eb:04:9b 
Jan 28 00:33:23 OpenWrt daemon.info dnsmasq-dhcp[14127]: DHCPACK(br-lan) 192.168.1.221 88:88:48:eb:04:9b android-4c89fa5e157c4c85
Jan 28 00:34:34 OpenWrt daemon.info dnsmasq[14127]: reading /tmp/resolv.conf.auto
Jan 28 00:34:34 OpenWrt daemon.info dnsmasq[14127]: using nameserver 202.96.128.166#53
Jan 28 00:34:34 OpenWrt daemon.info dnsmasq[14127]: using nameserver 202.96.134.133#53
Jan 28 00:34:34 OpenWrt daemon.info dnsmasq[14127]: using local addresses only for domain lan
Jan 28 00:34:35 OpenWrt kern.info kernel: [135314.230000] device wlan0 left promiscuous mode
Jan 28 00:34:35 OpenWrt kern.info kernel: [135314.230000] br-lan: port 2(wlan0) entered disabled state
Jan 28 00:34:38 OpenWrt kern.info kernel: [135316.630000] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jan 28 00:34:38 OpenWrt kern.info kernel: [135316.660000] device wlan0 entered promiscuous mode
Jan 28 00:34:38 OpenWrt kern.info kernel: [135316.730000] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jan 28 00:34:38 OpenWrt kern.info kernel: [135316.960000] br-lan: port 2(wlan0) entered forwarding state
Jan 28 00:34:38 OpenWrt kern.info kernel: [135316.970000] br-lan: port 2(wlan0) entered forwarding state
Jan 28 00:34:38 OpenWrt kern.info kernel: [135316.970000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Jan 28 00:34:40 OpenWrt kern.info kernel: [135318.970000] br-lan: port 2(wlan0) entered forwarding state
Jan 28 00:34:41 OpenWrt daemon.info dnsmasq[14127]: exiting on receipt of SIGTERM
Jan 28 00:34:42 OpenWrt user.notice dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
Jan 28 00:34:42 OpenWrt user.notice dnsmasq: Allowing 127.0.0.0/8 responses
Jan 28 00:34:44 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: authenticated
Jan 28 00:34:44 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: associated (aid 1)
Jan 28 00:34:45 OpenWrt daemon.info dnsmasq[9009]: started, version 2.65 cachesize 150
Jan 28 00:34:45 OpenWrt daemon.info dnsmasq[9009]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack
Jan 28 00:34:45 OpenWrt daemon.info dnsmasq-dhcp[9009]: DHCP, IP range 192.168.1.100 -- 192.168.1.249, lease time 12h
Jan 28 00:34:45 OpenWrt daemon.info dnsmasq[9009]: using local addresses only for domain lan
Jan 28 00:34:45 OpenWrt daemon.info dnsmasq[9009]: reading /tmp/resolv.conf.auto
Jan 28 00:34:45 OpenWrt daemon.info dnsmasq[9009]: using nameserver 202.96.128.166#53
Jan 28 00:34:45 OpenWrt daemon.info dnsmasq[9009]: using nameserver 202.96.134.133#53
Jan 28 00:34:45 OpenWrt daemon.info dnsmasq[9009]: using local addresses only for domain lan
Jan 28 00:34:45 OpenWrt daemon.info dnsmasq[9009]: read /etc/hosts - 1 addresses
Jan 28 00:34:45 OpenWrt daemon.info dnsmasq-dhcp[9009]: read /etc/ethers - 0 addresses
Jan 28 00:34:47 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: authenticated
Jan 28 00:34:47 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: associated (aid 2)
Jan 28 00:34:51 OpenWrt user.info firewall: adding lan (br-lan) to zone lan
Jan 28 00:34:52 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: authenticated
Jan 28 00:34:52 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: associated (aid 2)
Jan 28 00:34:52 OpenWrt user.info firewall: adding wan (pppoe-wan) to zone wan
Jan 28 00:34:53 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: deauthenticated due to local deauth request
Jan 28 00:35:01 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: deauthenticated due to local deauth request
Jan 28 00:35:05 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: authenticated
Jan 28 00:35:05 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: associated (aid 1)
Jan 28 00:35:05 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: associated (aid 1)
Jan 28 00:35:06 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: authenticated
Jan 28 00:35:06 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: associated (aid 2)
Jan 28 00:35:11 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: deauthenticated due to local deauth request
Jan 28 00:35:15 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: deauthenticated due to local deauth request
Jan 28 00:35:31 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: authenticated
Jan 28 00:35:31 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: associated (aid 1)
Jan 28 00:35:37 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: disassociated
Jan 28 00:35:40 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: deauthenticated due to local deauth request
Jan 28 00:35:57 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: authenticated
Jan 28 00:35:57 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: associated (aid 1)
Jan 28 00:36:03 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: disassociated
Jan 28 00:36:06 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: deauthenticated due to local deauth request
Jan 28 00:36:14 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: authenticated
Jan 28 00:36:14 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: associated (aid 1)
Jan 28 00:36:21 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: authenticated
Jan 28 00:36:21 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: associated (aid 1)
Jan 28 00:36:28 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: authenticated
Jan 28 00:36:28 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: associated (aid 1)
Jan 28 00:36:37 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: deauthenticated due to local deauth request
Jan 28 00:36:46 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: authenticated
Jan 28 00:36:46 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: associated (aid 1)
Jan 28 00:36:55 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: deauthenticated due to local deauth request
Jan 28 00:37:09 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: authenticated
Jan 28 00:37:09 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: associated (aid 1)
Jan 28 00:37:18 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: deauthenticated due to local deauth request
Jan 28 00:37:28 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: authenticated
Jan 28 00:37:28 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: associated (aid 1)
Jan 28 00:37:37 OpenWrt daemon.info hostapd: wlan0: STA c5:82:59:1e:d5:40 IEEE 802.11: deauthenticated due to local deauth request
Jan 28 00:38:27 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: authenticated
Jan 28 00:38:27 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: associated (aid 1)
Jan 28 00:38:36 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: deauthenticated due to local deauth request
Jan 28 00:38:47 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: authenticated
Jan 28 00:38:47 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: associated (aid 1)
Jan 28 00:38:50 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: disassociated
Jan 28 00:38:51 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Jan 28 00:39:26 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: authenticated
Jan 28 00:39:26 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: associated (aid 1)
Jan 28 00:39:35 OpenWrt daemon.info hostapd: wlan0: STA 88:88:48:eb:04:9b IEEE 802.11: deauthenticated due to local deauth request

Sorry, posts 403 to 401 are missing from our archive.

the new trunk build 35308 is great. at&t 6rd now propagates across the lan with minimal configuration.

Sorry, no idea. My build has standard radio hardware drivers & ap software. Based on your log, it looks like hostapd, the radio access point authentication server, stop accepting the clients. You might browse the Openwrt bug tracker about similar issues, as there should be nothing specific to my build.

Thanks for your reply. Maybe off topic, I used to follow arokh's thread and flash his normal build upto r34054, the issue mentioned above did not happen, but the non-oc builds haven't been updated since November......
Honestly, thanks for your working.

Hello Hnyman,
Something wrong with r35445.
I get IPV6 on the lan interface and PCs.
No IPv6 on the interface wan, it is not strange?
IPV6 test failed on PC and on the device interface.
@+

Edit: after a clean install I do not have public IPV6 at all.

(Last edited by Manani on 1 Feb 2013, 23:17)

Manani wrote:

Hello Hnyman,
Something wrong with r35445.
I get IPV6 on the lan interface and PCs.
No IPv6 on the interface wan, it is not strange?
IPV6 test failed on PC and on the device interface.
@+

Edit: after a clean install I do not have public IPV6 at all.

Hmm. probably an effect of this: https://forum.openwrt.org/viewtopic.php … 06#p190606

My own 6in4 tunnel works quite normally.

Why are/have you dropped radvd?

I ask because I am trying to work out how to configure my router.
The router server two networks,  LAN (a) with a variety of devices, and LAN (B) a number of internet facing servers providing such services as DNS, HTTP(s), SMTP, IMAPS, WebDAV, DaviCAL.

LAN (A) uses DHCP all addresses are dynamic and I do NOT want them publicly exposed!!!! I like the old rfc1918.
LAN (B) all addresses are static and all addresses are public!

I have a /48 block which is divided into 2001:470:dead:10::/64 LAN (A), 2001:470:dead:30::/64 LAN(B). We are planing on creating a third network which will handle the Internal WiFi, and possibly a fourth network to handle Guest WiFI.

Why drop radvd?
What advantage is ther in doing so?
And if its is a raelly good idea How do I configure my 6in4 and network to achieve my desired result?

JohnA

zzz2002 wrote:

Why are/have you dropped radvd?

Because it has been superseeded by the Openwrt-specific "ipv6-support" package in the trunk.

Link to new configuration info in the wiki is in the first message of this thread.
Support thread of the ipv6-support package is: https://forum.openwrt.org/viewtopic.php?id=40853

EDIT: If you want to use radvd, just use my Attitude Adjustment build. It still has radvd etc. Should be otherwise rather identical to the trunk build.

(Last edited by hnyman on 2 Feb 2013, 19:24)

radvd is simply too big for the few features it has. the new server is much smaller comes with an (optional) stateless dhcvp6 server and once turned on for an interface simply announces  all configured prefixes without the need to configure them in the service again.

for static prefix assignment you can keep using ip6addr and might want to nit use ip6prefix in the 6in4 interface configuration.

(Last edited by CyrusFF on 2 Feb 2013, 19:39)

Since these recent massive ipv6 changes on trunk, I could not get my Hurricane Electric tunnel to work until today.  I solved it by starting from scratch on settings.  I am not sure what is different, but it works fine now.

Ipv6 on Access Point?  But, I have two routers set up as access points via WDS.  Wifi clients using those access points can use ipv6, but the access point itself cannot do ipv6.  I tried many settings, but could not get it to work.  All interfaces are removed except LAN.  I have tried fixed IP, DHCP, creating lan6 with dhcp6, etc, etc, etc.  Any suggestions?

IPv6 ULA-Prefix?  Since I have a HE tunnel, should I change the IPv6 ULA-Prefix to my IPV6 routed tunnel?  I have tried this and it seems to work.  Interestingly, when I put my routed prefix on my access points, the LAN on the access point picks the same ipv6 address as the router.

(Last edited by johnthomas00 on 2 Feb 2013, 20:59)

It was a settings problem. Everything goes well as follows:

network

config interface 'wan6'
    option proto 'dhcpv6'
    option ifname '@wan'
    option reqaddress 'none'
    option reqprefix 'no'

6relayd

config server 'default'
    list network 'lan'
    option fallback_relay 'rd dhcpv6 ndp'
    option master 'wan6'
    option rd 'relay'
    option dhcpv6 'relay'

Thanks

johnthomas00 wrote:

Ipv6 on Access Point?  But, I have two routers set up as access points via WDS.  Wifi clients using those access points can use ipv6, but the access point itself cannot do ipv6.  I tried many settings, but could not get it to work.  All interfaces are removed except LAN.  I have tried fixed IP, DHCP, creating lan6 with dhcp6, etc, etc, etc.  Any suggestions?

IPv6 ULA-Prefix?  Since I have a HE tunnel, should I change the IPv6 ULA-Prefix to my IPV6 routed tunnel?  I have tried this and it seems to work.  Interestingly, when I put my routed prefix on my access points, the LAN on the access point picks the same ipv6 address as the router.

Your note prompted me to test this, and I met the same issue: my WDS slave, the router in "sta" mode, does not get an ipv6 address and gets left out of the party :-(

But clients' connected through it to the main router (in "ap" mode) do get ipv6 addresses assigned quite normally.

I tried several settings, but couldn't figure out what is the correct configuration for the wds slave.

EDIT: before the recent changes it worked quite ok. My WDS config is in https://forum.openwrt.org/viewtopic.php … 66#p186066 . Probably the recent changes prevent kernel from using accept_ra to acquire an ipv6 address.

(Last edited by hnyman on 2 Feb 2013, 21:58)

You have two options there.

Either set "option ip6slaac 1" (which replaces accept_ra but with some semantic changes, e.g. only works for proto=static)

or create an alias-interface:

config interface lan6
    option proto dhcpv6
    option ifname @lan
    option reqprefix no

The alias interface has the advantage that also the IPv6-DNS server can be used and if you set reqprefix to "no" then it even supports configuration from RA-only (including DNS if announced) even if no DHCPv6 server is available.

Thanks,
the first option did not seem to work, but the second one worked ok.

This is from WDS slave where ipv6 connectivity works ok:

config interface 'lan'
        option ifname 'eth0.1'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.1.2'
        option netmask '255.255.255.0'
        option gateway '192.168.1.1'
        option dns '192.168.1.1'

config interface lan6
        option proto dhcpv6
        option ifname @lan
        option reqprefix no

(I think that I tried almost those settings earlier, but did not set the "reqprefix no" option.)

And also Luci shows the interface status ok (gateway and DNS):

IPv6 WAN Status                  
br-lan
Address: 2001:xxxxxxxx:0:3046:9aff:fe1b:4d36/64
Gateway: FE80:0:0:0:7444:1FF:FE8D:A3E7
DNS 1: 2001:xxxxxxxx::1
Connected: 0h 4m 18s

Alias works for me too.  Should the main router also have this alias?  I think from a logic and consistency basis it makes sense, but not sure.

johnthomas00 wrote:

Alias works for me too.  Should the main router also have this alias?

I feel that it should not have an alias interface, as it already has the info and also acts as the dhcpv6 server (and gateway and DNS server).

(Last edited by hnyman on 4 Feb 2013, 23:03)

Thats right the server side (main router) should not have the dhcpv6 client interface alias because its acting as a server. It should rather have an RA and DHCPv6-server configured (e.g. 6relayd, radvd or similar).

The client side (slave router) should in contrast have dhcpv6 client interface alias configured but should not have an RA-Server and / or DHCPv6 server running.

Thanks again, working great.

By the way, what should I put in the "IPv6 ULA-Prefix" field (question applies whether one uses WDS or not)?  For my WDS setup, I put my "IPv6 routed prefix" from he.net on the WDS server and left the prefix blank on the WDS clients, but not sure if that is best practice.

Also, is the ipv6 DHCP server reporting host names (like openwrt does for ipv4)?  When I run iftop -i br-lan, I see ipv6 addresses rather than hostnames (ipv4 shows hostnames).  Is it possible to let the router resolve local ipv6 hostnames?

(Last edited by johnthomas00 on 5 Feb 2013, 15:03)

the ULA-prefix is similar to the private address ranges in IPv4 (192.168.x.y, 172.16.x.y, 10.x.y.z) you shouldn't put you routed prefix in there. Put yout routed prefix in an "option ip6prefix ..." into the 6in4 section.

Leave the ULA-prefix empty if you don't need it. It is mostly useful for local communication in case there is no IPv6 uplink or if you want to have some more static IPv6 addresses in your local net (remember that with native ipv6-connection your routed prefix might change on a daily basis).


The problems with the hostnames is this:
Clients (well at least Windows) only send their hostnames when doing stateful DHCPv6 (that is if DHCPv6 is used for address allocation).

So options are:
#1 Assume clients also have an IPv4 which we can correlate using the MAC and thus correlate IPv6 -> MAC -> IPv4 -> Hostname reported by DHCP(v4)
#2 Force clients into stateful mode (set the M-flag in the RAs) and acquire the hostnames. However there is at least Android which doesn't support DHCPv6 so far (only RAs).


I'm currently relatively busy with work so I will be doing bugfixes for the coming weeks only but I have this issue somewhere on my agenda, maybe try to implement a lightweight stateful DHCPv6 server (without adding too much size) into 6relayd. I will probably have to examine how other OS's (e.g. non-Windows) behave regarding the inclusion of the hostname so to see if it makes sense at all.

Awesome work!!  Thank you!

Can dnsmasq provide this?

I obviously don't know much about these things.

Thank you again.

Dnsmasq could probably provide the functionality if it would be built as the "dnsmasq-dhcpv6" variant. My build included that for a while, but I dropped it when the new ipv6-support module was introduced. Vainilla dnsmasq does not provide ipv6 functionality.


Note regarding Backfire:
I will be removing the download link to the Backfire build later in February, as the Attitude Adjustment is a better choice for a stable build. As of now the final AA has not yet been released, but hopefully the relase is soon.

EDIT: 23 Feb 2013: Backfire download has been removed from the FTP server.

(Last edited by hnyman on 23 Feb 2013, 11:32)

dnsmasq supports acting as a stateful DHCPv6 server. However this does not really solve the problem of the hostnames as not all OS (Linux distros usually don't, Android doesn't) send the hostname when doing DHCPv6.

Also until version 2.66 is released it is a mess to configure prefixes etc. and it (the DHCPv6-feature) does not yet have UCI nor LuCI support.

Maybe if someone contributes this then there would be a viable alternative with stateful DHCPv6.

Up until then I decided to implement #1 of my earlier post in like 3 or 4 weeks.

(Last edited by CyrusFF on 7 Feb 2013, 10:47)

I've got a Comcast dhcp IPv6 connection, and I'm seeing the local lan side IPv6 come up, and then go away.. then a new set of IPv6 addresses show  up on lan side, and repeats.

the syslog is full of these:

Feb 13 11:54:55 192.168.1.253 netifd: wan6 (17276): odhcp6c[17276]: State for eth1 changed to ra-updated
Feb 13 11:54:57 192.168.1.253 dnsmasq[3054]: reading /tmp/resolv.conf.auto
Feb 13 11:54:57 192.168.1.253 dnsmasq[3054]: using nameserver 2001:558:feed::1#53
Feb 13 11:54:57 192.168.1.253 dnsmasq[3054]: using nameserver 2001:558:feed::2#53
Feb 13 11:54:57 192.168.1.253 dnsmasq[3054]: using nameserver 75.75.75.75#53
Feb 13 11:54:57 192.168.1.253 dnsmasq[3054]: using nameserver 75.75.76.76#53
Feb 13 11:54:57 192.168.1.253 dnsmasq[3054]: using local addresses only for domain lan
Feb 13 11:54:58 192.168.1.253 miniupnpd[18030]: ST: urn:schemas-upnp-org:device:MediaServer:1 (ver=1)
Feb 13 11:54:58 192.168.1.253 miniupnpd[18030]: SSDP M-SEARCH from 192.168.1.22:4097 ST: urn:schemas-upnp-org:device:MediaServer:1
Feb 13 11:54:58 192.168.1.253 odhcp6c[17276]: State for eth1 changed to ra-updated
Feb 13 11:54:58 192.168.1.253 netifd: wan6 (17276): odhcp6c[17276]: State for eth1 changed to ra-updated
Feb 13 11:54:59 192.168.1.253 dnsmasq[3054]: reading /tmp/resolv.conf.auto
Feb 13 11:54:59 192.168.1.253 dnsmasq[3054]: using nameserver 2001:558:feed::1#53
Feb 13 11:54:59 192.168.1.253 dnsmasq[3054]: using nameserver 2001:558:feed::2#53
Feb 13 11:54:59 192.168.1.253 dnsmasq[3054]: using nameserver 75.75.75.75#53
Feb 13 11:54:59 192.168.1.253 dnsmasq[3054]: using nameserver 75.75.76.76#53
Feb 13 11:54:59 192.168.1.253 dnsmasq[3054]: using local addresses only for domain lan
Feb 13 11:55:01 192.168.1.253 odhcp6c[17276]: State for eth1 changed to ra-updated
Feb 13 11:55:01 192.168.1.253 netifd: wan6 (17276): odhcp6c[17276]: State for eth1 changed to ra-updated
Feb 13 11:55:03 192.168.1.253 dnsmasq[3054]: reading /tmp/resolv.conf.auto
Feb 13 11:55:03 192.168.1.253 dnsmasq[3054]: using nameserver 2001:558:feed::1#53
Feb 13 11:55:03 192.168.1.253 dnsmasq[3054]: using nameserver 2001:558:feed::2#53
Feb 13 11:55:03 192.168.1.253 dnsmasq[3054]: using nameserver 75.75.75.75#53
Feb 13 11:55:03 192.168.1.253 dnsmasq[3054]: using nameserver 75.75.76.76#53
Feb 13 11:55:03 192.168.1.253 dnsmasq[3054]: using local addresses only for domain lan
Feb 13 11:55:03 192.168.1.253 miniupnpd[18030]: ST: urn:schemas-upnp-org:device:MediaServer:1 (ver=1)
Feb 13 11:55:03 192.168.1.253 miniupnpd[18030]: SSDP M-SEARCH from 192.168.1.22:4097 ST: urn:schemas-upnp-org:device:MediaServer:1
Feb 13 11:55:04 192.168.1.253 odhcp6c[17276]: State for eth1 changed to ra-updated
Feb 13 11:55:04 192.168.1.253 netifd: wan6 (17276): odhcp6c[17276]: State for eth1 changed to ra-updated
Feb 13 11:55:05 192.168.1.253 dnsmasq[3054]: reading /tmp/resolv.conf.auto
Feb 13 11:55:05 192.168.1.253 dnsmasq[3054]: using nameserver 2001:558:feed::1#53
Feb 13 11:55:05 192.168.1.253 dnsmasq[3054]: using nameserver 2001:558:feed::2#53
Feb 13 11:55:05 192.168.1.253 dnsmasq[3054]: using nameserver 75.75.75.75#53
Feb 13 11:55:05 192.168.1.253 dnsmasq[3054]: using nameserver 75.75.76.76#53
Feb 13 11:55:05 192.168.1.253 dnsmasq[3054]: using local addresses only for domain lan
Feb 13 11:55:07 192.168.1.253 odhcp6c[17276]: State for eth1 changed to ra-updated
Feb 13 11:55:07 192.168.1.253 netifd: wan6 (17276): odhcp6c[17276]: State for eth1 changed to ra-updated
Feb 13 11:55:08 192.168.1.253 miniupnpd[18030]: ST: urn:schemas-upnp-org:device:MediaServer:1 (ver=1)
Feb 13 11:55:08 192.168.1.253 miniupnpd[18030]: SSDP M-SEARCH from 192.168.1.22:4097 ST: urn:schemas-upnp-org:device:MediaServer:1
Feb 13 11:55:09 192.168.1.253 dnsmasq[3054]: reading /tmp/resolv.conf.auto
Feb 13 11:55:09 192.168.1.253 dnsmasq[3054]: using nameserver 2001:558:feed::1#53
Feb 13 11:55:09 192.168.1.253 dnsmasq[3054]: using nameserver 2001:558:feed::2#53
Feb 13 11:55:09 192.168.1.253 dnsmasq[3054]: using nameserver 75.75.75.75#53
Feb 13 11:55:09 192.168.1.253 dnsmasq[3054]: using nameserver 75.75.76.76#53
Feb 13 11:55:09 192.168.1.253 dnsmasq[3054]: using local addresses only for domain lan
Feb 13 11:55:10 192.168.1.253 odhcp6c[17276]: State for eth1 changed to ra-updated
Feb 13 11:55:10 192.168.1.253 netifd: wan6 (17276): odhcp6c[17276]: State for eth1 changed to ra-updated
^C

Ideas on what is wrong?

it looks like comcast is spamming you with router advertisements or something in openwrt sends router solicitations en masse. could you maybe do a tcpdump?

Sure can..  You want it from the wan side of the router, correct?

Sorry, posts 426 to 425 are missing from our archive.