#10110 closed bug (invalid)
Eth connection hangs after some hours
| Reported by: | Giova84 | Owned by: | korli |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Drivers/Network/ipro1000 | Version: | R1/Development |
| Keywords: | Eth connection hangs after some hours ipro1000 | Cc: | |
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
I have an ethernet connection (DHCP - connected to a router) which has always worked without issues on Haiku.
But since i upgraded Haiku to hrev46239 i often experience dead connection, after some hours. With "dead connection" i mean that browsers (WebPositive and Qupzilla) will try to load sites without success and also the "ping" command doesn't show any output. I've also tried to stop and restart the net_server but this doesn't solve the situation. To get the connection again i have to reboot Haiku.
The syslog (oddly) seems that not contains anything about netwok hangs. But in anyway here i attach the last part of syslog before that my connection hangs: http://pastie.org/8410771
Let me know if i can do some other tests.
hrev46239 Ipro1000
Attachments (1)
Change History (21)
comment:1 by , 11 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:2 by , 11 years ago
comment:5 by , 11 years ago
Looking here, i bet that you suggest me a least hrev46192 because in hrev46193 was done this commit: http://cgit.haiku-os.org/haiku/commit/?id=3ad66bf0d6b125723da0f215e3907a3e4182cd70
Well, to be honest also with hrev46198 my connection used to working fine.
comment:6 by , 11 years ago
To be further accurate: when i lose connection on Haiku, i am still able to use connection on other computers on my LAN.
comment:7 by , 11 years ago
I have done another test. Few minutes ago i lose again the connection. And this time i have tried to open the network preflet, set the "Mode" to "disabled", click on apply, back to DHCP and then click apply again: DHCP was no longer able (during the previous session) to assign again the "Gateway" (empty field), while all others entries were properly set as before.
This is very odd, because the connection is still active on other PCs, and the syslog is always the same.
comment:8 by , 11 years ago
I've waited some days to update this ticket, to be sure of progresses which i've made. Well, three days ago i set my eth card to force static mode instead of DHCP, and in this way I no longer lose the connection, then i switched again to DHCP and connection was stable again. Odd, because the sull syslog doesn't show anything about the issue and when i was losing the connection on Haiku, on other PCs of my lan, all was fine. I think that this ticket could be closed as "no change required".
comment:9 by , 11 years ago
I'd prefer to have it open. I think there are issues either in dhcp or in the networking code, and I'd like to keep and collect these kind of problems for now.
comment:11 by , 8 years ago
Replying to diver:
Might be fixed in hrev49477.
Unfortunately I noticed that this issue, for me on my system when I use DHCP, appears more often since I'm back on Haiku few months ago (on hrev50067). With "more often" I mean that I lose the connection also after the boot of Haiku.
Since I have to stay with DHCP, I cant tell if switching to static configuration is still able to solve the trouble (as I said in the comment 8 ): the only way to get the connection again is still to reboot Haiku.
follow-up: 13 comment:12 by , 8 years ago
I have an update about this ticket.
When I lose the connection, I open the network preflet and I go to the ipv4 configuration, then I change the Mode from "DHCP" to "Disabled" (but without clicking on the "Apply" button), then I select again DHCP as mode (again, without clicking on the "Apply" button) and the connection will be available again (the net notification will tell me about the fact that my eth card is ready again).
How can I investigate more thoroughly? Due this bug ticket:12634 is very hard to find exact messages in the syslog, because is continuosly spammed with the same message.
follow-up: 15 comment:13 by , 8 years ago
Only the static mode is applied *when* Apply button is pushed, all other changes are applied immediately. Which mean a DHCP renegociation fix the issue, pointing the origin there. Either the DHCP lease expired before we renew it in time, or the DHCP server does something weird with the lease or we does something weird when we renew the DHCP lease.
Do you have any trace of a DHCP lease renewall somewhere in your syslog before connection get lost? According your attached syslog, the lease expired each hour. You should see some lease renewal attempt in the syslog every hour, theoretically.
comment:15 by , 7 years ago
Replying to phoudoin:
Do you have any trace of a DHCP lease renewall somewhere in your syslog before connection get lost? According your attached syslog, the lease expired each hour. You should see some lease renewal attempt in the syslog every hour, theoretically.
Today (Haiku hrev51051) I lose connection again. The odd thing is that someday the connection is stable for all day long; someday like today, instead, is prone to disappear suddenly. If i Look at the syslog, I noticed that is spammed with these messages:
DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST for 192.168.178.21 to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 500000 secs (try 1) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 1000000 secs (try 2) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2000000 secs (try 3) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 4000000 secs (try 4) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 8000000 secs (try 5) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 KERN: [ipro1000] (em) Link is Down KERN: /dev/net/ipro1000/0: media change, media 0x20 quality 1000 speed 1000000000 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2472203668 secs (try 6) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2472203626 secs (try 7) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2472203604 secs (try 8) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2472203578 secs (try 9) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2472203558 secs (try 10) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2472203539 secs (try 11) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2472203521 secs (try 12) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2472203509 secs (try 13) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2472203499 secs (try 14) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2472203490 secs (try 15) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2472203479 secs (try 16) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2472203469 secs (try 17) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2472203460 secs (try 18) ...... (CONTINUE) DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_REQUEST to 255.255.255.255:67 DAEMON 'DHCP': /dev/net/ipro1000/0: Timeout shift: 2472198975 secs (try 255)
Doesn't seems that the DHCP renewal appear when i lost the connection: in the syslog of today the DHCP renewal just appears two time: I will check more precisely. however, in these three years (since i opened the ticket) I changed three routers, and each of them has a different lease renew time: so i can exclude the fact that the connection here on Haiku, is weak due the router.. Soon i wanna try with another computer with another ethernet card.
comment:16 by , 7 years ago
Sounds that the first issue is link instability, no? Or at least the way the driver handle it...
Is this running under a VM or an actual baremetal Haiku with an actual intel Pro1000 NIC card in it?
I agree that your routers and their DHCP server can't be the issue source here, indeed.
comment:17 by , 7 years ago
I have an update.
First of all, I run Haiku only on bare metal ;)
Well, on the previous computer the eth card was an Intel 82567V-2 Gigabit (recognized as /dev/net/ipro1000); now i changed my desktop PC and I have an Realtek 8111F Gigabit (always on the motherboard) , which, under Haiku, work with the /dev/net/rtl81xx driver. But the same issue (link instability) still occurs, and I can definitely tell you that if I go with the static mode instead of DHCP, the connection is stable on the old PC and on this one.
comment:18 by , 5 years ago
Many DHCP issues seem to have cleared up with the ARP fix. Can you retest this under a recent nightly?
comment:20 by , 4 years ago
| Milestone: | R1 |
|---|
Remove milestone for tickets with status = closed and resolution != fixed
Update: when i lose connection, if i open the "Network" preflet i can see that all entries are correctly set/assigned (DHCP) as usual, but in anyway the connection itself is dead. Only a reboot can solve the situation.