...your DNS tweak nailed it Mike, multi-passes thru DHCP (with my needed wiz.SetIp(0,0,0,0)) and DNS now working! I'll let you know if I come across any issues, but now the package handles everything I'm doing. Good time to reiterate just how amazing and appreciated your work is!
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
...thanks for checking Igor. If adding the wiz.SetIp(0,0,0,0) to DHCP does no harm it's something to consider/remember if people find it necessary as I do (my setup pretty widely used, Netgear router & ATT ISP).
...Just to say I agree scenarios are too varied, better to leave DHCP lease renewal to the app. The idea of devoting a cog to DHCP overkill in most cases. But I could see combining RTC, DHCP lease renewal and NNTP (for RTC setting/correction) in a time&housekeeper cog. Would have to be pretty careful 'sharing' the SPI/W5200/network between cogs.
I remember reading about Linux having some smart network configuration that will automatically resolve client names to IPs when issuing DHCP. I'm not sure if that has anything to do with your setup. It does appear your ISP modem can resolve name to IP. Have you looked at the manual?
I think the assumption that the modem is resolving the ip adres is the case is correct , Dont think the linux smart networking you talk about has anything to do with my current setup . because the linux pc is using static ip and not dhcp. actualy i can not even see the linux pc or its ip (192.168.2.151 static )anywhere in the modem page , but it does work fine. so i didnt bother , with it anymore ,
If i use a other laptop that I have that does use dhcp to get its ip adress on the ISP modem , then also I can acces the prop by hostname, So i think its safe to say my ISP modem is responsible for the resolvingby the DHCP hostname. I just cant find the datasheet of manual of it anywhere to be 100 %
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.
Hihi , its always a good feeling to know that you were always on the right track .finding others used the same solution only makes that feeling stronger ,
So for me i think I sould forget about the dns , and get the netbios running along with the html5graph .
So for my modem the hostname is enough to let it resolve ,
and in other networks it wil resolve by netbios. Making it resolve in both senarios .
...thanks for checking Igor. If adding the wiz.SetIp(0,0,0,0) to DHCP does no harm it's something to consider/remember if people find it necessary as I do (my setup pretty widely used, Netgear router & ATT ISP).
Im happy I could help. no thanks need , do apriciate it ,
maybe indeed a good idee to leave the statment inside so it also works with yours also , as it didnt seem to affect it anyway . But it will work for sure in those 2 senarios
...Just to say I agree scenarios are too varied, better to leave DHCP lease renewal to the app. The idea of devoting a cog to DHCP overkill in most cases.
I also agree the senarios are varied.and the idea of an onther cog sounds scarry to be because im already almost runnign out of resources on the prop , with the other stuff i also have running along with the wiznet. a more stupid code just renewing the leasetime after a given count orso to get the leasetime never to run out ,
Leaving DHCP renewal to the app . any demos on how that wil be done ?
...if your app is aware of real-time it can schedule the lease renewal explicitly. If not, I think the idea of just renewing 'frequently' (ex: based on a counter of your main loop) would suffice. If an app connects infrequently/sporadically just renew the lease and check DNS everytime. Another idea would be to just renew the lease and update DNS only if/when a network error occurs.
Leaving DHCP renewal to the app . any demos on how that wil be done ?
Not so much a demo more like a counter hack. This example uses Counter B to create an NCO mode 610 Hz square wave on pin 7. Counter A is setup as a Positive Edge detector listening on pin 7. Every second the PHSA register increases by 610. We can use this setup to create a seconds timer. The trade-off is we need a spare pin.
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
CNT_PIN = 7
USB_Rx = 31
USB_Tx = 30
NCO_FREQ = 610 '($8000)(80x10^6)/2^32 = 610.3516Hz
FREQ_610 = $8000 ' AN001-P8X32ACounters-v2.0_2.pdf (page 6)
VAR
DAT
dhcpLease long 86400
OBJ
pst : "Parallax Serial Terminal"
PUB Main | freq
'Detect if a USB cable is connected
if ina[USB_Rx] == 0
outa[USB_Tx] := 0
else
pst.Start(115_200)
pause(500)
'Setup a 610 Hz square wave on pin 7
ctrb := %00100_000 << 23 + 1 << 9 + CNT_PIN
frqb := FREQ_610
dira[CNT_PIN] := 1
'Positive edge counter on pin 7
ctra := %01010 << 26 + CNT_PIN
frqa := 1
'UI so we can see the affect of the counter
repeat
pst.char(0)
pst.char(1)
pst.dec(86400 - phsa/NCO_FREQ)
pause(500)
'Reset the counter
if( (86400 - phsa/NCO_FREQ) < 86395 )
pst.char(0)
pst.str(string($01,"*** Reset ***"))
pause(2000)
phsa := 1
PRI pause(Duration)
waitcnt(((clkfreq / 1_000 * Duration - 3932) #> 381) + cnt)
return
...as I'm using the REPEATed DHCP (i.e. lease renewal) noticed some possible anomalies - here's the code. Notice I added variables t2 and t3 to track passes through the loop and number of failures respectively. I also commented out the 'return' in the error handler so it keeps running passes.
1. Maybe 2% of the passes there's a 'Discover Error' (as an aside, I notice that for my setup non-error cases always succeed first attempt of dhcp.DoDhcp)
Perhaps my Netgear wireless router/gateway (the DHCP Server) is sometimes pre-occupied? Anyway, I don't consider this a showstopper, it's as simple as trying again (which seems like the only choice with DHCP anyway i.e. app isn't going anywhere until it gets an IP). Here's the display when the Discover error occurs...
I have to say I agree with twc, went testing myself ,., but used the code i posted in post #22 to do the repeated dhcp assignment , and I also have the occuracne of the hole thing going Hi wire.
First time it happend ,the same thing came to my mind that in the normal case senario I would not repeat it that often that fast, probably what caused it to go nuts .
anyway , testing it and sniffing it wit wireshark. @twc . dont know if you already have wireshark but it helps allot, you wouldendt need the dhcpdemo to see the package, you could just sniff it out .
I have the same thing happening ,
I have also noticed that when it goes nuts , the last package recieved is an a offer from the modem
I did compare a few offer packages, but there doesnt look like theres something wrong with the data inside the pagage generated by the modem , so proably its inside the offer routine somthing unexpected happening ,
hopefully mike could share some more light on this , and knows wats going on .
and 2 logs showing ,log 1 it happens pretty fast, log 2 it takes much longer but also going Hi wire LOG.zip
@Mike , About the Counter hack , Nice Demo . I never understud those counters, but the demmo surely llets you understand if fast.
ill have to do more of the readig part on those counters, the freq is like just what i need to build a vfd also for the pwm , anyway. i think thats going to work out fine , for the dhcp renewal .
for the trade off pin ,
do you think using pin 30 or 31 wil do harm ? , I am currently not using them for anything else than the pst , and im not planning to leave the pst function on the controller anway .
of is this not a good idear, im pretty much using all the pins or already had other plans for them :P
did a test running it on ping 31 , and looks to work fine, just don't know with my very limited knowledge about those counters if thats a
I also wondered about over-running the router, tried increasing the delay, still fails at 30 seconds. Thanks for trying it Igor and the wireshark. My router is the DHCP server so my PC with wireshark can't see any of the DHCP activity.
The earlier (now solved) problem REPEATing DNS seemed to be caused by a data re-use issue (i.e. hostname was corrupted across iterations). So it would work if REPEAT was replaced with iREBOOT because the data was re-initialized each time. But with this REPEATing DHCP glitch I find that's not the case i.e. it still crashes eventually (garbage output to terminal) even if REPEAT is changed to REBOOT. Difference implies it's not the same kind of 're-use' problem, maybe helps narrow down the options.
Hope you had a nice vacation - you certainly deserve it!
In my testing the DNS appears solid, the issue is with DHCP. The failure frequency is low, but it can occur at any time. The fact it will eventually fail immediately after REBOOTing (and also tried wiz.HardwareReset) would seem to indicate the problem is not loop iteration or data reuse related (except possibly data that is NOT initialized by REBOOT (local vars I think?)).
Hope you had a nice vacation - you certainly deserve it!
Just what I wanted to say , A family vacation is always nice , and certainly deserve it after all the hard work with the wiznet , let allong your normal daily things,
Cause:
A complete DHCP Offer/ACK packet is not received after a Discover/Request DHCP packet is sent.
Solution:
Continue to receive bytes If the receive packet is not complete. A packet is determined complete when the UPD header data length field equals the data received minus the UPD header length (8).
This solution does not stop packet errors. Packet errors occur if the process times out while receiving an Offer/ACK or the received packet type is unexpected.
Mike that works like a charm
it must be the vacation .
i have let it run for 30 minut on my isp modem ,. with a pause(500) so pretty fast loop . but it runs finee without any problems.
just to be sure I am running it now on the linksys modem too . till now everything looks nice.
think that did the job,
comming pretty close to removing all the w5200 bugs i think ?
the packet errors you talk about , will they cause the program to go crazy like before ,. didnt realy understand if that cenario is now still possible knowing it reneaws the ip fine nou .
Nice explination about the cause anyway
UPDATE : The Linksys modem also seems to work fine , have run it for 45 min pause(500) , no problems . Nice job mike
ben trying to get the counter to work , not getting pretty far ,
another thing , the leasetime function doesnt seem pretty usefull now , because i can only call it along with the whole ip renewal . I only repeat getleasetime that it doesnt work , If i repeat it all , the leasetime also gets renewd , so i am unable to get the count going down
or I will have to stick to the idear of a stupid couter , just some thouts that the leasetime probably wil be different on different modems so getting the actual leastime ,or at least the the starting leastime and then couting down till half that.
could realy use some help with there counters,. ive assingd pin 17 , but realy want to use 30 or 31
UPDATE . I have updated the code above , I know have working that the leasetime is taken out of the dhcp , and countdown begin ,
but the instance i put the repeatloop of the mulitsocket sever , it hangs again , like the counter dont want to work with the multisocket
Re: DHCP - been running the stress test (and also DNS) for quite awhile - looks solid as a rock Mike! Just had to add wiz.SetIp(0,0,0,0) to work with my Netgear...
' Stress test
REPEAT
wiz.SetIp(0,0,0,0) 'My Netgear needs this
pst.str(string("Requesting IP....."))
...without it I get 'Discover Error' on 2nd pass as mentioned in earlier posts. Does wiz.SetIp(0,0,0,0) affect operation on your setup? Igor mentioned it worked ok on his (i.e. not necessary, but benign). Could be a router bug/'feature' other Netgear users may encounter, keep in mind if it comes up.
Ok , letting the counter start after the ip fetching seems to do it ,
but there s still something not right ,
If there is countiues communication between the client and the server , then the dhcp renewal works fine , I can see the dhcp getting renewd after about the 10 seconds ,
but if there is no communication between the 2 , meaning , if i just turn it on , and dont open the page, the dhcp never renews. meaning , if there is no activity for a long time , the leastime still wil run out ,
how to let it run independedn if there is activity or not ?
PUB MultiSocketServer | bytesToRead, i, page, j, x , bytesSent, ptr
bytesToRead := bytesSent := i := j := x := 0
repeat
if( (dhcpLease - phsa/NCO_FREQ) < (dhcpLease-10) )
DHCP_SETUP_IP
phsa := 1
pst.str(string("TCP Service", CR))
CloseWait
{
repeat j from 0 to SOCKETS-1
pst.str(string("Socket "))
pst.dec(j)
pst.str(string(" = "))
pst.hex(wiz.GetSocketStatus(j), 2)
pst.char(13)
}
repeat until sock[i].Connected
i := ++i // SOCKETS
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~
Another thing mike, The last source update , or maybe it was the one before , stoped the hostname from gettting resolved by my isp modem , Now I can only acces it by ip . Maybe a clue ?
I will need to get the netbios up anyway so I didnt realy mind it , just thout its a good thing to mention as it worked fine before , but not anymore
UPDATE , a modem restart made it resolved back , so the senario is the same
Does wiz.SetIp(0,0,0,0) affect operation on your setup? Igor mentioned it worked ok on his (i.e. not necessary, but benign). Could be a router bug/'feature' other Netgear users may encounter, keep in mind if it comes up.
I just don't know. I can use invoke wiz.SetIp(0,0,0,0) - or not - without issues.
I updated DhcpDemo.spin to include Discover/Offer and Request/Ack packets in PST. If you can post screenshots of the transactions, maybe something will jump out.
One thing that comes to mind, routers are also switches. Switches can persist routes. I believe 0.0.0.0 like 255.255.255.255 is a broadcast IP. We could be looking at some kind of route table that needs to be cleared?
repeat until sock[i].Connected
i := ++i // SOCKETS
check_lease
to keep it always repeating , before the prop gets stuck in the loop if there is noo active connection to the prop. now it cheks the leasetime succesfully .
ofcourese im doing to change it time to (dhcpLease/2) so it renews at half the leasetime ,Supose to get the problem fixed now
PUB Main | i
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)
DHCP_SETUP_IP
start_couter
repeat
repeat i from 0 to SOCKETS-1
sock[i].Init(i, TCP, 80)
OpenListeners
StartListners
\MultiSocketServer
pause(500)
PUB DHCP_SETUP_IP | i, dnsServer
pst.str(string("Requesting IP....."))
i := 0
repeat until dhcp.DoDhcp
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)
pst.str(string("DNS..............."))
dnsServer := wiz.GetDns
PrintIp(wiz.GetDns)
pst.str(string("DHCP Server......."))
printIp(wiz.GetDhcpServerIp)
pst.str(string("Router IP........."))
printIp(wiz.GetRouter)
pst.str(string("Gateway IP........"))
printIp(wiz.GetGatewayIp)
pst.str(string("Lease Time........"))
dhcpLease := dhcp.GetLeaseTime
pst.dec(dhcp.GetLeaseTime)
pst.char(CR)
return
PUB start_couter
'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
return
PUB MultiSocketServer | bytesToRead, i, page, j, x , bytesSent, ptr
bytesToRead := bytesSent := i := j := x := 0
repeat
pst.str(string("TCP Service", CR))
CloseWait
repeat j from 0 to SOCKETS-1
pst.str(string("Socket "))
pst.dec(j)
pst.str(string(" = "))
pst.hex(wiz.GetSocketStatus(j), 2)
pst.char(13)
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~
Didn't mean to imply my setups need to use wiz.SetIp(0,0,0,0) is a problem, just a curiousity, something to keep in mind if others get a 'Discover Error' trying to renew (i.e. calling do.Dhcp more than once).
Didn't mean to imply my setups need to use wiz.SetIp(0,0,0,0) is a problem, just a curiousity, something to keep in mind if others get a 'Discover Error' trying to renew (i.e. calling do.Dhcp more than once).
Well, it just does not make sense and I'd like to know what's going on. The IP is written to the WizNet register using the YIADDR segment of the Offer packet. I'm curious what the second set of packets look like.
...I was googling DHCP a bit to see if I could get some insight. I didn't find a clear answer, but vague mentions like...
The process of acquiring an IP address is described here
[LIST]
[*][B]Step 1[/B] The client workstation boots and initializes with a "null
IP address" that lets it communicate with the DHCP server using TCP/IP. It
prepares a message that contains its MAC address (for example, the hardwired
address of its Ethernet adapter) and its computer name. The message may also
contain a previous IP address that it has leased from a DHCP server. The client
"broadcasts" the message on the network and continues to send the message until
it receives a response from the server.
[/LIST]
...this implies the source ip should be 'null ip address' while current (ex: previously accepted) ip address is in the 'message'. My setup always gets the same ip address each iteration I was guessing because the mac address is unchanged (if mac changed, DHCP correctly returns a different ip address).
EDIT: Just noticed in the above examples the IP assigned by DHCP changes, maybe a clue...
1. If I run the two iteration loop with, and then without, wiz.SetIp(0,0,0,0) the four instances result = 157,157,157,Discover Error
2. If I reverse the order (i.e. without, then with wiz.SetIp) result = 158,Discover Error, 157,157
Hope this helps answer your question Mike , let me know if I can instrument the code, run addl tests.
On the second loop the Discover packet is (I believe) sent from 10.0.0.157 but the Offer packet does not return. If the Discover packet is sent from 0.0.0.0 then the offer packet is returned. I'll have to look more into it but I'd think the source IP in a DHCP request should not matter. The source IP should be a valid network IP though. What about the other network parameters, are they correct?
Yes, for my setup DHCP has never worked with any src ip other than 0.0.0.0. - even a valid ip (whether set manually or, as in this case, the address (10.0.0.157) returned by the first iteration). I'm guessing doDhcp works the first time after reset/F10 for my setup because the chip and/or your software is coming up with src ip at 0.0.0.0. Once the src ip is changed (i.e. to a net valid ip) the next call to doDhcp will fail. But the wiz.SetIp(0,0,0,0) fix seems completely effective. As for the other net parameters, everything seems fine - all the server/router/gateway addresses are the same (i.e. 10.0.0.1 which is the address of the router/gateway). Maybe it's just an issue/difference for Netgear? .
Comments
...thanks for checking Igor. If adding the wiz.SetIp(0,0,0,0) to DHCP does no harm it's something to consider/remember if people find it necessary as I do (my setup pretty widely used, Netgear router & ATT ISP).
I think the assumption that the modem is resolving the ip adres is the case is correct , Dont think the linux smart networking you talk about has anything to do with my current setup . because the linux pc is using static ip and not dhcp. actualy i can not even see the linux pc or its ip (192.168.2.151 static )anywhere in the modem page , but it does work fine. so i didnt bother , with it anymore ,
If i use a other laptop that I have that does use dhcp to get its ip adress on the ISP modem , then also I can acces the prop by hostname, So i think its safe to say my ISP modem is responsible for the resolvingby the DHCP hostname. I just cant find the datasheet of manual of it anywhere to be 100 %
Hihi , its always a good feeling to know that you were always on the right track .finding others used the same solution only makes that feeling stronger ,
So for me i think I sould forget about the dns , and get the netbios running along with the html5graph .
So for my modem the hostname is enough to let it resolve ,
and in other networks it wil resolve by netbios. Making it resolve in both senarios .
Im happy I could help. no thanks need , do apriciate it ,
maybe indeed a good idee to leave the statment inside so it also works with yours also , as it didnt seem to affect it anyway . But it will work for sure in those 2 senarios
I also agree the senarios are varied.and the idea of an onther cog sounds scarry to be because im already almost runnign out of resources on the prop , with the other stuff i also have running along with the wiznet. a more stupid code just renewing the leasetime after a given count orso to get the leasetime never to run out ,
Leaving DHCP renewal to the app . any demos on how that wil be done ?
Not so much a demo more like a counter hack. This example uses Counter B to create an NCO mode 610 Hz square wave on pin 7. Counter A is setup as a Positive Edge detector listening on pin 7. Every second the PHSA register increases by 610. We can use this setup to create a seconds timer. The trade-off is we need a spare pin.
Letting it run for awhile, the result is...
1. Maybe 2% of the passes there's a 'Discover Error' (as an aside, I notice that for my setup non-error cases always succeed first attempt of dhcp.DoDhcp)
Perhaps my Netgear wireless router/gateway (the DHCP Server) is sometimes pre-occupied? Anyway, I don't consider this a showstopper, it's as simple as trying again (which seems like the only choice with DHCP anyway i.e. app isn't going anywhere until it gets an IP). Here's the display when the Discover error occurs...
2. But after a number of passes (random) it crashes...
[code]
Requesting IP.....10.0.0.157
DHCP Attempts 0
DHCP Passes/Errors 410 / 11
Requesting IP.....10.0.0.157
DHCP Attempts 0
DHCP Passes/Errors 411 / 11
Requesting IP.....5 M4
First time it happend ,the same thing came to my mind that in the normal case senario I would not repeat it that often that fast, probably what caused it to go nuts .
anyway , testing it and sniffing it wit wireshark. @twc . dont know if you already have wireshark but it helps allot, you wouldendt need the dhcpdemo to see the package, you could just sniff it out .
I have the same thing happening ,
I have also noticed that when it goes nuts , the last package recieved is an a offer from the modem
I did compare a few offer packages, but there doesnt look like theres something wrong with the data inside the pagage generated by the modem , so proably its inside the offer routine somthing unexpected happening ,
hopefully mike could share some more light on this , and knows wats going on .
and 2 logs showing ,log 1 it happens pretty fast, log 2 it takes much longer but also going Hi wire
LOG.zip
ill have to do more of the readig part on those counters, the freq is like just what i need to build a vfd also for the pwm , anyway. i think thats going to work out fine , for the dhcp renewal .
for the trade off pin ,
do you think using pin 30 or 31 wil do harm ? , I am currently not using them for anything else than the pst , and im not planning to leave the pst function on the controller anway .
of is this not a good idear, im pretty much using all the pins or already had other plans for them :P
did a test running it on ping 31 , and looks to work fine, just don't know with my very limited knowledge about those counters if thats a
it doesnt seem to stop it from crashing , so the bug is probably inside the dhcp object , and not the dns ,
some more narrowing down
Thanks for your help.
Hope you had a nice vacation - you certainly deserve it!
In my testing the DNS appears solid, the issue is with DHCP. The failure frequency is low, but it can occur at any time. The fact it will eventually fail immediately after REBOOTing (and also tried wiz.HardwareReset) would seem to indicate the problem is not loop iteration or data reuse related (except possibly data that is NOT initialized by REBOOT (local vars I think?)).
Just what I wanted to say , A family vacation is always nice , and certainly deserve it after all the hard work with the wiznet , let allong your normal daily things,
Looking forward to seeing the fix .
Cause:
A complete DHCP Offer/ACK packet is not received after a Discover/Request DHCP packet is sent.
Solution:
Continue to receive bytes If the receive packet is not complete. A packet is determined complete when the UPD header data length field equals the data received minus the UPD header length (8).
This solution does not stop packet errors. Packet errors occur if the process times out while receiving an Offer/ACK or the received packet type is unexpected.
Give it a shot and let me know.
it must be the vacation .
i have let it run for 30 minut on my isp modem ,. with a pause(500) so pretty fast loop . but it runs finee without any problems.
just to be sure I am running it now on the linksys modem too . till now everything looks nice.
think that did the job,
comming pretty close to removing all the w5200 bugs i think ?
the packet errors you talk about , will they cause the program to go crazy like before ,. didnt realy understand if that cenario is now still possible knowing it reneaws the ip fine nou .
Nice explination about the cause anyway
UPDATE : The Linksys modem also seems to work fine , have run it for 45 min pause(500) , no problems . Nice job mike
another thing , the leasetime function doesnt seem pretty usefull now , because i can only call it along with the whole ip renewal . I only repeat getleasetime that it doesnt work , If i repeat it all , the leasetime also gets renewd , so i am unable to get the count going down
or I will have to stick to the idear of a stupid couter , just some thouts that the leasetime probably wil be different on different modems so getting the actual leastime ,or at least the the starting leastime and then couting down till half that.
could realy use some help with there counters,. ive assingd pin 17 , but realy want to use 30 or 31
UPDATE . I have updated the code above , I know have working that the leasetime is taken out of the dhcp , and countdown begin ,
but the instance i put the repeatloop of the mulitsocket sever , it hangs again , like the counter dont want to work with the multisocket
...without it I get 'Discover Error' on 2nd pass as mentioned in earlier posts. Does wiz.SetIp(0,0,0,0) affect operation on your setup? Igor mentioned it worked ok on his (i.e. not necessary, but benign). Could be a router bug/'feature' other Netgear users may encounter, keep in mind if it comes up.
but there s still something not right ,
If there is countiues communication between the client and the server , then the dhcp renewal works fine , I can see the dhcp getting renewd after about the 10 seconds ,
but if there is no communication between the 2 , meaning , if i just turn it on , and dont open the page, the dhcp never renews. meaning , if there is no activity for a long time , the leastime still wil run out ,
how to let it run independedn if there is activity or not ?
Another thing mike, The last source update , or maybe it was the one before , stoped the hostname from gettting resolved by my isp modem , Now I can only acces it by ip . Maybe a clue ?
I will need to get the netbios up anyway so I didnt realy mind it , just thout its a good thing to mention as it worked fine before , but not anymore
UPDATE , a modem restart made it resolved back , so the senario is the same
I just don't know. I can use invoke wiz.SetIp(0,0,0,0) - or not - without issues.
I updated DhcpDemo.spin to include Discover/Offer and Request/Ack packets in PST. If you can post screenshots of the transactions, maybe something will jump out.
One thing that comes to mind, routers are also switches. Switches can persist routes. I believe 0.0.0.0 like 255.255.255.255 is a broadcast IP. We could be looking at some kind of route table that needs to be cleared?
I did start the counter after the dhcp like mike suggested , and madea small pub that checks the leasetime ,
Inside thu multisocketserver pub
to keep it always repeating , before the prop gets stuck in the loop if there is noo active connection to the prop. now it cheks the leasetime succesfully .
ofcourese im doing to change it time to (dhcpLease/2) so it renews at half the leasetime ,Supose to get the problem fixed now
Well, it just does not make sense and I'd like to know what's going on. The IP is written to the WizNet register using the YIADDR segment of the Offer packet. I'm curious what the second set of packets look like.
Here's the display from DhcpDemo.spin for two passes using this code...
With the wiz.SetIp(0,0,0,0) included it completes both passes correctly...
...now here's the display with wiz.SetIp(0,0,0,0) commented out...
...I was googling DHCP a bit to see if I could get some insight. I didn't find a clear answer, but vague mentions like...
...this implies the source ip should be 'null ip address' while current (ex: previously accepted) ip address is in the 'message'. My setup always gets the same ip address each iteration I was guessing because the mac address is unchanged (if mac changed, DHCP correctly returns a different ip address).
EDIT: Just noticed in the above examples the IP assigned by DHCP changes, maybe a clue...
1. If I run the two iteration loop with, and then without, wiz.SetIp(0,0,0,0) the four instances result = 157,157,157,Discover Error
2. If I reverse the order (i.e. without, then with wiz.SetIp) result = 158,Discover Error, 157,157
Hope this helps answer your question Mike , let me know if I can instrument the code, run addl tests.