PDA

View Full Version : No network by default?


chrismurphy
24th March 2012, 10:38 PM
Fedora-17-Beta-x86_64-Live-Desktop.iso

No network connection by default with the LiveCD. Or after installation and rebooting, either on actual hardware or in a VM. ifconfig reports:

[chris@f17s ~]$ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

p5p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::21e:c2ff:fe1d:507e prefixlen 64 scopeid 0x20<link>
ether 00:1e:c2:1d:50:7e txqueuelen 1000 (Ethernet)
RX packets 84 bytes 10408 (10.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3 bytes 258 (258.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 17


If I go to Network Connections, click on "System p2p1", played around a bit and couldn't get anything to work. So I deleted "System p2p1" and created a new entry. Now I have a network connection.

ifo[chris@f17v ~]$ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.143 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::a00:27ff:fe85:6249 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:85:62:49 txqueuelen 1000 (Ethernet)
RX packets 357 bytes 56301 (54.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 71 bytes 9002 (8.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

DBelton
25th March 2012, 04:03 AM
something definitely got messed up. Even the MAC address is different. Do you by chance have 2 network adapters in that machine, but only one of them connected to the network?

stevea
25th March 2012, 04:48 AM

something definitely got messed up. Even the MAC address is different. Do you by chance have 2 network adapters in that machine, but only one of them connected to the network?

The first MAC addr is for an Apple product - and that's sort of critical to the problem. The second (working) MAC is for a cadmus products - but that MAC range is use by VirtualBox. So the two are not comparable.

It would be useful to see if Chris can stop NM, assign an IP address, mask and route and get the interface working.

My HUNCH is that it's some thing is wrong in th eNM dhclient.
If it's repeatable on real hardware - then it needs a bugzilla.
You should NEVER bugzilla a VBox problem - as it's not supported and has known problems.

DBelton
25th March 2012, 04:54 AM
You should NEVER bugzilla a VBox problem - as it's not supported and has known problems.

Not to mention getting cussed out by the kernel people for filing a bug while running vbox. :lol:

chrismurphy
25th March 2012, 08:33 AM
The first MAC addr is for an Apple product - and that's sort of critical to the problem. The second (working) MAC is for a cadmus products - but that MAC range is use by VirtualBox. So the two are not comparable.

It was just easier to copy paste. Other than the MAC addy the behaviors were the same. And the VM is on a different computer which does not exhibit the problem when it's booted off the same LiveCD natively.

It would be useful to see if Chris can stop NM, assign an IP address, mask and route and get the interface working.

So go to Services, stop network manager, and just restart it, or what? Because the above description isn't as easy as just deleting and creating a new connection - which does work.


My HUNCH is that it's some thing is wrong in th eNM dhclient.
If it's repeatable on real hardware - then it needs a bugzilla.

Is that hardware specific? It's a little odd that it's repeatable on Hardware A. Not repeatable on Hardware B. But repeatable in VM on Hardware B. Sounds like it could be enet driver related. The naming convention used between all three, for the enet interface, is also different. This p2p1 thing is kinda goofy UI.

chrismurphy
26th March 2012, 03:48 AM
*sigh*

Well never mind, for now, because it's not (consistently) reproducible.

stevea
26th March 2012, 10:13 PM
Hmmm ...

Chris ...
My suggestion would be to ...
systemctl stop NetworkManager.service
dhclient -i p2p1 (or whatever the interface name).

If that works then it points to NetworkManager.

You might also try setting the ip, mask, route manually like ....

ip addr add 192.168.1.77/24 dev p2p1
ip route add default default via 192.168.1.1 dev p2p1 proto static

Fill in your addresses and router adr. Then see if you can ping the router and
4.2.2.1. You can't resolve names without setting up a resolv.conf file
t