|
From: Erik de B. - L. <Er...@Lo...> - 2003-08-24 23:36:10
|
Hi UML people, I've got an (remote) online test box on which I'm trying to get networking up and running. Since I've been intensly trying for weeks, because I really NEED it to work (and refuse to give up), I almost know every bit of documentation about UML networking, and TUN/TAP. Before I get nuts, I'd like someone else to have a secound look at what I'm doing (wrong)! Here's my current setup: - Host kernel: Linux gen4 2.4.21 #6 Sat Aug 23 23:24:58 CEST 2003 i686 AMD Athlon(tm) XP 1800+ AuthenticAMD GNU/Linux distro: gentoo: Gentoo Base System version 1.4.3.8p1 CONFIG_TUN=y CONFIG_NETLINK_DEV not set CONFIG_ETHERTAP not set ##I don't want to use ETHERTAP so NETLINK_DEV shouln't be necesairy either. Uplink: eth1 - User-mode OS: kernels I've tried it al with: Linux uml1 2.6.0-test3-bk5-1um #1 Sun Aug 17 23:12:03 EDT 2003 i686 unknown, both from kernels.usermodelinux.org if I recall correctly TAP shows in dmesg: Universal TUN/TAP device driver 1.5 My objective: To be able to ping a UML instance through TUN/TAP (and get response) on a public IP address from a remote connection, with or without bridging. I'm trying first without bridging, because when you bridge you I have to set my uplink to promisc before I get the bridge up again. If I just enter the commands my ssh connection will be down before I can get the bridge up. I could do it through a script, but that breaks when the connection is gone as well. It can be done, but I guess it's risky business when you don't have a second uplink. I'll have that back next week, along with a minicom-link, so untill then I'd like to try it without bridging. What I'm doing: I've manually preconfigured the device. I've also skipped this part to let the uml_net helper do it, but it seems to be exactly what uml_net does. <skipped> root# tunctl -u root -t tap0 # creates the device root# ifconfig tap0 213.123.123.180 netmask 255.255.255.255 up # I've also tried with mtu 1484 root# bash -c echo 1 > /proc/sys/net/ipv4/ip_forward root# route add -host 213.123.123.181 dev tap0 root# bash -c echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp root# arp -Ds 213.189.19.181 eth1 pub </skipped> The preconfigured device and the uml_net helperconfigured tap could be pinged by the host at the tap end (ping own tap device @ 213.189.19.180 works) If I do the above manually, regardless of whether I start up the UML, when I ping (or nmap or anything similar) the UML ip 213.123.123.181 I get: ping: sendmsg: Operation not permitted ping: sendmsg: Operation not permitted ##ctrl-C I also get this when the UML runs on the preconfigured device, or when it's running with the uml_net helper. Googling around tells me that I've got to have permissions on the suid-root /bin/ping, I do, I'm root and it's set setuid anyway. I couldn't find other leads to what this means and what causes it. It can be related to: arp on the host shows it has an incomlete HwAddress/MAC (see the command + output below). Below this you'll find A LOT OF EXTRA INFORMATION. Don't feel too much overloaded, because I only wanted to give all information that's related. Just read the bits of commands you'd issue to find the problem! Thank you (in advance) very much for any help, and (already) for your attention! Best regards, Erik http://www.BudgetDedicated.com/ ________________________EXTRA INFO________________________ ## <-- comments right of double 'sharps', don't confuse with CLI-prompt! root# linux \ ## i run UML with this: eth0=tuntap,[when not-skipping the above: tap0],,213.123.123.180 \ umid=uml1 con=null con0=fd:0,fd:1 mem=64M hostfs=/home/uml/uml1/host_fs/ \ ubd0=/home/uml/uml1/Debian-3.0r0.ext2.5GB \ ubd1=/home/uml/uml1/swap \ rootfs=ubd/0 devfs=mount root=ubd/0 ## both the 2.4.20 and the 2.6.0test3 kernel seem to boot normally, debian runs smoothly ##--------boot proces shows:---------- ##Netdevice 0 : TUN/TAP backend - IP = 213.189.19.180 ##divert: allocating divert_blk for eth0 login: root password: **** UML# ifconfig eth0 213.123.123.181 up UML# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface ## routing table seems to be empty UML# route add -host 213.189.19.181 eth0 UML# route add default gw 213.189.19.180 # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 213.189.19.181 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 213.189.19.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 213.189.19.180 0.0.0.0 UG 0 0 0 eth0 UML# ifconfig |grep HWaddr eth0 Link encap:Ethernet HWaddr FE:FD:D5:BD:13:B5 HOST# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 213.123.123.181 * 255.255.255.255 UH 0 0 0 tap0 213.123.123.0 * 255.255.255.0 U 0 0 0 eth1 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 loopback localhost 255.0.0.0 UG 0 0 0 lo default 213.123.123.3 0.0.0.0 UG 0 0 0 eth1 HOST# arp Address HWtype HWaddress Flags Mask Iface 213.189.19.183 (incomplete) tap-test 213.189.19.181 (incomplete) tap0 ## incomplete 213.189.19.181 ether 00:FF:87:44:62:75 CM eth1 ## i don't know this HW addres... can this be a problem? 213.189.19.3 ether 00:00:5E:00:01:21 C eth1 213.189.19.2 ether 00:02:85:0A:C4:80 C eth1 213.189.19.1 ether 00:02:85:0B:AF:40 C eth1 213.189.19.183 * * MP eth1 213.189.19.181 * * MP eth1 HOST# arping 213.189.19.181 -I eth1 ARPING 213.189.19.181 from 213.189.19.160 eth1 Unicast reply from 213.189.19.181 [00:00:5E:00:01:21] 0.933ms ##this is the eth1 MAC address, but I guess the problem's something else. ##etc. HOST# netstat -i #some extra info?! Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 0 0 0 0 0 0 0 0 BMPU eth1 1500 0 4165888 0 0 0 183913 0 0 0 BMRU ext0 1500 0 0 0 0 0 0 0 0 0 BMRU lo 16436 0 643 0 0 0 643 0 0 0 LRU tap0 1500 0 981 0 0 0 942 0 0 0 BMRU UML# arp -n Address HWtype HWaddress Flags Mask Iface 213.189.19.180 ether 00:FF:3B:CC:1B:6F C eth0 #this IS the correct MAC for tap0@HOST HOST# tcpdump -i tap0 ## Irregularly outputs packets with: arp who-has 213.189.19.181 tell 213.189.19.180 ## I'm doing nothing on host or UML. What else to investigate?! |