IETF
roll@jabber.ietf.org
Wednesday, June 22, 2016< ^ >
mcr/credil has set the subject to: IETF96 ROLL WG meeting
Room Configuration
Room Occupants

GMT+0
[07:45:45] eintopf joins the room
[07:45:55] <eintopf> I am awake
[07:47:20] <eintopf> mcr: do you are statisfied with the stateful compression support?
[10:02:09] <eintopf> grml
[10:02:16] <eintopf> we have a bug in short address ndisc stuff
[10:02:39] <eintopf> fe80::ff:fe00:eee dev lowpan1 lladdr ce:14:9d:9e:0b:77:ba:47 STALE
fe80::cc14:9d9e:b77:ba47 dev lowpan1 lladdr ce:14:9d:9e:0b:77:ba:47 STALE short_addr 0x0eee
[10:03:13] <eintopf> on both should be short_addr visable
[10:05:38] <eintopf> ahh, now both has the short address
[10:05:53] <eintopf> I think some is not right there, but I had this on todo
[10:06:15] <eintopf> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/6lowpan/ndisc.c#n111
[10:06:27] <eintopf> and I think it isn't right to react on overrides flag only
[10:06:41] <eintopf> need an Ipv6 expert :(
[12:26:29] <eintopf> ahhh, I know why
[12:27:20] <eintopf> complicated issue, but at the end the RA messages didn't contained a short addr sllao and with that it works
[12:27:40] <eintopf> if not present, then the neighbour will be assign to 0xfffe -> UNSPEC
[13:28:23] <mcr/soho> eintopf, I haven't got to the stateful compression support yet.
[13:28:46] <eintopf> ah okay :(
[13:29:05] <mcr/soho> I'm looking, trying to see why I have a ping with a long source and a short dest.
[13:29:20] <eintopf> I will start to write an email today for stateful compression UAPI, RTNL doesn't fit there
[13:29:45] <eintopf> RTNL is much much generic ADDADDR, DELADDR, etc and depends on PF_INET, PF_INET6, PF_FOO
[13:30:03] <mcr/soho> dammit, need 15.4 decode for tcpdump, because copy and paste from wireshark is a pain.
[13:30:06] <eintopf> we are still PF_INET6 but mostly IPv6 use most of RTNL api stuff
[13:30:35] <eintopf> 03:29:05 PM) mcr/soho: I'm looking, trying to see why I have a ping with a long source and a short dest. - on linux?
[13:30:39] <mcr/soho> http://www.sandelman.ca/tmp/mcrcapture/3205.2016-06-22/capture1.png
[13:30:56] <mcr/soho> yes, Linux to Linux. RPI to RPI.
[13:31:32] <eintopf> this should not happen on Linux 6LoWPAN
[13:31:43] <eintopf> because 0x8000 bit indicate non unicast short address
[13:31:51] <eintopf> h
[13:31:53] <eintopf> ah
[13:31:58] <eintopf> it's not set, so it's correct
[13:32:24] <eintopf> why should destination short addrss be wrong?
[13:33:24] <eintopf> Sorry, I am back in ~30 minutes - need to eat something
[13:34:00] <eintopf> btw: the current strategy to use short addr, is if one is available
[13:34:28] <eintopf> but this isn't perfect, because IPHC SAM/DAM = 11 it depends on L3 if we should use short address or extended address
[13:35:29] <eintopf> set your wpan interface short address to something which has 0x8000 bit set (not 0xfffe, 0xffff it's not allowed to set that, but I think we need to remove the check to allow it)
[13:35:38] <eintopf> then extended will be used
[13:42:21] <mcr/soho> hi. oh. where does this 0x8000 issue come from?  is it from 6lowpan or 15.4?
[13:47:31] <mcr/soho> It appears that the fragments go out last to first. I know that is often better, but it may be a bad idea to do this at layer-2.
[13:54:24] <eintopf> https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#_6lowpan-parameters-2
[13:54:32] <eintopf> that's short address multicast mapping
[13:54:48] <eintopf> but it's in L2 unicast addressing
[13:55:24] <eintopf> I think they do the MESH routing dispatch stuff then, but I didn't saw any specification for meshing stuff
[13:55:41] <eintopf> lot of rfc4944 is out-of-scope
[13:56:17] <eintopf> (last fragment as first) - we can do that, just add them into a skb_queue at first and then send reverse
[13:56:35] <eintopf> (I need to go to lunch again)
[14:02:09] <eintopf> (0x8000 issue) -> if the wpan device has some short addr assigned where this is bit is set, we don't use them as unicast address (like 0xffff/0xfffe)
[14:02:35] <eintopf> but don't forbid to set wpan device short addresses because they are on L2 unicast
[14:02:41] <eintopf> 0x8000 bit comes from IETF
[14:19:23] <eintopf> (last fragment as first)  - we need to do that in skb queue at first, because FRAG1 and FRAGN has something different, if I remember correctly FRAGN are has some header fields with sized which is multiple 8 of something, I think the offset should be some 8 * multiple
[14:20:10] <eintopf> and FRAG1 doesn't has that because offset is 0 - I don't know if we can directly begin to create the last FRAGN up to FRAG1 and send directly after creation
[14:20:17] <eintopf> otherwise skb_queue would be a solution
[14:21:38] <eintopf> oh wait, I need to understand this correct: you want FRAG1 to FRAGN sequence for fragments or FRAGN to FRAG1? The current behaviour should be FRAG1 to FRAGN, depends on qdisc
[14:33:17] <eintopf> what I mean is, we sending FRAG1 to FRAGN to qdisc, if you see it different then maybe qdisc do something different
[15:08:52] <mcr/soho> bit 15 should be cleared, not set.
[15:13:21] <mcr/soho> I wonder if the short-address neighbour cache does not expire?
[15:22:29] <mcr/soho> I misunderstood before.
[15:33:39] <mcr/soho> for the purposes of interop, is there a way to turn off short-address use?
[15:33:48] <mcr/soho> i.e. to ignore them?
[15:34:54] <mcr/soho> I think that we have no way to see the neighbour cache of short addresses, right?
[15:36:41] <mcr/soho> I see FRAGN to FRAG1 in the trace.
[15:59:03] <eintopf> (05:34:54 PM) mcr/soho: I think that we have no way to see the neighbour cache of short addresses, right? - I have patches for that
[15:59:21] <eintopf> (05:13:21 PM) mcr/soho: I wonder if the short-address neighbour cache does not expire? - should be same like extended address
[15:59:58] <eintopf> (05:33:41 PM) mcr/soho: for the purposes of interop, is there a way to turn off short-address use? - don't set a short address, leave it 0xffff or something where bit 15 is set
[16:00:59] <eintopf> (05:08:52 PM) mcr/soho: bit 15 should be cleared, not set. - I didn't do that, because what about other 802.15.4 protocols besides 6LoWPAN? - 6LoWPAN will not use the short address if 15 th bit is set
[16:07:04] <mcr/soho> okay, will not setting my short address cause me to not use a short address for target?
[16:07:59] <eintopf> yes, because 15th bit isn't unicast address according iana above
[16:08:15] <eintopf> or leave it as default 0xffff (I want to make that possible again to set it)
[16:08:25] <eintopf> or 0xfffe (unspecific address)
[16:08:39] <eintopf> https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#_6lowpan-parameters-2
[16:09:12] <eintopf> I think they use the short address stuff for 6lowpan mesh routing stuff
[16:09:43] <eintopf> currently you cannot set 0xffff or 0xfffe via nl802154 again after you changed the address, this is because some historial issues because it was never possible
[16:09:47] <eintopf> but I like to change that
[16:10:35] <eintopf> http://lxr.free-electrons.com/source/net/ieee802154/nl802154.c#L1115
[16:11:10] <eintopf> 1123          * I think we should allow to set these settings but
1124          * don't allow to allow socket communication with it.
[16:12:08] <eintopf> yes, true we should drop such skb's then but the complete 802154 socket stuff needs a rework anyway, I don't think they are so clever to use wpan_dev assigned short address. Source address need to be set from userspace
[16:12:11] <eintopf> which is bad
[16:22:48] <eintopf> do you don't like that behaviour?
[16:23:18] <eintopf> the behaviour is: short address is optional, if they is valid unicast -> it will be added to target/source address options.
[16:24:26] <eintopf> the case whenever IPHC/802.15.4 should use short or extended, is the question of L3 address bits. In some cases extended address can compress more bytes than short address. It depends on L3 and fragmentation (NOT implemented yet)
[16:25:42] <eintopf> L3 address bits => how the ipv6 address is formed, but that's odd :-) I mean the case of DAM/SAM = 11 and the L3 address will be full elided (mostly in L3 autoconfiguation generated addresses)
[16:29:37] <eintopf> e.g. you will see some 6LoWPAN frames which use fe80::EXTENDED_ADDR/64 which fits in one frame, this should use extended address instead short address, because extended address will compress the 6LoWPAN header more. L3 can be fully elided
[16:30:15] <eintopf> fe80::EXTENDED_ADDR/64 => with u/e bit, the same for PREFIX::EXTENDED_ADDR/64 in case of stateful compression
[16:30:40] <mcr/soho> hi. was distracted.
[16:30:59] <eintopf> yea, sorry I write too much information here
[16:32:08] <mcr/soho> your point about extended addresses might compress more L3 is a good point.
[16:33:03] <mcr/soho> I have to head out on errands. back online tomorrow.
[16:38:47] <eintopf> ok
[16:51:29] eintopf always write u/e bit but means u/l bit
[19:51:51] <eintopf> mcr: https://lists.riot-os.org/pipermail/devel/2016-June/004119.html
[19:52:26] <eintopf> maybe you also interested into this, I definetly need OpenThread in userspace to test against MLE implementation for collecting ETX metrics
[20:43:32] eintopf leaves the room: Disconnected: closed
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!