Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#6454 closed bug (fixed)

DHCP isn't working when using router

Reported by: berregon Owned by: axeld
Priority: normal Milestone: R1
Component: Network & Internet Version: R1/Development
Keywords: Cc: kvarkus@…
Blocked By: Blocking:
Platform: All

Description

When i plus my cable modem to my linksys router and than link my computer to the router by cable, the dhcp isn't working. When i plug my cable modem directly to my computer, the dhcp is working. I don't know since which revision but presently i'm using hrev38152.

Thedhcp is working with the alpha2 using my router.

i have a realtek ethernet card: 

device Network controller (Ethernet controller) [2|0|0]
  vendor 10ec: Realtek Semiconductor Co., Ltd.
  device 8168: RTL8111/8168B PCI Express Gigabit Ethernet controller

I'll attach syslog of when it's working and when it's not.

Attachments (8)

syslog_norouter​ (328.2 KB ) - added by berregon 14 years ago.
syslog_withrouter​ (132.6 KB ) - added by berregon 14 years ago.
dhcp_norouter.png​ (33.2 KB ) - added by berregon 14 years ago.
dhcp_withrouter.png​ (32.7 KB ) - added by berregon 14 years ago.
network_with_router_r1alpha2.png​ (72.0 KB ) - added by berregon 14 years ago.
VirtualBox.DHCP.log​ (31.4 KB ) - added by siarzhuk 14 years ago.
tcpdump acquired with "src host 192.168.0.14 or dst port 67"
syslog​ (144.6 KB ) - added by Duggan 14 years ago.
I'm having the same problems. I've rebuilt with debug output as you've requested, here's my syslog.
syslog-autoconfig​ (404.1 KB ) - added by stippi 14 years ago.
syslog with the requested tracing enabled

Download all attachments as: .zip

Change History (41)

by berregon, 14 years ago

Attachment: syslog_norouter​ added

by berregon, 14 years ago

Attachment: syslog_withrouter​ added

by berregon, 14 years ago

Attachment: dhcp_norouter.png​ added

by berregon, 14 years ago

Attachment: dhcp_withrouter.png​ added

comment:1 by diver, 14 years ago

Same here in VirtualBox 3.0.12. Setting ip through Network preflet usually works, though.

comment:2 by axeld, 14 years ago

Owner: changed from nobody to axeld
Status: new → in-progress

The syslog with the router does not contain any helpful information (ie. the actual DHCP acquisition could be helpful). In the no router situation, it looks like no packet is received at all.

Is your router configured as a DHCP server? If it is missing, who is providing the DHCP address -- the cable modem directly? And if you have internet through the cable modem, it seems to already include a router on its own, as Haiku does not have a working PPP stack at the moment.

I will follow diver's tip, and try if I can reproduce the problem using VirtualBox and/or Qemu.

comment:3 by berregon, 14 years ago

Yes my rooter is configured as a DHCP server. With the alpha2 , the DHCP with the rooter looks like this:

Version 0, edited 14 years ago by berregon (next)

by berregon, 14 years ago

Attachment: network_with_router_r1alpha2.png​ added

comment:4 by berregon, 14 years ago

The adapter name isn't the same, rtl81xx in more recent revision and rtl8169 with alpha2 but i doubt it is the problem.

comment:5 by axeld, 14 years ago

VirtualBox 3.2.8 seems to work just fine. I do not get a network with Qemu, but I don't remember if I had to set some network parameters to change this. I'll look into that.

in reply to:  5 comment:6 by siarzhuk, 14 years ago

Replying to axeld:

VirtualBox 3.2.8 seems to work just fine. I do not get a network with Qemu, but I don't remember if I had to set some network parameters to change this. I'll look into that.

By the way version of Virtual Box 3.1.4 I use at work also become DHCP problems with last weeks changes. "Bridged" ipro1000 network emulation in it worked well on hrev37101 but cannot obtain DHCP on current 38xxx revisions. May it be related to mentioned problem? Trying to run tcpdump in that system bring it to KDL -may be tommorow I'll be more lucky. I can try to run Wireshark on the host Windows system but this is corporative network and it will be a bit difficult to filter out Haiku DHCP traffic. :-) May it help you with mentioned problem?

comment:7 by diver, 14 years ago

tcpdump output from hrev38182 in VirtualBox 3.0.12 

01:57:13.203716 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:00:27:c7:d8:5b (oui Unknown), length 255
01:57:13.204010 arp who-has 255.255.255.255 (Broadcast) tell 10.0.2.2
01:57:13.204189 IP 10.0.2.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 548
01:57:17.208698 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:00:27:c7:d8:5b (oui Unknown), length 255
01:57:17.208997 arp who-has 255.255.255.255 (Broadcast) tell 10.0.2.2
01:57:17.209189 IP 10.0.2.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 548
01:57:25.213800 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:00:27:c7:d8:5b (oui Unknown), length 255
01:57:25.214104 arp who-has 255.255.255.255 (Broadcast) tell 10.0.2.2
01:57:25.214283 IP 10.0.2.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 548
01:57:27.221220 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:00:27:c7:d8:5b (oui Unknown), length 255
01:57:27.221487 arp who-has 255.255.255.255 (Broadcast) tell 10.0.2.2
01:57:27.221736 IP 10.0.2.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 548
01:57:31.235515 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:00:27:c7:d8:5b (oui Unknown), length 255
01:57:31.249737 arp who-has 255.255.255.255 (Broadcast) tell 10.0.2.2
01:57:31.250010 IP 10.0.2.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 548
01:57:39.244519 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:00:27:c7:d8:5b (oui Unknown), length 255
01:57:39.244845 arp who-has 255.255.255.255 (Broadcast) tell 10.0.2.2
01:57:39.245061 IP 10.0.2.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 548
01:57:41.249756 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:00:27:c7:d8:5b (oui Unknown), length 255
01:57:41.250038 arp who-has 255.255.255.255 (Broadcast) tell 10.0.2.2
01:57:41.250287 IP 10.0.2.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 548
01:57:45.255889 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:00:27:c7:d8:5b (oui Unknown), length 255
01:57:45.256149 arp who-has 255.255.255.255 (Broadcast) tell 10.0.2.2
01:57:45.256358 IP 10.0.2.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 548

by siarzhuk, 14 years ago

Attachment: VirtualBox.DHCP.log​ added

tcpdump acquired with "src host 192.168.0.14 or dst port 67"

comment:8 by siarzhuk, 14 years ago

Look into VirtualBox.DHCP.log for failed DHCP session dump in mentioned above in comment:6 VirtualBox. corresponding ifconfig output is following: 

/dev/net/ipro1000/0
	Hardware Type: Ethernet, Address: 08:00:27:dc:6a:b2
	Media Type: 1 GBit, 1000BASE-T
	inet addr: 169.254.0.43, Bcast: 169.254.255.255, Mask: 255.255.0.0
	MTU: 1500, Metric: 0, up broadcast link auto-configured
	Receive: 6366 packets, 0 errors, 487458 bytes, 0 mcasts, 0 dropped
	Transmit: 45 packets, 0 errors, 13365 bytes, 0 mcasts, 0 dropped
	Collisions: 0

ip address of our DHCP server is 192.168.0.14 dump was acquired with "src host 192.168.0.14 or dst port 67" mask.

Hope it helps.

comment:9 by diver, 14 years ago

DHCP works now for me in hrev38356, thanks!

comment:10 by siarzhuk, 14 years ago

I have checked hrev38357. Unfortunately no changes under VirtualBox. Assigned IP is still default one. I'm going to test latest Haiku revisions in the same network environment with the real hardware so more details can come in some days.

comment:11 by stippi, 14 years ago

Same here on real hardware (no change). So far I have only tested with an "update-all" build and removing the interface and router settings files before booting.

comment:12 by stippi, 14 years ago

Running hrev38365, my rtl8139 still does not properly configure via DHCP. It is in "Configuring" state for quite some time, and during that time it has a weird address, then it has the usual 169.254.0.83 address, 169.254.255.255 broadcast and 255.255.0.0 netmask. It should be 192.168.1.59 for address (always got the same from the router before), and 255.255.255.0 for netmask.

comment:13 by stippi, 14 years ago

Additionally, when I manually configure a correct IP, I can ping google again, but interrupting the ping process via Ctrl-C in the Terminal puts it into a busy loop. It was possible to kill it via ProcessController.

comment:14 by axeld, 14 years ago

Resolution: → fixed
Status: in-progress → closed

Should be finally fixed with hrev38397.

Stippi, if the ping problem is reproducible, please file a separate bug report for it. The "weird" address is just how ad-hoc IPv4 network addresses should look like as defined by IANA - if you have no DHCP, and add several systems with automatic configuration to a network, they should all get a different address in the same subnet in order to be able to talk to each other.

comment:15 by diver, 14 years ago

Looks like hrev38397 broke networking for me in vbox, tcpdump doesn't output anything, in hrev38396 everything works fine. Should I open another ticket for it?

comment:16 by stippi, 14 years ago

Resolution: fixed
Status: closed → reopened

Actually, running hrev38401, clean build (GCC4 based hybrid, with the GCC2 cross tools updated and reconfigured), I don't get any networking anymore at all. DHCP is broken as before, and manual configuration does not resolve hosts anymore either.

comment:17 by anevilyak, 14 years ago

Similar regression here, though with slightly different semantics: DHCP does get a valid configuration, I can ping my gateway, but I can't do any DNS resolution.

comment:18 by axeld, 14 years ago

That's actually a new issue I introduced obviously with a last minute change. I hope I'll find the time to look into it over the next few days (I will be on vacation from Wednesday on).

comment:19 by axeld, 14 years ago

Resolution: → fixed
Status: reopened → closed

Indeed, it was a last minute change; should be fixed in hrev38415.

comment:20 by stippi, 14 years ago

Resolution: fixed
Status: closed → reopened

Manual configuration gives working networking again, but DHCP still doesn't work. Configuration takes a long time, during which the addresses shown by the NetworkStatus app in the alert change a couple times, but then the address it settles with is broken. DHCP configuration used to be pretty quick.

comment:21 by axeld, 14 years ago

I'm pretty sure berregon's problem is solved now at least :-)

Anyway, if you want to see this fixed, you'll have to provide a little more information than that. Can you enable debug output in protocols/ipv4, udp, and stack/interfaces.cpp, and datalink.cpp? datalink_protocols/arp would also be nice. Then boot and attach said debug output to this ticket.

I'm afraid I won't find the time to look into it before my vacation anymore, unless it's something subtle and obvious. Good luck! ;-)

by Duggan, 14 years ago

Attachment: syslog​ added

I'm having the same problems. I've rebuilt with debug output as you've requested, here's my syslog.

comment:22 by Duggan, 14 years ago

Also, after I started up I opened the Network settings and changed from static to DHCP, clicked Apply, waited for it to finish applying then closed the window, then opened it again to view the settings. I don't know if this is stored in the syslog or not, but if you look at it and see anything funny towards the end, that's why. By the looks of it, it seems it did store that information there.

comment:23 by Duggan, 14 years ago

I'm no good at speaking networkese, but it seems around line 2122 the router is trying to send the DHCP info to my computer, where "prototarget" is 10.0.0.5 which is what my IP should be and it kind of seems to go downhill from there... is that anything of consequence or am I just imagining things?

by stippi, 14 years ago

Attachment: syslog-autoconfig​ added

syslog with the requested tracing enabled

comment:24 by stippi, 14 years ago

To make the syslog smaller, I've chopped off some sections of repeated "KERN: PageWriteWrapper: Failed to write page 0x????????: General system error", with the question marks being a different address each line. Don't know what those mean.

comment:25 by axeld, 14 years ago

Should be finally fixed in hrev38450. Duggan's problem was an actual bug, while Stippi's router was a bit too creative :-)

Feel free to reopen if it still doesn't work; I won't care about it for the next three weeks, though ;-)

comment:26 by stippi, 14 years ago

Resolution: → fixed
Status: reopened → closed

Puh, finally it works again! Thanks very much, Axel! So I don't feel like reopening, but I feel like closing...

comment:27 by Duggan, 14 years ago

It works fantastically, thank you Axel! now I can finally upgrade from hrev37607 ;)

comment:28 by berregon, 14 years ago

I've been away so didn't test a new revision untill today and it's working fine now for me too.

comment:29 by skarmiglione, 14 years ago

My dhcp is not working in the last revision, 54m wireless ap router NEXXT SOLUTIONS.... no work, rev 38492.

comment:30 by kvark, 13 years ago

I'm running Haiku A3 on a laptop with the following card: "RTL8111/8168B PCI Express Gigabit Ethernet controller"

Most of the time DHCP doesn't work when connected to a router. It obtaines an address in the form 192.168.x.x while my local network is 10.0.1.x. I can set the IP/mask manually, but the name resolution doesn't happen. Is there a way to configure it by hands as well?

I'm not sure if I need to re-open this bug or create a new one.

comment:31 by kvark, 13 years ago

Cc: kvarkus@… added

in reply to:  30 comment:32 by umccullough, 13 years ago

Replying to kvark:

Most of the time DHCP doesn't work when connected to a router. It obtaines an address in the form 192.168.x.x while my local network is 10.0.1.x. I can set the IP/mask manually, but the name resolution doesn't happen. Is there a way to configure it by hands as well?

Probably better to create a new one.

I'm confused though - 192.168.x.x suggests that your machine did in fact locate a DHCP server which assigned it that address.

Are you running this in a VM using NAT mode? Are you certain you only have one DHCP server on your network?

comment:33 by kvark, 13 years ago

It actually was 169.x.x.x, not 192.168.x.x, sorry for the confusion. I was running it on a real hardware. Tried to reproduce it numerous times and failed. Maybe I just need to leave it for at least 5 minuts after boot for DHCP to finish the work correctly.

Note: See TracTickets for help on using tickets.