Updated the following files
Dhcp.spin
DhcpDemo.spin
TcpSocketClientDemoDhcpDns.spin
W5200.spin
I don't know for sure as I would need a packet dump but I believe the gateway IP is empty on the DHCP Offer packet. The gatway IP gets set to 0.0.0.0. Therefore, the DNS request fails because the packet is being sent to 0.0.0.0.
I changed the logic to look for an empty server field in the DHCP Offer packet. If the field is empty then use the router IP as the gateway.
Looks like I have to do a little more research to verify my understanding of DHCP is correct.
I think you're onto something Mike, 'cause I finally got TSCDDD working! I said it would be simple to fix (but not to find...:=). I think it is related to W5200 gateway setting because...
pst.str(string("DHCP: Router IP......."))
printIp(wiz.GetRouter)
pst.char(CR)
' dhcp ends here
' printIp(wiz.GetGateway)
wiz.SetGateway(10,0,0,1) // guess dhcp didn't set up W5200 gateway regs?
' printIP(wiz.GetGateway)
' dns starts here
pst.str(string("DNS: Resolving IP..."))
dns.Init(@buff, 6)
'remoteIP := dns.ResolveDomain(string("[URL="http://www.agaverobotics.com"]www.agaverobotics.com[/URL]"))
remoteIP := dns.ResolveDomain(string("finance.google.com"))
...by inserting a wiz.SetGateway (to my gateway) after dhcp. I tried to dig into your code to see where dhcp actually sets the W5200 gateway registers or even how to display the W5200 gateway registers but got lost (my code example shows a hypothetical 'wiz.GetGateway' that would make it easy to confirm the situation). Seems like you need something like 'W5200 gateway address := router address from dhcp. Hope this info helps.
Anyway, feels good to make progress. Thanks as always Mike.
...not quite, but it's the same easy fix from yesterday. If I run the new code out of the box...
Initialize W5200
Getting network paramters
Requesting IP.....10.0.0.133
DNS...............10.0.0.1
DHCP Server.......10.0.0.1
Router IP.........10.0.0.1
Gateway IP........0.0.0.0
Resolve domain IP.74.125.224.98
Initialize Socket
Begin Client Web request
Open
Connecting to.....74.125.224.98
...it doesn't connect as before. Note that gateway is still shown 0.0.0.0 after DHCP. Just to be sure I insert a PrintIP(wiz.GetGateway) right before the TCP open and can see the gateway is still 0.0.0.0.....
Initialize W5200
Getting network paramters
Requesting IP.....10.0.0.133
DNS...............10.0.0.1
DHCP Server.......10.0.0.1
Router IP.........10.0.0.1
Gateway IP........0.0.0.0
Resolve domain IP.74.125.224.135
Gateway IP........0.0.0.0
Initialize Socket
Begin Client Web request
Open
Connecting to.....74.125.224.135
...now if I insert the wiz.SetGateway right before the TCP open...
Initialize W5200
Getting network paramters
Requesting IP.....10.0.0.133
DNS...............10.0.0.1
DHCP Server.......10.0.0.1
Router IP.........10.0.0.1
Gateway IP........0.0.0.0
Resolve domain IP.74.125.224.33
Gateway IP........10.0.0.1
Initialize Socket
Begin Client Web request
Open
Connecting to.....74.125.224.33
Send HTTP Header
Bytes Sent: 99
HTTP/1.1 200 OK
Content-Type: application/vnd.ms-excel
...I think you were planning to do something like 'if gateway == 0.0.0.0 then gateway = router'? Looks like that's what dhcp.GetSetGateway is trying to do? Is the difference between 'router' and 'gateway' just syntax, or do they really mean different devices in the net world? Anyway, just need to figure out why gateway is still 0.0.0.0 at the time of TCP open.
Couple of notes...
1. Notice this time I put my gateway setting fix after DNS i.e. that means DNS works with gateway=0.0.0.0. But this may just be because, in my network case, DHCP is saying my router is the DNS server (both 10.0.0.1). I suspect if DHCP returned an external DNS server ip that Dns.spin would then hang, unable to connect just as TCP can't, with gateway 0.0.0.0. Or maybe my network can deal with gateway=0.0.0.0 for a UDP transaction, but not TCP?
2. It has always been, and remains, the case that in my network setup the W5200 source ip must be 0.0.0.0 or Dhcp.spin will have 'Discover Error' (even with valid source ip). I think this is different from your setup where DHCP will work with a (valid) ip? I had been adding wiz.SetIp(0,0,0,0) at the beginning of the demo, but the demo now works without it (i.e. power-up and/or your code starts up with W5200 source ip registers = 0.0.0.0). This probably not be an issue in the typical use case (i.e. call DHCP first thing to get ip), but you never know. Does DHCP work with source ip = 0.0.0.0 for you? Do you think it would work for everyone? If so you could put wiz.SetIp(0,0,0,0) at beginning of dhcp.spin. Otherwise, if people have DHCP 'Discover' errors they should check W5200 source ip is 0.0.0.0 (i.e. wiz.SetIp(0,0,0,0)) before calling Dhcp.spin.
Learning a lot Mike, thanks a lot for your support!
Please grab the latest code.
DHCP.spin
Socket.spin
DhcpDemo.spin
Through researched and asking around, it seems requesting option 3 (router) in the discovery packet and using it for the gateway configuration is the way to go.
Give it at shot when you get a chance. Let me know.
The aspect of using the 'router ip' returned by DHCP as the 'gateway ip' seems ok, but I'm afraid something else got broken. I'll have to dig further, maybe revert to previous versions to debug, but unfortunately I have to go out of town for a few days. Here's all I can leave you with for now...
1. The immediately prior versions of dhcp and socket, along with my explicit setting of GatewayIp := RouterIp was working perfectly, very fast and 100% reliable.
2. To complicate matters I've been using a slightly older version of TSCDDD (to preserve my mods, test code), but both the older and latest versions worked fine with prior versions of dhcp and socket.
3. Now, with the latest versions of socket and dhcp, there are issues...
a. The older version of TCSDDD manages to go thru dhcp and dns and GETs/displays the file, but fails the final step with 'timeout' instead of displaying bytecount and closing the TCP socket.
b. The latest version of TCSDDD gets thru dhcp and dns, makes the connection, issues the GET then 'timeout'.
4. If it's a clue, now the dns phase is very slow - maybe 6-7 seconds, was just 1 second or so before.
Again, sorry I have to take a break until next week and then I'll try to take a closer look at what changed from previous version of dhcp and socket compared to current version. Two steps forward, one back. But at least the GatewayIp := RouterIp part works now.
...no rush Mike - I'm leaving right now won't be able to work on it until next week. But I'm sure it will be OK since it was working great just prior. Sounds like you're making good progress with Igor too. Frustrating, but worth it - TCP Client + DHCP + DNS in 8KB, that's impressive!
He twc , fustrating maybe, Rewarding definitly.
Like I saw Ken Gracey also metion in another post ,Mike is the leader in understanding how this device works . And its been great to be able to work to get it all working with him , more input will always give more perspective in solving the problem , thats what Im helping out with here . Mike the engine.
Deffinitly comming to an nice ending . in the line of TCP Client + DHCP + DNS you forgot to mention the login page :P.
with it it wil become the complete package. Hopefully by next week when your back .it wil be working bugg free
Just tried the new software (i.e. TSCDDD) - bingo, it works! I'll go back and check the entire package again, but this was the only issue I'd found previously. Timeouts don't seem an issue - execution is very snappy, 3-4 seconds total for power-up init, DHCP, DNS, Connect, issue GET, display the file, Disconnect. I'm using a Netgear WND3300, pretty typical setup, so hopefully works for most folks/major brands.
I built a UDP client and server app. I'll drop it on the code repository.
NetBIOS uses broadcast to identify network devices. Run the NetBios unit test using some IP. Once the broadcast is complete, load one of the TCP server demos using the same IP used in the NetBIOS app. Now you can hit the server by typing http : // propnet: [port]
NetBiosUnitTest works as described in the comments (i.e. nbtstat, ping). But I guess you have to set the MAC in the data structure (nbStatQueryResp) as well as wiz.SetMac? The MAC in the data structure is what gets displayed by nbtstat -a PROPNET. Ran it once then changed IP & MAC and ran again thinking that would test attempt to register an already used name. But seems like that confused my router and/or PC, they thought it was still at first IP even though it was now at second IP so ping said PROPNET was unreachable. Tried the command to clear the cache (nbtstat -RR) but nbstat says that failed, access denied. Re-ran it and everything straightened out using second IP & MAC. Anyway, does what you say and I'm not knowledgable enough to test it beyond that.
But I guess you have to set the MAC in the data structure (nbStatQueryResp) as well as wiz.SetMac?
Ah poop... yes
Ya know I was really excited when I got the NetBIOS API working. I probably should hold back releasing the code until I make it a little ( a lot ) more user friendly.
Looks like I came across an issue with DNS. It seems to work fine with your demo examples (ex: 'finance.google.com'). But I wanted to try to use it to lookup ip for 'www.weather.gov' and it seems to crash...
...here's another possible clue using DnsDemo. With 'weather.gov' it returns proper ip (but not the one I need)...
Disconnect
No error condition. 0
1
204.227.127.201
...but with 'www.weather.gov' it returns confusing result/ip...
Disconnect
No error condition. 0
4
4.97.56.57
56.15.15.3
..i.e. thinks it found four ip's but only manages to display two (incorrect ones) and then seems to crash (DnsDemo is running in RAM, after a few seconds the Prop restarts and executes program in EEPROM).
www.weather.gov does not return an IP in the first answer of the DNS packet, it returns an encoded pointer to Primary name: www. weather. gov. edgesuite. net. That caused the parsers to be off by 2 bytes. I verify the two other examples still work.
I'll probably have to spent more time in the DNS object. Decoding DNS packets is a little tough.
That got it working Mike - thanks a lot! I'll let you know if I come across anything else, but problems definitely getting fewer and farther between at this end.
...partial correction/FYI: fixing Dns.spin works with the larger demos which use it, but I just noticed that the basic DnsDemo (which doesn't use the Dns.spin object) needs the same fix.
Been checking the latest release & demos. Only thing I found is DhcpUnitTest (which doesn't uses Dhcp.spin) 'Failsafes', probably needs whatever fixes you've made to Dhcp.spin. Otherwise all the TCP Client/Server, Dhcp, Dns, Authentication, Netbios, etc. demos work as advertised. Haven't tested the UdpSocket demos (not quite sure how), but UDP obviously works for DHCP & DNS. I'll let you know if I come across anything, but right now your software is handling everything I'm asking. This is a very nice foundation for net apps, leaves plenty of memory & MIPS to spare - well done!
Been checking the latest release & demos. Only thing I found is DhcpUnitTest (which doesn't uses Dhcp.spin) 'Failsafes', probably needs whatever fixes you've made to Dhcp.spin.
Thanks for the heads-up. You have to be careful with the unit test source. It may not function as expected since usually I'm testing just a unit of code.
Comments
Please describe your network setup. Do you have switches, routers...
Dhcp.spin
DhcpDemo.spin
TcpSocketClientDemoDhcpDns.spin
W5200.spin
I don't know for sure as I would need a packet dump but I believe the gateway IP is empty on the DHCP Offer packet. The gatway IP gets set to 0.0.0.0. Therefore, the DNS request fails because the packet is being sent to 0.0.0.0.
I changed the logic to look for an empty server field in the DHCP Offer packet. If the field is empty then use the router IP as the gateway.
Looks like I have to do a little more research to verify my understanding of DHCP is correct.
pst.str(string("DHCP: Router IP.......")) printIp(wiz.GetRouter) pst.char(CR) ' dhcp ends here ' printIp(wiz.GetGateway) wiz.SetGateway(10,0,0,1) // guess dhcp didn't set up W5200 gateway regs? ' printIP(wiz.GetGateway) ' dns starts here pst.str(string("DNS: Resolving IP...")) dns.Init(@buff, 6) 'remoteIP := dns.ResolveDomain(string("[URL="http://www.agaverobotics.com"]www.agaverobotics.com[/URL]")) remoteIP := dns.ResolveDomain(string("finance.google.com"))...by inserting a wiz.SetGateway (to my gateway) after dhcp. I tried to dig into your code to see where dhcp actually sets the W5200 gateway registers or even how to display the W5200 gateway registers but got lost (my code example shows a hypothetical 'wiz.GetGateway' that would make it easy to confirm the situation). Seems like you need something like 'W5200 gateway address := router address from dhcp. Hope this info helps.
Anyway, feels good to make progress. Thanks as always Mike.
printIp(wiz.GetRouter) pst.char(CR) ' dhcp ends here ' printIp(wiz.GetGateway) wiz.SetGateway(byte[wiz.GetRouter][0], byte[wiz.GetRouter][1], byte[wiz.GetRouter][2], byte[wiz.GetRouter][3]) ' printIP(wiz.GetGateway) ' dns starts here pst.str(string("DNS: Resolving IP...")) dns.Init(@buff, 6)BTW, i added a new method, start, to W5200. The signature...
It is not longer necessary to update the W5200 object CON block after downloading the most recent library updates.
Initialize W5200
Getting network paramters
Requesting IP.....10.0.0.133
DNS...............10.0.0.1
DHCP Server.......10.0.0.1
Router IP.........10.0.0.1
Gateway IP........0.0.0.0
Resolve domain IP.74.125.224.98
Initialize Socket
Begin Client Web request
Open
Connecting to.....74.125.224.98
...it doesn't connect as before. Note that gateway is still shown 0.0.0.0 after DHCP. Just to be sure I insert a PrintIP(wiz.GetGateway) right before the TCP open and can see the gateway is still 0.0.0.0.....
Initialize W5200
Getting network paramters
Requesting IP.....10.0.0.133
DNS...............10.0.0.1
DHCP Server.......10.0.0.1
Router IP.........10.0.0.1
Gateway IP........0.0.0.0
Resolve domain IP.74.125.224.135
Gateway IP........0.0.0.0
Initialize Socket
Begin Client Web request
Open
Connecting to.....74.125.224.135
...now if I insert the wiz.SetGateway right before the TCP open...
pst.str(string("Resolve domain IP.")) dns.Init(@buff, 6) 'remoteIP := dns.ResolveDomain(string("[URL="http://www.agaverobotics.com"]www.agaverobotics.com[/URL]")) remoteIP := dns.ResolveDomain(string("finance.google.com")) 'remoteIP := dns.GetResolvedIp(1) PrintIp(remoteIP) pst.char(CR) wiz.SetGateway(byte[wiz.GetRouter][0], byte[wiz.GetRouter][1], byte[wiz.GetRouter][2], byte[wiz.GetRouter][3]) pst.str(string("Gateway IP........")) printIp(wiz.GetGatewayIp) pst.str(string("Initialize Socket")) buffer := sock.Init(0, TCP, 8080)...it works fine...
Initialize W5200
Getting network paramters
Requesting IP.....10.0.0.133
DNS...............10.0.0.1
DHCP Server.......10.0.0.1
Router IP.........10.0.0.1
Gateway IP........0.0.0.0
Resolve domain IP.74.125.224.33
Gateway IP........10.0.0.1
Initialize Socket
Begin Client Web request
Open
Connecting to.....74.125.224.33
Send HTTP Header
Bytes Sent: 99
HTTP/1.1 200 OK
Content-Type: application/vnd.ms-excel
...I think you were planning to do something like 'if gateway == 0.0.0.0 then gateway = router'? Looks like that's what dhcp.GetSetGateway is trying to do? Is the difference between 'router' and 'gateway' just syntax, or do they really mean different devices in the net world? Anyway, just need to figure out why gateway is still 0.0.0.0 at the time of TCP open.
Couple of notes...
1. Notice this time I put my gateway setting fix after DNS i.e. that means DNS works with gateway=0.0.0.0. But this may just be because, in my network case, DHCP is saying my router is the DNS server (both 10.0.0.1). I suspect if DHCP returned an external DNS server ip that Dns.spin would then hang, unable to connect just as TCP can't, with gateway 0.0.0.0. Or maybe my network can deal with gateway=0.0.0.0 for a UDP transaction, but not TCP?
2. It has always been, and remains, the case that in my network setup the W5200 source ip must be 0.0.0.0 or Dhcp.spin will have 'Discover Error' (even with valid source ip). I think this is different from your setup where DHCP will work with a (valid) ip? I had been adding wiz.SetIp(0,0,0,0) at the beginning of the demo, but the demo now works without it (i.e. power-up and/or your code starts up with W5200 source ip registers = 0.0.0.0). This probably not be an issue in the typical use case (i.e. call DHCP first thing to get ip), but you never know. Does DHCP work with source ip = 0.0.0.0 for you? Do you think it would work for everyone? If so you could put wiz.SetIp(0,0,0,0) at beginning of dhcp.spin. Otherwise, if people have DHCP 'Discover' errors they should check W5200 source ip is 0.0.0.0 (i.e. wiz.SetIp(0,0,0,0)) before calling Dhcp.spin.
Learning a lot Mike, thanks a lot for your support!
DHCP.spin
Socket.spin
DhcpDemo.spin
Through researched and asking around, it seems requesting option 3 (router) in the discovery packet and using it for the gateway configuration is the way to go.
Give it at shot when you get a chance. Let me know.
The aspect of using the 'router ip' returned by DHCP as the 'gateway ip' seems ok, but I'm afraid something else got broken. I'll have to dig further, maybe revert to previous versions to debug, but unfortunately I have to go out of town for a few days. Here's all I can leave you with for now...
1. The immediately prior versions of dhcp and socket, along with my explicit setting of GatewayIp := RouterIp was working perfectly, very fast and 100% reliable.
2. To complicate matters I've been using a slightly older version of TSCDDD (to preserve my mods, test code), but both the older and latest versions worked fine with prior versions of dhcp and socket.
3. Now, with the latest versions of socket and dhcp, there are issues...
a. The older version of TCSDDD manages to go thru dhcp and dns and GETs/displays the file, but fails the final step with 'timeout' instead of displaying bytecount and closing the TCP socket.
b. The latest version of TCSDDD gets thru dhcp and dns, makes the connection, issues the GET then 'timeout'.
4. If it's a clue, now the dns phase is very slow - maybe 6-7 seconds, was just 1 second or so before.
Again, sorry I have to take a break until next week and then I'll try to take a closer look at what changed from previous version of dhcp and socket compared to current version. Two steps forward, one back. But at least the GatewayIp := RouterIp part works now.
Thanks for the feedback.
Like I saw Ken Gracey also metion in another post ,Mike is the leader in understanding how this device works . And its been great to be able to work to get it all working with him , more input will always give more perspective in solving the problem , thats what Im helping out with here . Mike the engine.
Deffinitly comming to an nice ending . in the line of TCP Client + DHCP + DNS you forgot to mention the login page :P.
with it it wil become the complete package. Hopefully by next week when your back .it wil be working bugg free
Get the latest Socket and DhcpDemo.
As always, thanks for your tireless support Mike.
Timeout settings do affect response time. For example, I have the Socket object's default configuration (CON Block) set to the following.
This setting is for Igor as his network has a pretty slow response times; over 1.5 seconds.
Eventually, I'll have this information in the code comments.
DhcpDemo
DnsDemo
TcpSocketClientDemo
TcpSocketClientDemoDns
TcpSocketClientDemoDhcpDns
TcpSocketServerDemo
TcpMultiSocketServerDemo.spin
HTML5Graph.spin
TcpSocketBasicAuthenticationServerDemo
...all work fine. Not sure how to test the Udp demos or NetBios. Anyway, looking good at this end!
NetBIOS uses broadcast to identify network devices. Run the NetBios unit test using some IP. Once the broadcast is complete, load one of the TCP server demos using the same IP used in the NetBIOS app. Now you can hit the server by typing http : // propnet: [port]
Ya know I was really excited when I got the NetBIOS API working. I probably should hold back releasing the code until I make it a little ( a lot ) more user friendly.
Looks like I came across an issue with DNS. It seems to work fine with your demo examples (ex: 'finance.google.com'). But I wanted to try to use it to lookup ip for 'www.weather.gov' and it seems to crash...
Initialize W5200
Getting network paramters
Requesting IP.....10.0.0.129
DNS...............10.0.0.1
DHCP Server.......10.0.0.1
Router IP.........10.0.0.1
Gateway IP........10.0.0.1
Resolve domain IP..@
Disconnect
No error condition. 0
1
204.227.127.201
...but with 'www.weather.gov' it returns confusing result/ip...
Disconnect
No error condition. 0
4
4.97.56.57
56.15.15.3
..i.e. thinks it found four ip's but only manages to display two (incorrect ones) and then seems to crash (DnsDemo is running in RAM, after a few seconds the Prop restarts and executes program in EEPROM).
www.weather.gov does not return an IP in the first answer of the DNS packet, it returns an encoded pointer to Primary name: www. weather. gov. edgesuite. net. That caused the parsers to be off by 2 bytes. I verify the two other examples still work.
I'll probably have to spent more time in the DNS object. Decoding DNS packets is a little tough.