can't get dhcp to work

[mrkrupa]

I thought I could solve this myself. I have a lucent wifi card that works using manual configuration. I've had the card about two years. Recently, I was playing (fiddling) with my netbook (the only computer over five years old that I still use all the time) and had to reboot losing my config. Anyway, I thougt I would try to once again get it to work in auto like everybody on this site says you can. Endless attempts later I am still only able to log on with the settings configured for manual, putting in my IP, gateway and so on.

I went to Diem's page and loaded flFinger per instructions but again to no avail.

Any suggestions from the residents? Thanks.

Paul Krupa

[Beakynet]

I am not sure what you are connecting to here, an access point, a hot spot or your own WiFI equipment!

DHCP requires a HDCP server to assign IP addresses according to a set of rules to the connecting devices. If the equipment your netBook is connecting to is not configured to assign the IP address to the Lucient Card, then this will never work.

David

[mrkrupa]

Thanks. I have two other wireless cards that connect to an AP on this network as well as my desktop that is hardwired via ethernet card. The device is a 4 port SMC barracuda. It works pretty well. I have had it as long as the card. The other devices get their assignments just fine.

I thought maybe I screwed up the driver somehow.

Paul Krupa

[PlutoPants]

I have a Buffalo wifi card running on the Lucent profile and - yes - I can only get it to work manually. DHCP just doesn't work - intermittently on some DHCP networks admitedly. Don't know why, but I gave up fiddling and settled for manual IP - at least it's low power consumption!
George:confused:

[Beakynet]

I also have a Buffalo wifi card running on the Lucent profile and i can get DHCP to work on my home setup with a Netgear WiFi Router. The MAC address is set up in the router though (for added security) and the IP address is perminantly allocated to this MAC Addr, but the Psion is configured for DHCP and it works well.

David

[PlutoPants]

AH,
Now that makes some sense.
Many routers I have seen configure through the web browser from the first computer that set them up - therefore that one gets recognised.
I guess the Netbook etc is just a little bit different in that respect.
I've tried in all sorts of offices to get DHCP to work for me in the Netbook, but perhaps it's something that just has to be.
I continued using static IP addresses in my own network so I could use VNC and the like easily.
George

[Beakynet]

Originally posted by PlutoPants
AH,
Now that makes some sense.
Many routers I have seen configure through the web browser from the first computer that set them up - therefore that one gets recognised.
I guess the Netbook etc is just a little bit different in that respect.
I've tried in all sorts of offices to get DHCP to work for me in the Netbook, but perhaps it's something that just has to be.
I continued using static IP addresses in my own network so I could use VNC and the like easily.
George

I use VNC too and have a static IP address assigned to the Router (which is also a firewall with network address translation). This means I get teh best of both worlds.

One thing to note is that not all Access Points are set up to act as DHCP servers, some can't or they asign from the DHCP Server on the wired network. In the office my netBook has an assigned IP address because of this, but at home it doesn't. I can't even remember why I assigned the IP address to the MAC address in the Router - it might have been on a whim. - I might delete the assignment and test again when I have a bit more time to play.

David

[PlutoPants]

I've just used this info as a suggestion for someone on the EPOC Digest - He had trouble with a CISCO WiFi card & Netbook.
Amazing how equipment conforming to a standard is so similar, but then so different isn't it?
George:)

[mrkrupa]

I suppose I should be glad I am not alone with this problem. Another development today. With the proliferation of wifi, I found myself (or my netbook) trying to hop onto a Lynksys AP instead of mine as I enjoyed the heat of my Washington DC morning. As an experiment, I quickly set the default DHCP and it took off. So I suspect the problem is a compatability one with my Lucent card and SMC AP/router.

This brings up another point. Is it ethical to hop onto these broadcasts?

Paul Krupa

[MAlexander]

I hate to open up an old thread like this, but perhaps this will be useful to someone searching for this information in the future.

I have several DHCP servers on my network and my netBooks (2 of them) work with all but one of them, which (of course) happens to be the only one I normally use. Since the one it doesn't work with is the Unix bootpd program which is open source, I was able to figure out what the problem is. This is also widely used around the Internet, so if it is incompatible with the EPOC DHCP client it's not surprising that others have had problems.

To get an IP address using the DHCP protocol the client (the netBook) sends a "DISCOVER" packet (see RFC 2131 (http://www.faqs.org/rfcs/rfc2131.html) for a description of the DHCP protocol) and the server replies with an "OFFER" packet. Then the client sends a "REQUEST" packet and the server responds with an "ACK" packet. The problem is with the "sname" field in the OFFER and ACK packets. This field (according to the DHCP protocol spec) has two possible uses. It can be the name of the server sending the packet (since this is ignored, that means the field is essentially unused) or it can be an extension of the options field in the packet. Which of these is the case is determined by the presence or absence of an "Option Overload" option in the options field of the packet.

If there is no "Option Overload" option in the packet sent by the server, the client should ignore the sname field in the packet. However, it appears that the DHCP client in the netBook doesn't work right in this regard and tries to interpret the sname field as options in all cases. If this fails it ignores the packet. The bootpd DHCP server fills in its name in the sname field and when I made a one line change to it to set the field to zero, the netBook DHCP client started working with it. There is also a "file" field in the packet which has a similar dual use and I suspect that the EPOC DHCP client has a similar bug with it, but I haven't tested this theory. Since bootpd sets that field to zero it isn't an issue.

If I had access to the source for the netBook DHCP client it would probably only take a few minutes to fix this bug. It might even be possible to patch a fix into it, but I haven't looked into this. However this information still might be useful (or at least interesting) since it might let you fix your DHCP server to be compatible with the broken DHCP client in the netBook. At least it explains why so many people have had problems and why the failure seems so random.