| View previous topic :: View next topic |
| Author |
Message |
BlueByte
Tux's lil' helper
Joined: 08 Apr 2004
Posts: 87
|
 Posted: Sat Oct 22, 2005 12:20 pm Post subject: Connection works only after manual command |
 |
|
Sometimes when I boot to gentoo my internet connection doesn't work, altough this is what gentoo prints
| Code: | * Starting eth0
* Bringing up eth0
* dhcp
* Running dhcpcd ... [ ok ]
* eth0 received address 85.77.1.42
* Mounting network filesystems ... [ ok ]
|
I have to do
| Code: | paula fuzzybyte # /etc/init.d/net.eth0 restart
* Unmounting network filesystems ... [ ok ]
* Stopping eth0
* Bringing down eth0
* Stopping dhcpcd on eth0 ... [ ok ]
* Shutting down eth0 ... [ ok ]
* Starting eth0
* Bringing up eth0
* dhcp
* Running dhcpcd ... [ ok ]
* eth0 received address 85.77.1.42
* Mounting network filesystems ... [ ok ]
|
about 1-2 times before connection works again! What is causing this?
ifconfig
| Code: | eth0 Link encap:Ethernet HWaddr 00:01:29:FC:4C:9F
inet addr:85.77.1.42 Bcast:85.77.1.255 Mask:255.255.254.0
inet6 addr: fe80::201:29ff:fefc:4c9f/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:561 errors:0 dropped:0 overruns:0 frame:0
TX packets:574 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:378620 (369.7 Kb) TX bytes:101915 (99.5 Kb)
Interrupt:20 Base address:0xa000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:300 (300.0 b) TX bytes:300 (300.0 b)
|
/etc/conf.d/net
| Code: | config_eth0=( "dhcp" )
iface_eth0=("dhcp")
|
I got dfi lanparty ut sli-d nforce4 with two ethernet cards nforce one (vitesse?) and marvell yukon. the problem exist with both of them. help  |
|
| Back to top |
|
 |
BlueByte
Tux's lil' helper
Joined: 08 Apr 2004
Posts: 87
|
| Posted: Sun Oct 23, 2005 8:06 pm Post subject: |
|
|
help! I can't solve this  |
|
| Back to top |
|
|
Galabriel
n00b
Joined: 25 Jan 2005
Posts: 64
Location: Südtirol / Italien
|
| Posted: Sun Oct 23, 2005 8:13 pm Post subject: |
|
|
try rc-update eth.0 default del
and then rc-update eth.0 default add
_________________
Was ist der unterschied zwischen Batman und Bill Gates?
Batman konnte den Pinguin besiegen;) |
|
| Back to top |
|
|
Cintra
Advocate
Joined: 03 Apr 2004
Posts: 2111
Location: Norway
|
| Posted: Mon Oct 24, 2005 6:28 am Post subject: |
|
|
I think you can remove
| Code: |
iface_eth0=("dhcp")
|
from /etc/conf.d/net. its enough for me with
| Code: |
config_eth0=( "dhcp" )
|
have you done | Code: |
rc-update add net.eth0 boot |
'rc-status -a' will show you
mvh
_________________
"I am not bound to please thee with my answers" W.S. |
|
| Back to top |
|
|
BlueByte
Tux's lil' helper
Joined: 08 Apr 2004
Posts: 87
|
| Posted: Mon Oct 24, 2005 5:52 pm Post subject: |
|
|
| Well thanks, but that didn't solve my problem |
|
| Back to top |
|
|
pointers
Tux's lil' helper
Joined: 18 Apr 2004
Posts: 123
|
| Posted: Tue Oct 25, 2005 6:29 am Post subject: debugging |
|
|
Hi,
to debug the problem, after booting issue the command
| Code: | #route -n[quote]
look at the default gateway and ping your gateway to learn you reach your local network or not.
Then restart network script and issue the same "route -n" command and compare the outputs for different patterns.
[/quote] |
|
|
| Back to top |
|
|
BlueByte
Tux's lil' helper
Joined: 08 Apr 2004
Posts: 87
|
| Posted: Tue Oct 25, 2005 11:00 pm Post subject: |
|
|
this is what i get with route -n (it's the same with network working or not working)
| Code: | 85.77.0.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo
0.0.0.0 85.77.0.1 0.0.0.0 UG 0 0 0 eth0 |
|
|
| Back to top |
|
|
pointers
Tux's lil' helper
Joined: 18 Apr 2004
Posts: 123
|
| Posted: Wed Oct 26, 2005 6:37 am Post subject: debugging |
|
|
Hi,
it is hard from here to guess the problem but you can use "tcpdump" software for debugging.
1)
After first initial booting (without restarting network script again)
ping your default gateway. In your setup, your gateway is 85.77.0.1
2)
Then look at the arp table to learn that there is no problem with arp mechanism.
if you have an entry for your gateway's IP it is good.
3) For final step ping your gateway in one secreen and run tcpdump command as below;
| Code: | | #tcpdump -n host 85.77.0.1 |
You can send all of these outputs for debugging.
PS: You should also do all these steps after restarting networking script.
Kind Regards. |
|
| Back to top |
|
|
DivideByZero
n00b
Joined: 04 Oct 2004
Posts: 3
|
| Posted: Thu Oct 27, 2005 9:42 pm Post subject: |
|
|
I just resolved a similar problem with one of my print/fileserver boxes. Inet just wouldn't start up on boot making most of the services (samba cupsd sshd ntpd...) inaccessable. Interestingly netatalk continued to work. I had to do the "/etc/init.d/net.eth0 restart" mantra after every reboot to fix it temporarily. A bit iffy since it's a headless box... 
The problem started sometime in august after my last emerge -u world (which doesn't happen very often on this box for a certain reason...) For me, the solution was changing the RC_PARALLEL_STARTUP="yes" to "no" in /etc/conf.d/rc .
But I guess I get what I deserve since most of the hw is crap (K5 cpu @ 150 MHz)!!! 
I guess it's just not fast enough for inet to start up before other services need it... |
|
| Back to top |
|
|
BlueByte
Tux's lil' helper
Joined: 08 Apr 2004
Posts: 87
|
| Posted: Sat Oct 29, 2005 7:55 pm Post subject: |
|
|
Here is what i get without restarting (network doesn't work)
| Code: | # ping 85.77.0.1
PING 85.77.0.1 (85.77.0.1) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Host Unreachable
From 192.168.1.1 icmp_seq=2 Destination Host Unreachable
From 192.168.1.1 icmp_seq=3 Destination Host Unreachable
From 192.168.1.1 icmp_seq=4 Destination Host Unreachable
From 192.168.1.1 icmp_seq=5 Destination Host Unreachable
From 192.168.1.1 icmp_seq=6 Destination Host Unreachable
From 192.168.1.1 icmp_seq=7 Destination Host Unreachable
From 192.168.1.1 icmp_seq=8 Destination Host Unreachable
From 192.168.1.1 icmp_seq=9 Destination Host Unreachable
From 192.168.1.1 icmp_seq=10 Destination Host Unreachable
From 192.168.1.1 icmp_seq=11 Destination Host Unreachable
From 192.168.1.1 icmp_seq=12 Destination Host Unreachable
--- 85.77.0.1 ping statistics ---
12 packets transmitted, 0 received, +12 errors, 100% packet loss, time 11002ms
----
# arp -n
Address HWtype HWaddress Flags Mask Iface
85.77.0.1 ether 00:A0:C5:9B:4E:8A C eth0
---
# tcpdump -n host 85.77.0.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
22:54:35.686364 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 12
22:54:36.686363 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 13
22:54:37.687122 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 14
22:54:38.686966 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 15
22:54:39.686773 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 16
22:54:40.686612 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 17
22:54:41.686456 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 18
22:54:42.686282 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 19
8 packets captured
16 packets received by filter
0 packets dropped by kernel
|
here is after restarting
| Code: | # ping 85.77.0.1
PING 85.77.0.1 (85.77.0.1) 56(84) bytes of data.
64 bytes from 85.77.0.1: icmp_seq=1 ttl=255 time=237 ms
64 bytes from 85.77.0.1: icmp_seq=2 ttl=255 time=17.4 ms
64 bytes from 85.77.0.1: icmp_seq=3 ttl=255 time=5.68 ms
64 bytes from 85.77.0.1: icmp_seq=4 ttl=255 time=5.69 ms
64 bytes from 85.77.0.1: icmp_seq=5 ttl=255 time=53.2 ms
64 bytes from 85.77.0.1: icmp_seq=6 ttl=255 time=92.2 ms
64 bytes from 85.77.0.1: icmp_seq=7 ttl=255 time=8.21 ms
64 bytes from 85.77.0.1: icmp_seq=8 ttl=255 time=36.5 ms
64 bytes from 85.77.0.1: icmp_seq=9 ttl=255 time=17.7 ms
--- 85.77.0.1 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8006ms
rtt min/avg/max/mdev = 5.683/52.711/237.606/70.613 ms
----
# arp -n
Address HWtype HWaddress Flags Mask Iface
85.77.0.1 ether 00:12:D9:9A:B6:C2 C eth0
---
# tcpdump -n host 85.77.0.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
22:43:49.590592 arp who-has 85.77.0.1 tell 85.77.1.42
22:43:49.590929 arp reply 85.77.0.1 is-at 00:a0:c5:9b:4e:8a
22:44:38.118179 arp who-has 85.77.0.1 tell 85.77.1.42
22:44:39.118028 arp who-has 85.77.0.1 tell 85.77.1.42
22:44:40.117876 arp who-has 85.77.0.1 tell 85.77.1.42
22:44:40.118360 arp reply 85.77.0.1 is-at 00:a0:c5:9b:4e:8a
22:45:09.535095 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 1
22:45:10.536262 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 2
22:45:11.536111 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 3
22:45:12.536957 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 4
22:45:13.536806 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 5
22:45:14.536653 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 6
22:45:15.536501 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 7
22:45:16.537349 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 8
22:45:17.537198 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 9
22:45:18.537045 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 10
22:45:19.536894 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 11
22:45:20.537742 IP 85.77.1.42 > 85.77.0.1: icmp 64: echo request seq 12
22:45:25.536970 arp who-has 85.77.0.1 tell 85.77.1.42
22:45:26.536818 arp who-has 85.77.0.1 tell 85.77.1.42
22:45:27.536666 arp who-has 85.77.0.1 tell 85.77.1.42
22:45:27.537048 arp reply 85.77.0.1 is-at 00:a0:c5:9b:4e:8a
22 packets captured
44 packets received by filter
0 packets dropped by kernel
|
| DivideByZero wrote: | The problem started sometime in august after my last emerge -u world (which doesn't happen very often on this box for a certain reason...) For me, the solution was changing the RC_PARALLEL_STARTUP="yes" to "no" in /etc/conf.d/rc .
But I guess I get what I deserve since most of the hw is crap (K5 cpu @ 150 MHz)!!!
I guess it's just not fast enough for inet to start up before other services need it... |
I got "no" already.
I still unable to solve this. |
|
| Back to top |
|
|
BlueByte
Tux's lil' helper
Joined: 08 Apr 2004
Posts: 87
|
| Posted: Tue Nov 08, 2005 10:34 pm Post subject: |
|
|
| help |
|
| Back to top |
|
|
|
Networking & Security
