IETF
roll@jabber.ietf.org
Thursday, February 18, 2016< ^ >
Thomas Watteyne has set the subject to: IETF93 ROLL WG meeting
Room Configuration
Room Occupants

GMT+0
[07:45:56] eintopf joins the room
[11:32:17] <eintopf> @short address handling: Yea, the NCE stuff is still todo. I just add the easier part at first -> adding autoconfiguration link-local address part
[11:32:42] <eintopf> but I will fight with the NCE stuff
[11:33:07] <eintopf> but I have a exam at 29th
[11:33:42] <eintopf> logic and (don't know the english word, but it's about what is calculationable and what's not)
[13:18:51] <eintopf> btw: greetings from jamal
[13:18:56] <eintopf> he said that he knows you
[13:33:53] <eintopf> netdev is great. Is a community conference
[13:33:54] <eintopf> no LF behind ;-)
[13:49:56] <Michael Richardson> hi. Yes, Jamal and I go back 20+ years.
[13:54:37] <eintopf> :-|
[14:27:40] <eintopf> btw: next netdev in tokyo
[15:46:43] mcr leaves the room
[15:49:16] mcr2 joins the room
[17:51:51] <eintopf> and I need to be at IETF in berlin
[18:05:51] <mcr2> yes, that would be awesome.
[19:52:46] <eintopf> currently I try to hack the short address
[19:52:53] <eintopf> first get it working somehow
[19:53:00] <eintopf> while hacking I get new ideas
[19:53:56] <eintopf> new ideas which fix also some other issues
[19:53:57] <eintopf> :D
[19:56:29] <eintopf> unsigned char           ha[ALIGN(MAX_ADDR_LEN * 2, sizeof(unsigned long))];
[19:56:34] <eintopf> that's what I am doing now
[19:56:43] <eintopf> #define NEIGH_GET_SND_ADDR(ha) (ha + MAX_ADDR_LEN)
[19:57:09] <eintopf> so the second address is currently some transparented after the first space
[19:57:42] <eintopf> you don't see the short address when dumping "ip -6 neigh" this requires additional changes
[20:13:22] <Michael Richardson> hi.
[20:14:18] <Michael Richardson> interesting hack, but it depends upon that MAX_ADDR_LEN*2 > sizeof(unsigned long), doesn't it?
[20:18:59] <eintopf> no
[20:19:11] <eintopf> they just make some boundaries there because cacheline stuff
[20:19:13] <eintopf> I suppose
[20:19:48] <eintopf> you call it as hack :(
[20:20:30] <eintopf> http://pastie.org/10727890
[20:20:39] <eintopf> memset(NEIGH_GET_SND_ADDR(buf), 0xff, 2);
[20:20:52] <eintopf> e.g. for indicate broadcast address
[20:20:57] <eintopf> that works now
[20:21:24] <eintopf> no more any mapping from 0xff...ff (extended) to 0xffff (short) anymore
[20:21:54] <eintopf> just a small step, the big issue is to handle SLLAO etc
[20:22:02] <eintopf> and evaluate the length field
[20:27:01] <eintopf> http://pastie.org/10727901
[20:27:06] <eintopf> another thing which I added
[20:27:26] <eintopf> I make a special 6lowpan dev_hard_header callback this solves also issues with AF_PACKET DGRAM sockets on 6lowpan interfaces
[20:27:35] <eintopf> which is broken/makes no sense
[20:28:07] <eintopf> AF_PACKET will then operate as RAW socket on 6lowpan interfaces with min_header_length of 40 bytes
[20:28:25] <eintopf> so you can feed the 6lowpan adaptation with own ipv6 headers
[20:28:45] <eintopf> but, I think we currently have some less "length checks" there, we need to fix that
[20:29:10] <eintopf> AF_PACKET DGRAM socket doesn't work then anymore, because we don't have the dev_hard_header stuff
[20:36:48] <eintopf> less "length checks" -> means you can kill the kernel with some ipv6 headers :-)
[20:43:07] <eintopf> I will check if short address is 0xfffe
[20:43:14] <eintopf> when it's set I use extended
[20:43:22] <eintopf> if it's different then I will use short
[20:43:44] <eintopf> for source address (0xffff will be included)
[20:44:02] <eintopf> I think that makes sense, somehow
[20:53:16] <mcr2> so, from userspace, we can open raw DGRAM right into 15.4 level?
[20:53:40] <mcr2> oh, you mean, it's above 6lowpan....
[20:59:43] <eintopf> it's not easy
[21:00:16] <eintopf> on wpan interfaces and AF_PACKET DGRAM (extended_addr are possible for source/destination) this will map to an intra-pan communcation only
[21:00:36] <eintopf> because the AF_PACKET DGRAM UAPI has only 8 bytes for address information
[21:01:04] <eintopf> if you need more address information then you need to use AF_802154
[21:01:40] <eintopf> on 6lowpan interface AF_PACKET DGRAM should be disabled (we don't implement the dev_hard_header callback) so it's like a RAW socket of AF_PACKET
[21:01:46] <eintopf> but currently we have implement it
[21:01:53] <eintopf> and I think it will make stupid things :-)
[21:03:18] <eintopf> I use sometimes DGRAM sockets for fast sending some unicast frames, but the UAPI doesn't fit into 802.15.4 address use-case
[21:07:28] <mcr2> so, doesn't AF_PACKET live above IPv6 layer, but you are saying we need something below it, but above 6lowpan layer?
[21:13:57] <eintopf> we don't need AF_PACKET at all :-)
[21:14:17] <eintopf> RAW socket must be there because wireshark/tcpdump. You are an expert into that
[21:14:26] <eintopf> but DGRAM sockets on a "virtual 6lowpan interface"
[21:14:33] <eintopf> this makes no sense
[21:14:52] <eintopf> what for a mac header should we place there, there is no mac
[21:15:06] <eintopf> RAW sockets okay, you can give the adaptation layer a IPv6 header
[21:15:19] <eintopf> for transmit side
[21:16:58] <eintopf> in other words: what would you suggest when you doing a AF_PACKET DGRAM socket on a 6lowpan interface
[21:19:34] <mcr2> I think that I need a diagram to understand the problem.
[22:19:11] <eintopf> I changed something
[22:19:16] <eintopf> now nothing works anymore
[22:19:47] <eintopf> grml, I sleep now and then I will create a new branch and check again everything
[22:25:54] eintopf leaves the room: Disconnected: closed
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!