PUB RenewDhcp is added to the Dhcp.spin object. It's pretty simple - it sends the Request packet and parses the response. So the initial IP request uses the whole Discover/Offer and Request/Ack transactions while a renew invokes only Request/Ack.
I quickly tested the theory (I researched the DHCP renew process) and it worked surprisingly easy on my box. Please let me know if it works out for you.
After a bit of headscratching I noticed you changed your pin connections :=)
Congratulations Mike, RenewDhcp works and nowI don't need wiz.SetIp(0,0,0,0) to renew. Just note that success of the initial DHCP request (i.e. dhcp.DoDhcp) for my Netgear still relies on the src ip = 0.0.0.0. For instance, if I manually set the source ip to a different (but valid network) address, the initial dhcp.DoDhcp will just keep retrying...
'DHCP Process
wiz.SetIp(10,0,0,160) 'this causes problem, will 'Retry DHCP' forever
repeat until DoDhcp
CreateTransactionId
pause(1000)
pst.str(string(CR, "Retry DHCP: "))
pst.dec(i++)
pst.char(CR)
As noted all along, it's seemingly not an issue after power-up/F10/wiz.HardReset or ? i.e. the src ip seems to 'default' 0.0.0.0 initially. But I want to mention it since I'm not exactly sure what reason(s) the src ip apparently comes up 0.0.0.0 first time. Could be your code setting it, W5200 power-up and/or HardReset or F10/boot variable initialization by Spin or ??? Anyway for now I don't need to explicitly set src ip = 0.0.0.0 prior to the initial dhcp.DoDhcp and after it succeeds dhcp.RenewDhcp works like a champ.
After a bit of headscratching I noticed you changed your pin connections :=)
Yeah, I'm using the new WizNet 5200 demo board.
As noted all along, it's seemingly not an issue after power-up/F10/wiz.HardReset or ? i.e. the src ip seems to 'default' 0.0.0.0 initially. But I want to mention it since I'm not exactly sure what reason(s) the src ip apparently comes up 0.0.0.0 first time. Could be your code setting it, W5200 power-up and/or HardReset or F10/boot variable initialization by Spin or ???
All network parameters are zeroed on start up. I'll add a add a Boolean parameter to the DoDhcp method so the IP can be set to 0.0.0.0.
BTW, there is also a PUB SetRequestIp(octet3, octet2, octet1, octet0) method which will request a particular IP.
The boolean parameter and SetRequestIp along with dhcp.RenewDhcp should cover all the bases. With my Netgear, REPEATing dhcp.DoDhcp seems to always return the same ip address based on the (unchanged) MAC address. dhcp.RenewDhcp is also returning the same ip address each time, but I wonder what it does if a) MAC address changes (unlikely app scenario) or b) the prior lease has expired? (the dhcp.DoDhcp option works in both cases). What would be a typical app situation taking advantage of dhcp.SetRequestIp? Anyway, just curious - both options (REPEAT dhcp.DoDhcp with ip=0.0.0.0 or REPEAT dhcp.RenewDhcp) working solid at this point.
but I wonder what it does if a) MAC address changes (unlikely app scenario) or b) the prior lease has expired? (the dhcp.DoDhcp option works in both cases). What would be a typical app situation taking advantage of dhcp.SetRequestIp?
I do not recommend changing the MAC address during run time. Certainly testable.
The lease time returned during the DHCP process is exposed through the dhcp.GetLeaseTime. Renew the release at [lease time]/2. If the lease time has expired, execute dhcp.DoDhcp(). The top level object must handle the timing.
Use dhcp.SetRequestIp to request an IP on the network. I use dhcp.SetRequestIp and HOSTS file to bind an IP to name.
Committed the following files...
So the initial IP request uses the whole Discover/Offer and Request/Ack transactions while a renew invokes only Request/Ack.
had that on my mind for a long time , seems it did the trick
.
here a wireshark log of the succes renewal . renew good.zip
One thing still , I mentiond it before in post #55
if i use the code like you changed it also in the html5 graph , the ip doesnt renew if there is no activity taking place . And only renews the first time the activity contiues. So if nothing happens for a day the leastime still expires .
Use dhcp.SetRequestIp to request an IP on the network. I use dhcp.SetRequestIp and HOSTS file to bind an IP to name.
the hostfile you refer to , is it also on the propeller , or is it hosten on a computer on your network ??
if i understand it resolves tha ip to the hostname, how do I get it implemented with the current code , been trying to get the netbios running but its proven a little bit of headace. think you can point me in the propper direction/solution for the resolving to ip issue of the propeller
can you confirm this , or is this not the best way to keep it renewing even if there is no activity taking place for a long time.
Looks good to me.
the hostfile you refer to , is it also on the propeller , or is it hosten on a computer on your network ??
if i understand it resolves tha ip to the hostname, how do I get it implemented with the current code ,
The posted HOSTS file link contains details on HOSTS files, please read.
been trying to get the netbios running but its proven a little bit of headace. think you can point me in the propper direction/solution for the resolving to ip issue of the propeller
NetBIOS name services all that's needed to bind a name to IP. Essentially, it is a broadcast on the local network that lets everyone know that PROPNET is bound to an IP. This is unit test code so the code a little raw and not user friendly. If you need IP/Name resolution now, I suggest you do some research. The source code is open and can provide a template.
Once I get the time, I plan to convert the NetBIOS unit test into an object. Right now I'm very busy with the WizNet 5200 Quick Start.
You can use the SetRequestId method of the dhcp object to request an IP during the DHCP process. If you set a high enough IP address and use a HOSTS file entry with the same IP you don't have too worry about IP reassignment.
You can use the SetRequestId method of the dhcp object to request an IP during the DHCP process. If you set a high enough IP address and use a HOSTS file entry with the same IP you don't have too worry about IP reassignment.
That can work too, but I dont think that is duable , if it is used in different networks every time ( customer) . maybe the network is using a completly different range of ip (e.g. 192.168.2.xx of 10.0.0.xx). then it wont work again .
and you need to make a hostfile ever time
I think the netbios is the best solution , So the final controller is just a plug & play .
network cable atached , switch on , acces by hostname
ill be digging in the netbios for the next couple of days
an other question about the security issue .
is an ssl or tls connection with the wiznet possible ?
I now use a secure tls connection with the database , where the html page is stored ( prop redirects to it ) .
so the connection between a client , and my server is secured for a man in the middle sniffer,
but the connection from my server to the prop ( mine localy now , or one on an different ISP ( custemer )) is not secured .
initialy there was the basic authentication, but I had to get over the option to keep it simple to make a new username and use it with the controller
this was because the ( root) username was stored on the eerprom and not changable during normal use.
now I use a database and php sesions to log in ,
but the security is now gone ,
I was thinking of base enqripting the url that the prop serves , so at least they are not easily readable
but a ssl of tls connection would be auwsem
any good advise before i begin digging into the info?
Ok Mike , I have thout about it for long , wireshared the life out of my network , but still cant figure out why it works like it does
I know you told me more than once that the dhcp is not suppose to resolve the hostname to ip . but this was still the case with my modem and is part of an option that is possible to use via dhcp a cant leave it alone
anyway . there is something realy fishy going on
Now with the latest drives , the ISP modem where the resolving by DHCP used to works , It Only works for a couple of minuts .
if I turn the prop on , let the dhcp procces go allong for it to get the ip assigned , i can resolve to ip just by using the hostname.
new to this is that now after a couple of minutes (about 5min) after turning the prop on the hostname doesnt resolve anymore . sniffing lets me see that the modem is just not resolving.it anymore , as it did this just fine before. a dns query also doesnt return the ip adress.
.
anyway . I went trying if the name also resolves on the linksys router for the first couple of minutes
to my surprise , at the linksys router the resolving seems to be working fine overall , it didnt work before , now it does resolve the ip .
I see it uses a dns query to resolve it , looks like its also a bit slower , if a see the repeated xml request going out . but it is resolving with the linksys modem
isp long log.zip
ISP modem, resolving by hostname worked fine before , ate No 1254 in the log , was the last time it new the correct ip , after that it didnt resolve anymore , all the rest of the data looks to be the same..
Maybe the hostname by dhcp wil work afterall , hope we can get out of this one
UPDATE
I noticed in the discovery packet.the hostname is inserted in the discovery packet correctly in the dhcp option field 12 . wich is the correct place for it . ,
but at the parameter request list , there is no request going on for the hostname , so I added it to it ( 0C = option 12 for the hostname )
paramReq byte $01, $03, $06, $0C, $2A ' Paramter Request; mask, router, domain name server, hostname ,network time
and increced the size from 4 to 5 in the pub.
it seems to me that it was a missing step .
but this doesnt make it all work. as my isp modem resolved correctly for a couple of minutes then fails
long log isp 2012.zip, Here the hostname resolving is clearly visable working at first , happering around alltle ,. then stopping, ,
#3 discovery
#5 offer
#6 request
#7 Ack
#8 first query done ( im trying to open the page http:/px-210/ in my brouwser )
#12 Query returns a ip adres , brouser knows where to find it , page opens up
til this part the calling by hostname works fine ,. after this it wil continue working for some time
. targeting the right ip directly without needing to query the hostname all the time
at
# 108 , # 1040 , # 2016 and # 2687
it loozes the ip ( or somtingelse ) does a new query for the hostname , and the 3 the query result beeing the correct one , then resumes correct. for those thimes ,
one thing stands out , that every thime it happens the previus package( before it starts the hostname query ) is one of the prop to the modem , havind the ack and the sequence number , Maybe the prop haging there somewhere or not providing the correct follow up number ??
at # 2976 it does a query again , but it doesnt resolve anymore. why ? not a clue . one thing again , the package before the queing started again was the same ,letting me think the prop is formatting it wrongl , . any idear ?
couldent realy find any thing diferent with the package from the previous succesfull ones
According to RFC 2132 a DHCP server may register DNS on the behave of the client if the host name option (12) is present in the DHCP REQUEST. However, using host name option (12) to facilitate a DNS registration is not the recommended method, according to RFC 2135. The option is undefined, as related to DNS, and may led to interoperability problems.
RFC 2135 recommends the following preferred methods for DNS registration
According to RFC 2132 a DHCP server may register DNS on the behave of the client if the host name option (12) is present in the DHCP REQUEST. However, using host name option (12) to facilitate a DNS registration is not the recommended method, according to RFC 2135. The option is undefined, as related to DNS, and may led to interoperability problems.
RFC 2135 recommends the following preferred methods for DNS registration
Issuing direct updates to DNS
Using the DHCP client FQDN option
Of course the DHCP server must support proxy DNS.
that is exactly what I was reading asking about,
I went on to try the fqdn option #81 . doing the following ,in the dhcp object
CON
FQDN_OPTION = 81
DAT
paramReq byte $01, $03, $06, $51 ' { $0C for hostname (12), $51 for fqdn (81) }
PRI Discover & Request
'WriteDhcpOption(HOST_NAME, strsize(@hostName), @hostName)
WriteDhcpOption(FQDN_OPTION, 9, @fqdn)
producing the following option according the the discription for the fqdn
im not complety sure if im using the correct format for the fqdn . if it is just px-210 or px-210.local or px-210.lan as lan is what the servers sends back as the domain name . ?
all with all , this doesnt do what i wish it would , that is regestering the hostname with the modem dns
the support proxy DNS you mentiond is the only for the issuing of a direct update to the dns ,. or with the fqdn option?
I can not reproduce the behavior described. My network never resolves the DHCP host name option (12).
IMO, figure out what's going on with your network. How does it resolves names. One clue is the DNS query originating from x.x.x151. The DNS query starts with px-210.local.domain to px-210.local and finally px-210. Why?
It looks like Multicast DNS but except not on port 5353.
One clue is the DNS query originating from x.x.x151. The DNS query starts with px-210.local.domain to px-210.local and finally px-210. Why?
the 192.168.2.151 is the pc that has the brouwser open thats asking for the http://px-210/xmltemp from the prop .
so the dns that gets resolved the 3 try , has to get be getting resolved by the modem , . but after some time it just stops .
Im still digging trying to figure out why
with the linksys modem the hostname now also seems to resolve ( chrome I think makes the query requests ) and it gets the correct ip on the 3 try , just like the isp modem , but now it never stops working , and with the isp modem it does , confusing
anyway , ill be digging into it these days hoping to find the solution for my hostname resolving ,
i was thinking of letting the propeller return a dns package with the right ip of the host , just like the modem does the dns query resolve. when it resolves succesfully ,
and just set the adres target and sourse to those values of the modem ,try to fake the brouwser its recieving them from the isp modem , but its realy the prop sending them , maybe it wil work
Comments
PUB RenewDhcp is added to the Dhcp.spin object. It's pretty simple - it sends the Request packet and parses the response. So the initial IP request uses the whole Discover/Offer and Request/Ack transactions while a renew invokes only Request/Ack.
pst.str(string("Requesting IP.....")) repeat until dhcp.DoDhcp if(++t1 > ATTEMPTS) quit if(t1 > ATTEMPTS) pst.char(CR) pst.str(string(CR, "DHCP Attempts: ")) pst.dec(t1) pst.str(string(CR, "Error Code: ")) pst.dec(dhcp.GetErrorCode) pst.char(CR) pst.str(dhcp.GetErrorMessage) pst.char(CR) return else PrintIp(dhcp.GetIp) { Stress test } repeat pst.str(string("Requesting IP.....")) t1 := 0 'wiz.SetIp(0,0,0,0) repeat until dhcp.RenewDhcp if(++t1 > ATTEMPTS) quit if(t1 > ATTEMPTS) pst.char(CR) pst.str(string(CR, "DHCP Attempts: ")) pst.dec(t1) pst.str(string(CR, "Error Code: ")) pst.dec(dhcp.GetErrorCode) pst.char(CR) pst.str(dhcp.GetErrorMessage) pst.char(CR) return else PrintIp(dhcp.GetIp)I quickly tested the theory (I researched the DHCP renew process) and it worked surprisingly easy on my box. Please let me know if it works out for you.Can we use this dhcp.spin renewdhcp for spinneret wiznet W5100 ?
Congratulations Mike, RenewDhcp works and nowI don't need wiz.SetIp(0,0,0,0) to renew. Just note that success of the initial DHCP request (i.e. dhcp.DoDhcp) for my Netgear still relies on the src ip = 0.0.0.0. For instance, if I manually set the source ip to a different (but valid network) address, the initial dhcp.DoDhcp will just keep retrying...
'DHCP Process wiz.SetIp(10,0,0,160) 'this causes problem, will 'Retry DHCP' forever repeat until DoDhcp CreateTransactionId pause(1000) pst.str(string(CR, "Retry DHCP: ")) pst.dec(i++) pst.char(CR)As noted all along, it's seemingly not an issue after power-up/F10/wiz.HardReset or ? i.e. the src ip seems to 'default' 0.0.0.0 initially. But I want to mention it since I'm not exactly sure what reason(s) the src ip apparently comes up 0.0.0.0 first time. Could be your code setting it, W5200 power-up and/or HardReset or F10/boot variable initialization by Spin or ??? Anyway for now I don't need to explicitly set src ip = 0.0.0.0 prior to the initial dhcp.DoDhcp and after it succeeds dhcp.RenewDhcp works like a champ.
All network parameters are zeroed on start up. I'll add a add a Boolean parameter to the DoDhcp method so the IP can be set to 0.0.0.0.
BTW, there is also a PUB SetRequestIp(octet3, octet2, octet1, octet0) method which will request a particular IP.
The lease time returned during the DHCP process is exposed through the dhcp.GetLeaseTime. Renew the release at [lease time]/2. If the lease time has expired, execute dhcp.DoDhcp(). The top level object must handle the timing.
Use dhcp.SetRequestIp to request an IP on the network. I use dhcp.SetRequestIp and HOSTS file to bind an IP to name.
I have updated the code , and it looks to be working pretty nice .
had that on my mind for a long time , seems it did the trick
.
here a wireshark log of the succes renewal . renew good.zip
One thing still , I mentiond it before in post #55
if i use the code like you changed it also in the html5 graph , the ip doesnt renew if there is no activity taking place . And only renews the first time the activity contiues. So if nothing happens for a day the leastime still expires .
if I add the
PUB MultiSocketServer | bytesToRead, i, page, j, x , bytesSent, ptr bytesToRead := bytesSent := i := j := x := 0 repeat if(dhcpLease - phsa/NCO_FREQ < dhcpLease-10) pst.str(string(CR, "Renew DHCP Lease", CR)) pst.str(string("Requesting IP.....")) if(dhcp.DoDhcp) PrintIp(dhcp.GetIp) dhcpLease := dhcp.GetLeaseTime phsa := 1 pause(1500)If I change it a bit , and insert it in the loopt thats keeps running while there is no activity then it does work nice always renewing ,
can you confirm this , or is this not the best way to keep it renewing even if there is no activity taking place for a long time.
PUB Main | i , dnsServer cognew(Tempcontrol,@stack1) cognew(controller,@stack2) i:=0 wiz.HardReset(nRESET_WIZ) pst.Start(115_200) pause(500) pst.str(string("Initialize W5200", CR)) wiz.start(6, 5, 4, 7) wiz.SetMac($00, $08, $DC, $16, $F8, $01) pst.str(string("Getting network paramters", CR)) dhcp.Init(@buff, 7) pst.str(string("Requesting IP.....")) repeat until dhcp.DoDhcp(false) if(++i > DHCP_ATTEMPTS) quit if(dhcp.GetErrorCode > 0 OR i > DHCP_ATTEMPTS) pst.char(CR) pst.str(string(CR, "DHCP Attempts: ")) pst.dec(i) pst.str(string(CR, "Error Code: ")) pst.dec(dhcp.GetErrorCode) pst.char(CR) pst.str(dhcp.GetErrorMessage) pst.char(CR) return else PrintIp(dhcp.GetIp) 'Setup a 610 Hz square wave on pin 31 ctrb := %00100_000 << 23 + 1 << 9 + CNT_PIN frqb := FREQ_610 dira[CNT_PIN] := 1 'Positive edge counter on pin 31 ctra := %01010 << 26 + CNT_PIN frqa := 1 pst.str(string("DNS...............")) dnsServer := wiz.GetDns PrintIp(wiz.GetDns) pst.str(string("DHCP Server........")) printIp(dhcp.GetDhcpServer) pst.str(string("Router IP.........")) printIp(dhcp.GetRouter) pst.str(string("Lease Time........")) dhcpLease := dhcp.GetLeaseTime pst.dec(dhcp.GetLeaseTime) pst.char(CR) repeat repeat i from 0 to SOCKETS-1 sock[i].Init(i, TCP, 80) OpenListeners StartListners \MultiSocketServer pause(500) PUB PrintIp(addr) | i repeat i from 0 to 3 pst.dec(byte[addr][i]) if(i < 3) pst.char($2E) else pst.char($0D) PUB OpenListeners | i repeat i from 0 to SOCKETS-1 sock[i].Open PUB StartListners | i repeat i from 0 to SOCKETS-1 if(sock[i].Listen) do_nothing else sock.Disconnect PUB do_nothing return PUB CloseWait | i repeat i from 0 to SOCKETS-1 if(sock[i].IsCloseWait) sock[i].Disconnect sock[i].Close if(sock[i].IsClosed) sock[i].Open sock[i].Listen PUB check_lease if(dhcpLease - phsa/NCO_FREQ < dhcpLease-10) pst.str(string(CR, "Renew DHCP Lease", CR)) pst.str(string("Requesting IP.....")) if(dhcp.RenewDhcp) PrintIp(dhcp.GetIp) dhcpLease := dhcp.GetLeaseTime phsa := 1 pause(1500) PUB MultiSocketServer | bytesToRead, i, page, j, x , bytesSent, ptr bytesToRead := bytesSent := i := j := x := 0 repeat pst.str(string("TCP Service", CR)) CloseWait repeat until sock[i].Connected i := ++i // SOCKETS check_lease pst.str(string("Connected Socket ")) pst.dec(i) pst.char(CR) 'Data in the buffer? repeat until bytesToRead := sock[i].Available if(bytesToRead < 0) pst.str(string("Timeout",CR)) sock[i].Disconnect sock[i].Open sock[i].Listen bytesToRead~ next pst.str(string("Copy Rx Data",CR)) 'Get the Rx buffer sock[i].Receive(@buff, bytesToRead) {{ Process the Rx data}} pst.char(CR) pst.str(string("Request:",CR)) pst.str(@buff) req.TokenizeHeader(@buff, bytesToRead) page := ParseResource pst.str(string("Send Response",CR)) pst.str(string("Byte to send ")) pst.dec(strsize(page)) pst.char(CR) bytesSent := 0 ptr := page repeat until bytesSent == strsize(page) bytesSent += sock[i].Send(ptr, strsize(ptr)) ptr := page + bytesSent pst.str(string("Bytes Sent ")) pst.dec(bytesSent) pst.char(CR) pst.str(string("Disconnect socket ")) pst.dec(i) pst.char(CR) if(sock[i].Disconnect) pst.str(string("Disconnected", CR)) else pst.str(string("Force Close", CR)) sock[i].Open sock[i].Listen sock[i].SetSocketIR($FF) i := ++i // SOCKETS bytesToRead~the hostfile you refer to , is it also on the propeller , or is it hosten on a computer on your network ??
if i understand it resolves tha ip to the hostname, how do I get it implemented with the current code , been trying to get the netbios running but its proven a little bit of headace. think you can point me in the propper direction/solution for the resolving to ip issue of the propeller
The posted HOSTS file link contains details on HOSTS files, please read.
NetBIOS name services all that's needed to bind a name to IP. Essentially, it is a broadcast on the local network that lets everyone know that PROPNET is bound to an IP. This is unit test code so the code a little raw and not user friendly. If you need IP/Name resolution now, I suggest you do some research. The source code is open and can provide a template.
Once I get the time, I plan to convert the NetBIOS unit test into an object. Right now I'm very busy with the WizNet 5200 Quick Start.
Ill continue with the reading ,googeling and understanding the hole netbios routine . and testing
ill do my best .
Thanks again .
That can work too, but I dont think that is duable , if it is used in different networks every time ( customer) . maybe the network is using a completly different range of ip (e.g. 192.168.2.xx of 10.0.0.xx). then it wont work again .
and you need to make a hostfile ever time
I think the netbios is the best solution , So the final controller is just a plug & play .
network cable atached , switch on , acces by hostname
ill be digging in the netbios for the next couple of days
an other question about the security issue .
is an ssl or tls connection with the wiznet possible ?
I now use a secure tls connection with the database , where the html page is stored ( prop redirects to it ) .
so the connection between a client , and my server is secured for a man in the middle sniffer,
but the connection from my server to the prop ( mine localy now , or one on an different ISP ( custemer )) is not secured .
initialy there was the basic authentication, but I had to get over the option to keep it simple to make a new username and use it with the controller
this was because the ( root) username was stored on the eerprom and not changable during normal use.
now I use a database and php sesions to log in ,
but the security is now gone ,
I was thinking of base enqripting the url that the prop serves , so at least they are not easily readable
but a ssl of tls connection would be auwsem
any good advise before i begin digging into the info?
I know you told me more than once that the dhcp is not suppose to resolve the hostname to ip . but this was still the case with my modem and is part of an option that is possible to use via dhcp a cant leave it alone
anyway . there is something realy fishy going on
Now with the latest drives , the ISP modem where the resolving by DHCP used to works , It Only works for a couple of minuts .
if I turn the prop on , let the dhcp procces go allong for it to get the ip assigned , i can resolve to ip just by using the hostname.
new to this is that now after a couple of minutes (about 5min) after turning the prop on the hostname doesnt resolve anymore . sniffing lets me see that the modem is just not resolving.it anymore , as it did this just fine before. a dns query also doesnt return the ip adress.
.
anyway . I went trying if the name also resolves on the linksys router for the first couple of minutes
to my surprise , at the linksys router the resolving seems to be working fine overall , it didnt work before , now it does resolve the ip .
I see it uses a dns query to resolve it , looks like its also a bit slower , if a see the repeated xml request going out . but it is resolving with the linksys modem
isp long log.zip
ISP modem, resolving by hostname worked fine before , ate No 1254 in the log , was the last time it new the correct ip , after that it didnt resolve anymore , all the rest of the data looks to be the same..
browser looking for hostname and resolving succesfull.zip
succesful hostname resolve with the linksys modem , didnt resolve the hostname at all before
Maybe the hostname by dhcp wil work afterall , hope we can get out of this one
UPDATE
I noticed in the discovery packet.the hostname is inserted in the discovery packet correctly in the dhcp option field 12 . wich is the correct place for it . ,
but at the parameter request list , there is no request going on for the hostname , so I added it to it ( 0C = option 12 for the hostname )
and increced the size from 4 to 5 in the pub.
it seems to me that it was a missing step .
but this doesnt make it all work. as my isp modem resolved correctly for a couple of minutes then fails
long log isp 2012.zip, Here the hostname resolving is clearly visable working at first , happering around alltle ,. then stopping, ,
#3 discovery
#5 offer
#6 request
#7 Ack
#8 first query done ( im trying to open the page http:/px-210/ in my brouwser )
#12 Query returns a ip adres , brouser knows where to find it , page opens up
til this part the calling by hostname works fine ,. after this it wil continue working for some time
. targeting the right ip directly without needing to query the hostname all the time
at
# 108 , # 1040 , # 2016 and # 2687
it loozes the ip ( or somtingelse ) does a new query for the hostname , and the 3 the query result beeing the correct one , then resumes correct. for those thimes ,
one thing stands out , that every thime it happens the previus package( before it starts the hostname query ) is one of the prop to the modem , havind the ack and the sequence number , Maybe the prop haging there somewhere or not providing the correct follow up number ??
at # 2976 it does a query again , but it doesnt resolve anymore. why ? not a clue . one thing again , the package before the queing started again was the same ,letting me think the prop is formatting it wrongl , . any idear ?
couldent realy find any thing diferent with the package from the previous succesfull ones
I have no idea why the system behaves as described in post #76.
RFC 2135 recommends the following preferred methods for DNS registration
Of course the DHCP server must support proxy DNS.
that is exactly what I was reading asking about,
I went on to try the fqdn option #81 . doing the following ,in the dhcp object
CON FQDN_OPTION = 81 DAT paramReq byte $01, $03, $06, $51 ' { $0C for hostname (12), $51 for fqdn (81) }producing the following option according the the discription for the fqdnim not complety sure if im using the correct format for the fqdn . if it is just px-210 or px-210.local or px-210.lan as lan is what the servers sends back as the domain name . ?
all with all , this doesnt do what i wish it would , that is regestering the hostname with the modem dns
the support proxy DNS you mentiond is the only for the issuing of a direct update to the dns ,. or with the fqdn option?
IMO, figure out what's going on with your network. How does it resolves names. One clue is the DNS query originating from x.x.x151. The DNS query starts with px-210.local.domain to px-210.local and finally px-210. Why?
It looks like Multicast DNS but except not on port 5353.
the 192.168.2.151 is the pc that has the brouwser open thats asking for the http://px-210/xmltemp from the prop .
so the dns that gets resolved the 3 try , has to get be getting resolved by the modem , . but after some time it just stops .
Im still digging trying to figure out why
with the linksys modem the hostname now also seems to resolve ( chrome I think makes the query requests ) and it gets the correct ip on the 3 try , just like the isp modem , but now it never stops working , and with the isp modem it does , confusing
anyway , ill be digging into it these days hoping to find the solution for my hostname resolving ,
i was thinking of letting the propeller return a dns package with the right ip of the host , just like the modem does the dns query resolve. when it resolves succesfully ,
and just set the adres target and sourse to those values of the modem ,try to fake the brouwser its recieving them from the isp modem , but its realy the prop sending them , maybe it wil work