Go Down

Topic: Ethernet shield - webClient example (Read 6 times) previous topic - next topic

linux-works

>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!

kg4wsv

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

Quote
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


linux-works

#17
Apr 29, 2009, 03:14 pm Last Edit: Apr 29, 2009, 03:15 pm by linux-works Reason: 1
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.

enough said, maybe? ;)

kg4wsv

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.

-j


*  Error Exists Between Keyboard And Chair


linux-works

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.

take it out.

linux-works

one more point of info, I was once in IT at a company whose numbering scheme was the other way around (sort of).  they numbered routers from the top end of the subnet on down and other kinds of devices from the bottom, up.  some reserved ranges were for dyn users, some for term servers, some for bridges, etc.  it was all designed and had been working fine for, well, probably a decade or so.

and you insist they have to renumber to fit YOUR view of the world where 'dot 1 = router' ??

there never WAS a 'dot one standard' for numbering where routers are.

there is a standard for class A,B,C subnetting but even that makes little sense since CIDR came along.  and so assuming a 'classical class-C' is even incorrect, really.

assuming anything other than what the users supplies to you just gets you into trouble, with api's like this.  all 4 parms are needed and NONE are truly guessable with reliability.

I hate having to beat this dead horse, but I'm not sure I'm getting thru...

follower

Keep in mind that the default on-chip "unconfigured" state for the gateway is fine if one is only intending to do local communication. In that case I don't think requiring the gateway parameter in the constructor is a plus.

--Phil.

linux-works

#22
Apr 30, 2009, 03:30 pm Last Edit: Apr 30, 2009, 03:31 pm by linux-works Reason: 1
this is also bad design, guys.

at some point, the 'lan only' application may see a wan.

and THEN what?

you gonna say 'oops, this was only meant for lans' ?

I cannot believe I have to argue about how to configure basic ip networking!  this is simply amazing.

I'm starting to not care anymore, I guess.  if you want a broken-by-design api, that's your business.  I have aruged all I can here.  if you guys want to play around with WRONG methods in how to configure ip, go ahead.  but don't blame me if you get complaints from users based on your 'assumptions' about how ip works.

sheesh...

Ray Andrews

While linux-works may need to switch to decaf', his points are valid.

Putting .1 into code is just a bad programming.  Whenever I set up a network, I avoid putting anything at .1  Why, because the first script-kiddie that my client hires is going to try .1  When possible I like to see a smart switch on .1 that locks out any mac address that tries to talk with it.

Yes, most home routers come configured as a.b.c.1,  and yes, in 90+ percent of the cases it's going to work because of that default setting.  So, it should be put into documentation that you should "try .1"  and it could be put in comments that you should "try .1"  but .1 should never be codified. Give the user/programmer the opportunity to make their own bad assumptions, don't give them a head start by making one for them.

255.255.255.0 is the same issue, sure it will work most of the time, but if it's configurable, make it so that it needs to be configured.  Start out with 255.255.255.255 and tell the user/programmer "hey you're going to have to put in a subnet".  Sure, they'll likely put in the standard easy one, but at least then you haven't started anyone off in the wrong direction.

glt

Quote
I cannot believe I have to argue about how to configure basic ip networking!  this is simply amazing.


Linux-works, undoubtedly many people value your contribution, but I believe many here are not computer science/IT type of people (including myself). Perhaps posting in software bugs/suggestions will get a wider audience? Don't give up and continue to care :-)

linux-works

hmmm, here's my proposal, then:

1) lw cuts down from 4 cups of coffee a day down to 2.  at least on days he posts about bugs.

2) the ethernet api goes up from 2 mandatory parms to 4 mandatory parms.  even on days lw is not drinking 2 cups of coffee.

DOES THA

does that work for everyone?

;)

kg4wsv

Requiring a router IP is wrong and potentially confusing, since as follower points out it is not required.  

Requiring a netmask is somewhere between unnecessary and wrong, since the default netmask can be derived from the first 3 bits of the IP address, and at least 99% of home networks will use the default.  That default does need to be calculated instead of hard coded, but I've already written that patch.

For those reasons, I think the 2 parameter begin() should stay.

[pauses to don kevlar jacket and helmet]

I really do not see a problem with assuming a default gateway of subnet.1 if no gateway is required.  It is not a universal default, but it is a reasonable guess.  I have been in training for "big iron" class routers where it was suggested that .1 is a good default to configure, so that it is easy to find.

Hey, we already let users write C programs with no main(), what does it hurt to guess at the router for them?

I won't argue with the developers if they decide to remove it, but I will not argue to have it removed, either.

-j (unix system and network administrator for 20 years)

kg4wsv

Come to think of it, I could argue for a 3 parameter begin() (mac, IP, netmask) for sub/supernetted non-routed networks...

-j


Ray Andrews

Quote
since the default netmask can be derived from the first 3 bits of the IP address


I dont see how this is possible, yes you can determine a little by looking to see if it's a 192. or a 10.  but that doesnt mean that the segment you are on is allowed to use all 255 values. It may also be that the ip range is using internet routable addresses but is not connected to the internet. There are lots of things that can limit what your subnet can actually be aside from assumed values.

Quote
I really do not see a problem with assuming a default gateway of subnet.1


There's probably nothing wrong with assuming that, but it should be your assumption to make, not something assumed in the code for you.


kg4wsv

Quote
I dont see how this is possible

Check the RFCs.  The default subnet mask is defined in the IPv4 standard.  First bit 0? class A.  first 2 bits 10? class B.  first 3 bits 110? class C.  Same for classes D and E, but those aren't node addresses.

-j


Go Up