unix nameToAddr() function appears to not work on Raspbian?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

unix nameToAddr() function appears to not work on Raspbian?

timrowledge

Somebody noticed that asking for the local address on a Pi vm returns 127.0.1.1 these days, whereas on my iMac it returns the actual machine IP. That’s a much more useful thing.

The Smalltalk code is in NetNameResolver class>>localHostAddress, using prim SocketPlugin.c->primitiveResolverLocalAddress() etc. Running this under gdb shows me that we are finding the machine’s local name ok (‘Pi-2’ in this case) but that sqResolverLocalAddress() is using nameToAddr() and being told “127.0.1.1” - well strictly speaking 0x7f000101 of course. I’ve tried `man nameToAddr` and googling nameToAddr and got.. nothing. I don’t even seem to find it listed in a header file out there.  Whah?

Puzzled in Qualicum...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- An 8086 in a StrongARM environment.


Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

David T. Lewis
 
On Wed, Sep 16, 2015 at 04:40:17PM -0700, tim Rowledge wrote:
>
> Somebody noticed that asking for the local address on a Pi vm returns 127.0.1.1 these days, whereas on my iMac it returns the actual machine IP. That?s a much more useful thing.
>
> The Smalltalk code is in NetNameResolver class>>localHostAddress, using prim SocketPlugin.c->primitiveResolverLocalAddress() etc. Running this under gdb shows me that we are finding the machine?s local name ok (?Pi-2? in this case) but that sqResolverLocalAddress() is using nameToAddr() and being told ?127.0.1.1? - well strictly speaking 0x7f000101 of course. I?ve tried `man nameToAddr` and googling nameToAddr and got.. nothing. I don?t even seem to find it listed in a header file out there.  Whah?
>
> Puzzled in Qualicum...
>

Some recent related discussion:

Tobias fixed a test that was failing due to this issue:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2015-September/185892.html

And he provided a link to some Debian documentation that explains why it
works that way on Debian based systems:

https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution

I replied to Tobias and claimed that primitiveSocketLocalAddress is
working as intended:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2015-September/185912.html

If you look in the /etc/hosts file on your Pi, you will probably see an entry
mapping the host name for your Pi to the address 127.0.1.1. I do not know why
your iMac is giving you the more sensible and useful result, but I would like
to know the answer if you figure it out. You might want to look at /etc/hosts
on the iMac and see if it offers any obvious clues.

One small but important point - there is no such thing as an "actual machine IP"
on your Pi. The IP addresses are associated with one or more network interfaces
(e.g. wireless or ethernet interfaces), and each interface may have one or more
IP addresses associated with it. The common case for a small machine would be
one network interface with a single IP address, which of course is what you are
trying to find.

Dave
 
Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

Eliot Miranda-2
In reply to this post by timrowledge
 
Hi Tim,

On Wed, Sep 16, 2015 at 4:40 PM, tim Rowledge <[hidden email]> wrote:

Somebody noticed that asking for the local address on a Pi vm returns 127.0.1.1 these days, whereas on my iMac it returns the actual machine IP. That’s a much more useful thing.

can you post the contents of /etc/hosts on your machine?
 
The Smalltalk code is in NetNameResolver class>>localHostAddress, using prim SocketPlugin.c->primitiveResolverLocalAddress() etc. Running this under gdb shows me that we are finding the machine’s local name ok (‘Pi-2’ in this case) but that sqResolverLocalAddress() is using nameToAddr() and being told “127.0.1.1” - well strictly speaking 0x7f000101 of course. I’ve tried `man nameToAddr` and googling nameToAddr and got.. nothing. I don’t even seem to find it listed in a header file out there.  Whah?

Puzzled in Qualicum...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- An 8086 in a StrongARM environment.

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

timrowledge
In reply to this post by David T. Lewis

Thanks Dave,

On 16-09-2015, at 7:55 PM, David T. Lewis <[hidden email]> wrote:
> Tobias fixed a test that was failing due to this issue:
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2015-September/185892.html
>
> And he provided a link to some Debian documentation that explains why it
> works that way on Debian based systems:
>
> https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution

Ah, right. Some words in that actually make sense to me, just not the gestalt. But happily I don’t have to care too much :-) Since it’s Debian (and therefore Raspbian) setup related and not me-making-mistake, it gets wrapped in a nice thick SEP field.

>
> One small but important point - there is no such thing as an "actual machine IP"
> on your Pi.

With enough of the appropriate memory enhancing drugs I would probably have remembered that, having run into similar stuff before, I think with a machine that had multiple ethernet cards.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
In the long run, every program becomes rococco, and then rubble.


Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

timrowledge
In reply to this post by Eliot Miranda-2


On 17-09-2015, at 8:33 AM, Eliot Miranda <[hidden email]> wrote:
> can you post the contents of /etc/hosts on your machine?
>  

Well, it had very plain contents, the usual localhosts & ipv6 stuff and finally the actual machine name line with 127.0.0.1

Changing that to the ‘proper’ IP (since I have my router setup to give the same address every time by MAC matching I felt safe enough) makes things behave much better. But I understand this is not a proper way to do things since using dhcp and/or multiple networks etc might make it all go poof. So I’m puzzled since surely asking for an IP address for the machine is a common thing? The socket plugin code hasn’t changed in years so far as I can see which makes me think it used to just work; certainly it must have done so at some point, and I’m sure I remember getting sensible addresses on a Pi via Scratch in order to do the mesh networking. Very puzzling.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- APRES MOE LE DELUGE - Larry and Curly get wet


Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

Hans-Martin Mosner

Am 18.09.2015 um 19:50 schrieb tim Rowledge:
> ...So I’m puzzled since surely asking for an IP address for the machine is a common thing?
Actually, as David already stated, asking for *the* IP address for a machine is asking for trouble.
The IP address returned (127.0.1.1) is one of the several IP addresses the machine has (via its several network
interfaces), so it's perfectly correct, just not usable for your purpose.
A somewhat more usable function would enumerate all IP addresses of all interfaces and return one that is designated as
public. However, in many situations a machine might be behind a NAT gateway and only has one or several private IP
addresses. Determining which of these is the one that you want to use may be very situation-specific.
So the best thing would be to drop primitiveResolverLocalAddress() altogether, as it is meaningless. Instead enumerate
all interfaces with all addresses and allow the image to determine with suitable selection algorithms which one to use.

Cheers,
Hans-Martin

Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

David T. Lewis
 
On Sat, Sep 19, 2015 at 08:46:47AM +0200, Hans-Martin Mosner wrote:
>
> Am 18.09.2015 um 19:50 schrieb tim Rowledge:
> > ...So I?m puzzled since surely asking for an IP address for the machine is a common thing?
> Actually, as David already stated, asking for *the* IP address for a machine is asking for trouble.
> The IP address returned (127.0.1.1) is one of the several IP addresses the machine has (via its several network
> interfaces), so it's perfectly correct, just not usable for your purpose.

To illustrate, try this:

  NetNameResolver addressesForName: 'google.com'

>From where I sit, it looks like this:

  ==>  an OrderedCollection(74.125.225.6(ord08s12-in-f6.1e100.net),0(0)-inet4-stream-tcp 74.125.225.9(ord08s12-in-f9.1e100.net),0(0)-inet4-stream-tcp 74.125.225.5(ord08s12-in-f5.1e100.net),0(0)-inet4-stream-tcp 74.125.225.7(ord08s12-in-f7.1e100.net),0(0)-inet4-stream-tcp 74.125.225.8(ord08s12-in-f8.1e100.net),0(0)-inet4-stream-tcp 74.125.225.14(ord08s12-in-f14.1e100.net),0(0)-inet4-stream-tcp 74.125.225.3(ord08s12-in-f3.1e100.net),0(0)-inet4-stream-tcp 74.125.225.0(ord08s12-in-f0.1e100.net),0(0)-inet4-stream-tcp 74.125.225.4(ord08s12-in-f4.1e100.net),0(0)-inet4-stream-tcp 74.125.225.1(ord08s12-in-f1.1e100.net),0(0)-inet4-stream-tcp 74.125.225.2(ord08s12-in-f2.1e100.net),0(0)-inet4-stream-tcp 2607:f8b0:4009:804::1005(ord08s10-in-x05.1e100.net),0(0)-inet6-stream-tcp)

The #addressesForName: method is used to look up names such as 'localhost' or
your local host name. Results will vary depending on network configuration,
contents of /etc/hosts, and so forth.

> A somewhat more usable function would enumerate all IP addresses of all interfaces and return one that is designated as
> public. However, in many situations a machine might be behind a NAT gateway and only has one or several private IP
> addresses. Determining which of these is the one that you want to use may be very situation-specific.
> So the best thing would be to drop primitiveResolverLocalAddress() altogether, as it is meaningless. Instead enumerate
> all interfaces with all addresses and allow the image to determine with suitable selection algorithms which one to use.
>

Agreed. I am not sure how to do that though.

Dave

> Cheers,
> Hans-Martin


Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

timrowledge


On 19-09-2015, at 7:14 AM, David T. Lewis <[hidden email]> wrote:
>
>  NetNameResolver addressesForName: ‘google.com'
>
[snip]

The annoying part there is that NetNameResolver addressesForName:’myPi’ quite clearly works out that myPi is the local host and then carefully returns 127.0.0.1 and no other.

> The #addressesForName: method is used to look up names such as 'localhost' or
> your local host name. Results will vary depending on network configuration,
> contents of /etc/hosts, and so forth.

And therein lies the rub; this used to work for the purpose of giving Scratch mesh network users a usable number but no longer does. It apparently used to work generally for most of us since the code just about the same in all platforms. (Well, except for OS X of course, which has to do everything different)

I’m sure we can eventually come up with something that will work but it really annoys me that what has worked for an apparent decade plus has suddenly become not-right without even a by-your-leave.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Yummy" said Pooh, as he rotated Piglet slowly on the spit.


Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

David T. Lewis
 
On Sun, Sep 20, 2015 at 03:34:35PM -0700, tim Rowledge wrote:

>
>
> On 19-09-2015, at 7:14 AM, David T. Lewis <[hidden email]> wrote:
> >
> >  NetNameResolver addressesForName: ?google.com'
> >
> [snip]
>
> The annoying part there is that NetNameResolver addressesForName:?myPi? quite clearly works out that myPi is the local host and then carefully returns 127.0.0.1 and no other.
>
> > The #addressesForName: method is used to look up names such as 'localhost' or
> > your local host name. Results will vary depending on network configuration,
> > contents of /etc/hosts, and so forth.
>
> And therein lies the rub; this used to work for the purpose of giving Scratch mesh network users a usable number but no longer does. It apparently used to work generally for most of us since the code just about the same in all platforms. (Well, except for OS X of course, which has to do everything different)
>
> I?m sure we can eventually come up with something that will work but it really annoys me that what has worked for an apparent decade plus has suddenly become not-right without even a by-your-leave.
>

Um ... are you sure that this "worked" previously? I just tried a Squeak
3.8 image, and it says that NetNameResolver localHostAddress is 127.0.1.1,
which is exactly what Squeak 5.0 says on this same computer.

I suspect that you are just running Squeak on a different platform, and
"NetNameResolver addressForName: self localHostName" is in fact different
compared to whatever it was on your previous systems.

Dave
 
Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

johnmci
 

On Sep 20, 2015, at 6:07 PM, David T. Lewis <[hidden email]> wrote:


On Sun, Sep 20, 2015 at 03:34:35PM -0700, tim Rowledge wrote:


On 19-09-2015, at 7:14 AM, David T. Lewis <[hidden email]> wrote:

NetNameResolver addressesForName: ?google.com'

[snip]

The annoying part there is that NetNameResolver addressesForName:?myPi? quite clearly works out that myPi is the local host and then carefully returns 127.0.0.1 and no other.

The #addressesForName: method is used to look up names such as 'localhost' or
your local host name. Results will vary depending on network configuration,
contents of /etc/hosts, and so forth.

And therein lies the rub; this used to work for the purpose of giving Scratch mesh network users a usable number but no longer does. It apparently used to work generally for most of us since the code just about the same in all platforms. (Well, except for OS X of course, which has to do everything different)

I?m sure we can eventually come up with something that will work but it really annoys me that what has worked for an apparent decade plus has suddenly become not-right without even a by-your-leave.


Um ... are you sure that this "worked" previously? I just tried a Squeak
3.8 image, and it says that NetNameResolver localHostAddress is 127.0.1.1,
which is exactly what Squeak 5.0 says on this same computer.

I suspect that you are just running Squeak on a different platform, and
"NetNameResolver addressForName: self localHostName" is in fact different
compared to whatever it was on your previous systems.

Dave


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

timrowledge
In reply to this post by David T. Lewis


On 20-09-2015, at 6:07 PM, David T. Lewis <[hidden email]> wrote:
>
> Um ... are you sure that this "worked" previously? I just tried a Squeak
> 3.8 image, and it says that NetNameResolver localHostAddress is 127.0.1.1,
> which is exactly what Squeak 5.0 says on this same computer.
>
> I suspect that you are just running Squeak on a different platform, and
> "NetNameResolver addressForName: self localHostName" is in fact different
> compared to whatever it was on your previous systems.

We can be sure it used to work since the Scratch hosting for the mesh network relies upon it (since about 1935) and a large number of thousands of people have been (and still need to be) using it in classrooms around the world. That’s why I’m more than a bit puzzled and concerned. As the article John pointed to implies it’s entirely likely that it’s nothing at all to do with ‘us’ but unfortunately we get to have to solve it. Seems typical that it might be a fudge caused by gnome.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: HBT: Harvest Binary Tree


Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

Bert Freudenberg
 
On 21.09.2015, at 06:59, tim Rowledge <[hidden email]> wrote:

>
> On 20-09-2015, at 6:07 PM, David T. Lewis <[hidden email]> wrote:
>>
>> Um ... are you sure that this "worked" previously? I just tried a Squeak
>> 3.8 image, and it says that NetNameResolver localHostAddress is 127.0.1.1,
>> which is exactly what Squeak 5.0 says on this same computer.
>>
>> I suspect that you are just running Squeak on a different platform, and
>> "NetNameResolver addressForName: self localHostName" is in fact different
>> compared to whatever it was on your previous systems.
>
> We can be sure it used to work since the Scratch hosting for the mesh network relies upon it (since about 1935) and a large number of thousands of people have been (and still need to be) using it in classrooms around the world. That’s why I’m more than a bit puzzled and concerned. As the article John pointed to implies it’s entirely likely that it’s nothing at all to do with ‘us’ but unfortunately we get to have to solve it. Seems typical that it might be a fudge caused by gnome.
I’m pretty sure it never worked reliably, not on the gazillions of Linux machines anyway. I remember discussions about this from at least 10 years ago (when OLPC got started).

It’s well-known that gethostbyname(gethostname()) won’t reliably work (e.g. http://tinyurl.com/d6e7gjl).

There’s two more reliable solutions. Either enumerate all network interfaces and guess the correct one. Or open a connection to somewhere on the internet and look at the local socket’s address (which the OS assigned to the right interface using its routing tables). The latter one is supposed to work pretty much across platforms. Here’s how it works in Python:

python -c "import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); s.connect(('8.8.8.8', 80)); print(s.getsockname()[0]); s.close()"

I tried that on a Linux and OS X, works on both. We should be able to do that in Squeak using a UDP socket, no?

- Bert -




smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

timrowledge


On 21-09-2015, at 5:27 AM, Bert Freudenberg <[hidden email]> wrote:
>
> It’s well-known that gethostbyname(gethostname()) won’t reliably work (e.g. http://tinyurl.com/d6e7gjl).

Sigh. It never ceases to amaze me just how clever we can collectively be at making life annoying for ourselves. Anyone would think that the entire point of modern operating systems was to make life difficult.

> python -c "import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); s.connect(('8.8.8.8', 80)); print(s.getsockname()[0]); s.close()"
>
> I tried that on a Linux and OS X, works on both. We should be able to do that in Squeak using a UDP socket, no?

I guess that might have to be done for a next release. This release will just have to be fixed in pubs.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- HARLEZ-VOUS FRANCAIS? - Can you drive a French motorcycle?


Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

timrowledge


On 21-09-2015, at 10:17 AM, tim Rowledge <[hidden email]> wrote:
> On 21-09-2015, at 5:27 AM, Bert Freudenberg <[hidden email]> wrote:
>> python -c "import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); s.connect(('8.8.8.8', 80)); print(s.getsockname()[0]); s.close()"
>>
>> I tried that on a Linux and OS X, works on both. We should be able to do that in Squeak using a UDP socket, no?

Doesn’t seem to want to work in my pi image; the simple version (bearing in mind an almost total lack of knowledge about sockets)

| foo bar|
foo := Socket newUDP.
foo connectTo: #[8 8 8 8] port: 80.
bar := foo localAddress.
foo close.
bar

fails to do the connect since
a) UDP sockets are created with the status set to connected
b) the #connectNoBlockingTo:port: method carefully checks for the status and fails when it is not ‘Unconnected’.

Trying a #setPeer:port: instead - which calls the primSocket:connectTo:port: directly and skips the status test - doesn’t leave me with anything interesting from #localAddress.

I even tried a quick ‘sendUDPData:’hello’ toHost: #[8 8 8 8] port: 80’ (which appeared to work) and still localAddress is 0.0.0.0 ‘self peerName’ is google-public-dns-a.google.com so it looks like I made some sort of connection.

Substituting a newTCP for the newUDP actually returned a useful IP number after a long delay and a notifier that it couldn’t connect. So as a desperate last attempt I tried
| foo bar|
foo := Socket newTCP.
foo setPeer: #[8 8 8 8] port: 80.
bar := foo localAddress.
foo close.
bar
- which worked essentially instantly. I even tried it on another Pi to make sure nothing was being locally cached.

I guess I can live with that if it’s the best we can do but
- does it point to a problem with our TCP sockets?
- it can’t work (presumably) if the machine is not on an externally connected network, which is quite plausible in many schools in many countries
- [8 8 8 8] is the sort of magic number nonsense I hate to see.

Can’t we do better?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Couldn't find his way through a maze even if the rats helped him.


Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

johnmci
 
The problem with connecting to 8.8.8.8 which is Google's public DNS server is that:
(a) you might not have access to the internet
(b) you might be going thru a proxy and it may not be on the school white-list
(c) tapping port 80 on the dns server likely won't work either. 


On Mon, Sep 21, 2015 at 11:17 AM, tim Rowledge <[hidden email]> wrote:


On 21-09-2015, at 10:17 AM, tim Rowledge <[hidden email]> wrote:
> On 21-09-2015, at 5:27 AM, Bert Freudenberg <[hidden email]> wrote:
>> python -c "import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); s.connect(('8.8.8.8', 80)); print(s.getsockname()[0]); s.close()"
>>
>> I tried that on a Linux and OS X, works on both. We should be able to do that in Squeak using a UDP socket, no?

Doesn’t seem to want to work in my pi image; the simple version (bearing in mind an almost total lack of knowledge about sockets)

| foo bar|
foo := Socket newUDP.
foo connectTo: #[8 8 8 8] port: 80.
bar := foo localAddress.
foo close.
bar

fails to do the connect since
a) UDP sockets are created with the status set to connected
b) the #connectNoBlockingTo:port: method carefully checks for the status and fails when it is not ‘Unconnected’.

Trying a #setPeer:port: instead - which calls the primSocket:connectTo:port: directly and skips the status test - doesn’t leave me with anything interesting from #localAddress.

I even tried a quick ‘sendUDPData:’hello’ toHost: #[8 8 8 8] port: 80’ (which appeared to work) and still localAddress is 0.0.0.0 ‘self peerName’ is google-public-dns-a.google.com so it looks like I made some sort of connection.

Substituting a newTCP for the newUDP actually returned a useful IP number after a long delay and a notifier that it couldn’t connect. So as a desperate last attempt I tried
| foo bar|
foo := Socket newTCP.
foo setPeer: #[8 8 8 8] port: 80.
bar := foo localAddress.
foo close.
bar
- which worked essentially instantly. I even tried it on another Pi to make sure nothing was being locally cached.

I guess I can live with that if it’s the best we can do but
- does it point to a problem with our TCP sockets?
- it can’t work (presumably) if the machine is not on an externally connected network, which is quite plausible in many schools in many countries
- [8 8 8 8] is the sort of magic number nonsense I hate to see.

Can’t we do better?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Couldn't find his way through a maze even if the rats helped him.





--
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================
Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

timrowledge


On 21-09-2015, at 1:41 PM, John McIntosh <[hidden email]> wrote:

> The problem with connecting to 8.8.8.8 which is Google's public DNS server is that:
> (a) you might not have access to the internet
> (b) you might be going thru a proxy and it may not be on the school white-list
> (c) tapping port 80 on the dns server likely won't work either.
‘zackly.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Has an inferiority complex, but not a very good one.


Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

John Dougan
 
This problem goes way back; in Open Cobalt I ended up going through a bunch of adhoc steps and adding a manual config option to try and figure out if I was behind a firewall and what the address of the firewalled interface was.

Have you considered the temp solution of forking off an ifconfig and parsing out the results? I suspect in many cases, choosing the IP of the default IPv4 or IPv6 interface would get you what you want. 

Cheers,
-- John


On Mon, Sep 21, 2015 at 1:53 PM, tim Rowledge <[hidden email]> wrote:


On 21-09-2015, at 1:41 PM, John McIntosh <[hidden email]> wrote:

> The problem with connecting to 8.8.8.8 which is Google's public DNS server is that:
> (a) you might not have access to the internet
> (b) you might be going thru a proxy and it may not be on the school white-list
> (c) tapping port 80 on the dns server likely won't work either.
‘zackly.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Has an inferiority complex, but not a very good one.





--
John Dougan
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

Bert Freudenberg
In reply to this post by johnmci
 
'xcept by connecting a UDP socket no actual data is sent yet, so the port doesn’t matter. In the python example you can use 0 for the port and it still works (have not tried C but I suspect it’s pretty much the same). The beauty of this approach is that we get the OS to consult its routing tables and pick the right interface and give us its address.

I suspect that our logic is tuned to TCP sockets and wont properly handle UDP (SOCK_DGRAM) ones for this use case.

Proxies shouldn't matter since Tim is trying to use this for LAN broadcast (which he called “mesh”). And me thinks it should work even if there is no actual internet connection, since default IP behavior is “if I can’t decide myself, just forward the package and hope someone else handles it” for which the machine should chose an external interface.

- Bert -

On 21.09.2015, at 22:41, John McIntosh <[hidden email]> wrote:

The problem with connecting to 8.8.8.8 which is Google's public DNS server is that:
(a) you might not have access to the internet
(b) you might be going thru a proxy and it may not be on the school white-list
(c) tapping port 80 on the dns server likely won't work either. 


On Mon, Sep 21, 2015 at 11:17 AM, tim Rowledge <[hidden email]> wrote:


On 21-09-2015, at 10:17 AM, tim Rowledge <[hidden email]> wrote:
> On 21-09-2015, at 5:27 AM, Bert Freudenberg <[hidden email]> wrote:
>> python -c "import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); s.connect(('8.8.8.8', 80)); print(s.getsockname()[0]); s.close()"
>>
>> I tried that on a Linux and OS X, works on both. We should be able to do that in Squeak using a UDP socket, no?

Doesn’t seem to want to work in my pi image; the simple version (bearing in mind an almost total lack of knowledge about sockets)

| foo bar|
foo := Socket newUDP.
foo connectTo: #[8 8 8 8] port: 80.
bar := foo localAddress.
foo close.
bar

fails to do the connect since
a) UDP sockets are created with the status set to connected
b) the #connectNoBlockingTo:port: method carefully checks for the status and fails when it is not ‘Unconnected’.

Trying a #setPeer:port: instead - which calls the primSocket:connectTo:port: directly and skips the status test - doesn’t leave me with anything interesting from #localAddress.

I even tried a quick ‘sendUDPData:’hello’ toHost: #[8 8 8 8] port: 80’ (which appeared to work) and still localAddress is 0.0.0.0 ‘self peerName’ is google-public-dns-a.google.com so it looks like I made some sort of connection.

Substituting a newTCP for the newUDP actually returned a useful IP number after a long delay and a notifier that it couldn’t connect. So as a desperate last attempt I tried
| foo bar|
foo := Socket newTCP.
foo setPeer: #[8 8 8 8] port: 80.
bar := foo localAddress.
foo close.
bar
- which worked essentially instantly. I even tried it on another Pi to make sure nothing was being locally cached.

I guess I can live with that if it’s the best we can do but
- does it point to a problem with our TCP sockets?
- it can’t work (presumably) if the machine is not on an externally connected network, which is quite plausible in many schools in many countries
- [8 8 8 8] is the sort of magic number nonsense I hate to see.

Can’t we do better?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Couldn't find his way through a maze even if the rats helped him.





--
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================




smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

David T. Lewis
 
On Tue, Sep 22, 2015 at 10:29:33AM +0200, Bert Freudenberg wrote:
>  
> 'xcept by connecting a UDP socket no actual data is sent yet, so the port doesn???t matter. In the python example you can use 0 for the port and it still works (have not tried C but I suspect it???s pretty much the same). The beauty of this approach is that we get the OS to consult its routing tables and pick the right interface and give us its address.
>
> I suspect that our logic is tuned to TCP sockets and wont properly handle UDP (SOCK_DGRAM) ones for this use case.

In Squeak, the localAddress of a connected UDP socket does not seem to be able to find its local address:

  addr := NetNameResolver addressForName: 'ntp.ubuntu.com'.
  s := Socket newUDP. "==> a Socket[connected]"
  s sendData: '!' toHost: serverAddr port: 13.
  local := s localAddress.
  s close.
  local ==> #[0 0 0 0]

But a connected TCP socket does know its local address:

  addr := NetNameResolver addressForName: 'squeak.org'.
  s := Socket newTCP connectTo: addr port: 80. " a Socket[connected]"
  local := s localAddress.
  s close.
  local ==> #[172 16 0 10]

So for a TCP connection, we can establish an outbound TCP session and ask
the socket for the local IP address that was used to establish that session.

For a UDP datagram, I would have guessed that the local IP address would be
known after data was first sent. On the other hand, these are datagrams, and
there is no inherent reason that they would need to be sent through any one
interface (although in practice that would surely be the case).

But if it works in Python, then it should work in Squeak.

Dave

>
> Proxies shouldn't matter since Tim is trying to use this for LAN broadcast (which he called ???mesh???). And me thinks it should work even if there is no actual internet connection, since default IP behavior is ???if I can???t decide myself, just forward the package and hope someone else handles it??? for which the machine should chose an external interface.
>
> - Bert -
>
> > On 21.09.2015, at 22:41, John McIntosh <[hidden email]> wrote:
> >
> > The problem with connecting to 8.8.8.8 which is Google's public DNS server is that:
> > (a) you might not have access to the internet
> > (b) you might be going thru a proxy and it may not be on the school white-list
> > (c) tapping port 80 on the dns server likely won't work either.
> >
> >
> > On Mon, Sep 21, 2015 at 11:17 AM, tim Rowledge <[hidden email] <mailto:[hidden email]>> wrote:
> >
> >
> > On 21-09-2015, at 10:17 AM, tim Rowledge <[hidden email] <mailto:[hidden email]>> wrote:
> > > On 21-09-2015, at 5:27 AM, Bert Freudenberg <[hidden email] <mailto:[hidden email]>> wrote:
> > >> python -c "import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); s.connect(('8.8.8.8', 80)); print(s.getsockname()[0]); s.close()"
> > >>
> > >> I tried that on a Linux and OS X, works on both. We should be able to do that in Squeak using a UDP socket, no?
> >
> > Doesn???t seem to want to work in my pi image; the simple version (bearing in mind an almost total lack of knowledge about sockets)
> >
> > | foo bar|
> > foo := Socket newUDP.
> > foo connectTo: #[8 8 8 8] port: 80.
> > bar := foo localAddress.
> > foo close.
> > bar
> >
> > fails to do the connect since
> > a) UDP sockets are created with the status set to connected
> > b) the #connectNoBlockingTo:port: method carefully checks for the status and fails when it is not ???Unconnected???.
> >
> > Trying a #setPeer:port: instead - which calls the primSocket:connectTo:port: directly and skips the status test - doesn???t leave me with anything interesting from #localAddress.
> >
> > I even tried a quick ???sendUDPData:???hello??? toHost: #[8 8 8 8] port: 80??? (which appeared to work) and still localAddress is 0.0.0.0 ???self peerName??? is google-public-dns-a.google.com <http://google-public-dns-a.google.com/> so it looks like I made some sort of connection.
> >
> > Substituting a newTCP for the newUDP actually returned a useful IP number after a long delay and a notifier that it couldn???t connect. So as a desperate last attempt I tried
> > | foo bar|
> > foo := Socket newTCP.
> > foo setPeer: #[8 8 8 8] port: 80.
> > bar := foo localAddress.
> > foo close.
> > bar
> > - which worked essentially instantly. I even tried it on another Pi to make sure nothing was being locally cached.
> >
> > I guess I can live with that if it???s the best we can do but
> > - does it point to a problem with our TCP sockets?
> > - it can???t work (presumably) if the machine is not on an externally connected network, which is quite plausible in many schools in many countries
> > - [8 8 8 8] is the sort of magic number nonsense I hate to see.
> >
> > Can???t we do better?
> >
> > tim
> > --
> > tim Rowledge; [hidden email] <mailto:[hidden email]>; http://www.rowledge.org/tim <http://www.rowledge.org/tim>
> > Useful random insult:- Couldn't find his way through a maze even if the rats helped him.
> >
> >
> >
> >
> >
> > --
> > ===========================================================================
> > John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk <https://www.linkedin.com/in/smalltalk>
> > ===========================================================================
>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: unix nameToAddr() function appears to not work on Raspbian?

marcel.taeumel
On my Windows machine, "NetNameResolver localHostAddress" does not even work because I have multiple (virtual) network adapters. Coming from VMWare in my case. NetNameResolver returns that "virtual IP".

Best,
Marcel
12