On Monday 06 December 2004 20:23, Zoltan NAGY wrote: > Peder Chr. Nørgaard wrote: > >On Monday 06 December 2004 15:04, Zoltan NAGY wrote: > >>Hello! > >> > >>How can I give my uml it's on IPv6 address? > >>It might sound stupid, but all I can read about is ipv4... : > >The thing is, the answer is "same way as you give your host system an IPv6 > >address", which means that the answer depends more on what kind of distro > > you use for your guest root file system, than it depends on UML. > > hmm. That's great! :) > I've tried... Well, networking is just great, isn't it?
> I've created a tap0 device: > inefty:~# ifconfig tap0 > tap0 Link encap:Ethernet HWaddr 00:FF:01:C5:FB:CE > inet6 addr: 3ffe:2c03:90::10/128 Scope:Global > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:3582 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3638 errors:0 dropped:8 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:309576 (302.3 KiB) TX bytes:313372 (306.0 KiB) If you wish for assistance you must tell *how* you made the tap0 device, and how you configured it. And for this question, what branch of distro you use for host system. I find two abnormal details in your "ifconfig" output. First, the prefix is /128 - on my systems it is consistently /64 which corresponds to the relevant RFC - 2464. Second, it does not print a link-local address (one starting with fe80:). It should. > set the routing: > nefty:~# ip -6 route | grep tap0 > 3ffe:2c03:90::10 dev tap0 metric 1024 mtu 1500 advmss 1440 metric10 64 > 3ffe:2c03:90::11 dev tap0 metric 1024 mtu 1500 advmss 1440 metric10 64 Again: *how* do you set this routing? These are host routes - routes to individual IPv6 destinations. And the ...:11 destination has probably not self-originated - there must be *some* reason that it pops up in the routing table. > started uml using: > ./linux ubd0=tesztgep/root_fs_tesztgep con0=null,fd:2 con1=fd:0,fd:1 > eth0=tuntap,tap0 Oh, you are using tuntap device. I have no experience with that - I use always the switch daemon (eth0=daemon,....) It has the definite advantage that it for all practical purposes behave like a real ethernet (or switch) > configured eth0: > devbox:~# ifconfig eth0 up > dev_ip_addr - device not assigned an IP address > devbox:~# ifconfig eth0 add 3ffe:2c03:90::11 > SIOCSIFADDR: Cannot allocate memory > > and, wow, it fails! > But not always, it works sometimes.. (the guest is a 2.6.9-ac12-bb4 anyway) > > like now: > devbox login: root > Last login: Mon Dec 6 19:15:11 2004 on tty1 > Linux devbox 2.6.9-ac12-bb4 #1 Fri Dec 3 20:13:29 CET 2004 i686 GNU/Linux > devbox:~# ifconfig lo 127.0.0.1 > devbox:~# ifconfig eth0 up > dev_ip_addr - device not assigned an IP address > devbox:~# ifconfig eth0 add 3ffe:2c03:90::11/128 > devbox:~# route add -A inet6 2000::/3 dev eth0 > devbox:~# > > so, after that, I try to ping the other end of the tap iface: > > devbox:~# ping6 3ffe:2c03:90::10 > PING 3ffe:2c03:90::10(3ffe:2c03:90::10) 56 data bytes > From 3ffe:2c03:90::10 icmp_seq=1 Destination unreachable: Address > unreachable > From 3ffe:2c03:90::10 icmp_seq=2 Destination unreachable: Address > unreachable > and so on.. > > running tcpdump -ni tap0 on the host gives: > > 20:21:06.312699 3ffe:2c03:90::11 > ff02::1:ff00:10: icmp6: neighbor sol: > who has 3ffe:2c03:90::10 > 20:21:06.312759 3ffe:2c03:90::10 > 3ffe:2c03:90::11: icmp6: neighbor > adv: tgt is 3ffe:2c03:90::10 > 20:21:06.313009 3ffe:2c03:90::11 > 3ffe:2c03:90::10: icmp6: echo request > seq 1 > 20:21:07.310007 3ffe:2c03:90::11 > 3ffe:2c03:90::10: icmp6: echo request > seq 2 > 20:21:08.327416 3ffe:2c03:90::11 > 3ffe:2c03:90::10: icmp6: echo request > seq 3 > 20:21:09.312596 3ffe:2c03:90::10 > 3ffe:2c03:90::11: [|icmp6] > 20:21:09.312616 3ffe:2c03:90::10 > 3ffe:2c03:90::11: [|icmp6] > 20:21:09.312621 3ffe:2c03:90::10 > 3ffe:2c03:90::11: [|icmp6] > and so on.. > after I've pressed C-c on the guest, it prints: > > 20:21:14.400956 3ffe:2c03:90::11 > 3ffe:2c03:90::10: icmp6: echo request > seq 9 > 20:21:15.364553 3ffe:2c03:90::10 > ff02::1:ff00:11: icmp6: neighbor sol: > who has 3ffe:2c03:90::11 > 20:21:15.365860 3ffe:2c03:90::11 > 3ffe:2c03:90::10: icmp6: neighbor > adv: tgt is 3ffe:2c03:90::11 > 20:21:16.364210 3ffe:2c03:90::10 > ff02::1:ff00:11: icmp6: neighbor sol: > who has 3ffe:2c03:90::11 > 20:21:16.370380 3ffe:2c03:90::11 > 3ffe:2c03:90::10: icmp6: neighbor > adv: tgt is 3ffe:2c03:90::11 > 20:21:17.363873 3ffe:2c03:90::10 > ff02::1:ff00:11: icmp6: neighbor sol: > who has 3ffe:2c03:90::11 > 20:21:17.364060 3ffe:2c03:90::11 > 3ffe:2c03:90::10: icmp6: neighbor > adv: tgt is 3ffe:2c03:90::11 > and so on, like in an infinite loop.. > > any ideas? > It must be a routing mistake made by me, I suppose, but.. where? :) > Where does ff02::1:ff00:11: comes into play? That is perfectly normal. It is the "solicited-node multicast address" that *must* be the destination of an initial Neighbor Discovery PDU. See RFC 2461 for details. -- Peder Chr. Nørgaard e-mail: [EMAIL PROTECTED] Gefionsvej 19 spejder-e-mail: [EMAIL PROTECTED] DK-8230 Åbyhøj tel: +45 87 44 11 99 Denmark mob: +45 30 91 84 31 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ User-mode-linux-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
