Blaisorblade <[EMAIL PROTECTED]> writes: > Guess probably not. The only problem may be if you used the > automatic uml_net setup and it does the wrong thing for your > special case.
Yeah, you guessed right. I just figured it out--thanks for your help! I set up the tap devices in advace manually and don't use the uml_net helper, so the problem did not lie there. > tcpdump on the host or on the guest? You must first check at > which point they get lost... doesn't see them routed up > correctly? You should check on the kernel logs if uml_net gave > a correct command to setup proxy ARP, and/or if you gave > correct commands if you did the thing yourself... Yeah, I'm not using proxy-arp and instead bridging the uml interfaces directly to the outside world. I guess having the ISP give me two separate blocks of IP addresses in different subnets is pretty irritating, but oh well. I suspect they're on different VLANs, but I don't have 802.1q support in my host kernel. A project for another day, I suppose. > From what you describe I cannot exclude that you bridged > together two different subnets, which is like having two > different subnets connected to the same hub. It's unusual, > while I cannot see specifically any reason for which it > shouldn't work, at least for a bridge in the simplest sense... Yes, I assumed it would work, but something odd is going on with that configuration. What ended up fixing it was the following: 1) Configure the first IP address in the new block as an alias on the bridge interface. (the primary address is from the original subnet.) 2) Enable IP forwarding on the host. 3) Allow traffic in the FORWARD iptables chain. Now, it's not the way I want it, since the traffic is not being bridged straight through, but it'll have to do for now. Clearly this is just my misunderstanding due to not really knowing a lot about L2 issues. It seems as though the linux virtual bridge code was not allowing ports to "connect" that were from a mismatched subnet. Sniffing on the main interface showed the arp requests going out eth0 and never getting to the interface on the other end of the TAP device--as soon as the bridge was configured with an IP in that second subnet, the arps were broadcast to all connected ports. >From there, I still needed to route the traffic through the host, which I still don't quite understand, but at least it's working. Thanks for the hints! :) -majere ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ User-mode-linux-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
