NetNameResolver localHostAddress returns 0.0.0.0 in FreeBSD

Mantis 7624. Originally reported as an error pulling out a badge.
Investigation reveals that the primitive is failing to return the
local IP address.

<primitive: 'primitiveResolverLocalAddress' module: 'SocketPlugin'> in
class NetNameResolver.

Works correctly in Win7 and Mac OS X.

FreeBSD has a reputation of dealing with network configuration
differently than Linux.

--
Gary Dunn
Honolulu

On Tue, 17 May 2011, Gary Dunn wrote:

The primitive can't work correctly, because it only returns one local
address, but a host can have any number of such addresses. If you bring up
a new network interface, then the primitive will return the address of
the new interface (on windows), so using this primitive from different
parts of the same program can result in unexpected behavior.


Levente

>
> --
> Gary Dunn
> Honolulu
>
>

I understand what you are saying, but my point is that it works for me on Win7 and OS X. Those machines have wired interfaces and WiFi, only the WiFi is active. Win7 and FreeBSD are on the same box. It works for Win7, not FreeBSD.

I was wondering what happens when the routine finds two active interfaces, but for anything other than a router that would be unlikely, if not dangerous.

Gary Dunn
Open Slate Project
http://openslate.org

On May 17, 2011 9:13 AM, "Levente Uzonyi" <[hidden email]> wrote:

On Tue, 17 May 2011, Gary Dunn wrote:

> Mantis 7624. Originally reported as an error pulling out a ...

The primitive can't work correctly, because it only returns one local address, but a host can have any number of such addresses. If you bring up a new network interface, then the primitive will return the address of the new interface (on windows), so using this primitive from different parts of the same program can result in unexpected behavior.


Levente

--
Gary Dunn
Honolulu

> I was wondering what happens when the routine finds two active interfaces,
> but for anything other than a router that would be unlikely, if not
> dangerous.

I disagree.  I have several boxes that are on two separate networks,
thus two active interfaces and they are not routers.

Elliot

On Wed, May 18, 2011 at 10:13 AM, Elliot Finley <[hidden email]> wrote:
>> I was wondering what happens when the routine finds two active interfaces,
>> but for anything other than a router that would be unlikely, if not
>> dangerous.
>
> I disagree.  I have several boxes that are on two separate networks,
> thus two active interfaces and they are not routers.

Yup. I run virtual machines (VMware, not Smalltalk) for development,
and that also tends to result in a lot of interfaces and IP address.
My desktop machine has 3 active interfaces and 3 addresses. One of my
virtual machines has 2 interfaces, with a total of 5 IP addresses, and
the other has 2 interfaces and 2 addresses.

We should probably just get rid of that primitive entirely.

Colin

Ok guys, I guess you are the exception that proves the rule ... something like that. My perspective is high school students in a classroom-like setting. You give me your IP address, I make a badge for you, and I can drop a morph on your badge to send it to you. You need a way to discover your IP address. Nice to be able to do it in Squeak.

Gary Dunn
Open Slate Project
http://openslate.org

On May 18, 2011 10:02 AM, "Colin Putney" <[hidden email]> wrote:

On Wed, May 18, 2011 at 10:13 AM, Elliot Finley <[hidden email]> wrote:
>> I was wondering ...

Yup. I run virtual machines (VMware, not Smalltalk) for development,
and that also tends to result in a lot of interfaces and IP address.
My desktop machine has 3 active interfaces and 3 addresses. One of my
virtual machines has 2 interfaces, with a total of 5 IP addresses, and
the other has 2 interfaces and 2 addresses.

We should probably just get rid of that primitive entirely.

Colin

On Thu, 19 May 2011, Bert Freudenberg wrote:

> What result do you get using the Etoys image? It uses the new SocketPlugin primitives (including IPv6 support), which if I see correctly have not been incorporated into Trunk yet.

It's not in the Trunk yet. I extracted and converted the code, it's in the
Inbox now, Network-ul.100.mcz. I didn't push it to the Trunk, because
1) Cog doesn't support the new primitives and the fallback code has to be
tested thoroughly.
2) I don't really like SocketAddress, because IIRC it's like
CompiledMethod, in the sense that it's a ByteArray, but it's storing
pointers/words.
3) SocketAddress lacks setter methods, so implementing
compatibility methods, like ByteArray >> #asSocketAddress is a PITA.


Levente

On 19.05.2011, at 00:31, Levente Uzonyi wrote:

> On Thu, 19 May 2011, Bert Freudenberg wrote:
>
>> What result do you get using the Etoys image? It uses the new SocketPlugin primitives (including IPv6 support), which if I see correctly have not been incorporated into Trunk yet.
>
> It's not in the Trunk yet. I extracted and converted the code, it's in the Inbox now, Network-ul.100.mcz. I didn't push it to the Trunk, because
> 1) Cog doesn't support the new primitives and the fallback code has to be tested thoroughly.

True. But maybe the new SocketPlugin would just work with Cog if somebody tried?

> 2) I don't really like SocketAddress, because IIRC it's like CompiledMethod, in the sense that it's a ByteArray, but it's storing
> pointers/words.

No, it does not store pointers. It's just a platform-dependent chunk of memory. See "man getnameinfo". POSIX requires to use that function to get fields out of the "sockaddr" struct.

> 3) SocketAddress lacks setter methods, so implementing compatibility methods, like ByteArray >> #asSocketAddress is a PITA.

It's platform-dependent. You need to call the primitives to create proper SocketAddresses. That is encapsulated in the class SocketAddressInformation. See e.g. forHost:service:flags:addressFamily:socketType:protocol:.

Btw, there is a method ByteArray>>#asSocketAddress. There are only two senders, it is only used when useOldNetwork is true. Not sure why this needs to be there. We could ask Michael what the idea was. I guess we could get rid of it.

- Bert -

On Wed, May 18, 2011 at 3:02 PM, Bert Freudenberg <[hidden email]> wrote:
> What result do you get using the Etoys image? It uses the new SocketPlugin
> primitives (including IPv6 support), which if I see correctly have not been
> incorporated into Trunk yet.

Not sure how to use Etoys image. I downloaded Etoys To Go 4.1.1 from
Squeakland. Right off the bat it would not run because FreeBSD puts
bash in /usr/local/bin. I edited etoys.sh to fix that and it errors.
The unzipped folder is still in my Downloads folder:

$ ./etoys.sh
./etoys.sh: line 68: cd: /usr/home/gary/Desktop/Downloads/Etoys-To-Go
4.1.1.app/Contents/FreeBSD-i386: No such file or directory
./etoys.sh: line 69: cd: /usr/home/gary/Desktop/Downloads/Etoys-To-Go
4.1.1.app/Contents/FreeBSD-i386: No such file or directory
cp: Contents is a directory (not copied).
exec: /tmp/-d.GhRtmJ3g
etoys-to-go-Ht2FZ/etoys: not found
rm: Contents: No such file or directory

So I guess this is Linux specific. Is there an image I can run with
the usual vm?

--
Gary Dunn
Honolulu

On Thu, May 19, 2011 at 10:57:29PM -0700, Gary Dunn wrote:
> On Wed, May 18, 2011 at 3:02 PM, Bert Freudenberg <[hidden email]> wrote:
> > What result do you get using the Etoys image? It uses the new SocketPlugin
> > primitives (including IPv6 support), which if I see correctly have not been
> > incorporated into Trunk yet.
>
> Not sure how to use Etoys image. I downloaded Etoys To Go 4.1.1 from
> Squeakland. Right off the bat it would not run because FreeBSD puts
> bash in /usr/local/bin. I edited etoys.sh to fix that and it errors.
> The unzipped folder is still in my Downloads folder:

There should be etoys.image and etoys.changes files somewhere in that
directory (perhaps Etoys-Dev-4.1.app/Contents/Resources/etoys.image
and Etoys-Dev-4.1.app/Contents/Resources/etoys.changes). You should
be able to copy those files to wherever you normally keep your images,
and use them directly like any other image.

Instructions for getting a "development" version of the Etoys image
are here:

 http://wiki.immuexa.com/display/sq/Starting+with+Etoys+Development+-+A+Five+Lines+Summary

 http://wiki.immuexa.com/display/sq/Starting+with+Etoys+Development

Dave

On 20.05.2011, at 07:57, Gary Dunn wrote:

Ah, FreeBSD. Etoys-To-Go does not include a BSD VM. Do you know if it can run Linux binaries? If so, then you could edit etoys.sh to make it work. Replace:

        BIN="$APP/Contents/$OS-$CPU"
with
        BIN="$APP/Contents/Linux-i686"

then run etoys.sh.

Or, as David wrote, just running "squeak etoys.image" should work, which would use your regular VM.

- Bert -

On Thu, 19 May 2011, Bert Freudenberg wrote:

I think it would work, though I didn't try it.

>
>> 2) I don't really like SocketAddress, because IIRC it's like CompiledMethod, in the sense that it's a ByteArray, but it's storing
>> pointers/words.
>
> No, it does not store pointers. It's just a platform-dependent chunk of memory. See "man getnameinfo". POSIX requires to use that function to get fields out of the "sockaddr" struct.

Okay, I got it, but what will happen if I save an image with SocketAddress
instances on Linux and open it on Windows? Will it crash if I try to use
those SocketAddresses?

>
>> 3) SocketAddress lacks setter methods, so implementing compatibility methods, like ByteArray >> #asSocketAddress is a PITA.
>
> It's platform-dependent. You need to call the primitives to create proper SocketAddresses. That is encapsulated in the class SocketAddressInformation. See e.g. forHost:service:flags:addressFamily:socketType:protocol:.
>
> Btw, there is a method ByteArray>>#asSocketAddress. There are only two senders, it is only used when useOldNetwork is true. Not sure why this needs to be there. We could ask Michael what the idea was. I guess we could get rid of it.

Existing code (e.g.: all senders of Socket >> #connectTo:port:) uses
ByteArrays where the new socket code expects SocketAddresses, so these
conversion methods are mandatory.


Levente

>
> - Bert -
>
>
>
>

On 21.05.2011, at 01:52, Levente Uzonyi wrote:

I don't know. SocketAddress instances are supposed to be temporary, IIUC, application code would not store them.

>>> 3) SocketAddress lacks setter methods, so implementing compatibility methods, like ByteArray >> #asSocketAddress is a PITA.
>>
>> It's platform-dependent. You need to call the primitives to create proper SocketAddresses. That is encapsulated in the class SocketAddressInformation. See e.g. forHost:service:flags:addressFamily:socketType:protocol:.
>>
>> Btw, there is a method ByteArray>>#asSocketAddress. There are only two senders, it is only used when useOldNetwork is true. Not sure why this needs to be there. We could ask Michael what the idea was. I guess we could get rid of it.
>
> Existing code (e.g.: all senders of Socket >> #connectTo:port:) uses ByteArrays where the new socket code expects SocketAddresses, so these conversion methods are mandatory.

#connectTo:port: has been changed to use either the old or the new socket code.

Anyhow: are you suggesting the extended SocketPlugin is completely useless, or that we should not use Michael's new in-image code?

IMHO the new primitives are a good foundation for the networking code to move forward. If we don't like how it's been integrated in the image, I would rather change (or even completely rewrite) that image code, encapsulating the new primitives as needed. But the plugin itself seems solid to me.

- Bert -

On Mon, 23 May 2011, Bert Freudenberg wrote:

>
> On 21.05.2011, at 01:52, Levente Uzonyi wrote:

snip

>>
>> Okay, I got it, but what will happen if I save an image with SocketAddress instances on Linux and open it on Windows? Will it crash if I try to use those SocketAddresses?
>
> I don't know. SocketAddress instances are supposed to be temporary, IIUC, application code would not store them.

Ok, I'll take a closer look at this.

That's right, but if my package has the following code:

Socket new connectTo: #[127 0 0 1] port: 12345

and I the image uses the new socket code, then I'll get an error, because
the ByteArray is not a SocketAddress.

>
> Anyhow: are you suggesting the extended SocketPlugin is completely useless, or that we should not use Michael's new in-image code?

No, nothing like that. We should only make sure that it's compatible with
the current socket API.


Levente

>
> IMHO the new primitives are a good foundation for the networking code to move forward. If we don't like how it's been integrated in the image, I would rather change (or even completely rewrite) that image code, encapsulating the new primitives as needed. But the plugin itself seems solid to me.
>
> - Bert -
>
>
>