The proc code was a stopgap. I'm glad you are fixing that.
I suppose I was thinking more of ipv4 LL addresses than ipv6 ones, where the
address was much more likely to have conflicts. I am certainly fine with
keeping the address scheme as we have it now, but I thought I'd bring this
up since using the MAC to differentiate interfaces has proved very useful
for configuration-free services on machines like laptops, where each NIC
only had one address, but that address changed as the laptop was run in
different locations. And in such instances I have found it useful to write
something that can dynamically detect the ip address changes. In windows,
this is a trivial system notification, on other platforms something as
simple as re-enumerating the NICs every 5 seconds to see if their address
changed inelegantly works -- making that more elegant was always "on my
list".
But perhaps this is overkill for what we are trying to provide with slpd.
And your points about knowing what mac is to use ipv4 vs. ipv6 are well
taken -- I haven't had to support ipv6 yet beyond some very rudimentary
connections, and have not had to think about the ipv4/ipv6 problem in my
other work. If slpd is being configured away from the default to only run
on one NIC, presumably it is being configured by someone who will know about
these issues, and who will find it easier to work with the ip addresses %
optional interface.
--Nick
2010/7/8 Varun Chandramohan <var...@linux.vnet.ibm.com>
> Hi Nick,
>
> On Thursday, July 08, 2010 09:55:16 pm Nick Wagner wrote:
> > I agree with Roel about handling multiple interfaces. There are definite
> > differences in how sockets operate in the different OSs, especially with
> > respect to multicast and multiple NICs.
> >
> Alright! I think we can skip this. Lets leave it the way slpd does
> currently. However for linux part, i do intend to change
> reading ipv6 ips from proc to system apis. I have written that code tested
> it well. Is that ok with all? The older proc code
> had major issues with endianess when tested in power system.
> > I'm very glad to see that people are still actively working on making
> > openSLP better. I haven't been able to get back to it for quite a while
> --
> > I had hoped to test some of these changes on Windows and OS X by now, but
> > work has taken over my time.
> >
> > I had a comment on changing net.slp.interfaces. IP address % interface
> > doesn't fully solve the specification issues when dealing with link-local
> > addresses, as those can change underneath you. The same could
> potentially
> > happen with a DHCP address. What if we changed net.slp.interfaces to
> > something that also allowed you to select the NICs via MAC address (with
> the
> > optional % interface for full differentiation on OSs that supported it)?
> >
> Iam a bit confused here. So, if we change it to MAC how can a user specify
> which ip openslp must use?
> I mean how to even say weather ipv4 or ipv6 should be used. If its ipv6,
> which ip of the list of ips for that interface must be used?
> My understanding is that LL address are system generated from the MAC
> address. Although i agree a link local address can be deleted and
> another LL address can be added, i feel this might not be the right
> approach. I have not though this through, may be we should introduce
> dynamic ip address change monitor? Like "ip monitor addr" does? Will this
> help? Just out of curiosity there must be many other projects that
> need requirement like this. How do they handle? I got your explanation
> wrong, please explain. :-)
> >
> > --Nick
> >
> >
> >
> > On Thu, Jul 8, 2010 at 2:17 AM, Roel van de Kraats <
> r...@advancedcargo.eu>wrote:
> >
> > >
> > >
> > > On 07/08/2010 08:49 AM, Varun Chandramohan wrote:
> > > > Hi All,
> > > >
> > > > I have been looking into openslp code and i found a few changes
> > > that might make things better in openslp. I dont have patches to share,
> but
> > > i will create them if everyone here agrees.
> > > >
> > > Dear Varun,
> > >
> > > Thanks for putting this effort in improving Openslp and for discussing
> > > your ideas on the mailing list.
> > > > - Multiple Binding Issue: I observed that, when the list of
> interfaces is
> > > not specified in the config file, the slpd daemon reads all interface
> > > information and binds to all address of all interfaces. I feel this is
> a
> > > overkill. When no specific interfaces are given, its much easier to
> bind to
> > > :: or INADDR_ANY.
> > > >
> > > That sounds simpler indeed. However, by doing so a lot of
> responsibility
> > > is moved from slpd (which we can adapt to our needs) to the OS (for
> > > which this is much harder). Since handling multiple interfaces the
> > > correct way is quite delicate, I'd rather keep this responsibility on
> > > the slpd side. And although receiving messages may become simpler this
> > > way, for sending messages it is still necessary to specify the
> > > interface; otherwise the 'default' interface (chosen by the OS) is
> used.
> > > Finally, since the functionality for handling different interfaces is
> > > needed anyway (in case they are specified in the cfg), it is, in my
> > > opinion, better to have one mechanism (behavior) for the different
> > > situations.
> > > > Proposal: In SLPDIncomingInit() function all the address are bound.
> > > >
> > > > if (G_SlpdProperty.interfaces != NULL)
> > > >
> SLPIfaceGetInfo(G_SlpdProperty.interfaces,&ifaces,&G_SLPDProcInfo,
> > > AF_UNSPEC);
> > > > else
> > > > ifaces.iface_count = 0;
> > > > When the interfaces are found to be NULL, we can assume that slpd
> must
> > > bind to all inetfaces. So depending on the config file we have 3 cases.
> > > > Case 1: Only IPv4 enabled. We can create TCP/UDP sockets with
> INADDR_ANY.
> > > > Case 2: Only IPv6 enabled. We can create TCP/UDP sockets with ::
> > > > Case 3: Both IPv6& IPv4 enabled. We can create sockets with :: but
> use
> > > IPV6_V6ONLY option set.
> > > >
> > > > This way we will have only 1 or 2 sockets listening instead of all.
> > > Improves performance as well. My only doubt is how this works with
> Windows.
> > > Iam no expert in that.
> > > > If the interfaces are specified then we do exactly what is done now.
> Is
> > > that ok with everyone?
> > > >
> > > > - Wrong Representation Of Interfaces In Config File: Although it
> looked
> > > at first as a minor issue, this has caused multiple problems to basic
> > > functionality. Openslp takes in ipaddress without the need for
> interface
> > > information.
> > > > This leads to major issues. The function v6GetScope() is faulty
> function.
> > > >
> > > > There can be cases when interfaces can have same ips. Eg:
> > > > eth2 Link encap:Ethernet HWaddr 00:06:29:55:60:81
> > > > inet6 addr: fe80::206:29ff:fe55:6081/64 Scope:Link
> > > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > > > RX packets:4037 errors:0 dropped:0 overruns:0 frame:0
> > > > TX packets:134395 errors:0 dropped:0 overruns:0 carrier:0
> > > > collisions:0 txqueuelen:1000
> > > > RX bytes:436006 (425.7 KiB) TX bytes:14655216 (13.9 MiB)
> > > > Interrupt:16 Base address:0x2200
> > > >
> > > > eth2.30 Link encap:Ethernet HWaddr 00:06:29:55:60:81
> > > > inet addr:192.168.1.2 Bcast:192.168.1.255
> Mask:255.255.255.0
> > > > inet6 addr: 3001::1/128 Scope:Global
> > > > inet6 addr: fe80::206:29ff:fe55:6081/64 Scope:Link
> > > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > > > RX packets:367 errors:0 dropped:0 overruns:0 frame:0
> > > > TX packets:15830 errors:0 dropped:0 overruns:0 carrier:0
> > > > collisions:0 txqueuelen:0
> > > > RX bytes:40872 (39.9 KiB) TX bytes:1650541 (1.5 MiB)
> > > >
> > > > The LL address of both interfaces are same, In which case it becomes
> > > clear viewing the v6GetScope() code that the scope id returned will be
> same
> > > for both interface but in reality it is different. This results in
> binding
> > > to
> > > > only one interface. This is wrong. This has to be changed. This also
> is
> > > the case with ips specified in the config file.
> > > >
> > > > net.slp.interfaces = fe80::206:29ff:fe55:6081
> > > >
> > > > There is no way of saying which interface this must bind to.
> > > >
> > > > Proposal: The posix standard must be adopted to fix the issue. The
> > > interface must be specified.
> > > > net.slp.interfaces =
> > > fe80::206:29ff:fe55:6081%eth2.30,2001::1%eth1,10.0.0.1%eth0
> > > >
> > > > The<ip>%<iface> is standard posix method. This will greatly help in
> > > getting the correct scopeid.
> > > >
> > > This is (probably) not described in the SLP RFC and I don't know if it
> > > creates an incompatibility, but when this extension is made optional,
> it
> > > sounds fine to me. I assume interface names never contain a ','
> > > otherwise that would clash with the list separator.
> > >
> > > BR,
> > > Roel
> > > > I have already looked into the code and made a temporary fix for the
> > > above problem. But i want to rewrite that patch to make it better. If
> > > everyone is ok with the above i will start working on it. Please reply
> back
> > > with any
> > > > issues. I have no windows programming knowledge, so if iam making a
> > > blunder here, do let me know.
> > > >
> > > > Regards,
> > > > Varun
> > > >
> > > >
> > >
> ------------------------------------------------------------------------------
> > > > This SF.net email is sponsored by Sprint
> > > > What will you do first with EVO, the first 4G phone?
> > > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > > > _______________________________________________
> > > > Openslp-devel mailing list
> > > > Openslp-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/openslp-devel
> > > >
> > >
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > This SF.net email is sponsored by Sprint
> > > What will you do first with EVO, the first 4G phone?
> > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > > _______________________________________________
> > > Openslp-devel mailing list
> > > Openslp-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/openslp-devel
> > >
> >
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Openslp-devel mailing list
Openslp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openslp-devel
