Opened 15 years ago
Closed 13 years ago
#3280 closed bug (fixed)
dhcp / network issue after a couple of hours uptime
| Reported by: | rossi | Owned by: | phoudoin |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Network & Internet | Version: | R1/pre-alpha1 |
| Keywords: | Cc: | adek336@…, umccullough, HubertNG@… | |
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
Upon bootup DHCP configures my network quite correctly and everything works fine. However after a couple of hours it looses the DHCP assigned address and neither powering down the interface (ifconfig ... down) nor the network preference panal are of any help here. If I then try to set a manuell address it doesn't work, it sticks to the 169.* assigned address and ifconfig ... auto-config doesn't also help. The only solution is to reboot. This happens definetly after 10h of uptime, sometimes already after 5h uptime.
Tested with hrev28861.
See attachements for hardware devices and screenshoot for the settings in the network preferences panel and if config output run after settings done and applied in panel ...
Attachments (4)
Change History (22)
by , 15 years ago
| Attachment: | listdev.log added |
|---|
by , 15 years ago
| Attachment: | screenshot1 added |
|---|
by , 15 years ago
| Attachment: | screenshot2 added |
|---|
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Something I overlooked last night (shouldn't file bug reports after having a good long island ice tea ;-) ...
The published network devices at least according to the ifconfig output are also trashed, as there appear two entries for my single physical adapter, the regular "/dev/net/marvell_yukon/0" but also another one named "/dev/net/marvell_yukon/"
comment:3 by , 15 years ago
Right after boot you don't have the additional "/dev/net/marvell_yukon/" interface listed with ifconfig, right?
Could you check in KDL "symbol gDeviceNameList" and when you see the entry from the marvell yukon driver and an address, do "dw 0x<that address>" and later "ds 0x<that address>" for all the addresses which will appear?
comment:4 by , 15 years ago
Correct, straight after boot, everything looks normal:
rossi@wayreth home> ifconfig loop Hardware Type: Local Loopback, Address: none
inet addr: 127.0.0.1, Mask: 255.0.0.0 MTU: 16384, Metric: 0, up loopback link Receive: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped Transmit: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped Collisions: 0
/dev/net/marvell_yukon/0
Hardware Type: Ethernet, Address: 00:17:42:84:49:31 Media Type: 100 MBit, 100BASE-TX inet addr: 10.0.0.100, Bcast: 10.0.0.255, Mask: 255.255.255.0 MTU: 1500, Metric: 0, up broadcast link auto-configured Receive: 56511 packets, 0 errors, 56200932 bytes, 0 mcasts, 0 dropped Transmit: 56338 packets, 0 errors, 6977403 bytes, 0 mcasts, 0 dropped Collisions: 0
I'll check the next time it happens, which I guess will be later tonight or tomorrow if the system manages to survive overnight unattended, which is also a problem lately, since the system tends to automatic reboots lately, when unattended over a longer period of time.
comment:6 by , 15 years ago
@Adeck336 ... I've attached the grep results to the ticket. Let me know, if you need more ...
comment:7 by , 15 years ago
Thanks[[br]] I was looking for a line that goes like
KERN: [marvell_yukon] marvell_yukon: /dev/net/marvell_yukon/
which would be a problem if_initname.
Anyway, there's these interesting two bunches of lines which differ only with the "0"
13 KERN: [marvell_yukon] marvell_yukon: /dev/net/marvell_yukon/0 14 KERN: [marvell_yukon] () Found MII: e1000phy 15 KERN: [marvell_yukon] () Adding entry for Ethernet none 16 KERN: loaded driver /boot/beos/system/add-ons/kernel/drivers/dev/net/marvell_yukon 17 KERN: get_device_interface: ask "network/devices/ethernet/v1" for /dev/net/marvell_yukon/0 18 KERN: ipv4_datalink_init(/dev/net/marvell_yukon/0) .... 33 KERN: [marvell_yukon] marvell_yukon: /dev/net/marvell_yukon/0 34 KERN: [marvell_yukon] () Found MII: e1000phy 35 KERN: [marvell_yukon] () Adding entry for Ethernet none 36 KERN: loaded driver /boot/beos/system/add-ons/kernel/drivers/dev/net/marvell_yukon 37 KERN: get_device_interface: ask "network/devices/ethernet/v1" for /dev/net/marvell_yukon/ 38 KERN: ipv4_datalink_init(/dev/net/marvell_yukon/)
comment:8 by , 15 years ago
| Cc: | added |
|---|
comment:9 by , 15 years ago
Btw, after the issue happend last night again, some more information on the publishing of the addition worng device without ".../0", this didn't happen again, therefore I believe, this wierd publishing effect was due to my ifconfig ... auto-config/down/up and network preferences trials to get networking back running. If it shows again, I'll provide the requested KDL data.
This time it just got assigned the 169. address ...
comment:10 by , 15 years ago
| Cc: | added |
|---|
comment:11 by , 15 years ago
| Cc: | added |
|---|
comment:13 by , 13 years ago
| Cc: | added; removed |
|---|
Good question... I'm pretty certain I still have similar issues with my netbook's Atheros wifi getting new DHCP addresses on R1/Alpha2 (may be a completely different cause/issue).
Whether it still happens with the 3com cards in my PIII boxes using the latest rev, I do not know. It would take me some time to setup and retest those, which I may find time to do over the long weekend which is coming up.
follow-up: 15 comment:14 by , 13 years ago
Tested with one of my 3com cards on a recent trunk build. It did not lose/renew the DHCP address after lengthy uptime (I left it running for > 8 hours).
However, when I unplugged the cable, and re-plugged it in after ~30 seconds, the address it got was a different one than it had before. I expected it would request/retrieve the same address. I guess that's a different issue, however, and deserves a different ticket.
follow-up: 16 comment:15 by , 13 years ago
Replying to umccullough:
However, when I unplugged the cable, and re-plugged it in after ~30 seconds, the address it got was a different one than it had before. I expected it would request/retrieve the same address. I guess that's a different issue, however, and deserves a different ticket.
Yes, request last known ip address when we have one for that interface is a desirable enhancement. I've some pending change related to our DHCP client that I should commit soon, but please file a ticket about this feature so I don't forget about it.
comment:16 by , 13 years ago
Replying to phoudoin:
Yes, request last known ip address when we have one for that interface is a desirable enhancement. I've some pending change related to our DHCP client that I should commit soon, but please file a ticket about this feature so I don't forget about it.
Ticket #7346 is about this behavior.
follow-up: 18 comment:17 by , 13 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
I believe this one might have been resolved by recent changes, any thoughts Philippe?
comment:18 by , 13 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Replying to anevilyak:
I believe this one might have been resolved by recent changes, any thoughts Philippe?
I also believe it. Please reopen if the issue is still there for your guys.
Not sure if this is related, but I have several machines running hrev28821 with 3com cards that end up getting different DHCP addresses after running for a while - I don't check them very often, maybe once every day or two, but they almost always have a different IP address when I do check them.
I only notice this because they're running headless with sshd - and whenever I have to SSH to them, I must go to the dhcp server first and check to see what IP address is currently leased to their MAC address.
Other DHCP machines on the same network do not have that problem.
If this is a completely different issue, I'll open a separate ticket.