Opened 5 years ago

Closed 22 months ago

#15723 closed bug (invalid)

Seeing a lot of DHCP messages

Reported by: dsuden Owned by: axeld
Priority: normal Milestone: Unscheduled
Component: Network & Internet/IPv4 Version: R1/Development
Keywords: Cc: ttcoder
Blocked By: Blocking:
Platform: All

Description (last modified by pulkomandy)

2020-02-16 15:15:47 DAEMON 'DHCP': /dev/net/rtl81xx/0: Timeout shift: 8000 msecs (try 5)
2020-02-16 15:15:47 DAEMON 'DHCP': /dev/net/rtl81xx/0: Send DHCP_DISCOVER to 255.255.255.255:67
2020-02-16 15:15:55 DAEMON 'DHCP': /dev/net/rtl81xx/0: Timeout shift: 24124 msecs (try 6)
2020-02-16 15:15:55 DAEMON 'DHCP': /dev/net/rtl81xx/0: Send DHCP_DISCOVER to 255.255.255.255:67

Attachments (1)

syslog (223.3 KB ) - added by ttcoder 5 years ago.
lots of DHCP spamming over 60 minutes

Download all attachments as: .zip

Change History (9)

comment:1 by pulkomandy, 5 years ago

Component: - GeneralNetwork & Internet/IPv4
Description: modified (diff)
Owner: changed from nobody to axeld
Summary: Seeing a lot of these messagesSeeing a lot of DHCP messages

Please include a more complete syslog (it can be used to check the timings, these messages are supposed to slow down and eventually stop if there is no reply).

by ttcoder, 5 years ago

Attachment: syslog added

lots of DHCP spamming over 60 minutes

comment:2 by ttcoder, 5 years ago

Cc: ttcoder added

See above the syslog that prompted us to file this ticket : after cycling a whole syslog it hopped to the next one, attached, where it went on for 60 minutes. Seems it goes to "attempt 25" and the restarts from zero.

The relevance for us is in case of future bugs of other issues to solve, we will probably need to look at the syslog (sans spam)..

Version 0, edited 5 years ago by ttcoder (next)

comment:3 by waddlesplash, 5 years ago

As PulkoMandy already commented in #15326:

2020-02-18 06:13:12 DAEMON 'DHCP': /dev/net/rtl81xx/0: Received DHCP_NACK from 192.168.0.1

Your DHCP server is rejecting the requests. So this is almost certainly *not* a Haiku bug.

comment:4 by ttcoder, 5 years ago

Would that be consistent with the fact that networking works great on that machine? Dane reports it transfers files on FTP ..etc faster than any other Haiku computer he has. Could the router configure the machine correctly yet reject it with DHCP_NACK ?

FWIW Dane is in beshare right now, so I...

  • asked him if the syslog is still spammed : it is.
  • asked him to switch to "static" IP, then back to DHCP: worked without issue, he's still networking happily. Make of that what you will :-)

Anyway no urgency since we're still battling with multiple media_server bugs ATM that are more urgent.

comment:5 by waddlesplash, 5 years ago

asked him to switch to "static" IP, then back to DHCP: worked without issue, he's still networking happily. Make of that what you will :-)

Well, if the machine has an IP assigned, and has a gateway configured, then it will probably continue working indefinitely (until an IP collision, gateway change, etc. but those are unlikely.)

Likely what happened was the first DHCP succeeded, and then after the lease expired and Haiku tried to renew it, then the NACKs began.

Anyway no urgency since we're still battling with multiple media_server bugs ATM that are more urgent.

Which ones are these? Just the "silence at boot"? (The media_addon_server crashes were recently fixed.)

in reply to:  3 comment:6 by pulkomandy, 5 years ago

Replying to waddlesplash:

Your DHCP server is rejecting the requests. So this is almost certainly *not* a Haiku bug.

Quite the opposite: if the server rejects our requests, there must be something wrong with them. We may need a tcpdump capture of the DHCP requests to see what the problem is, however.

comment:7 by pulkomandy, 3 years ago

I have fixed various issues with the timing of our DHCP requests, they should now work better.

Can you still reproduce this? If so, can you capture the DHCP requests and replies with tcpdump?

comment:8 by waddlesplash, 22 months ago

Resolution: invalid
Status: newclosed

No reply.

Note: See TracTickets for help on using tickets.