You are not logged in. Please login or register.
OpenWrt → Community Releases / Announcements → IPv6 oriented Openwrt build for WNDR3700/WNDR3800
This might not be your fault. Do you by chance have your OpenWrt router with the 6in4 tunnel behind another NAT-router which is then connected to your DSL / cable line?
If this is the case then it might be that this other router is not handling your tunnel correctly. Not all IPv4 routers handle 6in4 traffic correctly and there is really not much you can do about it.
Hi Cyrus,
For the LAN DHCPv6 leases it looks like Win8 get the lease and registers host name with the router ok.
However, the router thinks lease is 1hr vs Win8 reporting 24hrs.
I see the default DHCPv4 leasetime is 12h, yet win8 reports 24h lease.
I guess win8 must request 24h lease but ignores any response to the contrary?
Any suggestions?
-Rolf
Well if that is correct then this sounds like a bug in Windows 8.
Does it cause any disrupting behaviour? Does it still send a DHCPv6-RENEW at least every hour? (might be just that an incorrect value is shown but internally it might be correct)
But not sure what we can do about that. Setting the leasetime to 24h is not an option for IPv6 because these addresses might change more recently and thus would break client behaviour in general.
However even if it is that broken in Windows 8 addresses are still received via regular Router Advertisement which might save the IPv6-connectivity.
I'm not seeing that behavior, On my Win8 box the GUI shows the lease expiring 2 hours into the future, and the RENEW packet it sends to the router has a preferred lifetime of 1 hour and a valid lifetime of 2 hours.
Edit: My Mac on the other hand is sending a valid and preferred lifetime of 0 seconds, glad that isn't breaking anything.
0s are fine, they just mean that the client has no preference for anything. In general everything the client sends to the server is just a hint what the client likes to receive back, but the server is free to ignore any or all of those hints.
As long as the client adheres to what the server tells it, everything is fine.
I did a bit more testing on DHCPv6.
Looking at the openWRT gui the Win8 client shows expired for a few minutes then it shows up as leased again.
Is this just a delay in the logging?
However, when it shows up as leased after expiring it looses the host name and shows as '?'.
This is the most annoying part as I can't get the host IPv6 by name anymore.
@Cyrus Does the DHCPv6 renew get push by server when lease expires?
@Decryptor does your IPv6 hostname show in the openwrt active DHCPv6 section?
How do you get the detailed info about the DHCPv6 transactions?
BTW I'm using DUID so I can remember the local IPv6 addresses.
No, all communication normally originates from the client (including Renew).
There is one command that the server can send which is RECONFIGURE but that is not supported by Windows and is normally only used when changes happen to the addresses before their lifetime runs out.
...
@Decryptor does your IPv6 hostname show in the openwrt active DHCPv6 section?
How do you get the detailed info about the DHCPv6 transactions?BTW I'm using DUID so I can remember the local IPv6 addresses.
Yeah, the hostname shows up there, and is never actually removed (I had a VM machine stuck there for a week)
I'm using Wireshark to see the back and forth of DHCPv4/6 and RA messages, it can decode them into a human readable form.
Hi Cyrus,
That's what I thought, so probably win8 ipconfig /all is just reporting the wrong lease time info and actually renewing at or about the 1hr mark.
However, there are couple of questions remaining
1) Anyway to prevent loosing host name from DHCPv6 lease when expired and then renewed?
I suspect maybe hostname info is not send with renew?
Could host name be stored with DUID info ?
2) Can we extend a grace period on server a bit longer than 1h so that we can avoid expired condition? E.g. let the lease in server be 1:15h while telling the client that lease time is 1h?
Actually both things are already done and as the_decryptor said hostnames are currently even preserved after lease expiry
Then what would be causing the hostname to become '?'
I played a bit with wireshark
I see DHCPv6 replies with:
1) Identity Association for Non-temporary Address (3)
T1=1800 T2=2880 (30min and 48min ?)
2) IA address (5)
PrefLifetime=86400
ValidLifetime=86400 (Is this 24h?)
I'm confused of T1/T2 vs IA valid time
My interpretation is that the lease time is equivalent to IA valid time 24hrs.
T1/T2 is set to tell the client how frequent to contact DHCP server and when to try an DHCP server if it can't get the one that granted the current lease.
I don't see where openwrt get 60min lease time from?
A bit more info on the disappearing DHCPv6 hostname
The hostname disappears after openwrt is reset.
The once rebooted lease will renew but '?' will be shown as hostname.
'ipconfig /renew6' will not restore hostname
'ipconfig /release6' followed by 'ipconfig /renew6' will restore the hostname
Any suggestions?
Will hostname only be updated on initial request but not on renew?
- r37031: effects of new hotplug functionality :-(
There have been lots of changes during the weekend that have caused me the need to rewrite some of my own modifications.
"procd" acts now as the module init and takes care of button actions since r36987: https://dev.openwrt.org/changeset/36987
"ubox" takes care of the block-mount actions since r36988: https://dev.openwrt.org/changeset/36988
Both of those caused havoc. I have modified the reset button script and also placed a new radio-toggle script in the correct place. ( but the new radio button script caused CPU util to get stuck at 100% as hostapd consumes all available CPU...)
Apparently now button action scripts need to be in "/etc/rc.button" and be named correctly according to the button's hardware name. (I have not yet figured out if there is any way to record unspecified button actions like earlier. If all button names need to be known in advance, it may be rather hard to write new scripts or to even monitor button actions in a generic way. )
I have not yet figured out the correct syntax to get the new fstab to auto-mount my USB stick. I can manually mount it to the correct location without problems, but fstab fails. (The model fstab file was dropped from the default package, so I have tried to add one.)
WNDR3700v2 or WNDR3800
My WNDR3700v2 has bitten the bullet, and I need to replace it. Presently the 3800 is about $125 and the 3700 is about $90 at Amazon.
I simply need wifi (wpa2 psk), eventually WAN-accessible openvpn that relays my connection back to the WAN, and the various ipv6 WAN options which are well-provided by the 3700. I don't do NAS.
So is there any reason to go for the 3800? (e.g. more WIFI power; better reliability; etc.)
Thanks for thoughts and opinions.
I think the only difference between the 3700v2 and 3800 is increased RAM and flash space on the 3800. If you're using something like a pivot overlay then the flash size isn't important, but you might hit issues with the 16MB (?) or so of RAM the 3700v2 has (The 3800 has 128MB)
I think the only difference between the 3700v2 and 3800 is increased RAM and flash space on the 3800.
I have all three: 3700, 3700v2 and 3800...
As far as I know the RAM size is the only difference between 3800 and 3700v2. Both have 16 MB flash.
(and 3800 has a red front bezel...) I have not noticed any practical difference between those two with Openwrt. I have no comments for the original Netgear firmware as I have not used it.
With 3700 you need to be very careful to check that you really get a 3700v2, instead of 3700v3 or 3700v4 that are incompatible...
That's what I get for not checking, didn't realise the flash size was the same.
- r37035: fstab partially fixed, reset functionality is missing
fstab - the block device automounting - has been partially fixed. Apparently the config format has changed and the mounting can currently be configured only for known devices by uuid. Discussion here:
https://lists.openwrt.org/pipermail/openwrt-devel/2013-June/020541.html
A working model /etc/config/fstab is included in the build, but it works only for one of my USB sticks. You have to replace the uuid with your device's uuid...
root@OpenWrt:~# cat /etc/config/fstab
config 'mount'
option target '/mnt'
option uuid '8c6c-0792'
option enabled '1'
## Use 'block detect' to find out your disk's uuid.
## Then set the uuid option here correctly.Reset functionality is apparently broken since r36989.
I have created a ticket: https://dev.openwrt.org/ticket/13769
This might be my last build until late July. (If the reset functionality is fixed, I might do one more build tomorrow.)
Hello Hnyman,
Without the reset functionality I imagine it becomes difficult to recover from the failed upgrade?
Hello Hnyman,
Without the reset functionality I imagine it becomes difficult to recover from the failed upgrade?
The built-in Netgear TFTP recovery will work regardless of the screwed-up functionality inside Openwrt. That is one of the best features in WNDR3700/3800...
http://wiki.openwrt.org/toh/netgear/wndr3700#recovery.flash.in.failsafe.mode
Only the Openwrt "soft reset" is broken, meaning that "firstboot" or "jffs2reset" commands will not reset the jffs2 overlay partition.
EDIT:
Thanks to http://wiki.openwrt.org/doc/techref/preinit_mount#jffs2reset I traced that the old pre-ubox version of the reset could be duplicated by just including the contents of the old reset hook's scripts in the reset script. Those have already been deleted, but can still be found from svn:
https://dev.openwrt.org/browser/trunk/p … ?rev=36429
https://dev.openwrt.org/browser/trunk/p … ?rev=36429
https://dev.openwrt.org/browser/trunk/p … ?rev=36429
In practice only the commands in 20_reset_clear_jffs should be needed as I know that my build has the overlay.
I am not going to do that now, as I expect the developers to return the reset functionality sooner or later.
Great! So i'm going to upgrade.
Edit: Updated with success.
THANK YOU, The_Decryptor and hnyman for your quick replies!
Turns out that the V2 is not easy to find online, and the 3800 is rather pricey. However, I did manage to find a V2 at a local Best Buy (also saw some V3s and V4s, and an original 3700 :-) .
So I'm good to go; thanks again!
I'm having IPv6 drop out again..
This time it looks like this:
Jun 26 14:42:46 bazzle 6relayd[562]: Received 72 Bytes from fe80::201:5cff:fe24:3201%eth1
Jun 26 14:42:46 bazzle 6relayd[562]: --
Jun 26 14:42:46 bazzle 6relayd[562]: Received 128 Bytes from kernel%netlink
Jun 26 14:42:46 bazzle 6relayd[562]: --
Jun 26 14:42:46 bazzle 6relayd[562]: Received 64 Bytes from kernel%netlink
Jun 26 14:42:46 bazzle 6relayd[562]: --
Jun 26 14:42:46 bazzle 6relayd[562]: Received 128 Bytes from kernel%netlink
Jun 26 14:42:47 bazzle 6relayd[562]: --
Jun 26 14:42:47 bazzle 6relayd[562]: Received 128 Bytes from kernel%netlink
Jun 26 14:42:47 bazzle 6relayd[562]: --
Jun 26 14:42:47 bazzle 6relayd[562]: Received 128 Bytes from kernel%netlink
Jun 26 14:42:47 bazzle 6relayd[562]: --
Jun 26 14:42:47 bazzle 6relayd[562]: Received 72 Bytes from fe80::201:5cff:fe24:3201%eth1
Jun 26 14:42:47 bazzle 6relayd[562]: --
Jun 26 14:42:47 bazzle 6relayd[562]: Received 128 Bytes from kernel%netlink
Jun 26 14:42:47 bazzle 6relayd[562]: Termination requested by signal.
Jun 26 14:42:47 bazzle 6relayd[562]: Forgot about fd4e:2239:1b6c::1 on br-lan
Jun 26 14:42:47 bazzle 6relayd[562]: Forgot about 2601:9:280:b5::1 on br-lan
Jun 26 14:42:47 bazzle 6relayd[562]: Forgot about 2001:558:6045:14:6927:4d00:7bba:5e58 on eth1
Jun 26 14:42:48 bazzle 6relayd[645]: Sending RS to eth1
Jun 26 14:42:48 bazzle dnsmasq[2956]: reading /tmp/resolv.conf.auto
Jun 26 14:42:48 bazzle dnsmasq[2956]: using nameserver 2001:558:feed::1#53
Jun 26 14:42:48 bazzle dnsmasq[2956]: using nameserver 2001:558:feed::2#53
Jun 26 14:42:48 bazzle dnsmasq[2956]: using nameserver 75.75.75.75#53
Jun 26 14:42:48 bazzle dnsmasq[2956]: using nameserver 75.75.76.76#53
Jun 26 14:42:48 bazzle dnsmasq[2956]: using local addresses only for domain lan
Jun 26 14:42:48 bazzle 6relayd[645]: Relayed 8 bytes to ff02::2%eth1
Jun 26 14:42:48 bazzle 6relayd[645]: --
Jun 26 14:42:48 bazzle 6relayd[645]: Received 8 Bytes from fe80::2eb0:5dff:fe82:f7a2%eth1
Jun 26 14:42:48 bazzle 6relayd[645]: --
Jun 26 14:42:48 bazzle 6relayd[645]: Received 512 Bytes from kernel%netlink
Jun 26 14:42:48 bazzle 6relayd[645]: Learned about 2001:558:6045:14:6927:4d00:7bba:5e58 on eth1
Jun 26 14:42:48 bazzle 6relayd[645]: Learned about 2601:9:280:b5::1 on br-lan
Jun 26 14:42:48 bazzle 6relayd[645]: Learned about fd4e:2239:1b6c::1 on br-lan
Jun 26 14:42:48 bazzle 6relayd[645]: --
Jun 26 14:42:48 bazzle 6relayd[645]: Received 48 Bytes from kernel%netlink
Jun 26 14:42:48 bazzle 6relayd[645]: --
Jun 26 14:42:48 bazzle 6relayd[645]: Received 20 Bytes from kernel%netlink
Jun 26 14:42:48 bazzle 6relayd[645]: --
Jun 26 14:42:48 bazzle 6relayd[645]: Received 72 Bytes from 2001:558:4000:15::1%eth1
Jun 26 14:42:48 bazzle 6relayd[645]: Got a NS for 2001:558:4000:15:8222:3aff:fe4d:9064
Jun 26 14:42:48 bazzle 6relayd[645]: Failed to relay to 2001:558:4000:15:8222:3aff:fe4d:9064%br-lan (Network is unreachable)
Jun 26 14:42:48 bazzle 6relayd[645]: --
Jun 26 14:42:48 bazzle 6relayd[645]: Received 128 Bytes from kernel%netlink
Jun 26 14:42:48 bazzle 6relayd[645]: --
Jun 26 14:42:48 bazzle 6relayd[645]: Received 72 Bytes from 2001:558:4000:15::1%eth1
Jun 26 14:42:48 bazzle 6relayd[645]: Got a NS for 2001:558:4000:15:222:3aff:fe5f:b577
Jun 26 14:42:48 bazzle 6relayd[645]: Failed to relay to 2001:558:4000:15:222:3aff:fe5f:b577%br-lan (Network is unreachable)
Jun 26 14:42:48 bazzle 6relayd[645]: --
Jun 26 14:42:48 bazzle 6relayd[645]: Received 128 Bytes from kernel%netlink
Jun 26 14:42:48 bazzle 6relayd[645]: --
restarting 6relayd does not fix it, and I have to restart the network stack to fix it.
It's on:
BARRIER BREAKER (Bleeding Edge, r35725)
yes, it's a little behind, but it was solid until the past week or so. I'll upgrade it if needed.. first got to save off my dyndns IPv6 mods.
It's on:
BARRIER BREAKER (Bleeding Edge, r35725)yes, it's a little behind, but it was solid until the past week or so.
Sorry, but it makes no sense to report bugs in a 4 month old trunk version.
EDIT:
next build in late July...
The currently available trunk & AA builds still contain the 6rd dhcp bug (typo) fixed by 37051 and 37052. If you need that functionality, you might correct the bug by editing /lib/netifd/dhcp.script in the live system. https://dev.openwrt.org/changeset/37051
OpenWrt → Community Releases / Announcements → IPv6 oriented Openwrt build for WNDR3700/WNDR3800
Powered by PunBB, supported by Informer Technologies, Inc.