SUMMARY
------- This patch enhances networking support for the simulation under Linux. Includes updated support for Linux TUN/TAP, and the addition of support for Linux bridge devices. CHANGES ------- o Check to see if the d_txavail callback is present before calling it in the arp send code. This prevents a segfault when simulating the telnetd daemon with arp send enabled. o Adjust the simulation's netdriver_loop() so it will detect and respond to ARP requests. o Do not attempt to take the tap device's hardware address for use by the simulation. That hardware address belongs to the host end of the link, not the simulation end. Generate a randomized MAC address instead. o Do not assign an IP address to the interface on the host side of the TAP link. + Provide two modes: "host route" and "bridge". + In host route mode, maintain a host route that points any traffic for the simulation's IP address to the tap device. In this mode, so long as the simulation's IP is a free address in the same subnet as the host, no additional configuration will be required to talk to it from the host. Note that address changes are handled automatically if they follow the rule of if-down/set-address/if-up, which everything seems to. + In bridge mode, add the tap device to the specified bridge instance. See configs/sim/NETWORK-LINUX.txt for information and usage examples. This enables much more flexible configurations (with fewer headaches), such as running multiple simulations on a single host, all of which can access the network the host is connected to. o Refresh configurations in configs/sim where CONFIG_NET=y. They default to "host route" mode. o Add configs/sim/NETWORK-LINUX.txt CAVEATS ------- - The MAC address generation code is extremely simplistic, and does not check for potential conflicts on the network. Probably not an issue, but something to be aware of. - I was careful to leave it in a state where Cygwin/pcap should still work, but I don't have a Windows environment to test in. This should be checked. - I don't know if this was ever intended to work with OS X. I didn't even try to test it there. NOTES ----- - Was able to get telnetd working and simulate nsh over telnet, but only so long as listen backlogs were disabled. There appears to be a bug in the backlog code where sockets are being returned in SYN_RCVD state instead of waiting until they're ESTABLISHED; if you perform an immediate send after accepting the connection, it will confuse the stack and the send will hang; additionally, the connection will never reach ESTABLISHED state. Can be worked around by adding a sleep(1) after the accept in telnetd. I don't have the necessary knowledge of the IP stack to know what the correct fix is.
parent
6c852fae
Please register or sign in to comment