http://bugzilla.suse.com/show_bug.cgi?id=986395 http://bugzilla.suse.com/show_bug.cgi?id=986395#c1 Neil Brown changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #1 from Neil Brown --- I agree this is a bug, though it might have to turn into a feature request. I'll have a proper look in the next couple of weeks and see if there is an easy solution or not. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=986395 http://bugzilla.suse.com/show_bug.cgi?id=986395#c3 --- Comment #3 from Neil Brown --- I've looked into this a bit more. I think that using a temporary address to connect to the server is a valid thing to do. As Marius clarified, that address will remain valid as long as the connection to the server persists. If the client needs to disconnect and reconnect it should get a new client address. However for NFSv4.0 the client needs to tell the server how the server can call-back to the client for various state management functions. If a temporary address is provided for that, the server may find that it cannot contact the client. This is only needed for NFSv4.0. NFSv4.1 and later use the connection from client to server as a back-channel so the server never contacts the client directly. So: I think that if the client uses NFSv4.1, the temporary address should not cause a problem. So mount with "-o vers=4.1" - assuming the server supports that. If v4.0 must be used, then you can specify the preferred client address with the "clientaddr mount option. i.e. "mount -t nfs -o clientaddr=xx:xx:xx::xx ....." If no clientaddr option is given, mount.nfs will choose one itself. It would be best if mount.nfs chose a non-temporary address and I will look into that. However I'd like to be sure that I'm chasing the right problem. So please: 1/ explain exactly why you think it currently doesn't work - what symptoms are there? 2/ If possible, test with "-o vers=4.1" and see if the symptoms persist. 3/ Also test with "-o clientaddr=......" and see if the symptoms persist. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=986395 http://bugzilla.suse.com/show_bug.cgi?id=986395#c11 --- Comment #11 from Marius Tomaschewski --- (In reply to Neil Brown from comment #9)

But how often? RFC4941 doesn't list a minimum for TEMP_VALID_LIFETIME or TEMP_PREFERRED_LIFETIME, just recommended defaults of 1 week and 1 day. Cycling every 6 hours would probably be safe

IMO, it would not be safe at all. The defaults are veeeery long (and the defaults are similar to e.g. IEEE defaults for bridge STP causing up to 50s delay before forwarding packets or sleep(random(1..10s)) before dhcp4 starts to do anything. In practice, it is probably more common to use e.g. valid lifetime of 1hour. I'd not make any assumption about the times, but read the lifetime from the address. What would be probably doable is to a) prefer to use non-temporary addresses and (if there is none [a clear corner case]) b) start to switch over to a new temporary-address when the preferred lft reached 0 (still usable for existing connections until valid lft goes to 0). The temporary / privacy addresses are assigned additionally to non-temporary. IMO there is currently no autoconf option in the kernel to assign a privacy address only, that is, there is basically always a non-temporary / renewable [e.g. MAC based EUI64] address. When the user is using not using autoconf, but only dhcp6 and assigns only a temp addr, you can IMO assume he knows what he is doing and does not want to use nfs/persistent connections at all or he misconfigured the box. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=986395 http://bugzilla.suse.com/show_bug.cgi?id=986395#c13 --- Comment #13 from Neil Brown --- I've done some experimenting. An NFSv4 TCP connection never goes idle for more than about 5 minutes as it sends a periodic "RENEW" requests, so there is no chance of the clean change-over to the new address happening automatically. I set up temp address to be deprecated after 120 seconds and expired after 500 so I could test things a bit more easily. When the address I used to mount from expired, the client started ignoring replies from the server as expected and this continued for 5.5 minutes without the connection being broken, which is longer than I expected. It should be 3 minutes I think. But then the connection just started working again. The client started using the same temp IP address as before. Is that expected? I'll keep exploring. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=986395 http://bugzilla.suse.com/show_bug.cgi?id=986395#c17 --- Comment #17 from Marius Tomaschewski --- (In reply to Neil Brown from comment #12)

Always requesting a public address is certainly possible but seems to go explicitly against the configuration choice to use temporary private addresses for outgoing connections.

But is the right way to use in nfs client case IMO. While RFC3484 defined, that a public address is preferred over a temporary, RFC 6724 changes the default is to prefer temporary address (-> #section-5 and changes summary in appendix-B), but it is completely fine and _correct_ when the application does not use the defaults due to it's requirements, e.g.: https://tools.ietf.org/html/rfc6724#section-5 Implementations MUST provide a mechanism allowing an application to reverse the sense of this preference and prefer public addresses over temporary addresses (e.g., via appropriate API extensions such as [RFC5014]). Use of the mechanism MUST only affect the selection rules for the invoking application. Even the Privacy Extensions RFC 4941 considers this, e.g. section-3.6: The use of temporary addresses may cause unexpected difficulties with some applications. [...] In addition, some applications may not behave robustly if temporary addresses are used and an address expires before the application has terminated, or if it opens multiple sessions, but expects them to all use the same addresses. section-6: The determination as to whether to use public versus temporary addresses can in some cases only be made by an application. (In reply to Neil Brown from comment #15)

A couple of minutes later it says:

valid_lft 155sec preferred_lft 0sec so it jumped to 0 (and became 'deprecated') rather quickly. ... OK, more weirdness.. My temp address became valid_lft 0sec preferred_lft 14100sec

preferred_lft 0 is deprecated and should not be used for new connections; the kernel is even permitted to remove it _when_ there are no connections using it (. If valid_lft reaches 0 the address is not valid any more and prefered_lft > valid_lft is invalid lifetime. When something (e.g. router RA) contains a valid_lft 0, it is request to remove things (e.g. a prefix not valid any more). Sending prefered_lft 0 is kind of "scheduled removal". Your "valid_lft 0sec preferred_lft 14100sec" could be even be related to all this, but some cleanup code is not implemented properly.

I think I want to say "temporary addresses are obviously buggy, they shouldn't be used.."

:-) There were many changes in this area in 4.2/4.4 kernel. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=986395 Ludwig Nussel changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lnussel@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=986395 http://bugzilla.suse.com/show_bug.cgi?id=986395#c20 --- Comment #20 from Ludwig Nussel --- meanwhile Rudi gave up and changed the default use_tempaddr=1 ... So the problem gets hidden again. I'd suggest to submit the fix anyways -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=986395 Swamp Workflow Management changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|obs:running:5537:moderate | -- You are receiving this mail because: You are on the CC list for the bug.