[Vm-dev] unix nameToAddr() function appears to not work on Raspbian?

David T. Lewis lewis at mail.msen.com
Wed Sep 23 02:22:23 UTC 2015


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 <johnmci at smalltalkconsulting.com> 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 <tim at rowledge.org <mailto:tim at rowledge.org>> wrote:
> > 
> > 
> > On 21-09-2015, at 10:17 AM, tim Rowledge <tim at rowledge.org <mailto:tim at rowledge.org>> wrote:
> > > On 21-09-2015, at 5:27 AM, Bert Freudenberg <bert at freudenbergs.de <mailto:bert at freudenbergs.de>> 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; tim at rowledge.org <mailto:tim at rowledge.org>; 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>
> > ===========================================================================
> 
> 
> 
> 





More information about the Vm-dev mailing list