-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathDONE
1161 lines (721 loc) · 33 KB
/
DONE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
-*- outline -*-
* 15.7.2013+
** HP - Announce only links if _owner_ (can provide service on others, too)
(to browse domain that is; browse is set by ownership, and the links are
announced regardless. whether that is sensible or not is another matter I suppose..)
** Enable spaces in domain search strings
Right now, the shell scripts that deal with skvtool don't escape them
appropriately => things probably blow up horribly. Is this a real problem,
though?
=> We ignore them now; search domain is not really relevant with home being
separate administrative domain (according to Ole, but in violation of
RFC6204)
** Adding new tunnel interface should work faster.
skvtool 'tunnel.ula=[{"prefix":"fd00::/48"}]'
==> propagation takes a loong while. Reason is probably simple -
===> refactored things in elsa_pa.lua; now prefix assignment algorithm is
always run when available prefixes change (duh), and the handling in
general should have less timeouts.
** pa-config does not work
skvtool cannot set pa-config after the fact; other variables _do_ work, so
something weird going on in the handling there.
==> there was some weird logic about local and remote state not being of
equal value ('local' information preferred). in practise, 'the most recent'
information is always most valuable => use whatever we get (=> do not drop
remote updates if we have local state, but instead drop local state).
* 17.6.2013+
** dns library in general
RFC1035-compliant size checking on encode, and refusing to play ball if
input is invalid. This way, we're liberal in what we receive, but strict
when sending, hopefully making the world a better place?
(Obviously, dns->dns->mdns->dns chain will break at some point if someone feeds
in something invalid, but I think it's better not to cause problems with
other devices.)
* 10.6.2013+
** HP - Add support for detecting in-progress mdns query -> do not ask again, but instead wait for result
** HP - IPv4 - forward + reverse DNS for IPv4
- need to support both routers and nodes' A RRs too; right now we do only
AAAA
=> added A record support too
** HP - currently escaping of .'s on ifnames doesn't work
(does it reallyreally _matter_?, we support arbitrary-depth domains
anyway.. but perhaps it does, in some UI.)
** HP - Alter design s.t. it is possible to use some other resolver again
Right now we do our own resolving, and then fall-back to external in many
cases.
It should be possible to just output .home and the related sub-zones (and
reverse zones) and use BIND! Or something else. Unfortunately, dnsmasq is
not probably configurable enough..
.. now the zone creation is very 'local' (remote zones are just basically
NS records we receive via OSPF) => we _could_ synthesize real zones. If we
wanted to. (Or at least, BIND config file + few zone files.)
** HP - Add vanity router/link name support
.. added router name generation algorithm to the prefix assignment stuff in
OSPF. link names are entirely local constructs, and changed hp_ospf to use
ifname as base for creating them.
*** Router name
View has to be same across whole home. Therefore, in case of conflict,
perform automatic re-naming with -<X> suffixes until things look sane
again.
** HP - Add some hook to add 'extra' browsing domains to hybrid proxy
static-zones can be used for that now
** Disable non .home search paths when hybrid proxy in use?
RFC6204 indicates we should pass values across; on the other hand,
conversations with Ole indicate that passing search path across
administrative boundary is not good idea. Hmm.
* 3.6.2013+
** vstruct - enable strict support somehow
(so we can at least run tests under -lstrict again)
Apparently the endianness check's jit check is broken (io/endianness.lua
checks for 'jit')
https://github.com/ToxicFrog/vstruct/issues/18
=> added workaround for it
** Improve Debian 7.0 boot times in NetKit - they're ridiculously high now
- should use bootchart2 and track down the worst offenders, get rid of them
(the boot times have nasty multiplicative effect on productivity; 6.0 was
much better, at a guess it booted in half the time)
==> minimized the number of services to be loaded; filed a bug about
bootchart2 not working in UML (
https://github.com/mmeeks/bootchart/issues/47 )
* 27.5.2013+
** Enable Debian-based infra dev too
Now we have infra-on-OWRT+UML+NetKit pretty much done; however, how to get
stuff also working with Debian+Bird+stuff? It requires fixing of various
node templates under ttin/ at least.
** Write patch set for luasocket changes for Diego
.. Diego took in most of our changes already. Unfortunately, he did _not_
take multicast if join/leave name change => we maintain own branch just for
that (which isn't much, luckily, though).
* 20.5.2013+
** Handle name compression correctly regardless of content
Currently, what we do, is just do name compression correctly on _known_ RR
types. However, that's implementation artifact of dns_name.lua. Of course,
as re-encoding of records won't work correctly if we don't know contents of
RRs (so that name bits are decoded correctly when passing packet along),
I'm not sure if this is a big problem.
Obviously, pure binary forwarding would be nice. But there's elegance also
in passing along the decoded messages (as we can play with them). Perhaps
the correct thing to do is use decoded if and only if we want to change the
content, and forward blindly otherwise?
=> now we handle things in ~pure binary, with minimal
non-message-compression supporting and non-rr-decoding stuff to handle
correct message lengths in TCP. Yay.
* 8.4.2013+
** Make the whole thing easier to build from scratch
*** NetKit+UML env
- add our variant to github
- try to make whole thing build from source (the fs/packages/ is ugly hack)
- add git submodules for stuff we want (ISC dhcp, BIRD, odhcp6c,
whatever), and associated makefiles to build them
- build x86_64 - i386 is historic and should be treated so
==> Goal:
- github repos for netkit-core + fs + kernel
make kernel under kernel => kernel
make filesystem under fs => filesystem
=> working env
(no binaries, no closed-source)
- one 'root' repo with submodules for netkit-core+fs+kernel
- one centralized Makefile
* 26.3.2013+
** Fix route_to_rid checking laziness
- should know when routes have changed => after that, force re-check of
state?
.. now we call elsa_dispatch only as last, instead of in ~middle of ospf
dispatch => routes are up to date when it's called, yay.
** ISC dhclient
- duid not consistent (sigh) => interesting issues when rebooting routers..
-D LL seems to address it?
(encountered at IETF86)
(- low t1/t2 values => problems )
- near boot time, both ISC dhclient and dhcpd work strangely - can be
related to kernel version, the sockets won't get ADVERTISEs that someone
sends to us, but the situation persists until we restart daemon at some
later point
- aha, seems like just one at a time works => require multi-interface
support, or just rewrite the POS.. ;)
.. solution was just to get rid of ISC dhclient (for IPv6) altogether;
odhcp6c seems to work well enough, and with much smaller footprint.
* Done (IETF?)
** MDNS - Do math on scalability/feasibility of different approaches
*** site-local multicast
Traits
- add expensive (spams whole network)
- maintenance NONE
- queries expensive (spams whole network)
*** active probing (ours)
Traits
- add new => announced globally (OSPF, link churn)
- maintenance => just local resources probed every now and then
- queries ~free
*** relay-ish (Shwetha?)
? (I don't understand it well enough)
*** DNS-SD => mdns (Cheshire hybrid)
- scary question, though - when query is 'done'? (long-lived query draft
is the answer)
- typically requires manual configuration(?) or co-operation between
routers(??) to get browse paths right
- in homenet context, we could synthesize 'ask all links' case easily
enough from the OSPF ASPs
Traits
- add cheap (local op)
- maintenance NONE
- queries expensive
*** DNS-SD + DNS-SD update
- problem: liveliness of data
Traits
- add cheap (local op)
- maintenance NONE
- queries moderately expensive (given shitload of zones; however, can have
less zones than in DNS-SD => mdns case => probably
*** Conclusions
What it boils down to is the ratio of different ops - add / maintenance /
query. Impossible say what is the mix in a typical home network..
* Done (11.3.2013+)
** Propagated DHCP lifetimes not reflected correctly
.. seems to work now (unless pm.lua gets stuck, which might be related to
some other issues we had also in the past)
** Sometimes next-hop stuff _stays_ out of sync with reality
Correct solution is to check even contents of the route tables when
checking rules, it's not like it will break our CPU budget.
Yet better design-wise would be to use recursive routing; however, that's
bit awkward to do in practise.
.. It turns out that the 'tick' mechanism that checked next hops (on edge)
every 10 seconds was horribly broken.
* Done (4.3.2013+)
** Add some sort of 'initial state fetcher' (/ semi-random state refresher)
.. when becoming owner of an interface, should proactively query (with qu
set on?) for services, and then instances of those services..
i.e. q {'_services', '_dns-sd', '_udp', 'local'}
.. and then q for everything within!
(we _may_ also keep a list of services we've ever heard about, and include
those explicitly in initial query; that's also perfectly valid option, but
should be just used as backup solution)
* Done (25.2.2013+)
** Add support for multiple prefixes per interface
(or more generically, implement the ~real data structure handling, the raw
skv primitives seem too .. primitive?)
** refactor skv fields to be more sensible
- some sort of self-describing nested-table approach
- skvtool may need some sort of better data structure manipulation tools?
(add/remove to list?)
* Done (18.2.2013+)
** Write OSPF state sanitizer
- no linklocal addresses
- filter them out
( simple pass through list)
- no dangling SRVs
make sure mdns state contains addresses for srv
( can create dnsdb of a/aaaa records, and look those up; ~linear time
albeit with high constant factor )
make sure mdns state contains destination of ptr
- no dangling PTRs
harder; effectively, graph verification algorithm. it _can_ be done in
linear time though, given graph lookups are O(1), by keeping nested hash
of to do items <> resolved items
(This is bit mid-way, but..)
.. see OmniGraffle diagram for design, but basically single pass is enough
for both filtering _and_ dangling reference elimination ..
* Done (11.2.2013+)
** Determine why some state saves across test cases
make => fail; individual busted run => success (bisect done, test case is
mdns_core_spec #shb which fails, it apparently starts announcing something
else, and expiring something else too, for some reason).
Chances are, the nondeterministic run order of nodes is different when run
individually as opposed to when run as part of the whole, but if that is
the cause, there is something fundamentally broken _somewhere_.
- seems like the ttl=0 handling was bit too severe; added IGNORE_TTL_BELOW,
below which we consider ttls 'not interesting'
* Done (last week of January, 2013)
** Test OSPF LAP-based local interface stuff
** Test multicast join/leave in luasocket
** Add multicast join/leave to all interfaces
** Create stand-alone daemon
+ mdns_ospf + skv
+ elsa_pa: SKV<=>OSPF publishing
+ ssloop for event handling (mainly, to deal with skv, and to handle
inbound UDP packets; ssloop in general is done, but UDP support may
require small changes, as currently ssloop operates on TCP only)
+ Luasocket (w/ IPv6 multicast join/leave support) for socket handling
+ need to integrate to OpenWRT build process own version
+ replace the built-in luasocket with e.g. hnet-luasocket package (...)
+ mdns.lua
+ tie together above bits => one coherent whole (TODO: mcast join/leave)
** Implement SKV <> OSPF sync
+ [1] just toss the cache entries to jsonblob (good short-term solution,
least efficient encoding, hardest to push through)
** Make codebase it work with non-linklocal addresses too
Key idea:
- maintain ~every now and then updated local IPv6 address table (code
already exists in linux_if, although it isn't pretty as it just uses shell
commands and does not use the real API)
- elegant way would be to figure OS level API, abstract it to Lua,
etc.. but that sounds just like major hassle
- for any inbound packet, either it is
<fe80:...>%<ifname>
=> just use <addr> + <ifname>
or
<addr>
in case of <addr>, look up <ifname> with matching prefix, and use that
=> B.I.Y.U.
This stuff covers a number of SHOULDs in the draft.
* Done (19.11.+)
** Shouldn't run radvd on interfaces we listen on
- have to check the checks are mutually exclusive
.. in some cases, it seems they aren't, right now.
Set-theoretically
- radvd INTERSECTION listen_ra == null set
- radvd UNION listen_ra IN all interfaces
(but there may be interfaces for which we don't do RA, or listen to RA)
** Deal with 2.6 kernels' broken accept_ra == 2
That is, accept_ra won't work with them if forwarding, without kludging the
interface-specific forwarding flag. Luckily those old versions don't check
the flag..
Another alternative would be to do fallback to rdisc6 + best effort
(.. sigh ..)
Fixed in kernel commit
026359bc (Tore Anderson 2011-08-28 23:47:33 +0000 3029)
.. which went to 3.1-rc6, and eventually 3.1. So safe to say, <3.1 is
broken in this regard and we should do
** Test hnet package for OpenWRT on real hardware
.. it works in the VM topology, but test what's needed to get it working on
'pristine' source tree + router
** BIRD - dridd
Duplicate rid detection blows up if the router is connected to same
switch/hub using multiple interfaces (when it receives packets from itself)
* Done (12.11.+)
** Optimize memory usage
- there's ~300kb of static stuff that isn't really needed in the LSA/etc
.. but that's peanuts, 32MB router image ran out of memory when running
primitive topology(!).. by default ~40MB used. OMG :p
** Package hnet package for OpenWRT
- also have dependency on bird6-elsa, do all the relevant init scripts etc
=> ~plug-n-play
a problem, however, lies in the fact that enabling this will probably
imply disabling _lots_ of other things from being started
automatically.. perhaps the enable script can do that?
- provide big-ass warnings about this being bad for your system's security
as version #1 won't be compatible with using a firewall (.. sigh ..)
contents:
[/etc/bird4.conf - not needed? we auto-generate one anyway in the
bird4 handler]
/etc/bird6.conf
/etc/dhclient-exit-hooks
/etc/dhcp/dhcp/dhclient-exit-hooks.d/use-pd
/etc/dhcp/dhcp/dhclient-exit-hooks.d/use-v4
/sbin/dhclient-script
/usr/share/hnet/*.sh
/usr/share/lua/*.lua
/etc/init.d/hnet
(which fires up bird6-elsa, pm.lua)
** Duplicate lap's for v4
- boom2 log
iid=7 has two addresses, all 'valid'
10.164.106.0
cr: 06-11-2012 22:04:46 (asp)
rid: 3397908108
10.66.160.0
! seems to be the right onw
cr: 06-11-2012 22:04:52
rid?: 1401178559
[ this stuff was fixed in 9th commit, probably - there was a typo in the
duplicate detection at least, leaving multiple assigned ones.. and improved
on since, there's now a stress test too. and it still doesn't blow up,
which is nice. ]
* Done (5.11.+)
** Next-hop management in pm.lua
DHCPv6 case - the next-hop router _may_ change, for various reasons, and
now the internet connectivity stays down until DHCPv6 PD lease expires
.. provided by real RA support
** Real RA support
options:
a) use kernel
accept_ra 2 [ do RA accepting even when router ]
accept_ra_defrtr 1
accept_ra_pinfo 0 [ we don't really want normal address ]
and then..
- can get it from there either as part of in-Bird stuff
OR
+ using e.g. ip -6 route checking for default routes
- bit less effective, but much more robust?
! stuff needs to be enabled/disabled per-border detection, as otherwise
things break horribly (
.. as there's delay to this, we can use rdisc6 for _first approximation_
(and to speed up the initial part). Polling kernel will be painful :p
b) do it in userland
- listening to RA is easy
- NUD painful
** bugs
*** pd nh disappears at times at renew?
- the rdisc6 stuff should be more robust, or we should probe more actively
( the latter + correct state machine = win, in long term)
.. fixed by real RA use
*** dhcpd
- for some reason #4 box dropped dhcpv4 support
- configs look ok-ish
- but no response to e.g. DHCPv4
.. hmm.
eth0.2, eth0.3 same IPv4 subnet
ospf-lap={
{address="10.105.164.9/32", ifname="eth0.2", owner=true,
prefix="10.105.164.0/24"},
{ifname="eth0.2", owner=true, prefix="2001:470:e178:bd95::/64"},
{ifname="eth0.2", owner=true, prefix="2001:470:dd33:b0f9::/64"},
{ifname="eth0.2", owner=true, prefix="fcf7:7f30:29b2:6215::/64"},
{ifname="eth0.2", prefix="2001:470:e178:bdb1::/64"},
{address="10.174.208.51/32", ifname="eth0.2", prefix="10.174.208.0/24"},
{ifname="eth0.2", prefix="2001:470:dd33:b074::/64"},
{ifname="eth0.2", prefix="fcf7:7f30:29b2:7739::/64"},
{address="10.43.92.52/32", ifname="eth0.3", owner=true,
prefix="10.43.92.0/24"},
{ifname="eth0.3", owner=true, prefix="2001:470:e178:bd38::/64"},
{ifname="eth0.3", owner=true, prefix="2001:470:dd33:b07b::/64"},
{ifname="eth0.3", owner=true, prefix="fcf7:7f30:29b2:dda8::/64"},
{ifname="eth0.3", prefix="2001:470:e178:bdb1::/64"},
{address="10.174.208.49/32", ifname="eth0.3", prefix="10.174.208.0/24"},
{ifname="eth0.3", prefix="2001:470:dd33:b074::/64"},
{ifname="eth0.3", prefix="fcf7:7f30:29b2:7739::/64"},
{address="10.215.93.16/32", ifname="eth0.4", owner=true,
prefix="10.215.93.0/24"},
{ifname="eth0.4", owner=true, prefix="2001:470:e178:bd0a::/64"},
{ifname="eth0.4", owner=true, prefix="2001:470:dd33:b022::/64"},
{ifname="eth0.4", owner=true, prefix="fcf7:7f30:29b2:714a::/64"},
{address="10.135.129.54/32", ifname="eth1", prefix="10.135.129.0/24"},
{ifname="eth1", prefix="2001:470:e178:bdb2::/64"},
{ifname="eth1", prefix="2001:470:dd33:b03c::/64"},
{ifname="eth1", prefix="fcf7:7f30:29b2:5a2f::/64"},
{address="10.18.247.16/32", ifname="eth0.1", owner=true,
prefix="10.18.247.0/24"},
{ifname="eth0.1", owner=true, prefix="2001:470:e178:bd71::/64"},
{ifname="eth0.1", owner=true, prefix="2001:470:dd33:b089::/64"},
{ifname="eth0.1", owner=true, prefix="fcf7:7f30:29b2:de06::/64"}}
8: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
inet 10.174.208.51/24 brd 10.174.208.255 scope global eth0.2
9: eth0.3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
inet 10.174.208.49/24 brd 10.174.208.255 scope global eth0.3
! WTH are _two_ address'es doing out there?
! one owner, one not owner
- one relic from past but not cleaned up correctly?
.. let's compare it to what we have on another router
ospf-lap={
{address="10.174.208.52/32", ifname="eth0.2", prefix="10.174.208.0/24"},
{ifname="eth0.2", prefix="2001:470:dd33:b074::/64"},
{ifname="eth0.2", prefix="fcf7:7f30:29b2:7739::/64"},
{ifname="eth0.2", prefix="2001:470:e178:bdb1::/64"},
{address="10.132.137.43/32", ifname="eth0.2", owner=true,
prefix="10.132.137.0/24"},
{ifname="eth0.2", owner=true, prefix="2001:470:dd33:b09e::/64"},
{ifname="eth0.2", owner=true, prefix="fcf7:7f30:29b2:35d4::/64"},
{ifname="eth0.2", owner=true, prefix="2001:470:e178:bd27::/64"},
{address="10.3.175.60/32", ifname="eth0.3", owner=true,
prefix="10.3.175.0/24"},
{ifname="eth0.3", owner=true, prefix="2001:470:dd33:b036::/64"},
{ifname="eth0.3", owner=true, prefix="fcf7:7f30:29b2:a511::/64"},
{ifname="eth0.3", owner=true, prefix="2001:470:e178:bdc8::/64"},
{address="10.100.200.50/32", ifname="eth0.4", owner=true,
prefix="10.100.200.0/24"},
{ifname="eth0.4", owner=true, prefix="2001:470:dd33:b04c::/64"},
{ifname="eth0.4", owner=true, prefix="fcf7:7f30:29b2:ce3d::/64"},
{ifname="eth0.4", owner=true, prefix="2001:470:e178:bddd::/64"},
{address="10.18.247.12/32", ifname="eth1", prefix="10.18.247.0/24"},
{ifname="eth1", prefix="2001:470:dd33:b089::/64"},
{ifname="eth1", prefix="fcf7:7f30:29b2:de06::/64"},
{ifname="eth1", prefix="2001:470:e178:bd71::/64"},
{address="10.215.93.3/32", ifname="eth0.1", prefix="10.215.93.0/24"},
{ifname="eth0.1", prefix="2001:470:dd33:b022::/64"},
{ifname="eth0.1", prefix="fcf7:7f30:29b2:714a::/64"},
{ifname="eth0.1", prefix="2001:470:e178:bd0a::/64"}
}
! router 5 seems to have also bonus one
=> fixed ssloop timeout handling to be bit better (hopefully), and also
added assertion that we never punt this on to pm.lua again (things will
just blow up on elsa_pa skv export, if we find here again)
** should offer very, very short leases until we have DNS parameters?
** route to router (nh calc) still bugging
+ solution: just set up always subnet also on the ISP-facing side, and
route towards that using standard BIRD Nest API.. works, but not insanely
elegant.
* Done (29.10.+)
** Package lua-md5 for openwrt
it's prohibitively slow with sha1.. *sigh*
** skv gets to infinite loop at some point?
- or somehow gets same transaction multiple times
.. there was rather horrid bug in jsoncodec :p
** Convert to use ULA always? (and add option to disable it too)
- pa.disable_always_ula
** Why address assignments are not constant?
+ should make sure nothing uses non-hash-seeded randomness
.. as it turns out, we used rid as base, and in real world routers with
zero conf _start_ out with random rid => it's somewhat inferior to
starting with HWF-based one, as in that case the router starts with same
prefix regardless of what state it happens to be in..
[ do iid's stay constant? or should we use actually ifnames? hmm. ]
** Why some test timeouts
** Non-/8 divisible prefix length support
- not hard math, but should do it; also should avoid raw-binary (without
bit length) as datastore anywhere, as ascii+prefix length or
binary+prefix length are lossless data wise, but raw-binary isn't
** Write ~Pythonic key handling to mst. data structures
- requires ~Pythonia equality function
- API-wise, should look like current one
- except, accept tables and other arbitrary structures as keys and compare
them 'correctly' (now, has to be same table instance for it to work,
which is unfortunate)
** Improve DNS support
- provide _stateless_ DHCPv6 and RA DNS server + search domain information
! ISC DHCP P.O.S. does not do stateless stuff at all - needs some state to
work. Clearly not the option we want to support => at some point have to
write minimal DHCPv6 server (.. among other things. *sigh*)
.. and stateful stuff is horrible, e.g.
Interface eth1 matches multiple shared networks
(can only have only subnet per interface, it seems)
! rdnssd does not support search domain (even in it's latest
incarnation). even more stuff I could contirbute to, perhaps..
** Compile for Buffalo, get it working there
- write scripts (using Python telnetlib) to produce ~desired router config
from scratch
Plan B: Change OpenWRT installation s.t. luasocket is default, and so is
patches BIRD
~howto
.. need also iproute2 package ..
+ homenet-feed (feeds.conf add)
+ prefer it (scripts/feeds install -p homenet)
+ install bird6
=> by default included
- scripts
- fire up both bird6 + pm with valid config
- fire up ISC DHCPv6 PD client with appropriate script
=> zero-conf(!)
What's needed to get the getup on real Buffalo as opposed to OpenWRT?
+ image with binaries
+ ISC DHCP (v4, v6)
+ Babel
+ bird6-elsa
+ files/ with configuration
also the Lua stuff + shell script helpers
(these should move to a separate package at some point)
+ local_setup.sh which prepares ground
+ rc.local
** Why radvd doesn't stay up? Or does someone kill it?
- seems like it wasn't happy about nonexistent configs at least => making
sure we have valid config seems to have alleviated the problem a bit
- PD <> hnet integration is again bit questionable; we _really_ need NH
maintenance
! /var non-symlink = big issue on owrt, it seems..
** IPv4 support
What does it _mean_? RFC 1918 space allocation, pick _one_ random prefix,
NAT outbound stuff. Try to avoid detectable conflicts.
*** Who originates v4-ULA?
- whoever has highest combination of (configured, rid)
=> configured overrides rid, rid used as tie-breaker
- if not configured, ULA-like behavior
- try for unique-ish based on v4-upstream's (SHOULD)
[ can publish the upstream addresses to make the choice sensible ]
**** DIFFERENCE to ULA
- we want to have this setup regardless of existing v4 connectivity
- BUT we want to know about potential conflicts in the DHCP'd addresses
*** What payloads we need?
v4-ULA
- the internal address we use
v4-upstream (SHOULD)
- egress links' assigned addresses
(used to make ULA separate from them, if possible)
v4-ASP
- like v6 ASP
v4-AA
- assigned addresses (to the routers)
*** USP scheme
Just use 10.Y.X.0, or 192.168.X.0
Y = random number picked by whoever provides the route (v4-ULA message)
X = assigned subnet # (if someone has more than 255 networks in their home
running v4, oh well; we can alternatively use Y space also for X if that's
better model, but this one works with CGN that uses 10.* space, with 1/256
chance of failure .. )
*** Crazy idea 2:
Instead of having dedicated v4 payloads, use v6 ones!
/120 ASP
/108-114 USP
and ::ffff:ip base
Pro:
+ same data structure
+ same algorithms (for most part)
Con:
- have to deal with variable prefix width
- 3 types of USPs (now 'only' two, ULA and global-ish)
*** How we detect upstream connectivity? [if we want it dynamically anyway]
Simple - run DHCPv4 client _on each interface_, listen for anything that's
NOT from v4-ULA.
=> what's needed:
- DHCPv4 client per interface on box, which publishes results to skv pd-v4.IF
- slightly modified variant of PA alg
- PM needs to configure
- NAT rule
- DHCPv4 server per non-pd-v4.IF
*** Crazy idea 3
Routers need v4 addresses to function; we can allocate them using the same
'rid trumps' algorithm, from e.g. first /6 of the block (leaving the rest
for DHCPv4 - 64 routers, 192 hosts per subnet)
.. 'owner' responsible for running DHCPv4 server
.. could even sync DHCPv4 state across the 'cloud' for redundancy, but why
bother? DNS discovery?
** Make elsa.lua location configuration option
Hardcoding is bad, mmkay - and if not present, disable the whole thing
** Secondary demo features
~secondary - IPv4
- need to have IPv4 routing protocol (BIRD?)
- BIRD not necessarily optimal?
** IPv4 setup
pieces:
- dhclient with IPv4 _on interfaces with PD
=> potentially detect outside edges of the network
[ started manually by PM ]
[ or can be manually configured too, e.g. v4-iflist; pd interfaces are
just a default ]
[[ can be also statically configured ]]
- OSPFv3 changes (~pa.lua)
- v4-ext (external prefixes)
[ just toss 'em in JSON for the time being.. ]
! for the time being skipped
+ v4-usp (configured, prefix) combo => chosen from the router with highest
(configured, rid) tuple
[ can be probably normal USP with ~ULA-like behavior, with bit different
bit length, and extra constraint of it not being in v4-ext lists if not
manually configured? ]
! for the time being, no 'configured' flag
+ v4-asp - assigned from v4-usp
[ can be probably normal ASP, with different bit length ]
- v4-asa - assigned addresses on links to routers (rid-based duplicate
detection/elimination)
[ JSON contains list 'v4-asa' for a router ]
addresses have to be globally unique => which link they're attached on
doesn't matter (but usp-asp mechanism should result in the asp being only
on single switched network)
- local address assignment on interfaces (IPv4); based on OSPFv3 [ in PM ]
=> changes
+ pm* (v4 address assignment, dhclient running)
+ run dhclient for v4
+ elsa_pa (SKV export, changes to originated LSA)
+ pa (most of the changes)
+ ipv6s (v4-encoding stuff)
* Done (22.10.+)
** Race condition between DHCPv6 PD request, and RADVD setup for ULA
.. if RADVD is set up, we may get our _own_ address back
=> added temporary fix to ip-util, which will use -m option to deal with
that case, and filters own addresses out
(correct solution would be to do ND periodically, and offload the next hop
maintenance to pm.lua)
** Demo features?
+ DHCPv6 PD running on all interfaces
=> ~wan if receive something
+ DNS
+ learn from DHCPv6 PD
+ RA, stateless DHCPv6
- ULA all the time?
(MarkT's keen to test it; I'm still not sure..)
** Aggregate the updates
- _handle_ costly updates via 0-timeout in event loop in single big packets
[requires bit smarter handling code]
** Add DNS support
+ store them in OSPF?
+ provide out with RA (Linux doesn't really use, I suppose) and DHCPv6
stateless (trivial config file addition)
** PA alg - phase 1 - invoke only if necessary
pa:should_run() => call pa:run() only if needed
=> major CPU savings in the infra ;) (at least with logging enabled)
** Cleanup BIRD changes
+ works with, without lua? with ipv6, without ipv6?
** Minimize the BIRD changes (now there's still too many leftovers)
* Done (15.10.+)
** Fix 'flakiness'
~500 second+X interval when the connectivity goes down