Now the macbook pro in this case uses 192.168.1.141 as the assigned tcp/ip
address from our internal DHCP server.
All three interfaces show as active, and if you consider the 'ifconfig -a'
below you would be hard pressed to determine which interface is the one
facing the
[otter-2:~] johnmci% ifconfig
-a
lo0:
flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid
0x1
inet 127.0.0.1 netmask 0xff000000
gif0:
flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0:
flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:17:f2:d9:57:35
media: autoselect status: inactive
supported media: autoselect 10baseT/UTP
<half-duplex> 10baseT/UTP <full-duplex> 10baseT/UTP
<full-duplex,hw-loopback> 10baseT/UTP <full-duplex,flow-control>
100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX
<full-duplex,hw-loopback> 100baseTX <full-duplex,flow-control>
1000baseT <full-duplex> 1000baseT <full-duplex,hw-loopback>
1000baseT <full-duplex,flow-control> none
fw0:
flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 2030
lladdr 00:19:e3:ff:fe:93:92:7c
media: autoselect <full-duplex> status:
inactive
supported media: autoselect
<full-duplex>
en1:
flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::21b:63ff:fe02:d2db%en1 prefixlen 64
scopeid 0x6
inet 192.168.1.141 netmask 0xffffff00 broadcast
192.168.1.255
ether 00:1b:63:02:d2:db
media: autoselect status: active
supported media: autoselect
en4:
flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu
1500
inet6 fe80::21c:42ff:fe00:8%en4 prefixlen 64 scopeid
0x7
inet 10.211.55.2 netmask 0xffffff00 broadcast
10.211.55.255
ether 00:1c:42:00:00:08
media: autoselect status: active
supported media: autoselect
en5:
flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu
1500
inet6 fe80::21c:42ff:fe00:9%en5 prefixlen 64 scopeid
0x8
inet 10.37.129.2 netmask 0xffffff00 broadcast
10.37.129.255
ether 00:1c:42:00:00:09
media: autoselect status: active
supported media: autoselect
Where en0 is
ethernet jack, fw0 is firewire, en1 is wireless, en4 & en5 are
virtual.
Now the bias from
the committee is
scopev4 ::ffff:169.254.0.0/112 2
scopev4 ::ffff:127.0.0.0/104 2
scopev4 ::ffff:10.0.0.0/104 5
scopev4 ::ffff:172.16.0.0/108 5
scopev4 ::ffff:192.168.0.0/112 5
scopev4 ::ffff:0.0.0.0/96 14
This means of course the 10.0.0.0 address sorts before the 192.168.0.0
address. How helpful.
So how do we know *which* is the proper address to use? Well no idea!
However let's see what the API does.
NetNameResolver class>> addressesForName: hostName
| adresses
|
adresses :=
SocketAddressInformation
forHost:
hostName
service:
''
flags: 0
addressFamily:
0
socketType:
SocketAddressInformation socketTypeStream
protocol:
SocketAddressInformation protocolTCP.
^adresses
Now I can
make it return just IPV4 address by doing:
NetNameResolver class>> addressesForName: hostName
| adresses
|
adresses :=
SocketAddressInformation
forHost:
hostName
service:
''
flags: 0
addressFamily:
SocketAddressInformation addressFamilyINET4
socketType:
SocketAddressInformation socketTypeStream
protocol:
SocketAddressInformation protocolTCP.
^adresses
which then NetNameResolver localHostAddress gives:
10.37.129.2(10.37.129.2),0(0)
I can also supply a service number string say SSH
'22'
that give back
10.37.129.2(10.37.129.2),22(ssh)
since ssh is binding on all interfaces that's valid.
Technically the getnameinfo gives back three address but again the code below
grabs the first one which according to the rfc3484 is more likely to be the
correct answer.
addressForName: hostName
"NetNameResolver
addressForName: 'impara.de' "
"NetNameResolver
addressForName: 'localhost' "
"NetNameResolver
addressForName: '127.0.0.1' "
| addresses
|
self
useOldNetwork
ifTrue: [^self
oldAddressForName: hostName].
addresses :=
self addressesForName: hostName.
^addresses
ifEmpty:
[nil]
ifNotEmpty:
[addresses first socketAddress]
But grabbing the first one doesn't meet people's expectations of
correctness, however we just don't have enough information to decide *what* is
correct.
Now some people say OH let's return the en0 one because that is correct?
Really how do you know?
On my computer en0 is ethernet, but since I'm using wireless then en1 is
the correct one.
Obviously I could look in the list of IPV6 address find the LOWEST en#
value, then grab the IPV4 entry. This would assume I check for the fact
that the IPV6
interface has an IPV4 address and the sort order for the IPV6 is the same
as for the IPV4.
Gee that sounds ok?
Well it's not, when for example I tether my MacBook Pro to my iPhone and
abuse my privilege to move data over the cellular carrier, ah sorry you USA ATT
folks,
then the interface is:
en6: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu
1500
inet6
fe80::226:8ff:fe72:5aa%en6 prefixlen 64 scopeid 0x9
inet
192.168.20.2 netmask 0xffffff00 broadcast 192.168.20.255
ether
00:26:08:72:05:aa
media:
10baseT/UTP status: active
supported media:
10baseT/UTP
which fails the test that the lowest active en# is the one we want to
use.
10.37.129.2(10.37.129.2),0(0)-inet4-stream-tcp
10.211.55.2(10.211.55.2),0(0)-inet4-stream-tcp
192.168.20.2(192.168.20.2),0(0)-inet4-stream-tcp)
So the question is what would the community like to see happen. Well other
than hide under a rock and see if the problem goes away...
On 2010-03-12, at 8:41 AM, Chris Cunnington wrote:
How is NetNameResolver choosing the interface to
return an IP address from?
In Cobalt this is a problem. You need the right address to connect to
other spaces. Cobalt won't let you enter it by hand, so you are at the mercy
of its guessing the correct interface.
NetNameResolver localAddressString
executed in Workspace produces the IP from my fw0 interface, which is
useless. I need it to look at ppp0.
Can it be told which interface to look at?
How does it choose?
Chris
--
===========================================================================
===========================================================================