Hostname Expired ?? Ip stil working ; DHCP renew Leastime
Igor_Rast
Posts: 357
Ok . So here is the next headace that poped op
I think it all has to do with dhcp leas period. lease renewal maybe ?
from yesterday the proxy server worked fine localy or from the net , loading the page , running the graphs (xml). tested it a couple of times during the next day . from other placed , latly at night the propeller was no longer letting me see the graph run, but the page was still coming up , it works.
MMM.
Finding out whats happening , I see I can not reach the propeller by hostname , But if I type it by ip then ip does.
If I go to see in my modem web-page, what dhcp computer are connected, usualy the px-210 is among them , now it is gone,
If i access the propeller by ip adress. then it does work fine .
I updated the xml to change the hostname used to the ip . then all works fine again ,
Anyway , the prop is gone in the list , still accesable by ip but not by hostname ,
so the modem must have removed them when the lease period ended orso .
How can we prevent this from happening. it does keep working for the rest fine , by ip.
Im using Mike G latest code found online
I think it all has to do with dhcp leas period. lease renewal maybe ?
from yesterday the proxy server worked fine localy or from the net , loading the page , running the graphs (xml). tested it a couple of times during the next day . from other placed , latly at night the propeller was no longer letting me see the graph run, but the page was still coming up , it works.
MMM.
Finding out whats happening , I see I can not reach the propeller by hostname , But if I type it by ip then ip does.
If I go to see in my modem web-page, what dhcp computer are connected, usualy the px-210 is among them , now it is gone,
If i access the propeller by ip adress. then it does work fine .
I updated the xml to change the hostname used to the ip . then all works fine again ,
Anyway , the prop is gone in the list , still accesable by ip but not by hostname ,
so the modem must have removed them when the lease period ended orso .
How can we prevent this from happening. it does keep working for the rest fine , by ip.
Im using Mike G latest code found online
Comments
The DHCP host name does not resolve on my network. Which is the main main reason I wrote the NetBIOS object; broadcast IP/name resolution on a local network.
I'm a little confused though... if the DHCP lease period has ended, which you identified. Why not simply invoke DHCP again? What is the purpose of this post? Is it informative? Are you looking for a solution?
okl. mike , maybe its not designed to do it , but by changing the CON value below in the dhcp object, I was always able to open the prop just by calling it by the hostname . I thouth youd incorporated the netbios inside it , ill have to go look at it more closly then , but it did work fine .probably the modem that remembers the hostname and redirects.
. What I think happened was that , when the leas time ended , The prop did not ask for a renewal of the ip adres,
when that happen , (foto previus post ), the propeller was gone from the list , Then the addressing by hostname stopped working ,
but it was still possible to get to the prop if i was using the ip adress, that it had,
I didn't want to restart it , so I would lose the current scenario
so today, I test it again ,
And now i can not even access it by its ip , so I cannot access the propeller anymore ,havent touched it sins yesterday
I went to look inside the modem page, and I can see that anothe tel has been assign the ip adress that the prop had before , thats probably why i cant reach
I thouth this was already beeing done , keeping the same ip assignd, now , if the prop is connected for long , someone else may get his ip assignd by the dhcp engine of the modem , making it unaccessable.
Restarting the prop I get every thing working again as normal , Getting the propeller by Hostname ,
Image is how the modem has registerd it
It is up to the client to manage the IP lease. That means you - the programer - must manage the lease.
As far as I can tell, the DHCP object is functioning as expected.
So for me the next job =
1. get the prop to find out when the leastime is ending, and renew it before it does it before it expires .
2. integrate the netbios protocol along with the rest of the driver . tp be sure its always accesable by hostname
yes ? or do i understand it wrong ?
Re: renewing DHCP lease. I tried modifying TcpSocketClientDemoDhcpDns by putting Main in a REPEAT loop...
...you can see the 4 different places I tried REPEATing. The later three REPEATs encounter DHCP discover error on 2nd pass. Just FYI - The first REPEAT option causes the SPI check to fail (maybe need to call a wiz.stop before (re)wiz.start or ?). I noticed if I just put a 'reboot' statement at the end of Main it works fine i.e. repeats the entire process (i.e. DHCP, DNS, file display) indefinitely. What's the best way to renew the lease? Is there a way to find out when it expires? Or maybe it's reasonable practice just to renew every 'n' hours? Thanks for your support.
DHCP lease time is a router\network configuration. My router defaults to 24 hours. You need either a timer or a real time clock. Set the timer to 12 hours then invoke dhcp.DoDhcp.
...that's what I thought I was doing with this REPEAT option I tried i.e.
...1st pass works but the 2nd pass results in DHCP 'Discover Error'. If you insert a REPEAT at the same place does it work for you?
The clue is that putting the REBOOT command at the end of Main (instead of using a REPEAT loop) works i.e. REBOOT is initializing something that allows DHCP to work repeatedly while REPEAT encounters DHCP 'Discover Error' the 2nd pass. I did try (re)moving the wiz.HardReset, doesn't change behavior.
You can also clear the buffer from the DoDhcp method.
I'll add a renew method, expose the lease time, and maybe add a timer object. A timer will require a COG.
In my situation with the current objects used,
what is best ,
1. to integrate the netbios into the prop to get it accesable by name ,( netbios ip resolution )
or 2. is the DNS object the best to implement with it to resolve the ip by name
but then there wil be a socket needed to keep resolving the ip, ? or do i understand the working wrong
Or doesnt it matter that much , if its only inteded for local acces ( hostname ip resolution)
still testing with the dhcp renewal. the extra cog needed you mentio is the only thing making me think twice . cant a counter do the job , (i:= i++. if i > 100000? renew ip )
happy to see your renewal code.
Still seems to have a problem. I cut down the TCSDDD code to just do repeated calls to DHCP...
...it still has same behavior - DHCP works the first pass, gets 'Discover Error' 2nd pass. Does it work at your end? Interesting if I take out the REPEAT and stick a REBOOT at the end it works fine.
I appreciate your help testing the objects. I'll try to get a formal fix out this weekend.
A Wireshark filter using "port 67 or port 68" would go a long way helping me to figure out what is happening on your network.
...interestingly, using wiz.SoftReset instead of wiz.HardRest doesn't work (i.e. still encounters the '2nd pass Discover Error'). However, this 'fix' isn't perfect since now, though the program makes it thru the 2nd and subsequent passes of DHCP, the problem is shifted to '2nd pass DNS error' (resolved ip =0.0.0.0). BTW, as with DHCP, do I need a bytefill to clear the buffer between repeated use of DNS?
I will test some more, don't want to be a bother until I have a better feel. Sorry I can't be of more assistance with wireshark - it can't see any of the DHCP activity handled by the router. The obvious solution is to set up my own server, but that's beyond my means and ability at this time. Maybe there's a way (ex: port forwarding) to setup a test? But I can't fool around too much with my 'work' PC nor the LAN - if I crash the network wife & kids won't be happy :=)
I have to go out of town for a few days, get back into it next week. Thanks for your support Mike!
I did some more tryling with the dhcp , renewal .
Using the code below , extracted from the html5graphdemo .
The renewing works fine with my ISP modem , but will not work with my linksys modem
With My isp modem , it looks to get the dhcp ip assign succesfully repeatedly , so incorporating it by a timmer or clock will be all thats left .
Screenshots ,
wireshark log ISP modem succesful.zip
but when I disconnected all from the network modem en connect it to the linksys modemto get the wireshark (udp.port==68) and (udp.port==67) working on the linksys to so sniff out whats happening . because its not working there ,
If I see closely the offer is beeing sent to the wrong ip adress (sourse ip ) therefore never getting to the prop for it to send the ack back out ,
wireshark logs Linksys fail.zip
Hope this data is helpfull
...now it works fine for REPEATing the call to DHCP (and then DNS). Why don't you try it with your linksys Igor, maybe it will work for you too.
I think the problem with the linksys not getting the renewd ip has a different origin, because its also not getting the ip correctly the first pass,
If i look at what the wireshark sees(previous post) , The DHCP offer that my linksys modem sends out after the discovery request from the wiznet .
Is not formatted well , With this I mean ,
The modem is suppose to send the DHCP offer to 192.168.2.254 (dhcp server ip) . But its sending the offer to 192.168.2.1 wich was probably the ip that was supose to be offerd to the wiznet , this probably is the cause of the ip not getting set, Did have the problem before, Mike did a bugfix on it . But I havent used the linksys modem after that till now . thats when i realized the bug was still there ..
and probably inside the discovery request . correct me if im wrong
I saw that mike did a few changes and is working on the dhcp leastime , he has updated the source codes. now trying to figure out whats changed and if it takes care of my problem with the linksys.
@Mike . Hows the leastime getting along, what were the bug fixes that you implemented , were they for the ip problem that I have now or was it somthing else beeing fixed in the object ?
Igor
The DHCP packet is broadcast to 255.255.255.255. The source, 192.168.2.1, is the IP address of the router sending the Offer and ACK packet. This is correct. Only one of the WireShark logs shows multiple DHCP requests; increasing Ip. This logs shows the router responding with a DHCP NAK. Probably due to the requested IP being 0.0.0.0 and not on the network. The other logs show only one DHCP request. We might have to look at the testing code for errors or the logs did not run long enough to capture the DHCP request.
The DHCP object has been updated/refactored.
I do not use wiz.SetIp(0,0,0,0) and it works fine.
1. Just curious, does the previous test work with the wiz.SetIp(0,0,0,0) stmt. on your setup?
2. To isolate the DNS issue I moved the REPEAT statement...
...on my setup it resolves IP correctly the first pass (i.e. after F10 or REBOOT), 2nd and subsequent pass return 0.0.0.0.
3. Now I'm experimenting with DnsDemo.spin, just trying to put it in a REPEAT loop...
...tried putting the REPEAT a few places, none successful in making a 2nd pass As shown, the terminal displays...
...Note that I commented out the ' if (rcode == 0' check so the program displays the ParseDnsResponse even though there's a 'Name Error 3''. So in the display notice a) 2nd & subsequent DNS requests send less bytes than the first and b) the failing ParseDnsResponse seems to have one valid IP (instead of two as in the correct first pass) and one oddball 'ip_-1 0.0.0.0'.
Does this code exhibit similar behavior on your setup? If you tell me the proper way to put DnsDemo.spin in a REPEAT loop (i.e. where to put REPEAT statement) I can try it on my setup, help zero in on the difference. Thanks a lot Mike!
Im trying to understand first to minimize stupid questions beeing asked .:P .
About the DNS . to get the DNS working along with the rest ,as I did understand it wrong before ,
does it take just the adding of the dns object to the list
Adding a url thats gets resolved in the DAT section
and adding the next lines below the dhcp statments in the repeat loop.
Was this all thats needed to incorporate the dns with the server ???
Im having a dificult time with the DNS as my modem seems to already resolve the hostname to the ip adres, and like mike said this is not always the case . so I havent found a way to check if the dns itself is working . (without renewing )
I have updated the new source files from mike , Using the code below to test the ip renewal and the dns
Okay . Connected to my ISP modem , this is what happens ,
The Ip renewal seems to work fine , It did work fine before also with this modem , renewing it multiple times without a problem.
But for the DNS , if i incorporated it the right way then . Resolves only on the first pass. and after that keeps resolving to 0.0.0.0.
With the DNS lines inserted in the code , ( not resolving dns on second pass and forth )
Without the DNS inserted in the code .Seems to renew fine . only ip
wireshark logs ISP modem LOG.zip
Thats was the ISP Modem
Connecting all to the linksys modem I get the following result ,
The DHCP ip assigning issue seems to be fixed with the updated code.. Renewing it does also look to be working fine , This was not the case before . so that issue seems to be fixed,
This is the case without the DNS code beeing run.
If i put the DNS code also in it , I can see the DNS never gets assignd , not even on the first pass , always resolving to 0.0.0.0 probably the bug mike is now already aware of.
So Here some more logs where this is going wrong , hoping to get it all working.
Wireshark log linksys modem Linksys log.zip
Igor
o @ twc , I dont reset the ip to 0.0.0.0 and that works fine with both modems
@ mike , where to i incorporate the dhcp.GetLeaseTime to get it right , can you give a small example
I understand you and Mike don't need this wiz.SetIp(0,0,0,0), I was wondering what happens if you include it - still works OK or ?]
I got the updated software, results not changed i.e...
1. With the wiz.SetIp(0,0,0,0) I can make multi-passes thru DHCP, without it 2nd pass is Discover Error
2. 2nd pass thru DNS fails (resolves to 0.0.0.0) with different 'Bytes Sent' (using modified DnsDemo.spin in post #21) than 1st pass
Mike, maybe the DhcpDemo.spin and DnsDemo.spin should loop repeatedly to demonstrate proper usage and expose any issues. I'm not sure if my hacked DnsDemo.spin (REPEAT stmt. added) is proper, might/might not have the same issue (i.e. different 'Bytes Sent' on 2nd pass) on your & Igors setup.
In this instance, the test case caused the bug due to the destructive nature of dns.ParseUrl() and (I believe) the scope of repeat. ParseUrl converts a url string to its encoded DNS packet value. The url www.weather.gov is converted to the following encoding in a two step process
The first steps replaces all the dots in the source string with zero terminators. The second step reads each url segment length copies the length to the DNS packet then moves the segments to fledgling DNS packet.
When this method is placed in a repeat loop, the second iteration is not longer "www. weather. gov", $0. It's $03, w, w w, $00. Hence, the name error returned from the DNS query. I'd have to runs some tests but I believe the same scope issue is happening with the inline constant, string("www.weather.gov"), within the repeat loop.
I added a small buffer to Dns.Spin and DnsDemo.spin. The URL is copied to the buffer. dns.ParseUrl() modifies the buffer version and leaves the original. I'm not too fond of this solution. I might look into making the dns.ParseUrl() a little smarter so it can recognize an encoded URL. I'm not sure how often this situation will occur in a real world application but since it is possible, I'll add validation.
Lease time is a property of the Dhcp.spin. This property is populated from the DHCP ACK packet and is the time in seconds of the lease.
Ultimately, it has to be up to the programmer to implement a lease handler. There are just too many possible hardware and software requirements to consider. I have a few ideas and built 2 beta prototypes. However, both lease handlers have resource trade-offs.
and indeed that seem to fix the issue that the domain adres not being resolved on the second pass ( MY ISP MODEM) .
with the original url surviving , the ip keeps getting resolved on the continuing passes . Nice ,.
But with the Linksys modem , The issue is still the same, the domain name never resolves the ip . not even the first try.
the dhcp ip assignment doesnt seem to have any problems getting the ip renewd
@twc ,
i added the wiz.SetIp(0,0,0,0) inside the repeat to test out for you ,
letting my code look like below
Changing this didnt seem to have any effect on the workings , the senario that did work already keeps working , and to others still dont work. and behave the same
so this doesnt affect my setup
What do you mean by resoursce trade-offs , things beeing different with a different modem manufacturer >?? or that they all use different leas times? zo making a handler that works on all is kinda a verry big job .?
I noticed that the leastime is always the maximu leasetime time ( mine 864000 sec - 1 day) on the ongoing passed , meaning the lease time is beeing renewd on the dhcp pass, but ,
the handler will have to figure out the leasetime of the current session without it renewing it , and only renewing if it passed half the release time , ( at half the time I readed somewhere that is usualy the right time to renew the ip adress ) .
You will make me a verry happy man if I can see the 2 beta handler prototypes your talking about
@Mike
I noticed that if I use a different name in the main object for the from the name of the hostname in the dhcp object hostName to resolve the dns hostname ,
then it never resolves,
Ofcourse this is only with my isp modem with the linksys its not working at all .
If this is the case , isnt it best to let both of them use the same variable , so this mistake is not made making it not function. for resolving its own ip to a domain name? making calling the prop by hostname work by dns
Apparently, your ISP modem is able to register a name to IP. The Linksys router can not. I believe this is particular to your network configuration and something you'll have to work through.
The host name field in the dhcp object does not resolve on my network. I also use a Linksys router. I have to use NetBIOS name services to resolve name to IP on my local network.
I think you are getting stuck on a network device configuration that is somewhat unique.
The linksys router was not connected to the intertet/ISP modem . I just pluged the propeller to the linksys router , and unpluged my pc from the isp modem and put it also connected to the linksys modem , ,the pc I only connect to be able to wireshark it all. but before I just used the serial terminal. So there is no connection with the ISP modem in the testcase nor with the internet , its like a standing alone network.( it replaces the ISP modem )
i thout I use this test setup just to make sure the hole thing works with all modems .
NETbios ,DNS , Hostname , Indeed verry confusing with me , and the modem that I have . because its already resolving it . making it even more difficult to catch when its working or not
so if I understand you right this time, its best fot me to incorporate the netbios for it to work in most senarios ( also with your modem) getting called by the name
so ill have to incorporate the netbiosunittest object to the current project in place of the dns resolving that I am doing now,? ..
and the currect appouch of adding the dns resolving etcc is not the best solution/not the solution at all?
Did a Nmap on the prop and this is wat I get to see,.Looks like the dns working ? or is this not the case still cant find a better way to test
I do know - I have a Linksys router and the host name does not resolve. I downloaded nmap and tried to find the host name. It did not work. I ran the NetBIOS demo then nmap found the name. nmap found the name by broadcasting NetBIOS name services. Go figure! The main reason I created NetBIOS name services was because the DHCP host name did not resolve to an IP. I remember being very happy to find a DHCP option for Host Name. I though it would work - I was wrong.
How about trying an external address like www.weather.gov.
You do realize that the WizNet had two different IPs according to post #26 192.168.2.2 was assigned by the ISP modem while 192.168.2.100 was assigned by the Linksys. What was the network configuration when nmap was run in post 29?
Secondly, I wrote a DNS client - that's all. The client does not register with a DNS server nor does the DHCP object register with a DNS server.
ill continue with some more teste in the morning