But now am having trouble with the webClient example which doesn't connect at all.
I used the same IP address (byte ip[] = {169, 254, 70, 27 } that works with the webServer example & I'm able to ping the shield. Any tips?
I'm a bit bemused by wireshark in terms of trying to track down the issue, any tips with regards to that (or other software to track down the problem) would be gratefully received.
I've got the same problem using the same software and hardware My router is 192.168.1.2 so have added that to the setup but it still doesn't connect. I can ping it, but that's about it. I got the WebServer working but not this WebClient
I used the same IP address (byte ip[] = {169, 254, 70, 27 } that works with the webServer example & I'm able to ping the shield. Any tips?
Did you configure the router address... Oh, wait, is this still plugged into your computer directly rather than into the router? You will need it to be connected to the router unless you Mac is set up for internet connection sharing.
I'm a bit bemused by wireshark in terms of trying to track down the issue, any tips with regards to that (or other software) would be gratefully received.
Ummm... Record a packet capture while you try to connect. Look at the capture and...somehow notice what's going wrong. Not terribly helpful, I realise.
it's plugged into my network at work, I've turned the firewall off to test but it still doesn't work. You mentioned about capturing packets? how would you do that?
On my mac, turned the internet sharing on so that the mac was connected to wifi, and sharing that connection via ethernet.
Connected another mac to my machine via ethernet and looked up what ip it was getting. The important part is the first 3 sets of numbers, as those will have to be the same for what you give the arduino. In my case it was 192.168.2.xxx. (the ".2" is probably the surprise in all this btw)
Opened up the WebClient example and set the byte ip to 192,168,2,249 (just something high up there for the last digit), and reconnected my arduino.
At this point, it started working sporadically, kinda. It may appear to not work at all, to which I also had to do the following which is really odd...
Add the following line:
Serial.println(client.connect()); //ADD THIS LINE <----------
if (client.connect()) {
Serial.println("connected");
client.println("GET /search?q=arduino HTTP/1.0");
client.println();
} else {
Serial.println("connection failed");
}
It wasn't until I did all of this that I actually got everything working, and it hasn't failed me for 3 weeks so far. Let me know if any of this helps...
not that I know of, I ended up putting it outside the firewall and it seems to work.. well the webClient doesn't come up with any data but doesn't come up with any errors. is it not meant to return a google result?
I then tried the pachube example and that seems to work now, apart from it looping which I think other people have had:
got the WebClient working:)
Cheers asz it was one of your tips that solved it:
Connected another mac to my machine via ethernet and looked up what ip it was getting.
I unplugged the other mac & typed the same IP address that the mac was assigned {192,168,5,2}
So what confused me is that one IP address can work for the webServer but not for the webClient example. But the IP I identified above (using another machine) works for both examples.
So what confused me is that one IP address can work for the webServer but not for the webClient example. But the IP I identified above (using another machine) works for both examples.
Yeah, that's because I suggested the 169.254.x.y address specifically because it meant you didn't have to configure an IP address for your Mac if you used a direct connection between it and your Arduino.
Once you get past a direct connection it would no longer work in most cases--as you discovered.
could I suggest a HUGE bug be fixed in the ethernet libr?
I found that by reading the source, if you only give mac,ip to the constructor for ethernet it 'guesses' (HUH??) that your router is a.b.c.1.
WRONG-O, guys. really really wrong call here.
please remove this. its wrong, its misleading and it caused me hours of troubleshooting (cough, ahem, my network is NOT setup like yours and my router isn't "dot 1" ok?)
there is no such thing as a default default router (grin).
either properly detect a default router by sniffing the wire (unlikely) or trying ping blasting the wire to learn what's there (also unlikely) or just MAKE THE USER enter the 4 bits of into (subnet, ip, mac and router).
please guys, I beg you. remove the methods that take 2 and 3 parms. there should only be the 4 parm method. 'guessing' subnets and router ip's is bad news.
The vast majority of networks I've encountered use x.1 as the router, so I think it's a decent 'guess'. Most home routers that deal up DHCP addresses do this. For networks like yours that are configured differently, there are options to provide the correct values.
The documentation on server: Ethernet - Arduino Reference is more clear on this than the documentation on client: http://arduino.cc/en/Reference/ClientConstructor so the documentation should probably be updated to say what's going on with the abbreviated constructor. The documentation for begin: or begin: Ethernet - Arduino Reference states the optional and default values pretty clearly. Not sure how to request documentation changes.
I followed the web client test code (trying to connect to google) and that's what made the 'bug' very apparent to me.
hate to keep saying it, but assuming any magic-number for a default ip router is wrong, guys. been in the networking industry way too many years and this just is not done.
there IS no default and even if you document you are slamming in a dot one at the end, does not make it any more acceptable or correct. its hit and miss and if you hit when someone happens to have a .1 in their network, they get the false assurance that 'ok, cool, my code works now' and yet IT DOESN'T WORK. that's my point.
coding like this is wrong and its dangerous.
please change it. remove any 'assumed defaults' because not everyone is in class C and running with a dot-1 router in their subnet.
it will cause confusion, either immediately (I was lucky) or later on down the road when they DON'T have a dot 1 as their router.
sorry to rant, but its just bad to have defaults when there really are not. just force users to supply 4, all the time, always. then life is good. always.
The vast majority of networks I've encountered use x.1 as the router, so I think it's a decent 'guess'.
sorry again, but one does NOT design code on guesses.
please remove this api method. its problematic at the very assumption of it.
you must agree, I hope, that any solution which works in one case but fails in others is not a real clean solution and in fact gives false impressions that its working when its a time bomb waiting to go off.
so many people -thought- it worked and so it was published as a working example. this was a disservice since it was NOT a working example, it just HAPPENED to work for a few people who tested it. can you see that it isn't REALLY working?
I was thinking that on my local LAN, I don't need a default router and that inside a subnet, stations just talk direct. so when I was testing this 'on my local LAN' I found that the mac,ip method did not work. that costed me many hours of debugging only to find this horrible assumption about dot-1 addressing.
this is just not the way to write apis. based on 'well, its LIKELY that some user will have a .1 router'. sheesh!!
I'll have to admit at first I more or less ignored linux-works' post because it was a rant.
On further inspection, though, he's right - something is broken.
The method that assumes a subnet mask of 255.255.255.0 is clearly broken; the default subnet mask can easily be calculated from the first few bits of the IP address. If we want to do it for the users, we may as well do it right.
I'm not all that hung up on the x.1 "default" as the router (because that is so often the case), but the fact that he apparently could not carry out LAN communications because of these defaults seems like a serious issue.
linux-works, could you give us more details about what didn't work? IP address of the sender and receiver, at least, and the netmask in use on that LAN?
I didn't meant to come of ranting (lol) but I was actually quite surprised to see this.
my network has a .251 router (history reasons, my 'plastic firewall' was once forced at .251 and I just kept it over the years).
right there - is a reason why the 'dot one' idea breaks. it really is arbitrary and best practice is to have users just enter the darned quad of info
yes, I do run a pure class C at home but again, its so easy just to require the user to enter all 4 bits of info. the ard. is not a high end system and making the user enter all 4 bits is not such a burden
(well, entering a mac is quite surprising to me, as well. but I'll ignore that since its far less dangerous for the user to pick a mac than to 'guess' that the router is dot-one)
what really got me was that I could ping into the ard from other hosts on the lan but if the ard wanted to originate a packet (to google, via the demo code) it would get 'nothing but dialtone', so to speak.
default routers are important once you have to leave your lan (lol) and so guessing one is just really really wrong. unless you DISCOVER one, but that's way more than an ard-level box should really have to do.
(such a damned pity that dhcp isn't supported yet, although I admit I run only static IP's in my network).
I suspect that has to do with the cost of acquiring an address block from IEEE, or maybe some design requirement, although I'm a bit surprised as well.
I could ping into the ard from other hosts
OK, so sounds like there was no problem with LAN traffic, just routed traffic. This is what I would expect.
being able to ping into the ard at least proved my tx and rx wires were on on the rj45 and that the device was wired ok to my ard, itself.
when you get NOTHING you start checking phys things
all phys things seemed ok but the google demo didn't work.
so yes, it was a router definition issue and not anything hardware or my software.
what drove me even more nuts is that I tried one example that did list all 4 parms and that one worked. I tried it a few weeks ago and just made a mental note 'ethernet does work' and I went on to do other things. then I came back to this and found it didn't work (in the 2 or 3 parm version). and that causes me much grief as I had 'remembered' it once worked before.
Something I have noticed is that there is sometimes a large disconnect between the networking knowledge required to successfully use an arduino ethernet shield and what the typical arduino user may know about networking. This frequently gets the hardware or software blamed when it's an EEBKAC* problem. I salute the Arduino team's bravery; I'm not sure I would have released such a potentially troublesome beast.
I think the DHCP client that some folks are working on will help greatly in this area. I am also mentally kicking around some zero-configuration (er, zero-IP-configuration, at least) communication methods for arduino LAN traffic.
I have a code change to at least set the correct default netmask based on the IP; I'll submit that to the developers today.
does that mean you'll leave that .1 stuff in, though?
please, THAT is more the point.
just asking that they remove the 3 and 4 parm versions of the methods. insist that the user supply all 4.
what's wrong with that? it works, its GUARANTEED to work and never has false pos or neg's.
please, solve it right. I'm not asking all that much
and its NOT a user issue when you 'guess' based on crazy ideas about what people have in their networks. this dot one stuff is just problematic at best. at best.