• Please review our updated Terms and Rules here

MTCP DHCP lease 60

A

archeocomp

Experienced Member
Joined
Apr 29, 2012
Messages
416
Location
EU/SK
Since I changed my home network all my DOS computers claim their DHCP lease time is 60s :)
As there in no way to use such short lived automatically configured tcp.cfg file, I had to resort to static IP addresses.

My guess is it is most probably not a bug in mTCP. Is there any way to inspect DHCP communication?

Just for info my home network looks like this:
before: VDSL TP-Link https://openwrt.org/toh/tp-link/td-w8970_v1 (DHCP server)
now: optical Huawei HG8245 (stock, lan master, DHCP server) -> TP-Link Archer C7 as AP (OpenWRT, no DHCP)
 
You could just set the parameter in the mTCP config file where you can request a longer lease from the DHCP server ... A reasonable DHCP server will respect that.
 
All my mTCP systems use static IP via NAT. No DHCP necessary, and no problems. I use subnet 10.x.x.x, so I could (theoretically) have enough addresses for a large city (~16M) a la RFC1918.
 
Turns out I was still using 2020 mTCP version. Somehow I missed the July 2022 release. Now it really works with the new parameter . But there is maybe another problem. It ignores and/or removed my HOSTNAME entry. Is this expected behaviour?
I was thinking this option will tell dhcp server name of the machine.

tcp.cfg
Code: 
DHCPVER DHCP Client version Jul  1 2022
TIMESTAMP ( 1662283008 ) Sun Sep  4 11:16:48 2022
PACKETINT 0x60
MTU 1500
DHCP_LEASE_REQUEST_SECS 86400
HOSTNAME AT386SX

FTPSRV_PASSWORD_FILE C:\TCPIP\ftppass.txt
FTPSRV_LOG_FILE NUL
FTPSRV_SESSION_TIMEOUT 3600
FTPSRV_EXCLUDE_DRIVES AB

IPADDR 192.168.1.119
NETMASK 255.255.255.0
GATEWAY 192.168.1.1
NAMESERVER 192.168.1.1
LEASE_TIME 86400

reply from DHCP
Code: 
TCP DHCP Client by M Brutman (mbbrutman@gmail.com) (C)opyright 2008-2022
Version: Jul  1 2022

Timeout per request: 10 seconds, Retry attempts: 3
Requesting a 86400 second lease
Sending DHCP requests, Press [ESC] to abort.

DHCP request sent, attempt 1: Offer received, Acknowledged

Good news everyone!

HOSTNAME
DOMAIN
IPADDR 192.168.1.119
NETMASK 255.255.255.0
GATEWAY 192.168.1.1
NAMESERVER 192.168.1.1
LEASE_TIME 86400 seconds

Settings written to 'C:\TCPIP\tcp.cfg'

and the line in tcp.cfg:
HOSTNAME AT386SX
is deleted
 
In short, I wouldn't worry about it. It's documented in the PDF but the short story is that the HOSTNAME is a request to the DHCP server, and the DHCP server is free to ignore the request. It can assign something else, or nothing at all. Except for requesting the HOSTNAME mTCP doesn't use it for anything. And as far as your network goes, the HOSTNAME is whatever the DHCP server assigns it to be, and it doesn't matter what the client thinks about it.

Can you send me a trace? You are the second person to report this, but the first person has not sent a trace even though they reported the behavior weeks ago. Home/consumer DHCP servers seem to be honoring HOSTNAME. I think the other person who reported the problem had a Ubiquiti unit, which is a bit higher end. Does your Huawei HG8245 allow you to set the HOSTNAME by MAC address for your machine?

In a future release of mTCP I'll probably separate HOSTNAME into HOSTNAME_REQUESTED and HOSTNAME_ASSIGNED, but this behavior really has no ill-effect and it's probably due to the DHCP server implementation.
 
There is section in Huawei config which says:
DHCP Static IP Configuration
On this page, you can configure the reserved IP address that is assigned using DHCP for the specified MAC address.
Click to expand...
I did not configure any so far.

Funny thing is, that Huawei seems to accept proposed HOSTNAME (look at the picture), screenshot is with missing line in tcp.cfg therefore it say DOSRULES (your default). I could also see my specific HOSTNAME ALI386XS25 when I tried it. But Huawei seems not to return the HOSTNAME back to the DHCP client.

I tried to use pkttool, but as soon as I start it I can not run DHCP anymore right? There is no way to put pkttool.exe in backgrond in DOS IIRC :)
So it seems I need another DOS machine and run pkttool there and capture its output in RAW file? I will do it please just give me some instructions how to obtain a trace. Then I will excavate another AT machine from basement if necessary. BTW I am using raspberrypi right now, if it is posible to do network sniffing here I can do it.

huawei1.jpg
 
Check the section of the PDF on debugging - there is a trace mode. You enable the trace, then run DHCP. Here is the short version:

  • SET DEBUGGING=255
  • SET LOGFILE=TRACE.TXT

-Mike
 
Ok, the trace confirms that your machine is sending a hostname and that the router is not sending it back. I could see why it would not send it back in the case of an invalid name, a name collision, or some other error. But in this case it goes on to use the requested hostname, which makes no sense. I believe the router is wrong and that if it is going to allow a client to request a hostname, it has to return that hostname back in the DHCP offer and lease packets. Looks like a bug.

As for mTCP, it doesn't care - nothing on the DOS side uses the hostname. It is a convenience for other machines on the network to find your DOS machine, but that kind of assumes your DHCP and DNS are working correctly. Your router isn't quite there.
 
Looks like that. As hostname is usually read only value not many people stumbled upon it. This Chinese router is good enough to be sold worldwide:)
 
mbbrutman said:
Ok, the trace confirms that your machine is sending a hostname and that the router is not sending it back. I could see why it would not send it back in the case of an invalid name, a name collision, or some other error. But in this case it goes on to use the requested hostname, which makes no sense. I believe the router is wrong and that if it is going to allow a client to request a hostname, it has to return that hostname back in the DHCP offer and lease packets. Looks like a bug.

As for mTCP, it doesn't care - nothing on the DOS side uses the hostname. It is a convenience for other machines on the network to find your DOS machine, but that kind of assumes your DHCP and DNS are working correctly. Your router isn't quite there.
Click to expand...
I was the other person who reported this behaviour. My ubiquiti does the exact same thing, uses the name but doesn't "reply" it back to the DHCP client. Two completely different manufacturers having the same process doesn't seem like a bug with the router to me, perhaps they aren't wrong.

I would suggest you amend your client to assume the name was used if nothing was received to directly contradict that assumption.
 
maxtherabbit said:
Two completely different manufacturers having the same process doesn't seem like a bug with the router to me, perhaps they aren't wrong.
Click to expand...

It depends how you define “not wrong”. The paragraph from the relevant RFC says this:

Code: 
   The server MAY be configured to use the name supplied in the client's
   Client FQDN option, or it MAY be configured to modify the supplied
   name or to substitute a different name.  The server SHOULD send its
   notion of the complete FQDN for the client in the Domain Name field.
   The server MAY simply copy the Domain Name field from the Client FQDN
   option that the client sent to the server.  The server MUST use the
   same encoding format (ASCII or DNS binary encoding) that the client
   used in the Client FQDN option in its DHCPDISCOVER or DHCPREQUEST,
   and it MUST set the "E" bit in the option's Flags field accordingly.

In RFC-speak “Should” means “This is the correct/recommended way to implement this feature“; you should have a good reason if you’re choosing to ignore this part of the specification. If the router supports doing anything with hostnames it’s difficult to think of a valid reason to skip this.
 
Since its three directives are MAY, SHOULD, and MUST I'd say the only way you could definitively declare the implementation to be wrong would be if it said MUST. Otherwise it's subjective.
 
But the point there is that a client cannot be considered “wrong” if it expects the “should”. An implementation missing a “should” may be justified in certain circumstances but is by definition deficient.
 
Eudimorphodon said:
But the point there is that a client cannot be considered “wrong” if it expects the “should”. An implementation missing a “should” may be justified in certain circumstances but is by definition deficient.
Click to expand...
Ok so neither of them are "wrong". Now it just becomes a matter of accommodating practicality.
 
Well, I have one trace from a router that has this behavior - thank you Archeocomp! It's so hard to get people to send traces, even when I directly ask for them.

The spec is not great on the HOSTNAME and DOMAIN parts. My *safe* interpretation is to use the values given in the final DHCP packet exchange, which are definitive for what the server has given the lease for. When a router doesn't return a hostname I can't tell if that is because there was an error or a naming collision. I documented this behavior in the PDF. The possible solution I posted earlier (HOSTNAME_REQUESTED and HOSTNAME_ASSIGNED) might be slightly better but it also really doesn't do much to improve things; it just keeps people from having to fix the configuration file when they run into a router that doesn't confirm the HOSTNAME. As I said before, mTCP doesn't use this name - only other machines on the network might use it, assuming the router found it acceptable. And if the router is going to use it, then it should have returned it in the DHCP lease.

Based on download logs there are several thousand downloads of the latest version of mTCP. There are probably a few hundred to 2000 people who have actually run it. Of those, some may not be using HOSTNAME or have not noticed that their DHCP server is not sending a HOSTNAME, but otherwise it is probably safe to assume it is working correctly for the vast majority of people. I'll gather more data points and figure out what to do for the next mTCP release.
 
mbbrutman said:
Well, I have one trace from a router that has this behavior - thank you Archeocomp! It's so hard to get people to send traces, even when I directly ask for them.
Click to expand...
I'll post one right now if it will change anything, but my Ubiquiti does the exact same thing as his. Why didn't I post it before when you asked for it? I knew that it was only a matter time until someone else reported the problem - and that you would inevitably declare my router was simply wrong until someone else corroborated it.
 
So even though I was working in good faith to try to diagnose your problem and I asked you for a trace weeks ago, you just assumed that I would dismiss whatever I saw out of hand. Then why would I ask for a trace? For show?

If you are going to report a bug and I ask for a trace, then please send the trace. Don't blame your not sending the trace on me - that's on you.
 
mbbrutman said:
So even though I was working in good faith to try to diagnose your problem and I asked you for a trace weeks ago, you just assumed that I would dismiss whatever I saw out of hand.
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top