From larsbro at gmail.com  Wed Aug  1 10:41:29 2012
From: larsbro at gmail.com (Lars Bro)
Date: Wed, 1 Aug 2012 16:41:29 +0200
Subject: [Click] Selection on annotations
Message-ID: <CAFFLP3oeu5iDt49cRyGvUNyEZypgUrENX1xdCTQEbJJnodonVw@mail.gmail.com>

Hi, Click list

When using Paint annotations that are in a small interval starting with 0,
it is appropriate to use the PaintSwitch element for selecting.

However, if the interval is sparse, it can be a good idea to use PaintTee
instead like below:

... -> a::PaintTee(17) -> b::PaintTee(78) -> c::PaintTee(154) -> ...
a[1] -> ...
b[1] -> ...
c[1] -> ...

Now, I use VLANDecap() to get the VLAN VID, and it will be put into a
two-byte annotation.

As far as I can see, there is no way to select on the VLAN VID if it is >
256 which it is in my case. It can be up to 2^12

I do understand that a paint annotation is just a one-byte value, and
somehow it is OK that PaintTee also only uses one byte. If we want to check
on something more complex, maybe a Classiifier-like approach might be
appropriate

For example an AnnoClassifier element that works exactly as Classifier, but
on the annotation space instead.

What do you think?

Lars Bro

From jopen at informatik.uni-bonn.de  Tue Aug  7 07:44:48 2012
From: jopen at informatik.uni-bonn.de (Sascha Alexander Jopen)
Date: Tue, 07 Aug 2012 13:44:48 +0200
Subject: [Click] Args with multiple identical keywords
In-Reply-To: <CAF0C5S+DYCP=Pj_Ag_Po1BZeNOq_8+yGi9jzQDRcfCQy=5DQcg@mail.gmail.com>
References: <50167199.1000001@informatik.uni-bonn.de>
	<CAF0C5S+DYCP=Pj_Ag_Po1BZeNOq_8+yGi9jzQDRcfCQy=5DQcg@mail.gmail.com>
Message-ID: <5020FFB0.7030902@informatik.uni-bonn.de>

Hello,

while using read_all_with() i found different parse method signatures in
the parsers AnyArg and IPAddressArg for parsing into Vectors. I propose
to change the parse() signature of AnyArg for Vectors, as well as the
parser call in base_read_all_with() to have the same order of the
arguments as all other parse() methods. This may break existing custom
parsers, however.

You can find the necessary changes in the attached patch, if you think
this is a reasonable change.

Regards,
Sascha


On 07/30/12 19:37, Eddie Kohler wrote:
> Yes, try Args::read_all_with().
> 
> Eddie
> 
> 
> On Mon, Jul 30, 2012 at 7:35 AM, Sascha Alexander Jopen
> <jopen at informatik.uni-bonn.de> wrote:
>> Hey,
>>
>> is it possible to parse argument lists containing the same keyword
>> multiple times, having each occurence of the keyword values assigned to
>> another variable?
>>
>> For example, would like to parse a configuration like this:
>>
>> SomeElement(FIRSTKEYWORD 1, FIRSTKEYWORD 2, ..., SECONDKEYWORD a,
>> SECONDKEYWORD b, ...);
>>
>> Currently only the last value of a keyword group is parsed and returned
>> as a result after consume() and all additional identical keyword
>> arguments are removed from the configuration string.
>>
>> The only solution i see so far is having a single keyword and
>> concatenating all values into a single argument to this keyword. This
>> keyword is then parsed as a string, splitting the string and passing the
>> parts to additional argument parsers of the right type.
>>
>> Does anybody know a better solution, which can directly be handled by
>> the argument parser?
>>
>> Regards,
>> Sascha
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click

-------------- next part --------------
diff --git a/include/click/args.hh b/include/click/args.hh
index dd3174e..6039b6b 100644
--- a/include/click/args.hh
+++ b/include/click/args.hh
@@ -686,7 +686,7 @@ class Args : public ArgContext {
 	Slot *slot_status;
 	int read_status = -1;
 	while (String str = find(keyword, flags, slot_status)) {
-	    postparse(parser.parse(str, *this, variable), slot_status);
+	    postparse(parser.parse(str, variable, *this), slot_status);
 	    read_status = (read_status != 0) && _read_status;
 	    flags &= ~mandatory;
 	}
@@ -1174,7 +1174,7 @@ class AnyArg { public:
 	result = str;
 	return true;
     }
-    static bool parse(const String &str, const ArgContext &, Vector<String> &result) {
+    static bool parse(const String &str, Vector<String> &result, const ArgContext &) {
 	result.push_back(str);
 	return true;
     }

From qubu88 at gmail.com  Tue Aug  7 08:17:04 2012
From: qubu88 at gmail.com (Jakub Dudek)
Date: Tue, 7 Aug 2012 14:17:04 +0200
Subject: [Click] OSPF routing with own modifications
Message-ID: <CAAVMy+JVhjhzr6KKM7XYJH4TGJ75j=wVsoJ_CcgUzxZiYmfKmA@mail.gmail.com>

Hello,

I need to change static routing element into OSPF routing element. There
are exist prepared elements that implement OSPF functionality or I have to
impement them yourself? Maybe can I use other applications as Quagga?
Except implementing OSPF I would like entire some changes within.

Thanks
Jakub

From ekohler at gmail.com  Tue Aug  7 22:57:48 2012
From: ekohler at gmail.com (Eddie Kohler)
Date: Tue, 07 Aug 2012 22:57:48 -0400
Subject: [Click] Args with multiple identical keywords
In-Reply-To: <5020FFB0.7030902@informatik.uni-bonn.de>
References: <50167199.1000001@informatik.uni-bonn.de>
	<CAF0C5S+DYCP=Pj_Ag_Po1BZeNOq_8+yGi9jzQDRcfCQy=5DQcg@mail.gmail.com>
	<5020FFB0.7030902@informatik.uni-bonn.de>
Message-ID: <5021D5AC.8080104@seas.harvard.edu>

Hi Sascha,

This is a good point. Unfortunately, the different argument order in 
read_all_with was important for hidden reasons, specifically EtherAddressArg 
with an 'unsigned char *' argument. Furthermore the IPAddressArg::parse 
function for vectors actually parses a SINGLE SPACE-SEPARATED argument; it 
doesn't work for multiple arguments.

I checked in a number of changes that should fix this issue. The changes also 
add a new "Args::read_all()" method, which calls a parser once per argument 
and collects the results in a vector.

Hope this is useful.
Eddie


On 8/7/12 7:44 AM, Sascha Alexander Jopen wrote:
> Hello,
>
> while using read_all_with() i found different parse method signatures in
> the parsers AnyArg and IPAddressArg for parsing into Vectors. I propose
> to change the parse() signature of AnyArg for Vectors, as well as the
> parser call in base_read_all_with() to have the same order of the
> arguments as all other parse() methods. This may break existing custom
> parsers, however.
>
> You can find the necessary changes in the attached patch, if you think
> this is a reasonable change.
>
> Regards,
> Sascha
>
>
> On 07/30/12 19:37, Eddie Kohler wrote:
>> Yes, try Args::read_all_with().
>>
>> Eddie
>>
>>
>> On Mon, Jul 30, 2012 at 7:35 AM, Sascha Alexander Jopen
>> <jopen at informatik.uni-bonn.de> wrote:
>>> Hey,
>>>
>>> is it possible to parse argument lists containing the same keyword
>>> multiple times, having each occurence of the keyword values assigned to
>>> another variable?
>>>
>>> For example, would like to parse a configuration like this:
>>>
>>> SomeElement(FIRSTKEYWORD 1, FIRSTKEYWORD 2, ..., SECONDKEYWORD a,
>>> SECONDKEYWORD b, ...);
>>>
>>> Currently only the last value of a keyword group is parsed and returned
>>> as a result after consume() and all additional identical keyword
>>> arguments are removed from the configuration string.
>>>
>>> The only solution i see so far is having a single keyword and
>>> concatenating all values into a single argument to this keyword. This
>>> keyword is then parsed as a string, splitting the string and passing the
>>> parts to additional argument parsers of the right type.
>>>
>>> Does anybody know a better solution, which can directly be handled by
>>> the argument parser?
>>>
>>> Regards,
>>> Sascha
>>> _______________________________________________
>>> click mailing list
>>> click at amsterdam.lcs.mit.edu
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From Kaiser.Joerg at gmx.net  Wed Aug  8 05:08:25 2012
From: Kaiser.Joerg at gmx.net (=?ISO-8859-1?Q?J=F6rg_Kaiser?=)
Date: Wed, 08 Aug 2012 11:08:25 +0200
Subject: [Click] wrong assert in udpipencap?
Message-ID: <50222C89.90801@gmx.net>

Hi,

we were cross compiling and stumbled over an assert which seems to be in 
wrong position:
udpipencap.cc (line 86 et sqq.) assert can never hold true as headers 
are set afterwards.

cheers,
J?rg


Packet *
UDPIPEncap::simple_action(Packet *p_in)
{
   WritablePacket *p = p_in->push(sizeof(click_udp) + sizeof(click_ip));
   click_ip *ip = reinterpret_cast<click_ip *>(p->data());
   click_udp *udp = reinterpret_cast<click_udp *>(ip + 1);

#if !HAVE_INDIFFERENT_ALIGNMENT
   assert((uintptr_t)ip % 4 == 0);
#endif
   // set up IP header
   ip->ip_v = 4;
   ip->ip_hl = sizeof(click_ip) >> 2;
   ip->ip_len = htons(p->length());
   ip->ip_id = htons(_id.fetch_and_add(1));
   ip->ip_p = IP_PROTO_UDP;
   ip->ip_src = _saddr;


From jopen at informatik.uni-bonn.de  Wed Aug  8 06:49:49 2012
From: jopen at informatik.uni-bonn.de (Sascha Alexander Jopen)
Date: Wed, 08 Aug 2012 12:49:49 +0200
Subject: [Click] Args with multiple identical keywords
In-Reply-To: <5021D5AC.8080104@seas.harvard.edu>
References: <50167199.1000001@informatik.uni-bonn.de>
	<CAF0C5S+DYCP=Pj_Ag_Po1BZeNOq_8+yGi9jzQDRcfCQy=5DQcg@mail.gmail.com>
	<5020FFB0.7030902@informatik.uni-bonn.de>
	<5021D5AC.8080104@seas.harvard.edu>
Message-ID: <5022444D.10306@informatik.uni-bonn.de>

Thank you Eddie. This is exactly what i was looking for.

Sascha

On 08/08/12 04:57, Eddie Kohler wrote:
> Hi Sascha,
> 
> This is a good point. Unfortunately, the different argument order in
> read_all_with was important for hidden reasons, specifically
> EtherAddressArg with an 'unsigned char *' argument. Furthermore the
> IPAddressArg::parse function for vectors actually parses a SINGLE
> SPACE-SEPARATED argument; it doesn't work for multiple arguments.
> 
> I checked in a number of changes that should fix this issue. The changes
> also add a new "Args::read_all()" method, which calls a parser once per
> argument and collects the results in a vector.
> 
> Hope this is useful.
> Eddie
> 
> 
> On 8/7/12 7:44 AM, Sascha Alexander Jopen wrote:
>> Hello,
>>
>> while using read_all_with() i found different parse method signatures in
>> the parsers AnyArg and IPAddressArg for parsing into Vectors. I propose
>> to change the parse() signature of AnyArg for Vectors, as well as the
>> parser call in base_read_all_with() to have the same order of the
>> arguments as all other parse() methods. This may break existing custom
>> parsers, however.
>>
>> You can find the necessary changes in the attached patch, if you think
>> this is a reasonable change.
>>
>> Regards,
>> Sascha
>>
>>
>> On 07/30/12 19:37, Eddie Kohler wrote:
>>> Yes, try Args::read_all_with().
>>>
>>> Eddie
>>>
>>>
>>> On Mon, Jul 30, 2012 at 7:35 AM, Sascha Alexander Jopen
>>> <jopen at informatik.uni-bonn.de> wrote:
>>>> Hey,
>>>>
>>>> is it possible to parse argument lists containing the same keyword
>>>> multiple times, having each occurence of the keyword values assigned to
>>>> another variable?
>>>>
>>>> For example, would like to parse a configuration like this:
>>>>
>>>> SomeElement(FIRSTKEYWORD 1, FIRSTKEYWORD 2, ..., SECONDKEYWORD a,
>>>> SECONDKEYWORD b, ...);
>>>>
>>>> Currently only the last value of a keyword group is parsed and returned
>>>> as a result after consume() and all additional identical keyword
>>>> arguments are removed from the configuration string.
>>>>
>>>> The only solution i see so far is having a single keyword and
>>>> concatenating all values into a single argument to this keyword. This
>>>> keyword is then parsed as a string, splitting the string and passing
>>>> the
>>>> parts to additional argument parsers of the right type.
>>>>
>>>> Does anybody know a better solution, which can directly be handled by
>>>> the argument parser?
>>>>
>>>> Regards,
>>>> Sascha
>>>> _______________________________________________
>>>> click mailing list
>>>> click at amsterdam.lcs.mit.edu
>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>


From ekohler at gmail.com  Wed Aug  8 08:57:23 2012
From: ekohler at gmail.com (Eddie Kohler)
Date: Wed, 08 Aug 2012 08:57:23 -0400
Subject: [Click] wrong assert in udpipencap?
In-Reply-To: <50222C89.90801@gmx.net>
References: <50222C89.90801@gmx.net>
Message-ID: <50226233.8080302@gmail.com>

Hi J?rg,

No, the assert is correct. "ip" is set from "p->data()". Is the assert failing 
for you? You need to generate a correctly aligned input packet. Try click-align?

Eddie


On 8/8/12 5:08 AM, J?rg Kaiser wrote:
> Hi,
>
> we were cross compiling and stumbled over an assert which seems to be in
> wrong position:
> udpipencap.cc (line 86 et sqq.) assert can never hold true as headers
> are set afterwards.
>
> cheers,
> J?rg
>
>
> Packet *
> UDPIPEncap::simple_action(Packet *p_in)
> {
>     WritablePacket *p = p_in->push(sizeof(click_udp) + sizeof(click_ip));
>     click_ip *ip = reinterpret_cast<click_ip *>(p->data());
>     click_udp *udp = reinterpret_cast<click_udp *>(ip + 1);
>
> #if !HAVE_INDIFFERENT_ALIGNMENT
>     assert((uintptr_t)ip % 4 == 0);
> #endif
>     // set up IP header
>     ip->ip_v = 4;
>     ip->ip_hl = sizeof(click_ip) >> 2;
>     ip->ip_len = htons(p->length());
>     ip->ip_id = htons(_id.fetch_and_add(1));
>     ip->ip_p = IP_PROTO_UDP;
>     ip->ip_src = _saddr;
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From ekohler at gmail.com  Wed Aug  8 09:10:35 2012
From: ekohler at gmail.com (Eddie Kohler)
Date: Wed, 08 Aug 2012 09:10:35 -0400
Subject: [Click] Using multithreading in Userlevel
In-Reply-To: <CAFQP_p5rz13N1j8M_d4HxMXgsJHnxAb7pfbCLFFkRe7-Ah5r7w@mail.gmail.com>
References: <CAFQP_p5rz13N1j8M_d4HxMXgsJHnxAb7pfbCLFFkRe7-Ah5r7w@mail.gmail.com>
Message-ID: <5022654B.6000803@gmail.com>

Hi Arpita,

I think you may have meant "StaticThreadSched(is2 0, is1 1)"

Threads are numbered started from 0.

Eddie


On 7/8/12 11:52 PM, Arpita Agarwal wrote:
> Hi!
>
> I have installed userlevel click with multithreading support using
> --enable-user-multithread.
> I want to create a program, where i want to distribute certain tasks among
> different threads and measure the performance. how do i do so?
> This is how i am doing it right now.
>
> is1 :: InfiniteSource(DATA \<00 00 c0 ae 67 ef  00 00 00 00 00 00  08 00
> 45 00 00 28  00 00 00 00  40 11 77 c3  01 00 00 01
> 02 00 00 02  13 69 13 69  00 14 d6 41  55 44 50 20
> 70 61 63 6b  65 74 21 0a>, LIMIT 1000, STOP true)
> ->Strip(14)
>    -> CheckIPHeader2
> ->l1::Lock1        ///this is a dummy element i have created
> -> Print(ok)
> -> Discard;
>
> is2 :: InfiniteSource(DATA \<00 00 c0 ae 67 ef  00 00 00 00 00 00  08 00
> 45 00 00 28  00 00 00 00  40 11 77 c3  01 00 00 01
> 02 00 00 02  13 69 13 69  00 14 d6 41  55 44 50 20
> 70 61 63 6b  65 74 21 0a>, LIMIT 1000, STOP true)
> ->Strip(14)
>    -> CheckIPHeader2
> ->l2::Lock1
> ->Discard;
> StaticThreadSched(is2 1,is1 2);
> But this is not dividing the tasks the way i want to.
> I cannot install kernel level click right now.Is there any other way to do
> that.
>
> Thanks
> Arpita
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From ekohler at gmail.com  Wed Aug  8 09:15:56 2012
From: ekohler at gmail.com (Eddie Kohler)
Date: Wed, 08 Aug 2012 09:15:56 -0400
Subject: [Click] linux todevice lock problem
In-Reply-To: <CAM=Fr60n7pFjz97--Ph24spvCh71q1x5TN+XvxcD0Zyi5pgeew@mail.gmail.com>
References: <CAM=Fr60n7pFjz97--Ph24spvCh71q1x5TN+XvxcD0Zyi5pgeew@mail.gmail.com>
Message-ID: <5022668C.20404@gmail.com>

Brian,

What an awesome catch!! Thank you. I've committed this patch.

Eddie


On 7/29/12 10:06 PM, ??? wrote:
> Hi,
>
> [ 594.664181] NETDEV WATCHDOG: eth0: transmit timed out
>
> Sometimes I got this error messages.
> I found commit related this problem.
>
> http://read.cs.ucla.edu/gitweb?p=click;a=commit;h=01c8f4e084036338e83a6bff7a8e74dc49caa014
>
> And i think this is problem macro.
>
> # define click_netif_needs_lock(dev)           (((dev)->features &
> NETIF_F_LLTX) != 0)
>
> According to this article http://lwn.net/Articles/101215/
> lock is needed when dev->features dosen't have NETIF_F_LLTX
> So, I think need change like this
>
> --------------------------
> --- a/elements/linuxmodule/todevice.cc
> +++ b/elements/linuxmodule/todevice.cc
> @@ -258,7 +258,7 @@ ToDevice::cleanup(CleanupStage stage)
>   #endif
>
>   #ifdef NETIF_F_LLTX
> -# define click_netif_needs_lock(dev)           (((dev)->features &
> NETIF_F_LLTX) != 0)
> +# define click_netif_needs_lock(dev)           (((dev)->features &
> NETIF_F_LLTX) == 0)
>   #else
>   # define click_netif_needs_lock(dev)           1
>   #endif
> ---------------------------
>
> Thanks,
>

From sengmolika at gmail.com  Wed Aug  8 10:04:19 2012
From: sengmolika at gmail.com (Seng Molika)
Date: Wed, 8 Aug 2012 16:04:19 +0200
Subject: [Click] I could not get any packet from the second output of
 ACKRetrySender and ACKResponder
Message-ID: <CAH_NEGxAnGt7G4+q080zJj1g4Gd0GR7wu4RHOWTVS_dHKLK6FQ@mail.gmail.com>

Dear all,

I would like to ask for helps to my two questions.
  1- I am not sure my Classifier to filter 'ack', is it correct?
  2- I could not see any output from ACKRetrySender and ACKResponder. What
is the problem do I have in my click file?

The first PC, I am running hostap to make it as access point and its
Ethernet Address: 74:EA:3A:8F:38:18.
The second PC worked as the station and its Ethernet Address: C0 18 85 17
08 BC.

Click file 'test_ackRetrySender.click' run on PC_ap, and
Click file 'test_ackResponder.click' run on PC_station.

And the following are my click files which I am testing on 2 computer in
user level mode.

========= test_ackRetrySender.click ===========

AddressInfo(ap_xorr 192.168.1.1/24 wlan0);

winfo :: WirelessInfo(SSID "ap", BSSID ap_xorr, CHANNEL 11);

rates :: AvailableRates(DEFAULT 2 4 11 22);

tx :: ACKRetrySender (MAX_TRIES 3);

src1 :: InfiniteSource(DATA \<00 1F 3C 5F B9 C7  C0 18 85 17 08 BC  08 00
49 20 67 6f  20 74 6f 20  73 63 68 6f  6f 6c 2e 20
49 20 67 6f  20 74 6f 20  73 63 68 6f  6f 6c 2e 20
49 20 67 6f  20 74 6f 20  73 63 68 6f  6f 6c 2e 20
70 61 63 6b  65 74 21 0a>, LIMIT -1, STOP true)
//
    -> Queue(50) -> c_d :: Counter() -> [0]tx;

FromDevice(wlan0) -> wifi_cl :: Classifier (0/08%0c, //data
                 0/04%0c, //control
                 0/00%0c,// mgt
                 )

wifi_cl[0] -> Print(incoming_data) -> Discard;
wifi_cl[2] -> Print(incoming_mgt) -> Discard;

wifi_cl[1] -> ack_cl :: Classifier(0/d0%f0);
ack_cl -> Print(incoming_ack) -> Queue(50) -> [1]tx;

tx[0] ->c_tx::Counter()
    -> wifi_encap :: WifiEncap(0x02, WIRELESS_INFO winfo)
      -> set_rate :: SetTXRate(22)
    -> q::Queue(200)
    -> ExtraEncap()
    -> to_dev :: ToDevice(wlan0);

tx[1] -> c_rx::Counter() -> Queue(10) -> Discard;

DriverManager (pause,
        print >ap.records "data tx", print >>ap.records c_d.count,
        print >>ap.records "output 0", print >>ap.records c_tx.count,
        print >>ap.records "output 1", print >>ap.records c_rx.count)

===================  test_ackResponder.click  ====================

FromDevice(eth0)
    -> Prism2Decap()
    -> ExtraDecap()
    -> FilterTX()
    -> WifiDupeFilter()
    -> wifi_cl :: Classifier(0/08%0c); //data

resp :: ACKResponder(ETH 74:EA:3A:8F:38:18);
wifi_cl -> c_data :: Counter() -> resp;

resp [0] -> c_output0 :: Counter() -> Discard;
resp [1] -> c_ack :: Counter() -> Queue(10) -> ToDevice(eth0);

DriverManager(pause,
        print >station.records "incoming data", print >>station.records
c_data.count,
        print >>station.records "output 0- data", print >>station.records
c_output0.count,
        print >>station.records "output 1- ack", print >>station.records
c_ack.count)

================================================
_____  ap.records ______

data tx
31
output 0
92
output 1
0
_____ station.records ______

incoming data
89
output 0- data
89
output 1- ack
0

__________________________

>From the output file of ap.records and station.records, I could see that I
could not recieve any packets from output 1 of ACKRetrySender and
ACKResponder at all.

Thank you in advance,

Molika

From jimmy.kjallman at nomadiclab.com  Thu Aug 16 05:55:12 2012
From: jimmy.kjallman at nomadiclab.com (=?iso-8859-1?Q?Jimmy_Kj=E4llman?=)
Date: Thu, 16 Aug 2012 12:55:12 +0300
Subject: [Click] Recent optimizations may cause segmentation faults
Message-ID: <CECFD9D6-5BAA-4F78-B51C-228ABA49B144@nomadiclab.com>

FYI,

it seems that recent string-related optimizations in Click cause some problems when the code is compiled with GCC 4.2.1 - which is a rather old compiler, but is still used as the default compiler in some systems (e.g. in FreeBSD 8 and 9). Of course, some other versions of GCC might also have the same problem.

The code gets compiled (without errors etc.), but segmentation faults may occur when Click is started.

With other, newer compilers that I tried (e.g. GCC 4.6), the code seems to work as it should.


Some more details:

It seems that commit "String, StringAccum: Call strlen() early when the result's a constant" (8b94ae6) causes problems for GCC 4.2.1, at least based on my observations on FreeBSD and Mac OS X.

E.g. in String::String(const char *cstr), the code based on __builtin_constant_p(strlen(cstr)) and inlining doesn't get compiled correctly for some reason, so assign(cstr, strlen(cstr), false) gets called instead of assign(cstr, -1, false) at runtime. Possibly this is what always happens. If then cstr is NULL (for example), calling strlen(NULL) obviously causes a segmentation fault.

This error is very easy to produce: Running "click" without any arguments results in a segmentation fault in the string constructor. This happens before starting to read a configuration from stdin. Apparently this error also occurs if a configuration file given as input starts with require(...), for instance.

The current code works if I compile Click e.g. with GCC 4.6 in FreeBSD or LLVM-GCC 4.2.1 in OS X - and that's OK for me. Possibly some other workarounds, such as giving suitable options to the old compiler, might also work - but I haven't tried any. And I'm not sure whether this error occurs on all platforms.


 - Jimmy



From ashok.anand at gmail.com  Thu Aug 16 23:40:41 2012
From: ashok.anand at gmail.com (Ashok Anand)
Date: Fri, 17 Aug 2012 09:10:41 +0530
Subject: [Click] Issue in kernel-level click
Message-ID: <CALQsBOW6kjZ+Srb4iB3N15NdJhcavFzj0j1oOzn8tukvUxB97w@mail.gmail.com>

Hi,

I am using a following configuration for kernel-level click, click-2.0.1

oqueue :: Queue(1000);
th :: ToHost;
FromDevice(eth2)
-> c :: Classifier(12/0800, 12/0806 20/0002, -)
-> Strip(14)
-> CheckIPHeader2
-> MarkIPHeader(0)
-> SetIPAddress(10.1.1.3)
-> aq::ARPQuerier(10.1.1.4, eth2)
-> oqueue

c[1] -> t::Tee -> [1]aq;
t[1] -> th
c[2] -> th

oqueue -> ToDevice(eth2);

10.1.1.4 is the ip-address of the machine where it is running, eth2 is the
interface, and i am sending packet to 10.1.1.3.

The configuration seems to work fine, except that i get very low speed. I
find in dmesg that there is constantly some warning message being thrown.
Any thoughts on what could be going wrong?

[688191.001209] ------------[ cut here ]------------
[688191.001215] WARNING: at
/build/buildd-linux-2.6_2.6.32-45-amd64-FcX7RM/linux-2.6-2.6.32/debian/build/source_amd64_none/net/core/dev.c:1582
skb_gso_segment+0x109/0x263()
[688191.001220] Hardware name: HP Z800 Workstation
[688191.001222] ixgbe: caps=(0x331cbb3, 0x0) len=2948 data_len=0 ip_summed=1
[688191.001225] Modules linked in: click ixgbe proclikefs cn autofs4 nfsd
exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc bridge stp loop
firewire_sbp2 snd_hda_codec_realtek snd_hda_intel snd_hda_codec wmi
snd_hwdep snd_pcm nouveau snd_timer ttm snd drm_kms_helper drm i2c_algo_bit
i2c_core soundcore snd_page_alloc evdev psmouse pcspkr serio_raw processor
button ext4 mbcache jbd2 crc16 dm_mod nbd usbhid hid sg sr_mod sd_mod cdrom
crc_t10dif mptsas uhci_hcd mptscsih mptbase firewire_ohci ahci
scsi_transport_sas libata scsi_mod firewire_core crc_itu_t tg3 libphy
ehci_hcd floppy thermal usbcore nls_base thermal_sys dca [last unloaded:
click]
[688191.001450] Pid: 20474, comm: kclick Tainted: G        W
 2.6.32-5-amd64 #1
[688191.001471] Call Trace:
[688191.001482]  [<ffffffff81250611>] ? skb_gso_segment+0x109/0x263
[688191.001514]  [<ffffffff81250611>] ? skb_gso_segment+0x109/0x263
[688191.001541]  [<ffffffff8104df40>] ? warn_slowpath_common+0x77/0xa3
[688191.001551]  [<ffffffff8104dfc8>] ? warn_slowpath_fmt+0x51/0x59
[688191.001572]  [<ffffffff810114ce>] ? common_interrupt+0xe/0x13
[688191.001581]  [<ffffffff8119363e>] ? strncpy+0x9/0x1e
[688191.001598]  [<ffffffffa0023238>] ? ixgbe_get_drvinfo+0x78/0xd0 [ixgbe]
[688191.001619]  [<ffffffff81250611>] ? skb_gso_segment+0x109/0x263
[688191.001633]  [<ffffffff8125091b>] ? dev_hard_start_xmit+0x1b0/0x2db
[688191.001647]  [<ffffffff8126392c>] ? sch_direct_xmit+0x58/0x14c
[688191.001669]  [<ffffffff81250d99>] ? dev_queue_xmit+0x252/0x38d
[688191.001738]  [<ffffffffa080f3f0>] ?
_ZN8ToDevice12queue_packetEP6PacketP12netdev_queue+0x110/0x1d0 [click]
[688191.001828]  [<ffffffffa080f5c5>] ?
_ZN8ToDevice8run_taskEP4Task+0x115/0x250 [click]
[688191.001910]  [<ffffffffa080ab17>] ?
_ZN10FromDevice8run_taskEP4Task+0x97/0xf0 [click]
[688191.001974]  [<ffffffffa07b9a8d>] ?
_ZN12RouterThread6driverEv+0x38d/0x580 [click]
[688191.002051]  [<ffffffffa0851fc0>] ? _ZL11click_schedPv+0x160/0x250
[click]
[688191.002087]  [<ffffffff810482db>] ? finish_task_switch+0x88/0xaf
[688191.002099]  [<ffffffff81011baa>] ? child_rip+0xa/0x20
[688191.002144]  [<ffffffffa0851e60>] ? _ZL11click_schedPv+0x0/0x250 [click]
[688191.002178]  [<ffffffff81011ba0>] ? child_rip+0x0/0x20
[688191.002198] ---[ end trace 1b77e8b33d8320fb ]---
[688191.002243] ------------[ cut here ]------------
[688191.002247] WARNING: at
/build/buildd-linux-2.6_2.6.32-45-amd64-FcX7RM/linux-2.6-2.6.32/debian/build/source_amd64_none/net/core/dev.c:1582
skb_gso_segment+0x109/0x263()
[688191.002252] Hardware name: HP Z800 Workstation
[688191.002258] ixgbe: caps=(0x331cbb3, 0x0) len=2948 data_len=0 ip_summed=1
[688191.002265] Modules linked in: click ixgbe proclikefs cn autofs4 nfsd
exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc bridge stp loop
firewire_sbp2 snd_hda_codec_realtek snd_hda_intel snd_hda_codec wmi
snd_hwdep snd_pcm nouveau snd_timer ttm snd drm_kms_helper drm i2c_algo_bit
i2c_core soundcore snd_page_alloc evdev psmouse pcspkr serio_raw processor
button ext4 mbcache jbd2 crc16 dm_mod nbd usbhid hid sg sr_mod sd_mod cdrom
crc_t10dif mptsas uhci_hcd mptscsih mptbase firewire_ohci ahci
scsi_transport_sas libata scsi_mod firewire_core crc_itu_t tg3 libphy
ehci_hcd floppy thermal usbcore nls_base thermal_sys dca [last unloaded:
click]
[688191.002486] Pid: 20474, comm: kclick Tainted: G        W
 2.6.32-5-amd64 #1
[688191.002492] Call Trace:
[688191.002499]  [<ffffffff81250611>] ? skb_gso_segment+0x109/0x263
[688191.002509]  [<ffffffff81250611>] ? skb_gso_segment+0x109/0x263
[688191.002533]  [<ffffffff8104df40>] ? warn_slowpath_common+0x77/0xa3
[688191.002562]  [<ffffffff8104dfc8>] ? warn_slowpath_fmt+0x51/0x59
[688191.002589]  [<ffffffff810114ce>] ? common_interrupt+0xe/0x13
[688191.002611]  [<ffffffff8119363e>] ? strncpy+0x9/0x1e
[688191.002642]  [<ffffffffa0023238>] ? ixgbe_get_drvinfo+0x78/0xd0 [ixgbe]
[688191.002657]  [<ffffffff81250611>] ? skb_gso_segment+0x109/0x263
[688191.002687]  [<ffffffff8125091b>] ? dev_hard_start_xmit+0x1b0/0x2db
[688191.002710]  [<ffffffff8126392c>] ? sch_direct_xmit+0x58/0x14c
[688191.002728]  [<ffffffff81250d99>] ? dev_queue_xmit+0x252/0x38d
[688191.002795]  [<ffffffffa080f3f0>] ?
_ZN8ToDevice12queue_packetEP6PacketP12netdev_queue+0x110/0x1d0 [click]
[688191.002870]  [<ffffffffa080f5c5>] ?
_ZN8ToDevice8run_taskEP4Task+0x115/0x250 [click]
[688191.002957]  [<ffffffffa080ab17>] ?
_ZN10FromDevice8run_taskEP4Task+0x97/0xf0 [click]
[688191.003018]  [<ffffffffa07b9a8d>] ?
_ZN12RouterThread6driverEv+0x38d/0x580 [click]
[688191.003095]  [<ffffffffa0851fc0>] ? _ZL11click_schedPv+0x160/0x250
[click]
[688191.003130]  [<ffffffff810482db>] ? finish_task_switch+0x88/0xaf
[688191.003147]  [<ffffffff81011baa>] ? child_rip+0xa/0x20
[688191.003199]  [<ffffffffa0851e60>] ? _ZL11click_schedPv+0x0/0x250 [click]
[688191.003230]  [<ffffffff81011ba0>] ? child_rip+0x0/0x20
[688191.003250] ---[ end trace 1b77e8b33d8320fc ]---
[688191.003290] ------------[ cut here ]------------
[688191.003295] WARNING: at
/build/buildd-linux-2.6_2.6.32-45-amd64-FcX7RM/linux-2.6-2.6.32/debian/build/source_amd64_none/net/core/dev.c:1582
skb_gso_segment+0x109/0x263()
[688191.003300] Hardware name: HP Z800 Workstation
[688191.003304] ixgbe: caps=(0x331cbb3, 0x0) len=14532 data_len=0
ip_summed=1
[688191.003308] Modules linked in: click ixgbe proclikefs cn autofs4 nfsd
exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc bridge stp loop
firewire_sbp2 snd_hda_codec_realtek snd_hda_intel snd_hda_codec wmi
snd_hwdep snd_pcm nouveau snd_timer ttm snd drm_kms_helper drm i2c_algo_bit
i2c_core soundcore snd_page_alloc evdev psmouse pcspkr serio_raw processor
button ext4 mbcache jbd2 crc16 dm_mod nbd usbhid hid sg sr_mod sd_mod cdrom
crc_t10dif mptsas uhci_hcd mptscsih mptbase firewire_ohci ahci
scsi_transport_sas libata scsi_mod firewire_core crc_itu_t tg3 libphy
ehci_hcd floppy thermal usbcore nls_base thermal_sys dca [last unloaded:
click]
[688191.003545] Pid: 20474, comm: kclick Tainted: G        W
 2.6.32-5-amd64 #1
[688191.003568] Call Trace:
[688191.003584]  [<ffffffff81250611>] ? skb_gso_segment+0x109/0x263
[688191.003616]  [<ffffffff81250611>] ? skb_gso_segment+0x109/0x263
[688191.003644]  [<ffffffff8104df40>] ? warn_slowpath_common+0x77/0xa3
[688191.003667]  [<ffffffff8104dfc8>] ? warn_slowpath_fmt+0x51/0x59
[688191.003694]  [<ffffffff810114ce>] ? common_interrupt+0xe/0x13
[688191.003721]  [<ffffffff8119363e>] ? strncpy+0x9/0x1e
[688191.003752]  [<ffffffffa0023238>] ? ixgbe_get_drvinfo+0x78/0xd0 [ixgbe]
[688191.003782]  [<ffffffff81250611>] ? skb_gso_segment+0x109/0x263
[688191.003807]  [<ffffffff8125091b>] ? dev_hard_start_xmit+0x1b0/0x2db
[688191.003839]  [<ffffffff8126392c>] ? sch_direct_xmit+0x58/0x14c
[688191.003865]  [<ffffffff81250d99>] ? dev_queue_xmit+0x252/0x38d
[688191.003935]  [<ffffffffa080f3f0>] ?
_ZN8ToDevice12queue_packetEP6PacketP12netdev_queue+0x110/0x1d0 [click]
[688191.004018]  [<ffffffffa080f5c5>] ?
_ZN8ToDevice8run_taskEP4Task+0x115/0x250 [click]
[688191.004099]  [<ffffffffa080ab17>] ?
_ZN10FromDevice8run_taskEP4Task+0x97/0xf0 [click]
[688191.004166]  [<ffffffffa07b9a8d>] ?
_ZN12RouterThread6driverEv+0x38d/0x580 [click]
[688191.004240]  [<ffffffffa0851fc0>] ? _ZL11click_schedPv+0x160/0x250
[click]
[688191.004276]  [<ffffffff810482db>] ? finish_task_switch+0x88/0xaf
[688191.004297]  [<ffffffff81011baa>] ? child_rip+0xa/0x20
[688191.004355]  [<ffffffffa0851e60>] ? _ZL11click_schedPv+0x0/0x250 [click]
[688191.004373]  [<ffffffff81011ba0>] ? child_rip+0x0/0x20
[688191.004374] ---[ end trace 1b77e8b33d8320fd ]---


Regards,
Ashok

From ekohler at gmail.com  Fri Aug 17 10:08:35 2012
From: ekohler at gmail.com (Eddie Kohler)
Date: Fri, 17 Aug 2012 10:08:35 -0400
Subject: [Click] Recent optimizations may cause segmentation faults
In-Reply-To: <CECFD9D6-5BAA-4F78-B51C-228ABA49B144@nomadiclab.com>
References: <CECFD9D6-5BAA-4F78-B51C-228ABA49B144@nomadiclab.com>
Message-ID: <CAF0C5SJViGvj4fMbUQoT5Ja2LCzfom4G8s+a74j+r_P9_oYusw@mail.gmail.com>

Hi Jimmy,

Thanks for this bug report. I will shortly set up a FreeBSD VM to
test, but do the latest commits work for you?

Eddie


On Thu, Aug 16, 2012 at 5:55 AM, Jimmy Kj?llman
<jimmy.kjallman at nomadiclab.com> wrote:
> FYI,
>
> it seems that recent string-related optimizations in Click cause some problems when the code is compiled with GCC 4.2.1 - which is a rather old compiler, but is still used as the default compiler in some systems (e.g. in FreeBSD 8 and 9). Of course, some other versions of GCC might also have the same problem.
>
> The code gets compiled (without errors etc.), but segmentation faults may occur when Click is started.
>
> With other, newer compilers that I tried (e.g. GCC 4.6), the code seems to work as it should.
>
>
> Some more details:
>
> It seems that commit "String, StringAccum: Call strlen() early when the result's a constant" (8b94ae6) causes problems for GCC 4.2.1, at least based on my observations on FreeBSD and Mac OS X.
>
> E.g. in String::String(const char *cstr), the code based on __builtin_constant_p(strlen(cstr)) and inlining doesn't get compiled correctly for some reason, so assign(cstr, strlen(cstr), false) gets called instead of assign(cstr, -1, false) at runtime. Possibly this is what always happens. If then cstr is NULL (for example), calling strlen(NULL) obviously causes a segmentation fault.
>
> This error is very easy to produce: Running "click" without any arguments results in a segmentation fault in the string constructor. This happens before starting to read a configuration from stdin. Apparently this error also occurs if a configuration file given as input starts with require(...), for instance.
>
> The current code works if I compile Click e.g. with GCC 4.6 in FreeBSD or LLVM-GCC 4.2.1 in OS X - and that's OK for me. Possibly some other workarounds, such as giving suitable options to the old compiler, might also work - but I haven't tried any. And I'm not sure whether this error occurs on all platforms.
>
>
>  - Jimmy
>
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click


From feixiong at winlab.rutgers.edu  Sun Aug 19 11:30:58 2012
From: feixiong at winlab.rutgers.edu (Feixiong Zhang)
Date: Sun, 19 Aug 2012 11:30:58 -0400
Subject: [Click] need a timer which can be precise at 1 ms level
Message-ID: <CA+PrAhUAETSj5rSNC+SEtBEe2m4_5oWvZJ3BvKdBove4VJ+u_Q@mail.gmail.com>

Hi, all, I'm implementing a network-delay module as a click kernel module.
What the module does is that when it gets a packets, it will delay the
packet for a certain time (at millisecond order based on the packet's
incoming address) and then release it back to host stack. So I need a timer
that can fire precisely at millisecond level. I test the click timer's
function schedule_after_msec(1), but the timer actually fires after
normally 5~7 ms. Is there any other way to get a more precise timer? I took
a look at the timer document, it says there is a function adjustment()
which seems can be used. Can someone explain how it works in more detail?

Besides, what I found for the function timer.schedule_after_msec(1) is if
there are more frequent packets entering into the delay module, the timer
firing task will be delayed much more severely. Normally it will fire after
the incoming packets become sparse, but that is already long time later
than the time it should fire. Is this normal for click?

I'm using patchless click on linux 2.6.35-30-generic. I will appreciate a
lot if anyone can give some hints. Thanks.

Best Regards.
Feixiong

From jimmy.kjallman at nomadiclab.com  Mon Aug 20 05:45:04 2012
From: jimmy.kjallman at nomadiclab.com (=?iso-8859-1?Q?Jimmy_Kj=E4llman?=)
Date: Mon, 20 Aug 2012 12:45:04 +0300
Subject: [Click] Recent optimizations may cause segmentation faults
In-Reply-To: <CAF0C5SJViGvj4fMbUQoT5Ja2LCzfom4G8s+a74j+r_P9_oYusw@mail.gmail.com>
References: <CECFD9D6-5BAA-4F78-B51C-228ABA49B144@nomadiclab.com>
	<CAF0C5SJViGvj4fMbUQoT5Ja2LCzfom4G8s+a74j+r_P9_oYusw@mail.gmail.com>
Message-ID: <10D47001-C5B7-4250-B47D-3ABFA21101F2@nomadiclab.com>

Hi Eddie,

yes, the latest commits work. No segmentation faults now.

Thank you!

 - Jimmy


On 17.8.2012, at 17:08 , Eddie Kohler wrote:

> Hi Jimmy,
> 
> Thanks for this bug report. I will shortly set up a FreeBSD VM to
> test, but do the latest commits work for you?
> 
> Eddie
> 
> 
> On Thu, Aug 16, 2012 at 5:55 AM, Jimmy Kj?llman
> <jimmy.kjallman at nomadiclab.com> wrote:
>> FYI,
>> 
>> it seems that recent string-related optimizations in Click cause some problems when the code is compiled with GCC 4.2.1 - which is a rather old compiler, but is still used as the default compiler in some systems (e.g. in FreeBSD 8 and 9). Of course, some other versions of GCC might also have the same problem.
>> 
>> The code gets compiled (without errors etc.), but segmentation faults may occur when Click is started.
>> 
>> With other, newer compilers that I tried (e.g. GCC 4.6), the code seems to work as it should.
>> 
>> 
>> Some more details:
>> 
>> It seems that commit "String, StringAccum: Call strlen() early when the result's a constant" (8b94ae6) causes problems for GCC 4.2.1, at least based on my observations on FreeBSD and Mac OS X.
>> 
>> E.g. in String::String(const char *cstr), the code based on __builtin_constant_p(strlen(cstr)) and inlining doesn't get compiled correctly for some reason, so assign(cstr, strlen(cstr), false) gets called instead of assign(cstr, -1, false) at runtime. Possibly this is what always happens. If then cstr is NULL (for example), calling strlen(NULL) obviously causes a segmentation fault.
>> 
>> This error is very easy to produce: Running "click" without any arguments results in a segmentation fault in the string constructor. This happens before starting to read a configuration from stdin. Apparently this error also occurs if a configuration file given as input starts with require(...), for instance.
>> 
>> The current code works if I compile Click e.g. with GCC 4.6 in FreeBSD or LLVM-GCC 4.2.1 in OS X - and that's OK for me. Possibly some other workarounds, such as giving suitable options to the old compiler, might also work - but I haven't tried any. And I'm not sure whether this error occurs on all platforms.
>> 
>> 
>> - Jimmy
>> 
>> 
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click



From dave at copycall.com  Mon Aug 20 15:07:26 2012
From: dave at copycall.com (copycall)
Date: Mon, 20 Aug 2012 12:07:26 -0700
Subject: [Click] click voip router - donation
Message-ID: <CAKan7GpE5VGMWDjOs21qT5a48kzjr0AO8w=nEJaMGZaDfjwhpA@mail.gmail.com>

hello click list,

i am still looking for a click developer(savvy-user?) who can put together
a click version to maximize voip, specifically sip with 2 wan connections.

this is for my own business use.

donation or bounty is offered, please contact me off-list at dave at
copycall dot com.

thank you.

From bart.braem at ua.ac.be  Tue Aug 21 08:30:19 2012
From: bart.braem at ua.ac.be (Braem Bart)
Date: Tue, 21 Aug 2012 12:30:19 +0000
Subject: [Click] need a timer which can be precise at 1 ms level
In-Reply-To: <CA+PrAhUAETSj5rSNC+SEtBEe2m4_5oWvZJ3BvKdBove4VJ+u_Q@mail.gmail.com>
References: <CA+PrAhUAETSj5rSNC+SEtBEe2m4_5oWvZJ3BvKdBove4VJ+u_Q@mail.gmail.com>
Message-ID: <742A6D4F-D176-49A5-9DCD-EA5A79432F66@ua.ac.be>

Hi,

On 19 Aug 2012, at 17:30, Feixiong Zhang <feixiong at winlab.rutgers.edu> wrote:

> Hi, all, I'm implementing a network-delay module as a click kernel module.
> What the module does is that when it gets a packets, it will delay the
> packet for a certain time (at millisecond order based on the packet's
> incoming address) and then release it back to host stack. So I need a timer
> that can fire precisely at millisecond level. I test the click timer's
> function schedule_after_msec(1), but the timer actually fires after
> normally 5~7 ms. Is there any other way to get a more precise timer? I took
> a look at the timer document, it says there is a function adjustment()
> which seems can be used. Can someone explain how it works in more detail?
> 
> Besides, what I found for the function timer.schedule_after_msec(1) is if
> there are more frequent packets entering into the delay module, the timer
> firing task will be delayed much more severely. Normally it will fire after
> the incoming packets become sparse, but that is already long time later
> than the time it should fire. Is this normal for click?
> 
> I'm using patchless click on linux 2.6.35-30-generic. I will appreciate a
> lot if anyone can give some hints. Thanks.
> 

Take a look at <http://read.cs.ucla.edu/click/doxygen/class_timer.html#_details>
especially:
"Particularly at user level, there can be a significant delay between a Timer's nominal expiration time and the actual time it runs. Elements that desire extremely precise timings should combine a Timer with aTask. The Timer is set to go off a bit before the true expiration time (see Timer::adjustment()), after which the Task polls the CPU until the actual expiration time arrives."
This is how I would achieve a larger precision too.

best regards,
Bart

-- 
Bart Braem
PATS research group - IBBT
Dept. of Mathematics and Computer Science
University of Antwerp
Campus Middelheim, G3.26
Middelheimlaan 1
B-2020 Antwerpen, Belgium
Phone: +32 (0)3 265.38.64
Fax: +32 (0)3 265.37.77
Web: www.pats.ua.ac.be