Monday, November 9, 2015< ^ >
Dave Thaler has set the subject to: IETF 94 6lo WG meeting
Room Configuration
Room Occupants

[01:36:32] mcr leaves the room: Disconnected: No route to host
[07:17:51] mcr joins the room
[07:48:52] <eintopf> ah, ok.
[07:49:32] <mcr> hi. I'll follow that radvd link you sent.  I'm in airport now. Oleg went home last night.
[07:49:52] <eintopf> ok.
[07:50:15] <mcr> eintopf = Alex?
[07:51:18] <mcr> Oleg said you had some ideas on how to store short+long addresses in neigh table. I'm thinking that lowpan has a 14 byte "MAC" header... and we subdivide, and we can maybe put ETX in there too.
[07:52:08] <mcr> also was thinking a lot about how to handle 6CO and CIDs, and also about how to get unit testing framework (probably Rusty's netfilter one) around code.
[07:52:22] <mcr> if money became available, could you accept some to do more work?
[07:52:36] <eintopf> yes, I am Alex.
[07:54:15] <mcr> I will write up a summary of experiences and share them. In some ways, Oleg and I had more fun doing RPL interop than 6lo interop :-)
[07:54:34] <mcr> not was much Ipv6 in Japan as I thought there would be.
[07:55:09] <mcr> I got public IP on my mobile from Docomo, but no IPv6.  Also public IP in NEX train, but no IPv6 (and I had no account to even enable it...)
[07:55:49] <eintopf> you are welcome to write your idea's to linux-wpan, if it belongs to 6LoWPAN (which is actually IPHC things) then cc linux-bluetooth, please.
[07:59:59] <eintopf> there are some idea's around the linux-wpan developers(except you and Oleg, ~3 members) to handle the (short+extended) address mess inside the IPv6 neigh discovery. I think we can combine them and talk about the advantages/disadvantages
[08:00:59] <eintopf> to handle not short address is currently, very bad...
[08:02:42] <eintopf> @("if money became available, could you accept some to do more work?") - maybe you can talk about that with my boss. Please contact :-)
[08:03:50] <eintopf> My main work is currently to do linux-wpan during my study (from home-office), but we have a lot of linux kernel hackers
[08:10:52] <mcr> hmm.
[08:11:54] <mcr> I don't have any money, but there are a few parties that can't convince to give me money (European issues), who might able to go your way.
[08:13:04] <mcr> hmm. first beer I had was better than this one.
[08:13:20] <mcr> I missed deadline for FOSDEM main track.
[08:14:15] <eintopf> 1. Dec
[08:14:26] <eintopf> oh for main track - I don't know.
[08:14:48] <eintopf> (who might able to go your way) - You think that's the right way?
[08:22:30] <mcr> yeah, so IoT hack room is probably better.... I will write up some things about RPL for that.  I hope will do something about 6lo.
[08:23:16] <mcr> how did you intend to handle 6CO?  I'm thinking that for non-mesh uses, that we can use radvd on router, and it should install CID=0 with prefix for link into kernel.
[08:23:36] <mcr> for mesh uses this should be done by RPL daemon.  the 6CO CID interface should be /sys interface, I think.
[08:25:09] <mcr> should lowpan0 have a place in /sys/devices/virtual/net ?
[08:25:56] <mcr> do you know if we can operate on more than panid using a single radio at the same time?  I think that we can not do this with current architecture, but can at86.. device do it?
[08:28:33] <eintopf> for (6CO). We need at first kernel support for handling the contexts - There was some RFC (I think you saw it, from Lukasz Duda). I asked him ~1 month ago if I can work on this and if this is okay. He replied that he doesn't work on this anymore.
[08:29:39] <eintopf> I think at first it should be fine to manual set the context's via debugfs, this is what Lukasz also tried. Then we need some "better" interface for the context so radvd can access it and this would be a netlink interface then.
[08:30:22] <eintopf> netlnk or /sys
[08:31:35] <eintopf> the common way for doing all the networking stuff nowadays is to do netlink stuff, the debugfs is like something you want to offer for /sys but this is just for doing fast manipulation stuff.
[08:31:51] <eintopf> is this okay?
[08:35:24] <eintopf> (multiple pan's) I think we can do this by introducing a new interface type to make some PAN_BRIDGE or something else. Do you think also about channel hopping feature?
[08:37:06] <eintopf> or do you want no pan bridge, I don't know how the mapping works. We have some extended<->pan_id mapping and then we do some lookup?
[08:38:06] <eintopf> because pan_bridge is a lot of different thing than just changing the pan_id before transmit and then how is the receiving working, or do you want to disable address-filtering then?
[08:39:35] <eintopf> ehm, yes the source pan_id should be always the same, or not?
[08:40:39] <eintopf> lot of questions about the right use-case, what I can tell you... if you want different kernelspace handling for that then and the interface runs completely different -> add a new interface type
[08:41:40] <eintopf> are you still there? :-)
[08:42:15] <eintopf> ah, writing mails
[08:45:42] <eintopf> (radvd interface to kernel) radvd uses already netlink stuff, but then we need to open some special 6LoWPAN netlink stuff, when we have a 6LoWPAN interface.
[09:22:27] mcr leaves the room: Disconnected: closed
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!