Menu
▾
▴
ffpf-devel — development related issues
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(1) |
Feb
(31) |
Mar
(22) |
Apr
(31) |
May
(8) |
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(3) |
Nov
(10) |
Dec
(7) |
| 2006 |
Jan
(9) |
Feb
(7) |
Mar
(8) |
Apr
|
May
(17) |
Jun
(11) |
Jul
(4) |
Aug
(2) |
Sep
(1) |
Oct
(7) |
Nov
(3) |
Dec
(14) |
| 2007 |
Jan
(12) |
Feb
(38) |
Mar
(100) |
Apr
(36) |
May
(41) |
Jun
(35) |
Jul
(37) |
Aug
(38) |
Sep
(5) |
Oct
(3) |
Nov
(29) |
Dec
(17) |
| 2008 |
Jan
(13) |
Feb
(5) |
Mar
(13) |
Apr
(11) |
May
|
Jun
|
Jul
(1) |
Aug
(19) |
Sep
(28) |
Oct
(1) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(8) |
Dec
|
| 2010 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(23) |
May
|
Jun
(8) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Willem de B. <wil...@gm...> - 2012-04-13 20:24:50
|
Replied off-line before it was posted on here. I won't repeat myself :) 2012/4/12 Yasser Zamani <yas...@li...> > Dear Experts, > > I'm Yasser and new interested in Linux; Sorry if I disturb you but just a > few advice please. > > I selected Streamline for my first job with Linux and also I presented it > for my 'Advanced OS' course at Shahid Beheshti University, Iran. Just one > thing remaining is simulating and proofing the Streamline usage benefits > which I should present in only coming 8 days.[image: Sad smile] > > I successfully downloaded the VMWare image and built Streamline (both > kernel and user space is running). Then, in host machine, I wrote a small > simple C# application which transmits random fixed-length UDP packages to > the guest virtual machine (ubuntu-sl) as more as it can. I successfully ran > ./lib/slcli then interestingly I could divide this stream to two equal > streams by Streamline[image: Open-mouth smile][image: Nerd smile]. One > stream for logging and another for the main consumer (virtual consumer[image: > Winking smile]). > > Now, I would like to compare throughput when Streamline is running and > when is not. I'm not sure if I have to write code in Linux kernel or > Streamline itself to do this but my current idea is: > > 1. Stopping Streamline by: ./scripts/streamline stop > 2. Dividing the main incoming stream to two equal streams and sending them > to two files. (I DON'T KNOW HOW TO DO THIS IN LINUX (rather than > Streamline)). > 3. Doing step#2 for two minutes. > 4. Saving two files with names not_sl_1.txt and not_sl_2.txt. > 5. Starting Streamline by: ./scripts/streamline start > 6. Dividing the main incoming stream to two equal streams and sending them > to two files. (IS SIMPLE WITH STREAMLINE[image: Winking smile]) > 7. Doing step#6 for two minutes. > 8. Saving two files with names with_sl_1.txt and with_sl_2.txt. > 9. Moving the 4 result files to host machine and analysing them by C# to > draw the throughput (logged-packages per second) comparison graphs. > > My main problems are: > > 1. As my limited time, Is my current idea suitable to presenting proof of > Streamline results? > 2. If so, How to divide the stream to two equal streams forwarding to two > files in Linux (like Streamline)? > 3. And also finally, how to define a filter that only log the date and > time (ticks) of received UDP package? > > If I knew these three ones then I'll get the full score for my 'Advanced > OS' course at Shahid Beheshti University, Iran. So please advice me some > small idea then I'll get the full idea myself[image: Nerd smile] > > I'll also share my result at mailing list and if they were interesting > then they can be uploaded to netstreamline.org if you experts wished. > > Your Sincerely, > Yasser. > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Ffpf-devel mailing list > Ffp...@li... > https://lists.sourceforge.net/lists/listinfo/ffpf-devel > > |
|
From: Willem de B. <wil...@gm...> - 2012-04-13 20:20:32
|
udpsock sets up a UDP socket, so first of all, you will not see any full packets, just the payload > "insert udpsock 11000 | inspect" fails. This opens a socket in listening mode. I'm surprised that it fails. > "insert udpsock "192.168.52.129:11000" | inspect" does not fail BUT does not This opens a socket and calls connect on the specified ip:port. Since this is UDP, no actual handshake is performed in connect. Any data that is sent to this filter, should be forwarded to the given destination. > "insert udpsock 5050 | inspect" succeeds and also inspect my traffic. So it works for one port, but not another? I have no idea so far. |
|
From: Yasser Z. <yas...@li...> - 2012-04-13 12:57:16
|
Hi experts, I have a small simple UDP traffic generator which transmits current DataTime in host OS to guest Virtual Machine's OS. When I transmits to port 11000:"insert udpsock 11000 | inspect" fails."insert udpsock "192.168.52.129:11000" | inspect" does not fail BUT does not inspect my traffic also. (192.168.52.129 is guest VM IP)Outside of Streamline in linux, "cp -l -u -p 11000" inspects my traffic successfully.When I transmits to port 5050:"insert udpsock 5050 | inspect" succeeds and also inspect my traffic."insert udpsock "192.168.52.129:5050" | inspect" succeeds too but does not inspect my traffic at all.Outside of Streamline in linux, "cp -l -u -p 5050" inspects my traffic successfully.Any idea? Thanks in advance! |
|
From: Yasser Z. <yas...@li...> - 2012-04-12 15:46:57
|
Dear Experts, I'm Yasser and new interested in Linux; Sorry if I disturb you but just a few advice please. I selected Streamline for my first job with Linux and also I presented it for my 'Advanced OS' course at Shahid Beheshti University, Iran. Just one thing remaining is simulating and proofing the Streamline usage benefits which I should present in only coming 8 days. I successfully downloaded the VMWare image and built Streamline (both kernel and user space is running). Then, in host machine, I wrote a small simple C# application which transmits random fixed-length UDP packages to the guest virtual machine (ubuntu-sl) as more as it can. I successfully ran ./lib/slcli then interestingly I could divide this stream to two equal streams by Streamline. One stream for logging and another for the main consumer (virtual consumer). Now, I would like to compare throughput when Streamline is running and when is not. I'm not sure if I have to write code in Linux kernel or Streamline itself to do this but my current idea is: 1. Stopping Streamline by: ./scripts/streamline stop 2. Dividing the main incoming stream to two equal streams and sending them to two files. (I DON'T KNOW HOW TO DO THIS IN LINUX (rather than Streamline)). 3. Doing step#2 for two minutes. 4. Saving two files with names not_sl_1.txt and not_sl_2.txt. 5. Starting Streamline by: ./scripts/streamline start 6. Dividing the main incoming stream to two equal streams and sending them to two files. (IS SIMPLE WITH STREAMLINE) 7. Doing step#6 for two minutes. 8. Saving two files with names with_sl_1.txt and with_sl_2.txt. 9. Moving the 4 result files to host machine and analysing them by C# to draw the throughput (logged-packages per second) comparison graphs. My main problems are: 1. As my limited time, Is my current idea suitable to presenting proof of Streamline results? 2. If so, How to divide the stream to two equal streams forwarding to two files in Linux (like Streamline)? 3. And also finally, how to define a filter that only log the date and time (ticks) of received UDP package? If I knew these three ones then I'll get the full score for my 'Advanced OS' course at Shahid Beheshti University, Iran. So please advice me some small idea then I'll get the full idea myself I'll also share my result at mailing list and if they were interesting then they can be uploaded to netstreamline.org if you experts wished. Your Sincerely, Yasser. |
|
From: Willem de B. <wil...@gm...> - 2011-07-20 17:19:10
|
> Your example would work for one interface but what about two or more > interfaces (e.g. ether0, 1) exporting to the same new buffer? > > I believe I can not do: > > "(ether0, export, name="user_intf")" > and separately: > "(ether1, export, name="user_intf")" > ? Correct. Your approach of having both write to a shared (accept) filter is the right solution here |
|
From: john s. <wha...@ya...> - 2011-07-20 17:10:33
|
Thank you for your (always) quick help, Willem.
Your example would work for one interface but what about two or more interfaces (e.g. ether0, 1) exporting to the same new buffer?
I believe I can not do:
"(ether0, export, name="user_intf")"
and separately:
"(ether1, export, name="user_intf")"
?
thanks,
John
From: Willem de Bruijn <wil...@gm...>
To: john smith <wha...@ya...>
Cc: "ffp...@li..." <ffp...@li...>
Sent: Wednesday, July 20, 2011 7:29 AM
Subject: Re: interface buffer export and renaming
Hi John
> What is the correct syntax to export an interface buffer (e.g. "ether0/1")
> and assign it a new name that can be used with open_stream() api (from user
> space)?
>
> Here is an (incorrect sl_register_request() syntax) mockup of what I'd like
> to do:
>
> sl_register_request("(ether0) | (ether1) > (accept, export,
> name="usr_intf")")
> and
> open_stream("usr_intf", flags)
>
> instead of:
>
> open_stream("ether0", flags)
This is exactly how it works. The export option will export all the
packets that a filter has accepted, so if you only want the packets
passed by ether0, you could even just insert
"(ether0, export, name="user_intf\")"
Note that export sets up an index buffer (think of a NIC descriptor
queue) that references a secondary data buffer holding the actual
packets. If your request is not more elaborate than this, you can
avoid the indirection and have streamline write directly into a data
buffer as by using the exportdata flag, instead.
One small syntax issue: you may have to specify export=yes (or
exportdata=yes) instead of just export. It's been a while, so I'm not
sure.
cheers |
|
From: Willem de B. <wil...@gm...> - 2011-07-20 14:30:05
|
Hi John
> What is the correct syntax to export an interface buffer (e.g. "ether0/1")
> and assign it a new name that can be used with open_stream() api (from user
> space)?
>
> Here is an (incorrect sl_register_request() syntax) mockup of what I'd like
> to do:
>
> sl_register_request("(ether0) | (ether1) > (accept, export,
> name="usr_intf")")
> and
> open_stream("usr_intf", flags)
>
> instead of:
>
> open_stream("ether0", flags)
This is exactly how it works. The export option will export all the
packets that a filter has accepted, so if you only want the packets
passed by ether0, you could even just insert
"(ether0, export, name="user_intf\")"
Note that export sets up an index buffer (think of a NIC descriptor
queue) that references a secondary data buffer holding the actual
packets. If your request is not more elaborate than this, you can
avoid the indirection and have streamline write directly into a data
buffer as by using the exportdata flag, instead.
One small syntax issue: you may have to specify export=yes (or
exportdata=yes) instead of just export. It's been a while, so I'm not
sure.
cheers
|
|
From: john s. <wha...@ya...> - 2011-07-19 19:15:30
|
Hi Willem,
What is the correct syntax to export an interface buffer (e.g. "ether0/1") and assign it a new name that can be used with open_stream() api (from user space)?
Here is an (incorrect sl_register_request() syntax) mockup of what I'd like to do:
sl_register_request("(ether0) | (ether1) > (accept, export, name="usr_intf")")
and
open_stream("usr_intf", flags)
instead of:
open_stream("ether0", flags)
thanks,
John |
|
From: Willem de B. <wil...@gm...> - 2011-06-21 19:11:18
|
> For a branch that doesn't fit the diamond profile: > would that be correct? > "(a) > (( (accept) -22- > (b) ) | ( (accept) -23- (accept)) > (d)) | > ((accept) -24- > (e))" Perfect > I hope that is the last clarification I'd ask: No worries at all, John. Btw: remember that streamline is research quality software. It's fine for straightforward projects, but always be cautious, as I've had few guinea pigs. |
|
From: john s. <wha...@ya...> - 2011-06-21 19:07:52
|
I hope that is the last clarification I'd ask: For a branch that doesn't fit the diamond profile: / -- accept --22--> b -----\ / ----> d a-- \ --- accept --23--accept--/ \ \-- accept --24--> e would that be correct? "(a) > (( (accept) -22- > (b) ) | ( (accept) -23- (accept)) > (d)) | ((accept) -24- > (e))" Thanks, John ________________________________ From: Willem de Bruijn <wil...@gm...> To: john smith <wha...@ya...> Cc: "ffp...@li..." <ffp...@li...> Sent: Tuesday, June 21, 2011 11:40 AM Subject: Re: [Ffpf-devel] streamline sl_register_request(), conditional branch syntax > be correctly descibed with: > "(a) > ( (accept) -22- > (b) ) | ( (accept) -23- ) > (d)" Almost, but you will need to specify a second filter after -23->: "(a) > ( (accept) -22- > (b) ) | ( (accept) -23- (accept)) > (d)" |
|
From: Willem de B. <wil...@gm...> - 2011-06-21 18:40:51
|
> be correctly descibed with: > "(a) > ( (accept) -22- > (b) ) | ( (accept) -23- ) > (d)" Almost, but you will need to specify a second filter after -23->: "(a) > ( (accept) -22- > (b) ) | ( (accept) -23- (accept)) > (d)" |
|
From: john s. <wha...@ya...> - 2011-06-21 18:39:58
|
> (basically skip (b) for (a) processing return value of 23) basically skipping (c) for (a) processing return value of 23, thanks, John ________________________________ From: john smith <wha...@ya...> To: Willem de Bruijn <wil...@gm...> Cc: "ffp...@li..." <ffp...@li...> Sent: Tuesday, June 21, 2011 11:34 AM Subject: Re: [Ffpf-devel] streamline sl_register_request(), conditional branch syntax thanks Willem. what about this slightly modified graph: / ---> accept --22--> b --\ a -- -----> d \ ---> accept --23---------/ (basically skip (b) for (a) processing return value of 23) be correctly descibed with: "(a) > ( (accept) -22- > (b) ) | ( (accept) -23- ) > (d)" thanks, John ________________________________ From: Willem de Bruijn <wil...@gm...> To: john smith <wha...@ya...> Cc: "ffp...@li..." <ffp...@li...> Sent: Monday, June 20, 2011 4:00 PM Subject: Re: [Ffpf-devel] streamline sl_register_request(), conditional branch syntax > The > above then becomes > > "a | (accept | b) + (accept | c)" > > Where the '+' operator for parallelism is newly introduced I forgot that you asked about joins. The above operators simply combines the two streams that are accepted by b and c. If both accept the same packet (not possible in the given example, but certainly in other cases), the downstream filters would receive two copies of a packet. This is rarely what you want. Therefore, the boolean operators ++ and +* extend it with filtering. The first generates the join of the two and the second the union. You'll likely want to use ++. The older language has no equivalent operator, as far as I can remember, but it is possible to generate a functionally equivalent implementation by adding an explicit join filter between where the diamond closes and (d). willem ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Ffpf-devel mailing list Ffp...@li... https://lists.sourceforge.net/lists/listinfo/ffpf-devel |
|
From: john s. <wha...@ya...> - 2011-06-21 18:34:49
|
thanks Willem. what about this slightly modified graph: / ---> accept --22--> b --\ a -- -----> d \ ---> accept --23---------/ (basically skip (b) for (a) processing return value of 23) be correctly descibed with: "(a) > ( (accept) -22- > (b) ) | ( (accept) -23- ) > (d)" thanks, John ________________________________ From: Willem de Bruijn <wil...@gm...> To: john smith <wha...@ya...> Cc: "ffp...@li..." <ffp...@li...> Sent: Monday, June 20, 2011 4:00 PM Subject: Re: [Ffpf-devel] streamline sl_register_request(), conditional branch syntax > The > above then becomes > > "a | (accept | b) + (accept | c)" > > Where the '+' operator for parallelism is newly introduced I forgot that you asked about joins. The above operators simply combines the two streams that are accepted by b and c. If both accept the same packet (not possible in the given example, but certainly in other cases), the downstream filters would receive two copies of a packet. This is rarely what you want. Therefore, the boolean operators ++ and +* extend it with filtering. The first generates the join of the two and the second the union. You'll likely want to use ++. The older language has no equivalent operator, as far as I can remember, but it is possible to generate a functionally equivalent implementation by adding an explicit join filter between where the diamond closes and (d). willem |
|
From: Willem de B. <wil...@gm...> - 2011-06-20 23:00:56
|
> The > above then becomes > > "a | (accept | b) + (accept | c)" > > Where the '+' operator for parallelism is newly introduced I forgot that you asked about joins. The above operators simply combines the two streams that are accepted by b and c. If both accept the same packet (not possible in the given example, but certainly in other cases), the downstream filters would receive two copies of a packet. This is rarely what you want. Therefore, the boolean operators ++ and +* extend it with filtering. The first generates the join of the two and the second the union. You'll likely want to use ++. The older language has no equivalent operator, as far as I can remember, but it is possible to generate a functionally equivalent implementation by adding an explicit join filter between where the diamond closes and (d). willem |
|
From: Willem de B. <wil...@gm...> - 2011-06-20 22:52:21
|
Hi John,
> It is not clear to me (from the examples, slides, etc) what is the syntax
> for specifying the filters dependency/flow tree.
>
> For example:
>
> - forks: a packet transtitions from (a) to (b) (for a specific condition)
> and can also go from (a) to (c) for a different condition,
> would that be correct?
> "(a) fw_b > (b) | (a) fw_c > (c)"
Almost. The problem is expressing that the first and second instances
of "(a)" refer to the same filter. What I usually do is split the
output of a into two streams and then filter each independently, as
in:
"(a) > ( (accept) > (b) ) | ( (accept) > (c) )"
where you can annotate the inner edges for a specific classrange (see
below). Note that this is an older syntax and that recent interpreters
accept an equivalent syntax based on better known Unix pipelines. The
above then becomes
"a | (accept | b) + (accept | c)"
Where the '+' operator for parallelism is newly introduced and nesting
holds the semantics from above (i.e., it does not imply executing in a
subshell, as is the case in sh). This syntax has fewer parentheses to
have to keep track off (no scheme!)
> where fw_b/c would be the a filter's process2 return values for forwarding
> the packets to either filter (b) or (c).
To illustrate the use of process2's return value, let's replace (a) by
a more descriptive function (dport) that sets as classifier the
TCP/UDP port of the observed packet (or 0 if not TCP or UDP), then to
send traffic to the ssh port to b and traffic to the telnet port to c,
issue
"a | (accept |22 b) + (accept |23 c)"
Or, in old syntax
"(a) > ( (accept) -22-> (b) ) | ( (accept) -23-> (c) )"
> - joins: filter receives packets from multiple filters, for ex., (d)
> receives packet from either (b) or (c):
> would that be correct?
> "(a) fw_b > ((b) > d) | (a) fw_c > ((c) > d)"
"a | (accept |22 b) + (accept |23 c) | d"
notice how we've simply created a diamond-shaped subgraph. In glorious ascii art
/ --- accept --22--> b \
a -- ---> d
\ --- accept --23--> c /
Let me know if you have any further questions. Also, the most detailed
explanation can be found in chapter 3.3 of my phd thesis, at
http://www.netstreamline.org/willemdebruijn/publications/dissertation-1_1.pdf
cheers,
Willem
|
|
From: john s. <wha...@ya...> - 2011-06-20 21:22:14
|
Hi, It is not clear to me (from the examples, slides, etc) what is the syntax for specifying the filters dependency/flow tree. For example: - forks: a packet transtitions from (a) to (b) (for a specific condition) and can also go from (a) to (c) for a different condition, would that be correct? "(a) fw_b > (b) | (a) fw_c > (c)" where fw_b/c would be the a filter's process2 return values for forwarding the packets to either filter (b) or (c). - joins: filter receives packets from multiple filters, for ex., (d) receives packet from either (b) or (c): would that be correct? "(a) fw_b > ((b) > d) | (a) fw_c > ((c) > d)" thanks, John |
|
From: Mihai C. <m.l...@uv...> - 2011-04-14 07:07:23
|
Hi Herbert, All packets are 1324bytes long, coming from vlc streaming (you can see this in the screenshots I sent you before). This is how we identified the problem: vlc seemed to stream correctly udp-checksumized packets, but vlc doesn't display anything! This problem with garbage in payload could affect anything beyond 0x80 offset from UDP payload as we see in this dump. Yes, you could say that looks like having only packets with 128bytes payload maximum . J I think if you look only at small packets - they're fine. For instance, typing in netcat regardless is udp or tcp. I tracked down the issue to the place that it happens just after the hook, without doing any filtering (that's why you perhaps saw my ssh packets in the previous dump - I wasn't careful when I copied the kernel dumps to email such as to copy the udp ones). I also have found that only changing the kernel version - affects this behaviour. Hence, I believe, there is something so hard changed in kernel - that affects streamline handling of packets (maybe buffers, maybe netfilter .?) Cheers, Mihai From: her...@gm... [mailto:her...@gm...] On Behalf Of Herbert Bos Sent: 13 April 2011 23:44 To: m.l.cristea Cc: ffpf-devel Subject: Re: FW: [Ffpf-devel] streamline miss-behaviour on vlc streaming I don't get it -- this is a different issue, right? In the previous dump I saw a 100 byte pkt carrying tcp. That looked fine. Now these plots, on the other hand, suggest that you get only 128 bytes. That should be relatively straightforward to track down, I would think. HJB On Wed, Apr 13, 2011 at 10:13 PM, Mihai Cristea <m.l...@uv...> wrote: Hi Herbert, See in the attachment results from Wireshark, as it was hard to see with tcpdump this problem. I managed to capture the same packet twice (before streamline and after streamline). See in the left the original packet, which wireshark properly decodes the media-frames, while in the right - wireshark just tells it's udp. However, the payload of udp has lots of zeroes after 0x80, and all coming data is rubbish, I guess. Conclusion after several days spent on this issue: using latest streamline version with kernel 2.6.25 - everything is ok. Using earlier kernel 2.6.31, or latest one - 2.6.38 => is the effect we see in this attached screenshots. It doesn't matter what filters you put in streamline: it's happening just after streamline hook in netfilter. I hope you can ask someone to look at it. We still want to use streamline for programmable networks in virtual infrastructures. The next SC11 is coming this autumn! ;) Cheers, Mihai -----Original Message----- From: Mihai Cristea [mailto:m.l...@uv...] Sent: 07 April 2011 14:50 To: Willem de Bruijn Cc: ffp...@li... Subject: Re: [Ffpf-devel] streamline miss-behaviour on vlc streaming Hi Willem, fortunately, I've found the problem: I used a simple filter like this (no fpl - plain streamline): insert (netfilter_fetch_in,expression="145.100.132.170") > (skb_transmit) Then I put 2 wiresharks: one on the incoming NIC (145.100.132.170) and one on localhost (to see the packet after skb_transmit). You can see in the attached screenshots the same IP frame captured by those 2 wiresharks: they differ a lot in udp-payload: there are lots of zeros and garbage after it gets transmitted! I picked up different IP frames - the behaviour is similar: starting from offset 0x80 -> gets garbage! Next, I compared the transmit.c from the current version (which includes some improvements I did related to checksuming last year) and the version of 2008 (we used successfully at the SC08-demo). I've not seen any significant change in the payload-copy besides the skb_put at the begining of transmit. Then I simply took the transmit-2008 and tried to compile in this latest version 747 and 2.6.38. I had to do the minimum patching for the skb->dst that doesn't exist in kernel anymore (see the marks on the attached screenshot). Unfortunately, it still behaves same: put garbage in the payload (starting offset 0x80 in UDP) Could you think of something else that might affect the pkt. payload within streamline (some buffering issue, etc?) I would appreciate if we can fix this together quickly. Cheers, Mihai |
|
From: Mihai C. <m.l...@uv...> - 2011-04-13 20:18:27
|
Hi Herbert, See in the attachment results from Wireshark, as it was hard to see with tcpdump this problem. I managed to capture the same packet twice (before streamline and after streamline). See in the left the original packet, which wireshark properly decodes the media-frames, while in the right - wireshark just tells it's udp. However, the payload of udp has lots of zeroes after 0x80, and all coming data is rubbish, I guess. Conclusion after several days spent on this issue: using latest streamline version with kernel 2.6.25 - everything is ok. Using earlier kernel 2.6.31, or latest one - 2.6.38 => is the effect we see in this attached screenshots. It doesn't matter what filters you put in streamline: it's happening just after streamline hook in netfilter. I hope you can ask someone to look at it. We still want to use streamline for programmable networks in virtual infrastructures. The next SC11 is coming this autumn! ;) Cheers, Mihai -----Original Message----- From: Mihai Cristea [mailto:m.l...@uv...] Sent: 07 April 2011 14:50 To: Willem de Bruijn Cc: ffp...@li... Subject: Re: [Ffpf-devel] streamline miss-behaviour on vlc streaming Hi Willem, fortunately, I've found the problem: I used a simple filter like this (no fpl - plain streamline): insert (netfilter_fetch_in,expression="145.100.132.170") > (skb_transmit) Then I put 2 wiresharks: one on the incoming NIC (145.100.132.170) and one on localhost (to see the packet after skb_transmit). You can see in the attached screenshots the same IP frame captured by those 2 wiresharks: they differ a lot in udp-payload: there are lots of zeros and garbage after it gets transmitted! I picked up different IP frames - the behaviour is similar: starting from offset 0x80 -> gets garbage! Next, I compared the transmit.c from the current version (which includes some improvements I did related to checksuming last year) and the version of 2008 (we used successfully at the SC08-demo). I've not seen any significant change in the payload-copy besides the skb_put at the begining of transmit. Then I simply took the transmit-2008 and tried to compile in this latest version 747 and 2.6.38. I had to do the minimum patching for the skb->dst that doesn't exist in kernel anymore (see the marks on the attached screenshot). Unfortunately, it still behaves same: put garbage in the payload (starting offset 0x80 in UDP) Could you think of something else that might affect the pkt. payload within streamline (some buffering issue, etc?) I would appreciate if we can fix this together quickly. Cheers, Mihai |
|
From: Mihai C. <m.l...@uv...> - 2011-04-13 13:29:47
|
Hi Willem,
I did the display into streamline hooks of netfilter and unfortunately, I see the mislead packets (any packets that main-hook gets)!
The packets have zeroes in payload like the ones I put at the end of this email.
Here is the place I put display:
static unsigned int hook_nf_input (unsigned int hook, ....
{
displaydata(skb->data - ETH_HLEN, 250);
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,22)
hijacked = __hook_sub_in(skb->mac.raw, skb->len + ETH_HLEN,
&devsin, indev->ifindex, netfilter_in_all);
#else
#ifdef NET_SKBUFF_DATA_USES_OFFSET
hijacked = __hook_sub_in(skb->data - ETH_HLEN, skb->len + ETH_HLEN,
&devsin, indev->ifindex, netfilter_in_all);
#else
hijacked = __hook_sub_in(skb->mac_header, skb->len + ETH_HLEN,
&devsin, indev->ifindex, netfilter_in_all);
#endif
#endif
// allow filters to force a given return value
if (unlikely(nf_override_return != -1))
return __hook_returnsub(skb);
if (hijacked)
return NF_DROP;
else
return NF_ACCEPT;
}
Seeing this severe problem, I took older versions of streamline and patched the sources to get compiled on 2.6.38 (with minimum interventions):
- I took streamline versions v730 (autumn 2010) => same bad behaviour
- I took streamline versions v583 (autumn 2008) => same bad behaviour
Hence, I think there's something radically changed in the latest kernel versions that affects streamline buffers or management.
I would like to know if you have time to investigate this issue (I'll give you access to my vms). If not, could you suggest which kernel version should work fine and I'll take that one. I know that for SC08-demo we used 2.6.25.
We'd like to use a most recent kernel due to the kvm improvements that'll help our demo with hundreds of VMs (we have a few 48 cores machines).
BTW. I have a deadline on this Thursday to show something up&running. However, if you are busy these days, let me know when could you help me with this issue, and I'll put back the 2.6.25+very-old-streamline for time being.
Cheers,
Mihai
[235383.887239] 00 00 00 00 00 00 00 00 00 00 00 00 40 bc d6 df .....00 16 36 74 18 02 00 1c 23 80 4a 8c 08 00 45 00 ..6t....#.J...E.
[235384.017652] 00 64 85 ba 40 00 3d 06 da aa 92 32 34 ee 91 64 .d..@.=....24..d
[235384.017655] 84 aa e0 c2 00 16 be 29 76 30 89 65 0b 10 80 18 .......)v0.e....
[235384.017656] 00 66 eb 92 00 00 01 01 08 0a 00 1e 9d c3 0e 03 .f..............
[235384.017658] 18 6e 3b 35 cd 78 36 e7 34 80 4a 44 ac 37 c7 b2 .n;5.x6.4.JD.7..
[235384.017659] 64 e6 c4 a0 d5 f2 c8 28 7a e5 08 e7 2a f5 3f f6 d......(z...*.?.
[235384.017661] 75 f7 b1 26 05 68 95 b5 ac 59 d5 98 df 18 3f c7 u..&.h...Y....?.
[235384.017662] f3 b4 00 00 00 00 00 00 00 00 00 00 00 00 00 1c ................
[235384.017664] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[235384.017665] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[235384.017666] 00 00 00 00 01 00 00 00 f1 9f b1 ef 80 18 02 a3 ................
[235384.017668] e1 1d 00 00 01 01 08 0a 0e 02 7f 9e 00 1e 04 6d ...............m
[235384.017669] 02 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
[235384.017671] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[235384.017672] 00 00 00 00 00 00 00 00 70 29 bd de c0 a4 d6 df .....00 16 36 74 18 02 00 1c 23 80 4a 8c 08 00 45 00 ..6t....#.J...E.
[235384.040476] 00 34 85 bb 40 00 3d 06 da d9 92 32 34 ee 91 64 .4..@.=....24..d
[235384.040478] 84 aa e0 c2 00 16 be 29 76 60 89 65 0b 40 80 10 .......)v`.e.@..
[235384.040480] 00 66 2a 1e 00 00 01 01 08 0a 00 1e 9d d9 0e 03 .f*.............
[235384.040481] 19 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[235384.040483] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[235384.040484] 00 00 00 00 01 00 00 00 81 49 ec f1 8d ed 46 f9 .........I....F.
[235384.040485] 4b fd 00 00 00 00 00 00 00 00 00 00 00 00 00 1c K...............
[235384.040487] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[235384.040488] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[235384.040490] 00 00 00 00 01 00 00 00 be 29 75 70 80 18 02 a3 .........)up....
[235384.040491] dd 85 00 00 01 01 08 0a 0e 03 16 d4 00 1e 9b 8b ................
[235384.040492] 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
[235384.040494] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[235384.040495] 00 00 00 00 00 00 00 00 00 00 00 00 40 bc d6 df .....00 16 36 74 18 02 00 1c 23 80 4a 8c 08 00 45 00 ..6t....#.J...E.
[235384.141742] 00 64 85 bc 40 00 3d 06 da a8 92 32 34 ee 91 64 .d..@.=....24..d
[235384.141744] 84 aa e0 c2 00 16 be 29 76 60 89 65 0b 40 80 18 .......)v`.e.@..
[235384.141746] 00 66 7a 65 00 00 01 01 08 0a 00 1e 9e 3f 0e 03 .fze.........?..
[235384.141748] 19 07 86 0e 2e 72 bb e5 63 fd 51 81 af 2d 37 1e .....r..c.Q..-7.
[235384.141749] b9 a9 8d 6d fd e1 a3 c2 f6 8b 79 43 fb f7 d1 3c ...m......yC...<
[235384.141750] 78 c7 68 83 54 2f e4 11 b4 8f e1 74 8b e2 66 ea x.h.T/.....t..f.
[235384.141752] da cb 4f b4 75 9b 45 d7 f5 eb 16 56 cc c0 6a 3f ..O.u.E....V..j?
[235384.141753] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[235384.141755] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[235384.141756] 00 00 00 00 01 00 00 00 f1 9f b1 ef e0 5c d7 df .............\..
[235384.141758] 8c 00 ce 01 01 01 08 0a 0e 02 7f 8a 00 1e 04 57 ...............W
[235384.141759] 02 00 a8 05 02 00 01 00 00 00 00 00 00 00 00 00 ................
[235384.141760] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[235384.141762] 00 00 00 00 00 00 00 00 00 00 00 00 a0 46 d7 df .....trying parse of [192.168.122.192].16
[235384.166544] Partial match. Found 192
[235384.167727] success at #1: 192
[235384.168308] Partial match. Found 168
[235384.168716] success at #2: 43200
[235384.169551] Partial match. Found 122
[235384.170155] success at #3: 8038592
[235384.170543] Partial match. Found 192
[235384.170543] success at #4: -1065703232
[235384.172003] successfully parsed 192.168.122.192 into 192.122.168.192
[235384.172747] Successfully found device eth0 for address 192.168.122.192
[235384.173493] [Stop ] netfilter in dev 192.168.122.192
[235384.174478] [Stop ] netfilter in
[235404.390451] [Stop ] channel instance sysfs_up_signal from 1 to 4 (#4)
[235404.392029] [Stop ] channel instance sysfs from 1 to 4 (#3)
[235404.392808] [Stop ] route sysfs.4
[235404.393445] [Stop ] route sysfs_up_message.4
[235404.394145] [Stop ] route sysfs_up_signal.4
[235404.394852] [Stop ] route sysfs area.4
|
|
From: Mihai C. <m.l...@uv...> - 2011-04-11 21:02:19
|
Hi Willem, I tried on kernel 2.6.31: same problems! I guess you have never checked the content of the packets (the zeroes are after 0x80 in UDP/TCP payload). For example, typing in netcat works fine in any kernel version. I went back to 2.6.25 (the one I used in 2008 successfully) - and your latest streamline version works fine here. Unfortunately, I don't have the time to try out kernel by kernel and see where the processing model of streamline is not compatible with the kernel ... This work might be for a student of Herbert, if he's still interested to keep streamline alive. I'm already fighting for using streamline in our current research projects with programmable networks in Clouds, and especially in demos. Fortunately for streamline, we didn't find (yet) an alternative in building programmable routers in the linux kernels. Cheers, Mihai > -----Original Message----- > From: Willem de Bruijn [mailto:wil...@gm...] > Sent: 11 April 2011 14:24 > To: m.l...@uv... > Cc: ffp...@li... > Subject: Re: [Ffpf-devel] streamline miss-behaviour on vlc streaming > > > I would like to know if you have time to investigate this issue (I'll give you > access to my vms). > > I'm afraid I won't. > > >If not, could you suggest which kernel version should work fine and I'll take > that one. I know that for SC08-demo we used 2.6.25. > > 2.6.31 is the last version that I know worked well. Why don't you try bisection > to find the version that starts failing and then have a look at the differences > between that and the previous (last known good) kernel. Changes that can > affect us will be minimal. > > good luck |
|
From: Willem de B. <wil...@gm...> - 2011-04-11 12:24:03
|
> I would like to know if you have time to investigate this issue (I'll give you access to my vms). I'm afraid I won't. >If not, could you suggest which kernel version should work fine and I'll take that one. I know that for SC08-demo we used 2.6.25. 2.6.31 is the last version that I know worked well. Why don't you try bisection to find the version that starts failing and then have a look at the differences between that and the previous (last known good) kernel. Changes that can affect us will be minimal. good luck |
|
From: Willem de B. <wil...@gm...> - 2011-04-09 01:10:07
|
> I know that you could tell me the exact place that will get when calling netfilter_fetch_in, but I think is interesting for me (and also for the others reading this) to understand the functionality of the netfilter.c code of streamline with pointing to the functions calls for each of the implemented cases (hooks): netfilter_in, netfilter_fetch_in, netfilter_out, netfilter_fetch_out, netfilter_toggle. You're correct that the netfilter module does not cot conform to streamline standard. It tries to merge the netfilter model with that of streamline. To get packets from netfilter, code has to register a callback. There are different callbacks for ingress and egress traffic at different points in the network stack. NF_IP_LOCAL_IN or similar will give you all the traffic destined to the host before it is actually sent up the host. netfilter_in and netfilter_fetch_in receive this traffic. The modules netfilter_out and netfilter_fetch_out attach to a similar hook for egress traffic. There's quite some information on the web about intercepting traffic with netfilter, for instance the netfilter hacking howto at http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO.html Forget everything about iptables: we don't use that. Now whenever netfilter calls your function with a packet, the function can decide whether it should continue or be dropped, by returning a special return value (NF_ACCEPT, resp. NF_DROP). The only difference between netfilter_$direction and netfilter_fetch_$direction is which return code it generates. These functions always return their hardcoded action... .. actually, that's no longer true, which brings us to the odd netfilter_toggle function. You requested this a year and a half ago. It allows a streamline pipeline to override the default behavior of the netfilter input function. By default netfilter_fetch_in will drop a packet. Say that you want 99% dropped, but occasionally a packet should make it through. Add netfilter_toggle to your pipeline to only that stream that contains packets that go through. The return value will be whatever is the classifier received by this filter. I expect that NF_DROP corresponds to 0 and NF_ACCEPT to 1. Changing the behavior of a filter A from filter B in pipeline A | B may sound odd, but in reality, our netfilter hook is a function that calls streamline through another function slrun. When slrun returns, we are back in the netfilter hook and can decide what netfilter should do with the packet. The streamline model is for filters to have an (optional) ->newex and ->delex pair of functions that are called when filters are created and destroyed. If you want to see how streamline attaches to netfilter, have a look at these functions. It can be a bit difficult to follow, because the four variants of netfilter share much, but not all, of this code. willem (written after a few beers, please be considerate; I'm on a bus and have nothing better to do, so your timing was excellent) |
|
From: Mihai C. <m.l...@uv...> - 2011-04-08 21:21:07
|
Hi Willem,
I must admit that I'm in trouble with netfilter code and I need your assistance:
Although netfilter_process2 seems to do nothing (always returns 0), I think it has to do with the hooks: __hook_subsub() or __hook_sub()
netfilter_process2(struct iptr *iptr, struct fptr *fptr, const struct functiondata *fdata)
{
return 0;
}
I know that you could tell me the exact place that will get when calling netfilter_fetch_in, but I think is interesting for me (and also for the others reading this) to understand the functionality of the netfilter.c code of streamline with pointing to the functions calls for each of the implemented cases (hooks): netfilter_in, netfilter_fetch_in, netfilter_out, netfilter_fetch_out, netfilter_toggle.
Thanks for details,
Mihai
On Apr 8, 2011, at 5:28 PM, Willem de Bruijn wrote:
>> How can I check the incoming packet before any processing?
>> If there's no way to debug from slcli, let me know the hard-way: where in the streamline code should I call this inspect such as to identify the root of the problem.
>
> you should insert the displaypkt function call into netfilter_fetch_in
> as early as possible. Look at inspect_process2 to see the precise
> function name and its arguments. It's fairly straightforward.
|
|
From: Willem de B. <wil...@gm...> - 2011-04-08 16:05:29
|
> !slfile_accesscontrol(orig->shared, flags, getuid(), getpid())) {
> if (!slfile_accesscontrol(orig->shared, flags, getuid(), getgid())) {
ah, right. That should be getgid() in both cases. Thanks for pointing out.
|
|
From: Mihai C. <m.l...@uv...> - 2011-04-08 16:02:52
|
Good morning! ;)
read again the few lines of code of 2 functions for kernel/user-space. In some places there's gid in others pid instead. How's correct?
src/core/file.c
__open_newstream()
...
#ifdef __KERNEL__
if (!in_interrupt()) {
buf->shared->uid = getuid();
buf->shared->gid = getgid();
}
else {
buf->shared->uid = 0;
buf->shared->gid = 0;
}
#else
buf->shared->uid = getuid();
buf->shared->gid = getgid();
#endif
...
}
and in this function: __open_existingbd()
...
#ifdef __KERNEL__
if (!in_interrupt() &&
!slfile_accesscontrol(orig->shared, flags, getuid(), getpid())) {
#else
if (!slfile_accesscontrol(orig->shared, flags, getuid(), getgid())) {
#endif
...
}
|
99 messages has been excluded from this view by a project administrator.
