Sunday, February 7, 2016< ^ >
Thomas Watteyne has set the subject to: IETF93 ROLL WG meeting
Room Configuration
Room Occupants

[09:37:20] mcr2 leaves the room: Disconnected: closed
[09:37:20] Michael Richardson leaves the room: Disconnected: closed
[09:41:31] Michael Richardson joins the room
[09:44:13] mcr2 joins the room
[15:58:26] eintopf joins the room
[15:58:31] <eintopf> Hey Michael
[15:58:47] <eintopf> I've got a mail two days ago
[15:58:59] <eintopf> they cut the presentation time to 30 minutes than 45
[15:59:30] <eintopf> and then I put RPL stuff outside, I would really like to tell about RPL and the opensource userspace software RPL
[16:00:44] <eintopf> I have 20 minutes only
[16:10:26] <eintopf> ok
[16:10:30] <eintopf> I will try to remove one slide
[16:10:38] <eintopf> and add one slide for RPL and unstrung
[16:23:57] <mcr2> hi.
[16:24:56] <mcr2> hey... I read about the loss of your 15minutes... so I think that your focus should be on how to deal with the short/long addresses... maybe just have a slide at the end with a bunch of relevant URLs...
[16:25:02] <mcr2> btw: do you have a kernel git three?
[16:25:35] <mcr2> is rpi-4.5.y ahead of, or behind it... and I wonder about it compared to bluetooth-next...
[16:26:04] <mcr2> 4.5-rc2 fails on RPI; the dwc2 driver is screwed up so no ethernet.
[16:26:17] <mcr2> is your branch ahead of 4.5?
[16:28:06] mcr2 is now known as mcr
[16:28:17] <mcr> (time to take the kid sking)
[16:40:00] <eintopf> wait a second
[16:40:01] <eintopf> I replied to your mail now
[16:40:38] <eintopf> (short/long address) I think this is not a big issue right now
[16:41:09] <eintopf> We just add some for each neighbor a L2 private data
[16:41:19] <eintopf> and then adding runtime decisions
[16:43:26] <eintopf>
[16:43:29] <eintopf> see this old mail
[16:43:34] <eintopf> We can have L2-specific private data per NCE, and 6lowpan uses ARPHRD_IEEE802154.
Please consider using it for L2 private data, if you need L2-speicic extra
information per NCE.
[16:43:58] <eintopf> 6lowpan uses ARPHRD_IEEE802154 - not true anymore it's ARPHRD_6LOWPAN
[16:44:18] <eintopf> but you can then check on the 6LoWPAN link-layer type
[16:44:40] <eintopf> it's just many "check type" -> casting private data
[16:45:18] <eintopf> Michael, I can give you instruction to run the WPANKit
[16:45:41] <eintopf> the WPANKit is one BSP which I made for the openlabs modules and you can directly build bluetooth-next with that
[16:45:45] <eintopf> with some tweaks
[16:45:52] <eintopf> RPi/RPi2 is supported
[16:46:11] <eintopf> RPi2 and bluetooth next ~ in 1 month
[16:46:22] <eintopf> because there are pending patches
[16:49:52] <eintopf> and we don't do "extended addr + short address"
[16:50:05] <eintopf> to get the source short address, you need some casting things
[16:51:04] <eintopf>
[16:51:08] <eintopf> to get this value
[16:52:25] <eintopf> and we do some policy if short address is set (short_address != 0xffff || short_address != 0xfffe) then we use the short address, otherwise we use extended_addr
[16:52:49] <eintopf> some default handling at first
[16:53:09] <eintopf> s/||/&&/
[17:05:17] <eintopf> I added now a Routing-Slide with unstrung and hope I will be still in-time :-)
[17:05:22] <eintopf> otherwise I will talking fast
[17:27:17] <eintopf> after netdev I promise you to work on short address! But there are still other things todo I have one exam for study
[17:27:19] <eintopf> but maybe I will abort that crap
[17:27:26] <eintopf> and do it next semester
[17:27:50] <eintopf> I will go there and hope I will have some successful :-)
[17:28:04] <eintopf> not the best mark, but it's enough
[17:54:57] <eintopf> but when we fix the short address handling -> What we do with rfc6775?
[17:55:59] <eintopf> meh, anyway the ndisc implementation need to deal with two kinds of mac addresses somehow... maybe we add a complete new ndisc implementation for 6lowpan only
[17:56:24] <eintopf> or disable all messages stuff inside kernel and handle it in userspace (if possible) and manipulate the entries from userspace
[18:42:54] <mcr> hey, skiing didn't happen....
[18:44:12] <mcr> looking at URLs...
[18:45:53] <mcr> I'm not convinced that storing the short address as private data makes sense; don't we need to be able to look up the NCE by the short address?  Can we do that efficiently?
[18:46:09] <mcr> (NCE stands for... ? Neighbour Cache Entry?)
[18:46:58] <mcr> so, is WPANKit based upon which kernel?
[18:58:07] <eintopf> NCE is
[18:58:20] <eintopf> unsigned char           ha[ALIGN(MAX_ADDR_LEN, sizeof(unsigned long))]; - stores the lladdr
[18:59:32] <eintopf> and we need some L2 private-data to indicate if ha is a short or extended addr, then adding some runtime decisions about dev->addr_len (or maybe that the addr_len is given by NCE)
[18:59:52] <eintopf> and then adding more runtime decisions to deal with the length field in NS
[19:00:27] <eintopf> for SLLAO
[19:01:10] <eintopf> (WPANKit) it's by default kernel 4.4 which I get working, but you can replace the kernel with a symlink to bluetooth-next repository (doe development)
[19:01:14] <eintopf> s/doe/for/
[19:01:36] <eintopf> if I remember correctly Stefan Schmidt has also current issues with RPi and dwc2
[19:03:56] <eintopf>
[19:04:01] <eintopf> this is what you looking for
[19:04:14] <eintopf> simple add it to your remotes in git and then git cherry-pick
[19:06:50] <eintopf> (or maybe that the addr_len is given by NCE) - this will be a correct handling that the lladdr length is given by neighbor and NOT by interface
[19:07:42] <eintopf> I hope "yoshfuji" is there somewhere at netdev11 and I can hopefully pronounce his name correctly
[19:12:05] <mcr> actually,  I tried that patch :-)
[19:12:12] <mcr> I'll try it again, I guess.
[19:13:01] <eintopf> and sorry, you have these issues because me. I added the power domain driver for RPi some days ago and detected issues in dwc2 while probing
[19:13:13] <eintopf> then people began to hacking without testing it again on RPi
[19:15:26] <eintopf> ( lladdr length is given by neighbor and NOT by interface) - I think when we change it, then we don't need any L2 private data there
[19:15:57] <eintopf> then we have all necessary information to deal with different lladdr length for neighbors
[19:16:03] <eintopf> it's just one think which is stupid
[19:16:40] <eintopf>
[19:17:08] <eintopf> this will be called from neighbor discovery (AND LOT OF OTHER LAYERS) to generate a mac header
[19:17:20] <eintopf> and there is no length information for the lladdr :-)
[19:18:27] <eintopf> we can try to add more parameters daddr_len and saddr_len, don't know if the netdev community likes that but then we should go to the right way
[19:19:07] <eintopf> most people disagree because something doesn't fit again into some cache_lines :-)
[19:19:34] <eintopf> s/think which is stupid/thing which is stupid/
[19:42:47] <mcr> patch worked this time... must have tftp'ed the wrong file last time.
[19:43:17] <mcr> not grok'ing your comment about L2 private data.
[19:44:13] <mcr> the constantness of the lladdr in all the system is why I'm thinking that a 10 or 11 byte lladdr might be the best hack.
[19:44:16] <eintopf> The neighbor discovery handles address length by interface (dev->addr_len)
[19:44:41] <eintopf> but it should be not by interface, the address length should be per neighbor inside the cache
[19:44:51] <eintopf> if we have that, then we don't need any L2 data
[19:45:31] <mcr> I'm thinking that talking about a hack like that at netdev11 might cause some people to realize that a length inside the NCE would be better.
[19:46:05] <eintopf> but there exists some callback for L2 to say "hey, here is daddr and saddr. Generate me an mac address. And this callback needs also addres length information
[19:46:21] <eintopf> but the callback is very generic and not only used by neighbor discovery
[19:46:34] <eintopf> but we just add dev-addr_len for them then by default
[19:46:37] <mcr> so, looking at struct neighbour, it's the struct hh_cache hh, that contains the actual address?  or primary_key?
[19:47:13] <mcr> I'm not very useful, because this code is not well known to me.
[19:47:24] <eintopf> unsigned char           ha[ALIGN(MAX_ADDR_LEN, sizeof(unsigned long))];
[19:47:28] <eintopf> this stores the lladdr
[19:48:08] <eintopf> what actually the others do, I don't know :-)
[19:48:40] <eintopf> it's a cache and of course they have some mechanism for fast accessing
[19:49:30] <eintopf>
[19:49:55] <eintopf> this call of dev_hard_header will tell (e.g. ethernet) create me a MAC header with this address
[19:50:45] <eintopf> so daddr is given, saddr is NULL (it will be used the saddr which is assigned at dev <- net_device)
[19:51:46] <eintopf> (10 or 11 byte lladdr might be the best hack.) - I talked with some people about that and all told me it's a hack :-)
[19:52:17] <mcr> right, the idea is to then ask, "so what do you suggest? how would you solve this?"
[19:53:19] <mcr> is struct neighbour always looked up by l3 address to get l2 info?  Or is it used somewhere to map LL addresses to L3?
[19:54:46] <mcr> We need the 8-byte address at all times for certain types of packets (I don't have a list in front of me).  Whenever we have a 2-byte LL address for a peer, we should use it (unless magic debug flag is set).  The rest of the system need not about that.
[19:55:09] <eintopf> (05:52:25 PM) eintopf: and we do some policy if short address is set (short_address != 0xffff || short_address != 0xfffe) then we use the short address, otherwise we use extended_addr
[19:55:11] <mcr> We could create a new table mapping 8-byte addresses to 2-byte addresses, and use that.
[19:55:15] <eintopf> you mean this?
[19:55:50] <eintopf> Such mapping doesn't exist so far I know
[19:55:52] <mcr> well, sort of.  The magic debug flag is really just for interop testing, when we might need to force 8-byte frames.
[19:56:37] <mcr> exactly... maybe we have to create such a mapping table.  Best would be if we could stuff the 2-bytes into the struct neighbour somehow. ... that really amounts to the 10-byte hack again, but in a different way.
[19:56:54] <mcr> what is primary_key... it's a [0], which means it expands to be the right size.
[19:57:37] <eintopf> that means somehow they assign more data than sizeof(struct neighbor) only and put something behind (the primary_key)
[19:57:45] <mcr> I mean, we could add "ha2"...
[19:58:43] <mcr> yes... I'm curious what that part is.  It does mean that something is tracking the real size of that struct, and I don't see a size entry, so it must be determined by something else.
[19:59:08] <eintopf>
[19:59:17] <eintopf> seems like some hash key :-)
[19:59:55] <eintopf> and then we need to make the address length somehow part of the hash, if the primary key is somehow generated by the mac address
[19:59:57] <mcr> Yeah, it has an IPv4 or IPv6 address.   Also a 2-byte option, maybe for some other protocol.
[20:00:12] <mcr> the primary_key has a L3 address in it.
[20:00:18] <eintopf> ahhhh
[20:00:22] <mcr>
[20:00:52] <eintopf> okay, then it's fast lookup neighbor from L3 address
[20:01:26] <eintopf>
[20:01:41] <eintopf> example, simple search for "dev->addr_len"
[20:01:58] <eintopf> and this need (if possible) not per dev, but per neigh->addr_len
[20:02:22] <eintopf> I hope that we can deal then with different length for neighbors
[20:02:46] <eintopf> and HA can store short or extended than, indicated by the length
[20:03:34] <eintopf> the 10 bytes array, yes we can use it. If the short is then some valid address then we know "ah - this neighbor stores a short address"
[20:04:03] <eintopf> but putting two addresses into such array sounds wrong
[20:04:22] <eintopf> and "ip -6 neigh" will display stupid things :-)
[20:04:45] <eintopf> if we don't do runtime decision for checking on link-layer type inside userspace (when we have support for that)
[20:11:39] <eintopf> but if somebody to L2 to L3 address mapping then we need the address length of L2, indeed
[20:12:05] <eintopf> I hope that's at some position only where we can add runtime decisions and then we know what we want :-)
[20:12:13] <eintopf> memcpy(&neigh->ha, lladdr, dev->addr_len);
[20:12:16] <eintopf> everywhere!
[20:12:26] <eintopf> I like a: memcpy(&neigh->ha, lladdr, neigh->addr_len);
[20:13:25] <eintopf> most people get scared when they heard "IPv6 and different length for lladdr"
[20:27:15] <Michael Richardson> yeah, so yes, ip -6 neigh will show all ten bytes, which is looking dumb, but at least we'd be able to see the data.
[20:27:23] <Michael Richardson> (switched computers)
[20:28:18] <Michael Richardson> it would be worth having a slide with just what you wrote.... "we'd need to change all: memcpy(&neigh->ha, lladdr, dev->addr_len); to memcpy(&neigh->ha, lladdr, neigh->addr_len);
[20:28:53] <Michael Richardson> but, we'd also have two LL addresses for a single v6, and then we'd need some priority... so storing them both in a single struct neighbour would be better... if only we could figure out how.
[20:30:43] <eintopf> ah, yes
[20:30:48] <eintopf> we need to store both
[20:32:08] <eintopf> then things getting much compilcated and the 10 bytes lladdr looks good :-)
[20:32:17] <eintopf> nono
[20:32:46] <eintopf> then the neighbor need to store a list of mac addresses and their length
[20:33:25] <eintopf> and we always use list_entry_first at first, for special 6LOWPAN interface with 802.15.4 we do list_for_each
[20:37:04] <eintopf>
[20:37:11] <eintopf> list_frist_entry
[20:37:30] <eintopf> that's just deferencing, no running loops
[20:38:01] <eintopf> so all link-layers which use one lladdr type with one length use that and we can put more there
[20:38:19] <eintopf> and other link-layers which use 3 lladdr types can use them as-well
[20:40:42] <eintopf> (nobody can understand really this issue in 20 minutes) :D
[21:04:45] <eintopf> list - because we have no static boundaries for that then
[21:04:55] <eintopf> and netlink can also deal nice with list stuff
[21:07:22] <eintopf> but then we can also change the dev_addr/addr_len of net_device to a list
[21:07:46] <eintopf> with the same backwards compability handling "list_first_entry"
[21:08:00] <eintopf> introduce new netlink stuff for handling them as list
[21:12:24] <eintopf> dev_addr of net_device is already a list, but not bounded with a length
[21:12:46] <eintopf> I think it's to making some fast context switching of mac addresses or something like that, need to dig into that
[21:23:34] <eintopf> first solving neighbor discovery cache issue with multiple lladdr with different length
[21:24:59] <eintopf> and I think it's already a big step to make a struct neigh_lladdr with ha-array, ha_len and struct list - then do everywhere a List_first_entry and list_add, etc...
[21:26:01] <eintopf> ah, and ha - array should be the first in struct neigh_lladdr
[21:26:12] <eintopf> then dev_hard_header will be backwards compability
[21:26:25] <eintopf> on 802.15.4 interfaces we can cast then
[21:26:31] <mcr> hi. I got my desktop back from my son's friend. (They were playing minecraft)
[21:27:08] <eintopf> (10:26:25 PM) eintopf: on 802.15.4 interfaces we can cast then -> no that's not working because dev_hard_header will be used also from another subsystems
[21:27:15] <mcr> why do we need a list of mac addresses?  Why aren't two enough?
[21:27:27] <eintopf> I think more into the future
[21:27:33] <eintopf> we have already this problem
[21:27:42] <eintopf> if somebody has 3 types of lladdr
[21:27:54] <eintopf> :D
[21:28:03] <eintopf> just don't do it static
[21:28:19] <mcr> when do we need 3LL? I can see it in 802.11 bridging, or 802q mode stuff....
[21:29:13] <mcr> dev_addr of net_device is a list... hmm.  I think it's because you can create multiple LL for a single interface, possibly also related to multicast?
[21:30:23] <eintopf> ah, ok
[21:30:26] <mcr> yes, replacing the ha with a new struct neigh_lladdr, whose first member is ha, and then putting in a #define ha ll.ha would work well.
[21:30:32] <eintopf> yes but all of them has the same length :-)
[21:30:58] <mcr> yes, they are all the same length... we don't even know at this point how to store *our* two LLs of different length.
[21:31:11] <eintopf> we have
[21:31:34] <mcr> oh, yeah, it's in the device private, isn't it?
[21:31:42] <eintopf> this is part of struct wpan_dev which is part of net_device private data
[21:31:43] <eintopf> yes
[21:31:56] <eintopf> you need to evaluate some types and then casting
[21:32:28] <eintopf> but for "struct neighbor" we don't have
[21:32:50] <eintopf> I would like to see a list there because we need support for "multiple lladdr per neighbor"
[21:33:04] <eintopf> and "2 lladdr per neighbor" sounds static :-)
[21:33:30] <eintopf> if we send for 2 a patch, somebody will mark it as review
[21:33:39] <mcr> sure... it would be a good question for the group: "we need two different length LL per neighbour.  Should we generalize to n?"
[21:33:53] <eintopf> yes
[21:34:07] <eintopf> I ever met "the group"
[21:34:16] <eintopf> I mean I don't asking that during the talk
[21:34:19] <mcr> might be pre-mature optimization; maybe it can be done such that if n= constant, that it's more efficient.
[21:34:23] <eintopf> because this issue is too complex
[21:34:45] <mcr> if netdev11 is like 01, then the group will ask lots of questions, and will be easy to engage.
[21:35:27] <eintopf> that's why they introduced "MAX_ADDR_LEN" it's something which fits in some cache lines
[21:35:31] <mcr> yeah, that patch for the dwc2 isn't enough..
[21:35:31] <eintopf> and access it fast
[21:35:46] <eintopf> mhh
[21:35:59] <eintopf>
[21:36:23] <mcr> MII is busy in smsc95xx_mdio_read
[21:36:27] <mcr> is spammed all over dmesg.
[21:36:54] <eintopf> :-(
[21:37:05] <mcr> yeah, that looks better... I was about look deeper into that balbi tree
[21:37:42] <eintopf> I hope I am prepared to answer the question from "the group"
[21:38:48] <eintopf> I think, I need to understand the question at first
[21:39:00] <eintopf> one year ago I didn't know what SLLAO is
[21:39:26] <eintopf> because my first work was IPHC, FRAG handling at first
[21:40:32] <mcr> :-)
[21:40:56] <mcr> I think most of the group won't know what SLLAO is either; but they will understand LL addresses in the kernel.
[21:42:25] <mcr> have you travelled to Seville yet?
[21:47:16] <eintopf> no
[21:47:35] <eintopf> I never was in spain
[21:47:43] <eintopf> been
[21:47:55] <eintopf> there is also the mac80211 maintainer
[21:48:26] <eintopf> I can ask this guy for 802.15.4 (we mostly grab the code from mac80211 but with 802.15.4 functionality)
[21:48:40] <mcr> he may care about having multiple LL (but his will all be 6-bytes) as there are 2-address, 3-address, and 4-address modes for L2 encapsulation.....
[21:49:13] <eintopf> you see
[21:49:36] <eintopf> if we do it for multiple things then others can use it as well ;-)
[21:50:30] <eintopf> I maybe want to mention with 6LoWPAN Generic Framework, it could be that you can run IPv6 (6LoWPAN) on mac80211 directly with some tweaks
[21:50:35] <eintopf> nobody specifies it yet
[21:50:38] <eintopf> but you could do it
[21:50:58] <eintopf> if we have more a "framework" this is still in todo
[21:51:00] <mcr> RPI speaks ethernet now...
[21:51:06] <eintopf> good
[21:53:55] <eintopf> also maybe in ethernet ipv6 has some crazy (?debugging?) use-case to add more than one lladdr for one L3 address
[21:54:15] <eintopf> not sure if this is something which breaks everything in IPv6
[21:54:26] <eintopf> seems not
[21:57:51] <eintopf> don't know how SLLAO will be handled then, there must be one MAC address which should be used then
[21:58:01] <eintopf> what you already said, we need some policy then
[21:58:11] <eintopf> ah no
[21:58:22] <eintopf> that's only for the source address
[21:58:30] <eintopf> but neighbor contains destination
[21:58:48] <eintopf> :D it's not easy
[22:12:46] <eintopf> I go sleep now
[22:13:30] <eintopf> good night
[22:13:37] <eintopf> be here ~8 hours again
[22:13:44] eintopf leaves the room: Disconnected: closed
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!