• Please review our updated Terms and Rules here

MTCP DHCP lease 60

Man, this is sure getting sour over a thing that‘s barely even a cosmetic problem. What application is this actually causing a problem with?
 
Isn't that exactly what you did with the OP in this thread? "that kind of assumes your DHCP and DNS are working correctly. Your router isn't quite there"

In the thread where we discussed this on vogons you were already angling toward that conclusion with me.

I drew that conclusion after examining a trace and seeing that the router was not doing something that should be done. That is no where near dismissing something out of hand; the trace was provided and I examined it. That is a big difference.

It's up to you to provide a trace or not to. I've asked multiple times, and I've shown my willingness to try to figure out what is going on. But it's difficult to work without data.
 
Man, this is sure getting sour over a thing that‘s barely even a cosmetic problem. What application is this actually causing a problem with?
It isn't, at least not for me. My only interest in reporting the bug was to help improve the product. Mike and I may not be soul sisters but he makes a tool that is exceedingly valuable to the community writ large. Trace attached
 

Attachments

  • TRACE.TXT
    11.5 KB · Views: 3
Pictures of the DHCP client table before and after running the traced request
 

Attachments

  • 20220905_151853.jpg
    20220905_151853.jpg
    2.3 MB · Views: 7
  • 20220905_151912.jpg
    20220905_151912.jpg
    2.3 MB · Views: 8
It's a quick look so I haven't done any deep archaeology that might uncover something interesting, but at first blush it is the same behavior. The mTCP DHCP client requests a HOSTNAME and the router seems to be honoring it, but not sending it back as part of the lease. From a client perspective it is inconclusive; what's in the lease packet from the server is supposed to be definitive/authoritative. Not acknowledging the requested hostname while using it is inconsistent.

A client could do a work-around like do a DNS lookup on the requested name to see if a response comes back, and if so, check to see if the response matches the assigned IP address.

Either way, it's another good data point. If anybody else is following this and is having similar trouble, please let me know what router you have and send a trace so I can confirm it.
 
barely even a cosmetic problem
It's not purely cosmetic. The issue would be very real if you actually need to use the host name on your network, because the DHCP client purges the hostname directive from the configuration file after the first DHCP request. Therefore your requested host name will only be honoured by the router the very first time you run the DHCP client. Every execution thereafter (I assume most users put DHCP in their AUTOEXEC.BAT) will result in the client requesting the default host name of DOSRULES.
 
I'm downloading and installing the latest version of mTCP now just to see what the hubbub is even about? The version I have doesn't emit the "DOMAIN" and "HOSTNAME" fields upon receipt of a DHCP offer, but it is asking the router to assign the name I have behind "hostname" (lowercase) in the config file and is apparently successfully getting what it's asking for...

It's not purely cosmetic. The issue would be very real if you actually need to use the host name on your network, because the DHCP client purges the hostname directive from the configuration file after the first DHCP request. Therefore your requested host name will only be honoured by the router the very first time you run the DHCP client. Every execution thereafter (I assume most users put DHCP in their AUTOEXEC.BAT) will result in the client requesting the default host name of DOSRULES.

Ah. okay, if the issue now is that the "hostname" line is getting blown away if no response at all is returned then, yeah, I would agree that's sort of unfriendly behavior. A better default would probably be to only overwrite it if: a: a response is returned AND b: it's different than what was requested.

I've been leafing through them (and getting a headache), and generally speaking... it seems like the DHCP RFCs are a little nebulous about whether a DHCP server MUST return a "read back" of a client requested option flag under all circumstances. (I looked in both the specific RFC about DNS updates and the general DHCP RFC.) There *may* be some support for a "sloppy" interpretation that under a circumstance like this it's okay for a client to assume what it asked for is acceptable if it isn't told otherwise (IE, you ask for hostname "happyboy" and you can assume that you are a happy boy if the server doesn't specifically tell you "no, your name is 'sadboy'"), but that leaves it open to interpretation whether the DHCP server actually supported what you asked for at all. Overall I would personally agree with Mike that a server that's not providing the response isn't being a good citizen, but I can definitely also agree with the case that a better default behavior would be to not wipe out the HOSTNAME config directive if already set.

(His proposal of having a separate "ask for this hostname" directive that won't be overwritten might actually be the best idea, because it would make it obvious if the server handed you out something different than what you asked for, which might be the case if you're using assigned DHCP addresses in your server.)
 
It bends the brain more when you consider a Linux machine where the hostname is set locally. If the DHCP server doesn't acknowledge the requested hostname the OS is certainly not going to change it's name to match. But yet every local program will think it's hostname is one thing, while everything else on the network might have a different view of it. (That happens when there is a name collision.)

In retrospect the HOSTNAME_REQUESTED and HOSTNAME_ASSIGNED would have been better to start with, but I think we can all agree this behavior was not expected. I want to gather more data points and see how many more routers do this; if it turns out to be very widespread it is easy enough to work around.
 
Did the older versions of mTCP wipe out the "hostname" if it didn't get a response or is that new behavior just for this version? If it's the latter would an acceptable workaround for now to be just use the DHCP binary from an older distribution?
 
Here's a trace from a completely different network, with a different DHCP server/router, in this case Netgear.
 

Attachments

  • TRACE.TXT
    10.1 KB · Views: 4
Looks about the same. Can you give me the specific Netgear model?
 
Did the older versions of mTCP wipe out the "hostname" if it didn't get a response or is that new behavior just for this version? If it's the latter would an acceptable workaround for now to be just use the DHCP binary from an older distribution?

An older version should work, minus whatever features the newer version has. I've been fairly disciplined about not breaking the config file.

I'd love to have more data points from both people who it is broken for and people who it works for. But the general problem is that people are really reluctant to send bug reports, so I have to keep polling forums and other places for them. And that's very time consuming.

I'll probably wait and see a little longer to see if I can get more feedback, and then post a test version that has the work-around I proposed above. If anybody else who is following this wants to provide me with a data point, just let me know HOSTNAME is working for you (or not) and what router you have. (Working means you have HOSTNAME set before DHCP runs, and it remains set after it. If it gets cleared, you are being hit by this problem.) (Use email please - my email is right in the output of the DHCP client.)


Thanks,
Mike
 
I have a test version of the DHCP client available. You can download it from https://brutman.com/mTCP/download/dhcp-2022-10-04.zip .

This version implements HOSTNAME_ASSIGNED. HOSTNAME is back to being read-only again. This work-around doesn't solve the problem in the DHCP servers, but at least it stops the nuisance problem of having the HOSTNAME line deleted in the configuration file.
 
Thanks, tested on a different DOS computer. (I am rotating them, so none of them rests forever). This one is Turbo XT 10MHz

I got this:
Warning: Your DHCP server may not have honored your hostname request.
Requested hostname: "TURBO10", Assigned hostname: ""

Hostname was not wiped out form tcp.cfg.

Huawei router says this:
Host Name: TURBO10
Device Type: --
IP Address: 192.168.1.125
MAC Address: 00:00:4d:11:68:51
Device Status: Online
Port Type: ETH
Port ID: LAN1
Online Duration: 0 hour 0 minute
IP Acquisition Mode: DHCP
Remaining Lease Time: 28570(s)
 
Thanks, tested on a different DOS computer. (I am rotating them, so none of them rests forever). This one is Turbo XT 10MHz

I got this:
Warning: Your DHCP server may not have honored your hostname request.
Requested hostname: "TURBO10", Assigned hostname: ""

Hostname was not wiped out form tcp.cfg.

Huawei router says this:

Thanks for testing it - that is the expected behavior.

Your router should be returning the assigned hostname in the DHCP options, but it is not. It is honoring the hostname request, but not telling the DHCP client. Hence the warning message.

With this new version HOSTNAME goes back to being read-only. If the router had also indicated that it honored the hostname by sending it as a DHCP option, then HOSTNAME_ASSIGNED would also be written to the configuration file.
 
Back
Top