Opened 11 years ago

Closed 9 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:
Has a Patch: no 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)

listdev.log (2.9 KB ) - added by rossi 11 years ago.
screenshot1 (277.6 KB ) - added by rossi 11 years ago.
screenshot2 (276.0 KB ) - added by rossi 11 years ago.
grep_marvel_yukon_syslog (6.0 KB ) - added by rossi 11 years ago.
Requested syslog output

Download all attachments as: .zip

Change History (22)

by rossi, 11 years ago

Attachment: listdev.log added

by rossi, 11 years ago

Attachment: screenshot1 added

by rossi, 11 years ago

Attachment: screenshot2 added

comment:1 by umccullough, 11 years ago

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.

comment:2 by rossi, 11 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 Adek336, 11 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 rossi, 11 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:5 by Adek336, 11 years ago

Could you grep the syslog for marvell_yukon ?

by rossi, 11 years ago

Attachment: grep_marvel_yukon_syslog added

Requested syslog output

comment:6 by rossi, 11 years ago

@Adeck336 ... I've attached the grep results to the ticket. Let me know, if you need more ...

comment:7 by Adek336, 11 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 Adek336, 11 years ago

Cc: adek336@… added

comment:9 by rossi, 11 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 umccullough, 11 years ago

Cc: umccullough@… added

comment:11 by Hubert, 11 years ago

Cc: HubertNG@… added

comment:12 by Coldfirex, 9 years ago

Is still an issue in newer revisions?

comment:13 by umccullough, 9 years ago

Cc: umccullough added; umccullough@… 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.

comment:14 by umccullough, 9 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.

in reply to:  14 ; comment:15 by phoudoin, 9 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.

in reply to:  15 comment:16 by deejam, 9 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.

comment:17 by anevilyak, 9 years ago

Owner: changed from axeld to phoudoin
Status: newassigned

I believe this one might have been resolved by recent changes, any thoughts Philippe?

in reply to:  17 comment:18 by phoudoin, 9 years ago

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.