At 16.06.2007 22:35, [EMAIL PROTECTED] wrote:
>
> ip -f inet6 neigh show
> fe80::204:23ff:fec1:c435 dev eth0 lladdr 00:04:23:c1:c4:35 router STALE
>
> jetzt kommt das paket:
>
> 19:18:57.833551 00:04:23:c1:c4:35 > 33:33:00:00:00:01, ethertype IPv6
> (0x86dd), length 110: (hlim 255, next-header: ICMPv6 (58), length: 56)
> fe80::204:23ff:fec1:c435 > ff02::1: [icmp6 sum ok] ICMP6, router
> advertisement, length 56
> hop limit 64, Flags [other stateful], pref medium, router
> lifetime 1800s, reachable time 0s, retrans time 0s
> prefix info option (3), length 32 (4): 2001:638:902:200f::/64,
> Flags [onlink, auto], valid time 2592000s, pref. time 604800s
> 0x0000: 40c0 0027 8d00 0009 3a80 0000 0000 2001
> 0x0010: 0638 0902 200f 0000 0000 0000 0000
> source link-address option (1), length 8 (1): 00:04:23:c1:c4:00
> 0x0000: 0004 23c1 c400
>
> wenn ich das richtig interpretiere wird hier in der source link-address
> option die falsche MAC gesendet. nachdem das paket durch ist, steht auch
> wieder der falsche eintrag im cache:
>
> ip -f inet6 neigh show
> fe80::204:23ff:fec1:c435 dev eth0 lladdr 00:04:23:c1:c4:00 router STALE
Hab ich's nicht gleich richtig vermutet?! Im RA wird die falsche
LL-Adresse verbreitet, gemäß RFC übernimmt der Client diese gleich in
die neigh-Tabelle, um sich einen weiteren Lookup zu ersparen.
> das problem tritt allerdings nur bei vlan-interfaces auf. da scheint das
> quagga nicht 100%ig mit netbsd zusammenzuarbeiten.
Haben alle RA's 00 zum Schluß? Dann stimmt wohl was mit der Übernahme
nicht, schau mal in den Source-Code...
Viel Erfolg!
Servus,
Peter
--
Dr. Peter Bieringer http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D mailto:[EMAIL PROTECTED]
Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/
Xing/OpenBC http://www.xing.com/hp/Peter_Bieringer/
--
ipv6 mailing list
[email protected]
http://listserv.uni-muenster.de/mailman/listinfo/ipv6
