On Monday 02 March 2015 08:22:38 Lankswert, Patrick wrote: > > What are the bits supposed to mean? Detecting the WAN interface may not > > be so simple. It might be possible to do this on the majority of cases by > > scanning the routing table, but it will fail on edge cases (e.g., my > > laptop when > > connected to both Intel office's wired and wireless). But that same > > algorithm > > would conclude that my regular wireless on my laptop is WAN. > > > > That said, I do agree we should provide a heuristic approach to trying to > > detect which interface is connected to the outside world, if we can. We > > just > > need to document the assumptions so people know when it may fail.
I've thought about this more and I think we should simply provide a flag saying "a default route points here". That way, the user needs to scan which interface has the flag set. For everything except routers and devices with IPv6 link-local only, the only IP interface will also have the flag set, so people will be suitably aware of making decisions based on the flag. > > > > Why does the user care if the interface is wired or not? How about the > > bridge > > interface that is both wired and wireless? > > I am making stuff up, but you may want to poll (multicast) wired more often > than wireless. Hmm... while that makes some sense, I have to ask: if you can get away with an interval N over wireless, why should you poll more frequently on wired? Also remember that your multicast wired packets may be bridged over the wireless by a router. I am a great fan of minimal API. Until we find a good use-case for providing the flag, we shouldn't provide it at all. > > What is secure? > > I am making stuff up for the purpose of example, but if the interface was > Bluetooth and had a link key, the communication channel is already secure. Then let's provide that information. > > > int getIFaceCount(); // Returns the max index struct iface* > > > getIFace(int index); // Returns NULL or iface record > > > > Good idea. But remember that interface indexes don't have to be contiguous > > (my router has 1-9 and 12-16). > > When it comes to IP, only interfaces with an IP address are serviceable, > interesting and I am going to bet that you have quite a bit few IP > addresses. > > > Unless you meant our own interface numbers, separate from the interface > > index from the OS, which would be used on sin6_scope_id in the IPv6 > > sockets. > > Yes, these interfaces are really effectively map to internal file handles. I'd much rather use the if_index / sin6_scope_id interface ID, since it's a global number. The user won't be confused by a different index. An alternative is to not provide indexes and instead just operate on pointers. PS: your suggestion implies a non-thread-safe global state, which may not be suitable for libraries that want to operate when new interfaces are detected and connected. > > > Does that make sense? I think that this approach handles some of the > > > issues that Thiago raised including multiple radios of the same type > > > (ie. eth0, eth1, wan0, wan1, etc.) > > > > FYI, here's what my router reports: > > > > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state > > UNKNOWN mode DEFAULT group default > > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel > > state UP mode DEFAULT group default qlen 1000 > > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel > > state UP mode DEFAULT group default qlen 1000 > > 4: sit0: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group > > default > > 5: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode > > DEFAULT group default qlen 32 > > 6: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode > > DEFAULT group default qlen 32 > > 7: gre0: <NOARP> mtu 1476 qdisc noop state DOWN mode DEFAULT group > > default > > 8: gretap0: <BROADCAST,MULTICAST> mtu 1476 qdisc noop state DOWN > > mode DEFAULT group default qlen 1000 > > 9: teql0: <NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group > > default qlen 100 > > 12: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > > noqueue state UP mode DEFAULT group default > > 13: eth0.1 at eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > > noqueue master br-lan state UP mode DEFAULT group default > > 14: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq > > master br-lan state UP mode DEFAULT group default qlen 1000 > > 15: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq > > master br-lan state UP mode DEFAULT group default qlen 1000 > > 16: wlan0-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq > > state UP mode DEFAULT group default qlen 1000 > > And, only 8 are up and I bet that only 3-4 have bound IP addresses. Correct, only lo, eth1, br-lan and wla0-1 have both IPv4 and IPv6. Additionally, eth0, wlan0 and wlan1 have link-local IPv6 addresses, but those interfaces can't send or receive, as they're bridged together. > All good points. My basic example was to define sending to networks (by > routable address) instead of by network type (Ethernet, WiFi, BT, etc.). I > have hopes to make the common usages very simple with the expressive > capability to define precise control without a huge API. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 173 bytes Desc: This is a digitally signed message part. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150302/bef668ab/attachment.sig>
