dlink 2740R - not starting at boot [solved]

[Kieth]

With my new modem, I'm not able to get it to start at boot. In MCC, I've tried different ways to get it to hook up, but each time it says it fails. Strange thing though. Even though it says it fails, it gives me an internet connection. Of course, once I log out, the connection is closed, and I have to go through the ordeal again. I disabled ipv6 in firefox, but it didn't help. The protocol that I have to use is PPPoE (or PPPoA if the previous isn't supported). On another web site, someone mentioned knowing the output of this command:

 

$ lspcidrake

Card:ATI Radeon X1950 and earlier: ATI Technologies Inc|RV280 [Radeon 9200] [DISPLAY_VGA] (rev: 01)

k8temp : Advanced Micro Devices [AMD]|K8 [Athlon64/Opteron] Miscellaneous Control [bRIDGE_HOST]

unknown : Advanced Micro Devices [AMD]|K8 [Athlon64/Opteron] DRAM Controller [bRIDGE_HOST]

unknown : Advanced Micro Devices [AMD]|K8 [Athlon64/Opteron] Address Map [bRIDGE_HOST]

unknown : Advanced Micro Devices [AMD]|K8 [Athlon64/Opteron] HyperTransport Technology Configuration [bRIDGE_HOST]

via_rhine : VIA Technologies, Inc.|VT6102 [Rhine-II] [NETWORK_ETHERNET] (rev: 78)

slamr : VIA Technologies, Inc.|AC'97 Modem Controller [COMMUNICATION_OTHER] (rev: 80)

snd_via82xx : VIA Technologies, Inc.|VT8233/A/8235/8237 AC97 Audio Controller [MULTIMEDIA_AUDIO] (rev: 60)

i2c_viapro : VIA Technologies, Inc.|VT8237 ISA bridge [KT600/K8T800/K8T890 South] [bRIDGE_ISA]

ehci_hcd : VIA Technologies, Inc.|USB 2.0 [sERIAL_USB] (rev: 86)

uhci_hcd : VIA Technologies, Inc.|VT82xxxxx UHCI USB 1.1 Controller [sERIAL_USB] (rev: 81)

uhci_hcd : VIA Technologies, Inc.|VT82xxxxx UHCI USB 1.1 Controller [sERIAL_USB] (rev: 81)

uhci_hcd : VIA Technologies, Inc.|VT82xxxxx UHCI USB 1.1 Controller [sERIAL_USB] (rev: 81)

uhci_hcd : VIA Technologies, Inc.|VT82xxxxx UHCI USB 1.1 Controller [sERIAL_USB] (rev: 81)

pata_via : VIA Technologies, Inc.|VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [sTORAGE_IDE] (rev: 06)

sata_via : VIA Technologies, Inc.|VIA VT6420 SATA RAID Controller [sTORAGE_RAID] (rev: 80)

saa7134 : Philips Semiconductors|SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [MULTIMEDIA_OTHER] (rev: f0)

shpchp : VIA Technologies, Inc.|VT8237 PCI bridge [K8T800/K8T890 South] [bRIDGE_PCI]

unknown : VIA Technologies, Inc.|VT8385 [K8T800 AGP] Host Bridge [bRIDGE_HOST] (rev: 01)

 

and this command:

 

# ifup eth0

 

Determining IP information for eth0...PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

 

--- 192.168.1.1 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 1.196/1.196/1.196/0.000 ms

done.

 

When I ran the above command, it killed my internet service, and I had to run MCC again to get it up. Of course, as I said, MCC said there were problems, but it still gave me internet service. Here's what it said (and always says):

 

Problems occured during the network connectivity test.

 

This can be caused by invalid network configuration, or problems with your modem or router.

 

You might want to relaunch the configuration to verify the connection settings.

 

Any ideas on how to resolve the problem?

 

Thanks,

Kieth

Edited October 17, 2011 by Kieth

[ianw1974]

First of all, PPPoE and PPPoA are completely different. You will have to use the exact one as per your internet service provider. If your connection is via PPP over ATM then you need to use PPPoA. If it's PPP over Ethernet, then you need to use PPPoE. Please configure this exactly how it should be for your connection first of all. You mentioned you use one or the other, so I need to make sure you're using the correct one - as I wasn't able to ascertain why you mentioned using one or the other?

 

Are you using Mandriva to initiate your connection with PPPoA or PPPoE? If so, are you sure you really need to do this? This modem should have the ability to connect to the internet itself. I would then just configure Mandriva to use a standard ethernet connection. There is no need to do bridging for your ethernet connection if this is what you are doing? If so, change it, so that the router manages the connection, and you just have the modem giving you a DHCP address to each computer connected by the four ethernet ports, or via wireless.

 

I'm expecting some mis-configuration on the router. Either that it's not giving a DHCP address to the machine, or that it's not responding in a certain amount of time, or that MCC is giving you false information with the errors - it certainly sounds that way as you are able to connect to the internet without any problems. Most likely instability with Mandriva.

[Kieth]

Thanks, got it. Your explanation helped me find the problem. I had previously setup Mandriva to use the standard Ethernet connection only, but it still wouldn't work. I just had to mark the box "Allow users to manage the connection".

 

Thanks,

Kieth

[ianw1974]

Providing the router was powered on when you turned on the Mandriva machine, it should have worked and obtained the IP address. Ticking the box for allowing users to manage, just lets them bring the connection up and down without root privileges. Had you renewed the connection as root, chances are it should have worked also :)

 

This could be easily checked if you really wanted to. First check that /etc/sysconfig/network-scripts/ifcfg-eth0 is set to use DHCP - it should be if that is how you configured the ethernet connection. Secondly, you could then go into MCC and disable the option allowing users to manage the connection. This will revert it back to how it was before.

 

Next, to find out where the problem is, from a console su to root and provide your root password when asked. Then do:

 

ps aux | grep -i dhcp

 

this should list something with dhcpcd or dhclient pointing to eth0. You can then kill this process, because running dhcpcd or dhclient again on this connection would cause some issues. This can be killed with:

 

killall dhcpcd
killall dhclient

 

depending on which one is in use. It could even be something else. But you can post here with the results from the ps aux and we can verify. Then to bring up the connection:

 

dhcpcd eth0
dhclient eth0

 

again, depending on results from ps aux. Or, if you want to use the parameters from /etc/sysconfig/network-scripts/ifcfg-eth0, then:

 

ifup eth0

 

should run dhcp and start the interface. As you were doing this normally before, it would be better to just run the dhcp commands to rule out some Mandriva mis-configuration with ifcfg-eth0. Alternatively, you can just forget about it as you now have it solved :) but I thought for completeness, I'd provide extra steps for you to check it and find out exactly where the problem was.

[Kieth]

Thanks for the info and help and clarifications. I think I fixed up everything the "right" way!! :)

 

Let me see, this was the content to /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0

BOOTPROTO=dhcp

ONBOOT=yes

METRIC=10

MII_NOT_SUPPORTED=no

USERCTL=yes

RESOLV_MODS=no

IPV6INIT=no

IPV6TO4INIT=no

ACCOUNTING=yes

NM_CONTROLLED=yes

DHCP_CLIENT=dhclient

NEEDHOSTNAME=no

PEERDNS=yes

PEERYP=yes

PEERNTPD=no

 

I went into MCC, and unchecked the box to allow users to manage the connection.

 

And this wass the result of ps aux | grep -i dhcp

# ps aux | grep -i dhcp

root 1706 0.0 0.0 5248 1012 ? S 02:19 0:00 /sbin/dhsr/lib/nm-dhcp-client.action -pf /var/run/dhclient-eth0.pid -lf /var/lib/bd0-0bb0-7ffb-45f1-d6edd65f3e03-eth0.lease -cf /var/run/nm-dhclient-eth0.

root 16822 0.0 0.0 5788 776 pts/1 S+ 12:49 0:00 grep --c

 

Next, I ran the kill commands.

 

# killall dhcpcd

dhcpcd: no process found

[root@localhost ~]# killall dhclient

[root@localhost ~]#

 

I brought up the connection with

 

# dhclient eth0

[root@localhost ~]#

 

Lastly, I used this command:

 

# ifup eth0

/sbin/ifup: interface eth0 is controlled by NetworkManager; skipping.

 

I rebooted, and I have Internet service! :)

 

Thanks again.

Kieth

[ianw1974]

Looks like you have Network Manager managing your ethernet connection, and so that is why you got that error that it passed the ifup command.

 

Anyway, if you've ran dhclient eth0, you don't need to do ifup eth0. Because the interface should already then be active.

 

ps aux | grep -i nm-applet

 

should show if Mandriva is using the Network Manager applet. And also:

 

ps aux | grep -i network

 

to see if network manager is starting at boot. We can also see:

 

chkconfig --list | grep :on

 

which should show the services that are enabled at boot, one of them is probably network manager. If network-manager is doing it, then you should just be able to click the network manager applet by the clock and then selecting the eth0 connection will automatically give it an address anyway, or refresh it if you lost the link. This usually works fine for me, it seems now they have got ridden of the crappy MandrivaNetwork program which was always being used to control the network, and network manager is far superior and less buggy than this was.

 

Finally, I'm glad if Mandriva has decided to move to network manager, because this was one thing I hated about Mandriva. You couldn't even switch to network manager without a host of problems, so I'm happy to see them dropping that program finally.

[Kieth]

A few minutes ago I didn't have internet, so I called my server provider to complain. He asked me to check the modem, and it was "blinking" (therefore communicating). So then he asked me to go to WXP, and sure enough, there was internet service. He had me do some checking (command pcconfig? and then ping my gateway). All was OK. I then rebooted to Mandy, and I have internet. So something isn't quit right. Here are the commands you mentioned.

 

root@localhost ~]# ps aux | grep -i nm-applet

root 7129 0.0 0.0 5784 776 pts/1 S+ 18:09 0:00 grep --color -i nm-applet

 

root@localhost ~]# ps aux | grep -i network

root 1484 0.0 0.5 29980 5316 ? Ssl 17:06 0:00 /usr/sbin/NetworkManager --no-daemon

root 7136 0.0 0.0 5788 776 pts/1 S+ 18:10 0:00 grep --color -i network

 

root@localhost ~]# chkconfig --list | grep :on

 

Note: This output shows SysV services only and does not include native

systemd services. SysV configuration data might be overriden by native

systemd configuration.

 

alsa 0:off 1:off 2:on 3:on 4:on 5:on 6:off 7:off

crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off 7:on

cups 0:off 1:off 2:on 3:on 4:on 5:on 6:off 7:off

dm 0:off 1:off 2:off 3:off 4:off 5:on 6:off 7:on

haldaemon 0:off 1:off 2:on 3:on 4:on 5:on 6:off 7:on

messagebus 0:off 1:off 2:on 3:on 4:on 5:on 6:off 7:on

partmon 0:off 1:off 2:on 3:on 4:on 5:on 6:off 7:on

portreserve 0:off 1:off 2:on 3:on 4:on 5:on 6:off 7:off

pppoe 0:off 1:off 2:on 3:on 4:on 5:on 6:off 7:off

preload 0:off 1:off 2:off 3:off 4:off 5:on 6:off 7:off

rsyslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off 7:on

slmodemd 0:off 1:off 2:off 3:on 4:on 5:on 6:off 7:off

sound 0:off 1:off 2:on 3:on 4:on 5:on 6:off 7:off

udev-post 0:off 1:on 2:on 3:on 4:on 5:on 6:off 7:off

 

Here is the contents of ifcfg-eth0 again.

 

DEVICE=eth0

BOOTPROTO=dhcp

ONBOOT=yes

METRIC=10

MII_NOT_SUPPORTED=no

USERCTL=no

RESOLV_MODS=no

IPV6INIT=no

IPV6TO4INIT=no

ACCOUNTING=yes

NM_CONTROLLED=yes

DHCP_CLIENT=dhclient

NEEDHOSTNAME=no

PEERDNS=yes

PEERYP=yes

PEERNTPD=no

 

Here is the present results of one command, again.

 

[root@localhost ~]# ps aux | grep -i dhcp

root 1715 0.0 0.0 5248 572 ? S 17:06 0:00 /sbin/dhclient -d -4 -sf /usr/lib/nm-dhcp-client.action -pf /var/run/dhclient-eth0.pid -lf /var/lib/dhcp/dhclient-5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03-eth0.lease -cf /var/run/nm-dhclient-eth0.conf eth0

root 7328 0.0 0.0 5788 776 pts/1 S+ 18:22 0:00 grep --color -i dhcp

 

How's it look?

 

Thanks bunches,

Kieth

[ianw1974]

OK, so they're not using nm-applet, but they have it bound with network-manager. I can see that NetworkManager daemon is running and the ifcfg-eth0 is controlling it. Seems a bit of a weird implementation to me, but then it is Mandriva so anything is possible :)

 

An:

 

ifconfig eth0

 

should at least then show the IP address that eth0 has which was provided by dhclient. Also:

 

route -n

 

will show the default gateway which should be the address of your router. When internet stops working, run these two commands to see how it looks. We can ascertain if you have connectivity by the ifconfig meaning you have an IP, and the route command to see if it knows to go to your DSL router. You can then try pinging the router (maybe 192.168.1.1) depending on how you configured it. And then pinging 8.8.8.8 which is a google DNS server, which should reply if the ifconfig and route commands show the information we're looking for.

[Kieth]

:) Thanks for the info. When it goes down, I'll run the commands. In the meantime, here is the result of those 2 commands.

 

[root@localhost ~]# ifconfig eth0

eth0 Link encap:Ethernet HWaddr 00:13:D4:8C:3A:57

inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0

inet6 addr: fe80::213:d4ff:fe8c:3a57/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:299659 errors:0 dropped:0 overruns:0 frame:0

TX packets:508361 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:155298212 (148.1 MiB) TX bytes:98867359 (94.2 MiB)

Interrupt:23 Base address:0xa000

 

[root@localhost ~]# route -n

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0

 

I pinged 198.168.0.1 (like the guy had me do on WXP) and 8.8.8.8, but they never stop! I let it go up to 100 pings, then hit alt-f4, which killed console. How do I make it stop?

 

Thanks again.

Kieth

[ianw1974]

CTRL-C can stop the ping. If it's replying then that means you have connectivity. But when you lose your internet connection, check with ifconfig, the route command to see if you the 0.0.0.0 192.168.0.1 line, and see if it replies when you ping the router, and also the google address I gave you.

[Kieth]

:D OK, Thanks! Hopefully I won't loose my connection B) , but when and if I do, I'll use the commands you gave. Thanks again,

Kieth

[Greg2]

Kieth

You can also use the -c (count) option with ping, i. e.

ping -c 5

will transmit 5 packets and stop.

[ianw1974]

Hehe, forgot about that option ;)

[Kieth]

Gotcha! ping -c 5!

[Kieth]

OK, it went down, and this is the results of the commands you gave me.

 

[root@localhost ~]# ifconfig eth0

eth0 Link encap:Ethernet HWaddr 00:13:D4:8C:3A:57

inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0

inet6 addr: fe80::213:d4ff:fe8c:3a57/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:1210973 errors:0 dropped:0 overruns:0 frame:0

TX packets:1716557 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:648721949 (618.6 MiB) TX bytes:459733379 (438.4 MiB)

Interrupt:23 Base address:0xa000

 

[root@localhost ~]# route -n

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0

[root@localhost ~]# ping -c 5 192.168.0.1

connect: No buffer space available

[root@localhost ~]# ping 192.168.0.1

connect: No buffer space available

[root@localhost ~]# ping -c 5 8.8.8.8

connect: No buffer space available

[root@localhost ~]# ping 8.8.8.8

connect: No buffer space available

 

Ideas?

Thanks,

Kieth