The 4.2.y kernel is rather old on F23 at this point.  It has already been rebased to 4.4.2.  Does this problem happen on the latest 4.4.2 kernel available?

@Josh Boyer:

It still fails on "Linux d33tah-pc 4.3.5-300.fc23.x86_64 #1 SMP Mon Feb 1 03:18:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux". This is the latest available in my F23 repo.

Still happens on 4.4.x kernels.

Possible duplicates: bug #1282254 and bug #1289499

There was no change in the r8169.c on kernel upstream, if you diff the git logs:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/net/ethernet/realtek/r8169.c?h=v4.2.6
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/net/ethernet/realtek/r8169.c?h=v4.2.3

No directly related changes in fedora kernel git either. Seems like something outside r8169.c broke it.

It still happens in Fedora 24 with kernel 4.6.4-301.fc24.x86_64.
After resuming the driver reports link down, even ethtool reports link down.
Unloading and reloading r8168 module makes link up again.

*********** MASS BUG UPDATE **************
 
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs.
 
Fedora 23 has now been rebased to 4.7.4-100.fc23.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25.
 
If you experience different issues, please open a new bug report for those.

NetworkManager still shows connection problems after suspend, but I haven't managed to reproduce a connection loss on suspend by trying 4 times. I disabled my workaround and will report back in case the issue is happening again.

Running kernel-4.7.4-200.fc24.x86_64

(In reply to Christian Stadelmann from comment #7)
> NetworkManager still shows connection problems after suspend, but I haven't
> managed to reproduce a connection loss on suspend by trying 4 times. I
> disabled my workaround and will report back in case the issue is happening
> again.
> 
> Running kernel-4.7.4-200.fc24.x86_64

After a week of running without my previous workaround the issue stays the same: Network connection doesn't drop any more, but NetworkManager still shows a question mark on its gnome-shell icon.

With kernel 4.7.4-200.fc24.x86_64 this problem seems solved to me.

Today I had this problem once again with kernel 4.8.4-200.fc24.x86_64.

dmesg:
[11828.743479] wlp7s0: deauthenticating from 08:17:35:9c:b8:32 by local choice (Reason: 3=DEAUTH_LEAVING)
[11830.605427] PM: Syncing filesystems ... done.
[11831.320986] PM: Preparing system for sleep (mem)
[11831.321261] Freezing user space processes ... (elapsed 0.002 seconds) done.
[11831.323706] Double checking all user space processes after OOM killer disable... (elapsed 0.000 seconds) 
[11831.323885] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[11831.325307] PM: Suspending system (mem)
[11831.325407] Suspending console(s) (use no_console_suspend to debug)
[11831.325834] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[11831.412677] sd 0:0:0:0: [sda] Stopping disk
[11831.799927] PM: suspend of devices complete after 474.375 msecs
[11831.812778] PM: late suspend of devices complete after 12.839 msecs
[11831.814104] r8169 0000:13:00.0: System wakeup enabled by ACPI
[11831.814275] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI
[11831.814405] ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI
[11831.825790] PM: noirq suspend of devices complete after 13.007 msecs
[11831.826232] ACPI: Preparing to enter system sleep state S3
[11831.845758] ACPI : EC: EC stopped
[11831.845759] PM: Saving platform NVS memory
[11831.846652] Disabling non-boot CPUs ...
[11831.848834] smpboot: CPU 1 is now offline
[11831.850695] smpboot: CPU 2 is now offline
[11831.852482] smpboot: CPU 3 is now offline
[11831.854226] ACPI: Low-level resume complete
[11831.854287] ACPI : EC: EC started
[11831.854288] PM: Restoring platform NVS memory
[11831.855494] Enabling non-boot CPUs ...
[11831.855532] x86: Booting SMP configuration:
[11831.855533] smpboot: Booting Node 0 Processor 1 APIC 0x1
[11831.858008]  cache: parent cpu1 should not be sleeping
[11831.858446] CPU1 is up
[11831.858507] smpboot: Booting Node 0 Processor 2 APIC 0x2
[11831.861760]  cache: parent cpu2 should not be sleeping
[11831.862210] CPU2 is up
[11831.862251] smpboot: Booting Node 0 Processor 3 APIC 0x3
[11831.865201]  cache: parent cpu3 should not be sleeping
[11831.865681] CPU3 is up
[11831.873937] ACPI: Waking up from system sleep state S3
[11831.897163] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
[11831.897650] ehci-pci 0000:00:1a.0: System wakeup disabled by ACPI
[11831.897732] PM: noirq resume of devices complete after 13.357 msecs
[11831.898055] PM: early resume of devices complete after 0.297 msecs
[11831.898511] r8169 0000:13:00.0: System wakeup disabled by ACPI
[11831.899434] ath: phy0: ASPM enabled: 0x43
[11831.908570] sd 0:0:0:0: [sda] Starting disk
[11832.029575] r8169 0000:13:00.0 enp19s0: link down
[11832.120376] usb 1-1.5: reset full-speed USB device number 5 using ehci-pci
[11832.177681] rtc_cmos 00:01: System wakeup disabled by ACPI
[11832.198677] usb 1-1.5: device firmware changed
[11832.199199] PM: resume of devices complete after 301.151 msecs
[11832.199530] PM: Finishing wakeup.
[11832.199532] Restarting tasks ... 
[11832.207570] usb 1-1.5: USB disconnect, device number 5
[11832.210301] done.
[11832.226371] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[11832.245956] ata4.00: configured for UDMA/66
[11832.279331] usb 1-1.5: new full-speed USB device number 6 using ehci-pci
[11832.358204] usb 1-1.5: New USB device found, idVendor=0489, idProduct=e027
[11832.358211] usb 1-1.5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[11832.668182] usb 1-1.5: USB disconnect, device number 6
[11833.352313] usb 1-1.5: new full-speed USB device number 7 using ehci-pci
[11833.431741] usb 1-1.5: New USB device found, idVendor=0cf3, idProduct=3005
[11833.431748] usb 1-1.5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[11833.503967] video LNXVIDEO:01: Restoring backlight state
[11834.535570] i8042: Can't write CTR while closing AUX port
[11834.849230] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[11834.873884] ata1.00: configured for UDMA/133
[11835.061405] i8042: Can't reactivate AUX port
[11835.495124] IPv6: ADDRCONF(NETDEV_UP): enp19s0: link is not ready
[11835.625261] r8169 0000:13:00.0 enp19s0: link down
[11835.625341] IPv6: ADDRCONF(NETDEV_UP): enp19s0: link is not ready
[11835.626622] IPv6: ADDRCONF(NETDEV_UP): wlp7s0: link is not ready
[11835.646703] IPv6: ADDRCONF(NETDEV_UP): wlp7s0: link is not ready
[11835.690577] IPv6: ADDRCONF(NETDEV_UP): wlp7s0: link is not ready
[11836.474269] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input15
[11837.613049] wlp7s0: authenticate with 08:17:35:9c:b8:32
[11837.631382] wlp7s0: send auth to 08:17:35:9c:b8:32 (try 1/3)
[11837.632840] wlp7s0: authenticated
[11837.634631] wlp7s0: associate with 08:17:35:9c:b8:32 (try 1/3)
[11837.637739] wlp7s0: RX AssocResp from 08:17:35:9c:b8:32 (capab=0x431 status=0 aid=96)
[11837.637893] wlp7s0: associated
[11837.637968] IPv6: ADDRCONF(NETDEV_CHANGE): wlp7s0: link becomes ready
[11837.645921] ath: EEPROM regdomain: 0x817c
[11837.645924] ath: EEPROM indicates we should expect a country code
[11837.645926] ath: doing EEPROM country->regdmn map search
[11837.645927] ath: country maps to regdmn code: 0x37
[11837.645929] ath: Country alpha2 being used: IT
[11837.645930] ath: Regpair used: 0x37
[11837.645932] ath: regdomain 0x817c dynamically updated by country IE
[11837.692952] wlp7s0: Limiting TX power to 17 dBm as advertised by 08:17:35:9c:b8:32
[11838.148302] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input17

I don't remember this from February, but this has happened to me three times in the last two days after upgrading to 4.8, too.  My log looks pretty similar.

F24, btw.

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This issue is still present on Fedora 27 and Fedora 28. See bug 1574334. Should this bug be reopened or cloned? Or should bug 1574334 be used to track this for F28?