Open hammadmazhar1 opened 6 years ago
What is the "(ipv4_address)" that you are using? If you use 127.0.0.1, you will be getting the local address inside the mahimahi container -- probably not what you want as this will not transit the emulated link.
From within any chain of nested mahimahi containers, the IP address of the "base" container (the normal one that your webserver is probably running in) will be stored in the MAHIMAHI_BASE environment variable. This will typically be an address like 10.64.0.1.
So if you are trying to reach a webserver that's running on your computer (in the normal namespace) from within a chain of mahimahi shells, you probably want to point the Web client to something like http://$MAHIMAHI_BASE/index.html
You can also use a public facing IP address of the machine and it will work fine too, as long as the webserver is listening on INADDR_ANY. Or you can access some webserver across the Internet.
The address is a public facing one. The experiment is orginally written to access the public facing address (not my codebase). The address can be pinged, but cannot be connected to. I assume I should not be able to access google.com or other webpages from within the link. I'll check and see if the page is accessible over the $MAHIMAHI_BASE address.
The server needs to be listening on INADDR_ANY (or "0") for a client to be able to reach it over multiple interfaces. If the server is only listening on localhost or on a particular public-facing interface, clients will have trouble trying to reach it from a different interface (in this case, from over the emulated mahimahi link).
The server is started outside the link shell and is configured to listen on all interfaces (the default configuration for Apache 2.X). I tried accessing the server using $MAHIMAHI_BASE both in the link shell and outside. I was not able to access it within the linkshell but can access it outside the link shell
As a further test, I also tried to use the example mm-webrecord command. This also did not lead to completion as the hostname (www.nytimes.com) could not be resolved.
mm-webrecord /tmp/nytimes chromium-browser --ignore-certificate-errors --user-data-dir=/tmp/nonexistent$(date +%s%N) www.nytimes.com
There is something wrong with the configuration of your machine (perhaps a firewall?) if network programs within the mm-delay container are not able to reach processes listening on INADDR_ANY outside the container.
Could you please try:
Running the regression test that comes with the mahimahi source code. You can either run "make installcheck" inside a source checkout, or just run the script at https://github.com/ravinet/mahimahi/blob/master/src/tests/packetshell-test . It should report packetshell-test PASSED
.
Getting a fresh Debian or Ubuntu machine (e.g. an Amazon EC-2 VM) and installing the mahimahi package and trying from there.
Letting us know if you have any unusual firewall configuration that might be stopping processes inside the container (from 100.64.0.2) from reaching daemons listening on your computer.
I have run the regression test, which passed. I have also checked the firewall configuration which is the default configuration.
Ok, can you please try #2 as well? Re #3, I'm not sure what you mean by the firewall configuration being "the default configuration" -- what did you check and what did it say?
In the meantime, can you please try this simple test?
nc -v -l -p 8080 & mm-delay 20 bash -c 'sleep 1; echo Hello | nc -N $MAHIMAHI_BASE 8080'
On a fresh Ubuntu machine 16.04 LTS machine, it will result in output like this:
[2] 30473
Listening on [0.0.0.0] (family 0, port 8080)
Connection from 100.64.0.2 44566 received!
Hello
[2]- Done nc -v -l -p 8080
If you don't see the "Connection... received" or the "Hello", something is wrong.
And to be clear, processes within the mm-delay container are supposed to be able to access the Internet (including a site like google.com) as well as the normal container on the same computer (as $MAHIMAHI_BASE).
I decided to run the experiment on another system, it seems to work on that one. I tested the nc command on the previous system, and it did not complete. As for the firewall, I looked at the rules setup by iptables by using the command
iptables -L
which listed:
I assume these are the default configurations.
Hi @keithw , I am also facing the similar problem as @hammadmazhar1 . I can't load any webpage from the replay shell (telling site can't be reached). Although the packetshell-test passed with rtt_min 212.854 ms but while trying your (@keithw ) next one,
_nc -v -l -p 8080 & mm-delay 20 bash -c 'sleep 1; echo Hello | nc -N $MAHIMAHI_BASE 8080' Showing the following error [2] 15388 Listening on [0.0.0.0] (family 0, port 8089) nc: invalid option -- 'N'.
I guess it might be -n and after modifying the testcase to this _nc -v -l -p 8099 & mm-delay 20 bash -c 'sleep 1; echo -n "Hello" | nc $MAHIMAHIBASE 8099' I tried again but this is the current output of mine
_[4] 16015
Listening on [0.0.0.0] (family 0, port 8099)
Died on std::runtime_error: bash -c sleep 1; echo -n "Hello" | nc $MAHIMAHI_BASE 8099': process exited with failure status 1 Died on std::runtime_error:
packetshell': process exited with failure status 1_
Can anyone please help why this test giving this output? and how to resolve the problem of not loading webpage from linkshell?
Hello -- I think both of you will need to look at and possibly correct your firewall settings.
@spaul13, the nc -N
option is supported by what Ubuntu calls the netcat-openbsd
package. (This is the default version installed by, e.g., the ubuntu-minimal
meta-package.) Before we get to netcat, can you ping $MAHIMAHI_BASE from inside the container?
@hammadmazhar1, I'm not sure it's a good assumption that those are default settings. You seem to be using the 'ufw' firewall, and I think it may be blocking your connections. You might try with blank iptables (or on a fresh VM) and see if you can replicate the problem.
hey @keithw @hammadmazhar1 @spaul13 , I was also trying to use linkshell as part of an experiment and am facing similar problems.
When I run nc -v -l -p 8080 & mm-delay 20 bash -c 'sleep 1; echo Hello | nc -N $MAHIMAHI_BASE 8080'
, I get the correct output:
[1] 17400 Listening on [0.0.0.0] (family 0, port 8080) Connection from 100.64.0.2 43224 received! Hello [1]+ Done nc -v -l -p 8080
However, if I try wget google.com
from within the link shell, it shows connection refused. Similar is with wget to the localhost.
Could It be because I am behind a proxy server? How should I work around this issue?
Also, If I run my web server from within the link shell, and try to access $MAHIMAHI_BASE:9596/index.html from the browser, It fails and is unable to connect. (server configured to listen on port 9596)
@hammadmazhar1 I am also facing a similar problem. Is your problem resolved?
I an using mahimahi link and delay as part of a experiment to measure video streaming performance. Before I run the experiment, I try to see if I can access a locally hosted page over mahimahi using wget. I am using a basic trace file to simulate 12 Mbps of downlink/uplink bandwidth with 80 ms RTT. I first run the following command.
mm_delay
40 mm-link 12mbps 12mbps` This gives me the link shell. I now try to access the locally hosted webpage by using: 'wget (ipv4_address)/index.html' The connection fails after 3 tries. The same page is accessible easily outside of the linkshell.I am using mahimahi version 0.98+667-0ppa-ubuntu16.04.1