Ethernet shield - webClient example

I got the webServer example working after a bit of help
( http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1236113841/5#5 )

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 }:wink: 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.

Oh yes, I'm on OSx arduino 13.

Ta Tom:)

I've got the same problem using the same software and hardware :frowning: 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

arduino 13 and Ethernet shield

my code is here:

#include <Ethernet.h>

byte mac[] = { 0x00, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = { 192, 168, 1, 99 };
byte gateway[] = { 192, 168, 1, 2 };
byte subnet[] = { 255, 255, 255, 0 };
byte server[] = { 64, 233, 187, 99 }; // Google

Client client(server, 80);

void setup()
{
  Ethernet.begin(mac, ip, gateway, subnet);
  Serial.begin(9600);
  
  delay(1000);
  
  Serial.println("connecting...");
  
  if (client.connect()) {
    Serial.println("connected");
    client.println("GET /search?q=arduino HTTP/1.0");
    client.println();
  } else {
    Serial.println("connection failed");
  }
}

void loop()
{
  if (client.available()) {
    char c = client.read();
    Serial.print(c);
  }
  
  if (!client.connected()) {
    Serial.println();
    Serial.println("disconnecting.");
    client.stop();
    for(;;)
      ;
  }
}

I used the same IP address (byte ip[] = {169, 254, 70, 27 }:wink: 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. :slight_smile:

--Phil.

it's plugged into my network at work, I've turned the firewall off to test :slight_smile: but it still doesn't work. You mentioned about capturing packets? how would you do that?

cheers

boppyer

Here's how I solved my issues:

  1. On my mac, turned the internet sharing on so that the mac was connected to wifi, and sharing that connection via ethernet.
  2. 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)
  3. 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...

  1. 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...

The routers on your work network havnt got restrictions based on the mac addresses have they?

Gordon

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:

http://community.pachube.com/?q=node/112#inputoutput

thanks for your help, going to keep persevering

got the WebClient working:)
Cheers asz it was one of your tips that solved it:

  1. 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.

Very happy now:)!

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. :slight_smile:

--Phil.

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?) :wink:

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.

please.

/bryan

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. :wink:

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?

-j

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 :wink:

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 :wink:

(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) :wink:

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'm not all that hung up on the x.1 "default" as the router (because that is so often the case),

its quite frequent that I find US mailboxes on the corner of streets.

therefore, I'd like to suggest we all just go to the corner of our streets and drop letters there, EXPECTING the boxes to be in place.

see my point?

do you design code assuming that 'most users' have a certain addressing scheme?

come on!

entering a mac is quite surprising

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.

-j

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 :wink:

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.

enough said, maybe? :wink:

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. :slight_smile:

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.

-j

* Error Exists Between Keyboard And Chair

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 :wink:

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.

take it out.