I am trying to do an assignment (from another univ's coursepage) which has a line in the starter code (Python with mininet) as
os.system("rmmod tcp_probe; modprobe tcp_probe full=1")
Popen("cat /proc/net/tcpprobe > %s" % (outfile), shell=True)
which gives an error saying that tcp_probe has been disabled.
I found out by googling that tcp_probe has been deprecated in the linux kernel. However it just asks me to 'do the same using ftrace'. I have tried searching online but could not find out how to use ftrace to achieve the same.
Any help is appreciated.
tldr;
Unfortunately, I could not find any way to get TCP tracepoints to work in Mininet, which is what ftrace would uses. The reason for this is that the mininet's /sys/kern/debug directory is empty, i.e., tracing cannot be enabled.
Options:
1. Using mininet-tracing (not recommended)
There probably is a way to get the kernel to include this, or you could use https://github.com/mininet/mininet-tracing which might get you what you need, but I have seen reports that it is slow, and has been updated 9 years ago...
2. Writing a new kernel module (I have tested this and it works)
What I found as a solution instead, was to force printing for the TCP I had in mind and then take a look at the results that way. In order to enable this, you would essentially need to extend some of TCP's behaviour and (quite possibly) reuse the TCP module you have in mind. And create a new kernel module.
Here I have provided an example that you can use. It logs socket information on each ACK. I also included a Makefile and a script to load/unload the kernel module. After you enable the module and let some traffic flow (assuming you are on a debian-based linux) you should be able to find the logs of your TCP in /var/log/kern.log.
Note:
This is a hacky way around the issue, but was good enough for my needs, and hopefully can help someone else too.
Related
As you may assume I need a little assistance here.
I have four routers (TP-Link WDR3600) that I need to use to create an Ad-Hoc network. Currently I am only dealing with two of the four routers for simplicity. All of the routers have OpenWRT Chaos Calmer 15.05 OS installed on them and all of them are running the OLSR routing protocol. My question is super simple but the answer eludes me and I would love some direction on the matter.
How do I get these two (and eventually four) routers to talk to each other using HNA (Host and Network Association) and the setup specified above?
Edit: they need to be connected to each other wirelessly too. End edit.
I have followed this specific guide to the T but as soon as it gets to "HOW TO Step 4" the guide breaks down in terms of application because the file they point to (/etc/olsrd.conf) does not exist in my setup. When continuing anyway and running "olsrd start" it spits out: Notice how it says "Could not find specific config file /etc/olsrd/olsrd.conf" and how that differs from earlier when it asked me to modify "/etc/olsrd.conf"
In addition, the folder "/etc/olsrd" also does not exist in case you are wondering. I'm at a loss regarding this. Does anybody have any input on the matter? I'm certain that I'm missing something simple.
Thanks in advance.
I had to create /etc/olsrd.conf using the template provided and uncomment the third line of /etc/config/olsrd. I would also recommend installing olsrd-mod-httpinfo using opkg like he recommends.
One thing I noticed is that he never specifies giving the wireless interface (wlan0 in my case) an IP address to communicate with the mesh. Since I believe that is required, I had to use LuCI to give the interface an IP. I think I have my setup working but I am trying to get my new OpenWRT node to communicate with my previous DD-WRT nodes right now. Might just have to change them all to OpenWRT since it offers more "customization" due to it's bare-bones type configuration.
Can you try to run :
/usr/sbin/olsrd -d -f /etc/olsrd.conf
I'm trying to do basically this in Go:
netstat -an | grep 2375 -c
I need to count the number of connections to the Docker daemon in my regression test for a connection leak bug. However, because I run this in multiple places in different OS (local dev box, CI, etc), I cannot rely on the "netstat" tool, so I wonder how can I do this in a more programmatic way in Go?
I looked around the net package and could not find anything that would help. There are some libraries that basically replace netstat:
https://github.com/drael/GOnetstat
https://github.com/dominikh/netstat-nat
But they are not cross-platform compliant (Mac and *nix). Any idea how can I achieve this?
In linux this info is exposed in the /proc filesystem.
Use os.Getpid and query the info in /proc/<pid>/fd. Most likely a simple count is good here, if you need more see the proc man page.
Cross platform compatibility for this kind of thing is going to be roll your own, as the ways of identifying open fd's for a process are very per platform. If you simply need to compile, and pass some tests for this on non linux platforms you can use Go's per platform support to make this a no-op on other platforms, or implement an appropriate solution.
I have an assignment to implement simple fault-tolerance in an OpenMPI application. The problem we are having is that, despite setting the MPI error handling to MPI_ERRORS_RETURN, when one of our nodes is unplugged from the cluster we get the following error on the next MPI_ call after a lengthy hang:
[btl_tcp_endpoint.c:655:mca_btl_tcp_endpoint_complete_connect] connect() failed: Connection timed out (110)
My take from this is that it is not possible to continue processing on all other nodes when one node drops from the network with OpenMPI. Can anyone confirm this for me, or point me in a direction for preventing the btl_tcp_endpoint error?
We are using OpenMPI version 1.6.5.
The MPI_ERRORS_RETURN code paths are not well tested (and probably not well implemented) in Open MPI. They simply haven't been a priority, so we've never really done much work in this area.
Sorry.
As someone who is very new to the opensource PBX projects like Asterisk and FreeSWITCH, I am grappling with some information overload. Have read the basic FreeSWITCH docs on Wiki, but still have few questions. Since I am not very familiar with the terminology, I will try to use close approximations.
Trying to create a small/minimalistic build of FreeSWITCH, that needs to run on an rather old laptop (Celeron 1GHz, 512MB RAM, 20GB HDD, already running Debian "Wheezy"), and set it up as a 6-port GSM-SIP/Jabber gateway. So, by "small" and "minimalistic", I mean one which doesn't have modules/optional-software that is not absolutely necessary (e.g. no need for IVR announcements, or Skype integration) -- to keep memory footprint smallest, and occupy less hard-disk real-estate.
The rough idea is to have 6 GSM ports (via 'GSM-open module', similar to chan_dongle) towards public telephony network, and about 60 SIP extension, and support upto 6 calls involving GSM ports, and about 6 SIP-SIP calls (intra PBX), on this setup. I have read that the CPU overhead of GSMopen module is pretty low, so I am guessing this is possible.
Can someone confirm this to be a realistic goal?
What might be the minimum set of modules to select for minimalistic build?
For modules not chosen during initial build, can those be added later? If so, would it require me to rebuild FreeSWITCH completely, only the modules, or that everything would be built, but only configuration changes would be required to ensure that modules are loaded, and configure?
Is there any rough estimate of what might be the maximum call-rate that could be supported in such a configuration? For SIP-SIP calls? Given the underpowered processor, and little RAM (as per modern standards), I am guessing that both shall be bottlenecks, but adding RAM might still be possible (even if costly and difficult).
I have read that "hooks" can be created using Lua/Python/Java etc.. However if someone share share few examples of what-all is possible using such hooks, it would make the concept clearer. Can one hope to write an application like "missed call log" or "redirect on no answer" using these hooks?
Can someone confirm this to be a realistic goal?
Yes, this is quite realistic. You need to target as little as possible transcoding, because that's where CPU resources are needed. But even with a 1Ghz Celeron, 6 transcoded sessions seem quite realistic. But it needs testing :)
What might be the minimum set of modules to select for minimalistic build?
Just start with the default list of modules, and add gsmopen (I have no experience with gsm gateways, can't help with that part). The memory footprint is pretty low, and you may need some of those modules later.
For modules not chosen during initial build, can those be added later?
as far as I remember, Wiki describes this process. You edit modules.conf and make the specific module.
Is there any rough estimate of what might be the maximum call-rate that could be supported in such a configuration? For SIP-SIP calls? Given the underpowered processor, and little RAM (as per modern standards), I am guessing that both shall be bottlenecks, but adding RAM might still be possible (even if costly and difficult).
It really depends on complexity of your dialplan. Each context consists of a number of conditions, which are doing regexp match on channel variables. So, the more complex your dialplan is, the less CPS you get. But for a 6-channel gateway, I don't see this a problem. GSM network will be much slower than your box :)
I have read that "hooks" can be created using Lua/Python/Java etc.. However if someone share share few examples of what-all is possible using such hooks, it would make the concept clearer. Can one hope to write an application like "missed call log" or "redirect on no answer" using these hooks?
You can control every aspect of FreeSWITCH behavior with FreeSWITCH. There are even examples when the complete dialplan is re-implemented by an external program (Kazoo does that).
The simplest mode of operation is when your Lua/JS/Perl/Python script is launched from within the dialplan: then it receives a "session" object, and you can do whatever you want with the call: play sounds, bridge, forward, make a new call and bridge them together, and so on. Here in my blog there's a little practical example.
Then, you can build an external application which connects to the FS socket and monitors the events and performs actions on active calls.
Also, it can be done in the opposite direction: you run a server, and FS connects to it with its socket library.
Also, you can have an HTTP service which delivers pieces of XML configuration to FreeSWITCH, and it requests those on every call (this would be the most CPU-intensive application). This way, you can feed FS from some internal database, and build fault-tolerant systems.
I hope this helps :)
You can also find me in skype if needed.
FreeSWITCH is not really memory-hungry, and you can simply start with the default set of modules (the best is to use the prebuilt Debian packages). For example, on my 64bit machine, the FreeSWIITH process occupies only 35MB of memory.
freeswitch#vx03:~$ uname -a
Linux vx03 2.6.32-5-xen-amd64 #1 SMP Thu Nov 3 05:42:31 UTC 2011 x86_64 GNU/Linux
freeswitch#vx03:~$ ps -p 11873 v
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
11873 ? S<l 10:29 0 0 258136 36852 2.3 /opt/freeswitch/bin/freeswitch -nc -rp -nonat -u freeswitch -g freeswitch
I will go through the rest of your questions later today
When I start a process in background in a terminal and some how if terminal gets closed then we can not interact that process any more. I am not sure but I think process also get killed. Can any one please tell me how can I detach that process from my terminal. So even if I close terminal then I can interact with same process in new terminal ?
I am new to unix so your extra information will help me.
The command you're looking for is disown.
disown <processid>
This is as close as you can get to a nohup. It detaches the process from the current login and allows it to continue running. Thanks David Korn!
http://www2.research.att.com/~gsf/man/man1/disown.html
and I just found reptyr which lets you reparent a disowned process.
https://github.com/nelhage/reptyr
It's already in the packages for ubuntu.
BUT if you haven't started the process yet and you're planning on doing this in the future then the way to go is screen and tmux. I prefer screen.
You might also consider the screen command. It has the "restore my session" functionality. Admittedly I have never used it, and forgot about it.
Starting the process as a daemon, or with nohup might not do everything you want, in terms of re-capturing stdout/stdin.
There's a bunch of examples on the web. On google try, "unix screen command" and "unix screen tutorial":
http://www.thegeekstuff.com/2010/07/screen-command-examples/
GNU Screen: an introduction and beginner's tutorial
First google result for "UNIX demonizing a process":
See the daemon(3) manpage for a short overview. The main thing of daemonizing
is going into the background without quiting or holding anything up. A list of
things a process can do to achieve this:
fork()
setsid()
close/redirect stdin/stdout/stderr to /dev/null, and/or ignore SIGHUP/SIGPIPE.
chdir() to /.
If started as a root process, you also want to do the things you need to be root
for first, and then drop privileges. That is, change effective user to the "daemon"
user or "nobody" with setuid()/setgid(). If you can't drop all privileges and need
root access sometimes, use seteuid() to temporary drop it when not needed.
If you're forking a daemon then also setup child handlers and, if calling exec,
set the close on exec flags on all file descriptors your children won't need.
And here's a HOWTO on creating Unix daemons: http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html
'Interact with' can mean a couple of things.
The reason why a program, started at the command-line, exits when the terminal ends, is because the shell, when it exits, sends that process a HUP signal (see documentation for kill(1) for some introduction; HUP, by the way, is short for 'hang up', and originally indicated that the user had hung up the modem/telephone). The default response to a HUP signal is that a process is terminated – that is, the invoked program exits.
The details are slightly more fiddly, but this is the general intuition.
The nohup command tells the shell to start the program, and to do so in a way that this HUP signal is ignored. That is, the program keeps going after the invoking terminal exits.
You can still interact with this program by sending it signals (see kill(1) again), but this is a very limited sort of interaction, and depends on your program being written to do sensible things when it receives those signals (signals USR1 and USR2 are useful things to trap, if you're into that sort of thing). Alternatively, you can interact via named pipes, or semaphores, or other bits of inter-process communication (IPC). That gets fiddly pretty quickly.
I suspect what you're after, though, is being able to reattach a terminal to the process. That's a rather more complicated process, and applications like screen do suitably complicated things behind the scenes to make that happen.
The nohup thing is a sort of quick-and-dirty daemonisation. The daemon(3) function does the daemonisation 'properly', doing various bits of tidy-up as described in YePhIcK's answer, to comprehensively break the link with the process/terminal that invoked it. You can interact with that daemonised process with the same IPC tools as above, but not straightforwardly with a terminal.