Bug 980274

It could be multiple reasons. One think that comes to my mind is your network configuration. Can you describe your setup?
I think there could be a problem if you are connected to a Wi-Fi router both via cable and Wi-Fi with the same computer.

Would you get some info and logs from your system, when both wired and wireless connections are active?

$ route -n
$ ip a
$ nmcli dev
* /var/log/messages log
* output of dmesg command

Created attachment 772530 [details]
dmsg - 130711

dmseg output

Created attachment 772531 [details]
messages - 130711

/var/log/messages output

(In reply to Jirka Klimes from comment #1)
> It could be multiple reasons. One think that comes to my mind is your
> network configuration. Can you describe your setup?
> I think there could be a problem if you are connected to a Wi-Fi router both
> via cable and Wi-Fi with the same computer.
> 
> Would you get some info and logs from your system, when both wired and
> wireless connections are active?
> 
> $ route -n
> $ ip a
> $ nmcli dev
> * /var/log/messages log
> * output of dmesg command

Hi there,

I do have a wireless router and have the laptop connected via wireless and wired connection; when I'm away from my desk I use the wifi but then put the laptop on a dock when I'm back.

The output from the commands are below (I have added the outputs as attachements):

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 em1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 em1

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:21:cc:ce:bc:8e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.105/24 brd 192.168.1.255 scope global em1
       valid_lft forever preferred_lft forever
    inet6 fe80::221:ccff:fece:bc8e/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether e0:06:e6:c5:a6:85 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.103/24 brd 192.168.1.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::e206:e6ff:fec5:a685/64 scope link 
       valid_lft forever preferred_lft forever

DEVICE     TYPE              STATE        
wlan0      802-11-wireless   connected    
em1        802-3-ethernet    connected

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 
'version' of '18'.

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 prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 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 to Fedora 18's end of life.

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.

The problem here is that NetworkManager (again) adds every route with the same Metric!

Problem was solved in Fedora 19 and "unfixed" with the redesign of NM in Fedora 20.

So I have the same Problem here.
If you connect the cable the traffic is not rerouted to the wired NIC because of the same Metric.

[zippi@garm ~]$ route
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         192.168.15.254  0.0.0.0         UG    1024   0        0 eth0
192.168.15.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.15.0    0.0.0.0         255.255.255.0   U     0      0        0 wlan0

When you connect the wireless first the last 2 entries will swap and wireless will remain the "active" connection for all data the the network 192.168.15.0/24.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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.