Opened 14 years ago

Closed 14 years ago

#7490 closed bug (fixed)

Intel ProWifi3945ABG (DHCP does not work anymore )

Reported by: brunobratwurst Owned by: korli
Priority: normal Milestone: R1
Component: Network & Internet/Wireless Version: R1/Development
Keywords: intel pro 3945abg Cc:
Blocked By: Blocking:
Platform: x86

Description

I have problems with DHCP again...

With the one month older nightly development build (February) I had no problems with DHCP...

I got the correct IP Number by doing nothing... only had to wait a bit (2min).

...so something must be happened since then... I use rev 41293 now and DHCP will not connect to the internet automatically.

It gives me a wrong IP-Number something like.. 157.164.0.57 I need something like 192.168.2.100

Trying to use static IP does not work either or I use wrong numbers

Attachments (12)

syslog​ (20.0 KB ) - added by brunobratwurst 14 years ago.
screenshot1.png​ (124.7 KB ) - added by brunobratwurst 14 years ago.
ipconfig​ (850 bytes ) - added by brunobratwurst 14 years ago.
syslog_February​ (305.5 KB ) - added by brunobratwurst 14 years ago.
syslog_may​ (408.1 KB ) - added by brunobratwurst 14 years ago.
syslog_41142​ (307.7 KB ) - added by brunobratwurst 14 years ago.
syslog_41264​ (198.6 KB ) - added by brunobratwurst 14 years ago.
syslog_41272​ (208.6 KB ) - added by brunobratwurst 14 years ago.
syslog_41249​ (493.2 KB ) - added by brunobratwurst 14 years ago.
syslog_41256​ (298.7 KB ) - added by brunobratwurst 14 years ago.
syslog R1 Alpha 3 41612​ (165.2 KB ) - added by brunobratwurst 14 years ago.
syslog R1 Alpha 3 41612.2​ (165.2 KB ) - added by brunobratwurst 14 years ago.

Change History (22)

in reply to:  description ; comment:1 by bonefish, 14 years ago

Owner: changed from axeld to phoudoin
Status: new → assigned

Replying to brunobratwurst:

...so something must be happened since then...

I believe Philippe happened. ;-)

in reply to:  1 comment:2 by phoudoin, 14 years ago

Replying to bonefish:

I believe Philippe happened. ;-)

brunobratwurst, could you attach your /var/log/syslog file so I can investigate what may have happened... beside, well, me coding. ;-)

If you can also give some details on your DHCP server (is it a home router, which model, so on), it could help too.

Thanks.

by brunobratwurst, 14 years ago

Attachment: syslog​ added

by brunobratwurst, 14 years ago

Attachment: screenshot1.png​ added

by brunobratwurst, 14 years ago

Attachment: ipconfig​ added

comment:3 by brunobratwurst, 14 years ago

I use a DSL-EasyBox from Vodafone a very common company here in Germany, dont know the specs... do you need them? If so i will try to find out...

It is a home router used with 3 computer...

I can try download the older development rev. from February and post the syslog from it... if it helps...

by brunobratwurst, 14 years ago

Attachment: syslog_February​ added

comment:4 by phoudoin, 14 years ago

Thanks for attachments, february's syslog in particular. There is three issues in one here it seems:

  1. the first DHCP_DISCOVER don't receive any reply, and there is several wifi driver messages mixed in.
  2. the DHCP client request the local-only address, which it should not!
  3. when these requests all timeout (which is expected for a local-only address), it doesn't fall back to DHCP_DISCOVER cycle, which it should do.

I'll investigate the two laters issues, but for the first one I can only suspect ATM some issue with the state of network interface when DHCP messages are sent. What you could try for this first issue is replacing the iprowifi3945 driver with the one from february.

by brunobratwurst, 14 years ago

Attachment: syslog_may​ added

comment:5 by korli, 14 years ago

It would help if you could check a revision between hrev41251 and hrev41273. This is more or less after changes to the ipro3945 driver and before DHCP changes. Thanks in advance.

by brunobratwurst, 14 years ago

Attachment: syslog_41142​ added

by brunobratwurst, 14 years ago

Attachment: syslog_41264​ added

by brunobratwurst, 14 years ago

Attachment: syslog_41272​ added

by brunobratwurst, 14 years ago

Attachment: syslog_41249​ added

by brunobratwurst, 14 years ago

Attachment: syslog_41256​ added

comment:6 by phoudoin, 14 years ago

Thanks for bisecting the issue.

Turns out that the last revision it was working fine is hrev41142:

  1. hrev41142 OK
  2. hrev41249 broken
  3. hrev41256 broken
  4. hrev41264 broken
  5. hrev41272 broken
  6. hrev41273 -> first DHCP client changeset...

So my best guess is that the driver is the root issue here, as suspected by korli.

comment:7 by korli, 14 years ago

Owner: changed from phoudoin to korli

Could you please check again with hrev41559 or newer on trunk?

in reply to:  4 comment:8 by phoudoin, 14 years ago

  1. the DHCP client request the local-only address, which it should not!


This specific issue should be fixed since hrev41538, BTW.

  1. when these requests all timeout (which is expected for a local-only address), it doesn't fall back to DHCP_DISCOVER cycle, which it should do.


After more thinking, the main issue is the failure to send anything over the network, there is no point to reset the DHCP client state. What could be done better, though, is detect such failure and escape earlier the DHCP process, which will avoid waiting for timeout. Will do that during next free time slot, eventually.

Last edited 14 years ago by phoudoin (previous) (diff)

comment:9 by brunobratwurst, 14 years ago

I just did a clean install of Haiku R1/alpha3 rev.41612... no idea if GCC 4 hybrid or GCC 2.95

It is working better than ever... very fast connecting time compared to the one before...

Anyway I will enclose a syslog for you devs...

thanks very very good work...

ah yes I think this bug can be closed...

Last edited 14 years ago by brunobratwurst (previous) (diff)

by brunobratwurst, 14 years ago

Attachment: syslog R1 Alpha 3 41612​ added

by brunobratwurst, 14 years ago

Attachment: syslog R1 Alpha 3 41612.2​ added

comment:10 by korli, 14 years ago

Resolution: → fixed
Status: assigned → closed

Closing as fixed.

Philippe, I let you see what to do with the specific DHCP issue you mentioned earlier.

Note: See TracTickets for help on using tickets.