Re: [Bug 192174] Re: Allow binary dumping to stdout
Hi, thanks for following up. What i was looking for is a raw dump of the TCP stream without any byte or character substitution. In this way, I could pipe the tcpflow output to a decoder, in order to get a human readable display of a proprietary binary message format. Does that make sense? I don't (try to) use tcpflow for this any more, but i still feel strongly that it should support this mode of operation. Thanks, Rick On Dec 26, 2011 5:10 PM, Simson Garfinkel 192...@bugs.launchpad.net wrote: Hi. I've taken over the maintenance of tcpflow. The new version has support for IPv6 and VLANs. The next version will output in DFXML and be significantly faster and more scalable. I am happy to implement the binary output, but I do not understand its' purpose. What is the format of the binary output? What is the advantage of binary to XML? Regarding the issue of simultaneous outputs to the same file --- that can happen to the same file but not to stout. If it is useful to have output to the same file, I can implement locking. However there is no easy way to detect that multiple processes are outputting to the same file, so I will need to implement this as a flag to prevent overhead. Any thoughts? -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/192174 Title: Allow binary dumping to stdout To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tcpflow/+bug/192174/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/192174 Title: Allow binary dumping to stdout To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tcpflow/+bug/192174/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 65281] Re: [edgy] Failure trying to run: chroot /target dpkg ...
Hi, I hit this error using Ubuntu Server 9.10, install as minimal virtual machine (JeOS) I will attach the various debug logs. ** Attachment added: syslog.txt http://launchpadlibrarian.net/42518700/syslog.txt -- [edgy] Failure trying to run: chroot /target dpkg ... https://bugs.launchpad.net/bugs/65281 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 65281] Re: [edgy] Failure trying to run: chroot /target dpkg ...
** Attachment added: hardware-summary.txt http://launchpadlibrarian.net/42518748/hardware-summary.txt -- [edgy] Failure trying to run: chroot /target dpkg ... https://bugs.launchpad.net/bugs/65281 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 65281] Re: [edgy] Failure trying to run: chroot /target dpkg ...
** Attachment added: partman.txt http://launchpadlibrarian.net/42518768/partman.txt -- [edgy] Failure trying to run: chroot /target dpkg ... https://bugs.launchpad.net/bugs/65281 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 65281] Re: [edgy] Failure trying to run: chroot /target dpkg ...
I tried reinstalling but this time with guided partitioning, all-in-one partition. I did not hit this issue. Therefore, the issue is a result of the partitioning choices I had made. Either I made some illegal combination, or the installer is buggy. I suggest that the installer could detect some classes of illegal partitioning choices. -- [edgy] Failure trying to run: chroot /target dpkg ... https://bugs.launchpad.net/bugs/65281 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 192174] Re: Allow binary dumping to stdout
makes sense. I don't think I ever actually tested Matteo's patch.
I still support this feature and behavior.
- Rick
On Thu, Feb 25, 2010 at 7:55 AM, binary.koala
binary.ko...@gmail.comwrote:
there seems to be a slight logical mistake in Matteo's patch.
Unless it is a 'feature' to have '\n' after each packet the very last lines
of the patch should read:
code
- putchar('\n');
+ if(strip_nonprint)
+putchar('\n');
fflush(stdout);
/code
i.e. if(strip_nonprint) statement needs to be inverted.
--
Allow binary dumping to stdout
https://bugs.launchpad.net/bugs/192174
You received this bug notification because you are a direct subscriber
of the bug.
--
Allow binary dumping to stdout
https://bugs.launchpad.net/bugs/192174
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 192174] Re: Allow binary dumping to stdout
Did you take a look at what I did to get tcpflow to behave as desired? http://launchpadlibrarian.net/18406455/tcpflow_patch_readme.txt I am not much of a C hacker. Maybe it's better to start from scratch to get the desired behavior, rather than starting w/ Matteo's patch? - Rick On Thu, Feb 25, 2010 at 11:31 AM, binary.koala binary.ko...@gmail.comwrote: another thing, with Matteo's patch applied -B doesn't seem to output sequential (read consistent) streams. new stream is being printed as soon as it's put together regardless if another stream is being printed at that moment, which results in streams being mixed together... which defeats the whole purpose of tcpflow :() this, of course, doesn't happen if you save streams into files and then 'cat' them together. to reproduce (requires tcpflow patched with http://launchpadlibrarian.net/11992351/20_stdout-dump.diff): cd /tmp mkdir dump; cd dump # run two _parallel_ tcpflow processes in background sudo su tcpflow -i ethX 'port 80' tcpflow -i ethX -B ../stdout.dump # run two parallel downloads wget http://upload.wikimedia.org/wikipedia/commons/8/8a/Ptolemy_Cosmographia_Sarmatia%2BRha-river.jpg-O /dev/null wget http://upload.wikimedia.org/wikipedia/commons/0/09/Skeleton_of_boiled_woman.jpg-O /dev/null #when completed - stop tcpflow killall tcpflow cd .. now edit stdout.dump and remove two HTTP GET headers and compare it with appropriate dump file from the first tcpflow instance, e.g: hexdiff dump/remote.server.00080-local.ip.12345 stdout.dump somewhere in the middle of 'stdout.dump' you will notice new HTTP header injected in the middle of binary JPEG data. any ideas? -- Allow binary dumping to stdout https://bugs.launchpad.net/bugs/192174 You received this bug notification because you are a direct subscriber of the bug. -- Allow binary dumping to stdout https://bugs.launchpad.net/bugs/192174 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 192174] Re: Allow binary dumping to stdout
Danja, Ok, I never noticed the stream mixing bug. Or, hm, maybe I did -- I think i would get anomalous results every now and then. I didn't get a chance to really evaluate your analysis on that. And yes, I definitely like to pipe tcpflow to a binary decoder for doing traffic analysis. I haven't heard of tcpxtract. So I think we are definitely on the exact same page as to how we want tcpflow to behave. As far as starting from scratch, I mean starting from the latest tcpflow upstream source, before applying Matteo's or anyone else's patch. If that software contains your stream mixing bug, then obviously that will need to be worked out in any case. I take it you don't see Matteo's patch as introducing the stream mixing bug. In any case, I don't think I can help much with the actual development. But I can provide moral and technical support, as to demonstrating this is a valid use case, and doing testing, etc. - Rick On Thu, Feb 25, 2010 at 12:24 PM, binary.koala binary.ko...@gmail.comwrote: yes, i did look at your patch too, but i don't see how it would solve 'stream mixing' bug. i'm neither a C hacker, but desperately trying to marry tcpflow with foremost by using a pipe :) i did try tcpxtract, but it looks dated and suffers some problems of producing broken binaries. what do you mean by starting from scratch, new sets of patches or a completely new app? Danja -- Allow binary dumping to stdout https://bugs.launchpad.net/bugs/192174 You received this bug notification because you are a direct subscriber of the bug. -- Allow binary dumping to stdout https://bugs.launchpad.net/bugs/192174 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 192174] Re: Allow binary dumping to stdout
Matteo, I have been manually patching tcpflow for this feature on my own. My way was much cruder -- I have been using the -C flag -- removed the automatic invocation of -s and totally disabled the newlines by commenting out the putchar(\n) in tcpip.c I strongly support the addition of this flag and behavior to main package. Purely as an addendum, I have attached the README I created to remind me how to patch tcpflow on a new platform. Again, your diff looks much cleaner. Regards, Rick ** Attachment added: the patch described is dirtier than Matteo's, but it lays out the whole package maintenance process http://launchpadlibrarian.net/18406455/tcpflow_patch_readme.txt ** Description changed: Binary package hint: tcpflow This patch adds the ability to dump binary data to output, so it can be processed with another tool. eg. - tcpflow -b tcp port 80 |mytool + tcpflow -B tcp port 80 | mytool -- Allow binary dumping to stdout https://bugs.launchpad.net/bugs/192174 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 192174] Re: Allow binary dumping to stdout
I nominated this for release. I am fairly new to Launchpad, so my apologies if this was inappropriate. -- Allow binary dumping to stdout https://bugs.launchpad.net/bugs/192174 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 187383] Re: System monitor causes Xorg to consume 100% CPU
As stated before, the CPU consumption increases with window size. Also, this is primarily (only?) for the Resources tab. After further examination, the CPU utilization is much more sensitive to horizontal increases. Stretching the window vertically does not affect things too much. -- System monitor causes Xorg to consume 100% CPU https://bugs.launchpad.net/bugs/187383 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 187383] Re: System monitor causes Xorg to consume 100% CPU
System: Dual Opteron 246 (single core) 2GHz, 2GB ECC DRAM, ATi RAGE XL (onboard, crappy) graphics, 1280 x 1024 @ 60Hz OS: Hardy Beta install, fully updated as of today (4/5/2008) For me the CPU usage is dependent on the size of the System Monitor window. At its normal size, it consumes 0-20% of a single CPU. At, say, 1000 x 1000, it (well, Xorg) consumes 50+% of one and 100% of the other, maxing Xorg very unresponsive. xorg.conf paste below -- quite vanilla -- I haven't touched it Section InputDevice Identifier Generic Keyboard Driver kbd Option XkbRules xorg Option XkbModel pc105 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver vmmouse EndSection Section Device Identifier Configured Video Device EndSection Section Monitor Identifier Configured Monitor EndSection Section Screen Identifier Default Screen Monitor Configured Monitor Device Configured Video Device EndSection Section ServerLayout Identifier Default Layout Screen Default Screen EndSection ** Attachment added: Xorg.0.log http://launchpadlibrarian.net/13137384/Xorg.0.log -- System monitor causes Xorg to consume 100% CPU https://bugs.launchpad.net/bugs/187383 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
