From jiangmeng1272 at sina.com  Sun Jan  6 03:22:47 2013
From: jiangmeng1272 at sina.com (jiangmeng1272 at sina.com)
Date: Sun, 06 Jan 2013 16:22:47 +0800 
Subject: [Click] About Classifier
Message-ID: <20130106082247.5B7244780FC@webmail.sinamail.sina.com.cn>

Hi,
I am trying to develop a pragram with IPEncap. But when I want to use the element of Classifier, I am confused. I only know 
12/0806 20/0001 represent ARP requests; 12/0806 20/0002 represent ARP reples; 12/0800  represent IP packets and - represent others. But I don't know  which "offset/value" can represent IP-in-IP packets.Like following picture,how to represent each kind ? 
please help me.

Thank you
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ??1.jpg
Type: image/jpeg
Size: 11299 bytes
Desc: not available
Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20130106/77634d48/attachment-0001.jpg 

From ashok.anand at gmail.com  Sun Jan  6 09:52:32 2013
From: ashok.anand at gmail.com (Ashok Anand)
Date: Sun, 6 Jan 2013 20:22:32 +0530
Subject: [Click] netmap support?
Message-ID: <CALQsBOXw6oSWauT5sRabymxHDWOk_rNWbbqgHy0hd8hMj9J60A@mail.gmail.com>

Hi,

I was wondering if netmap has been integrated with click, and is available
to use. please let me know.

Regards,
Ashok

From cliff at meraki.com  Sun Jan  6 11:33:51 2013
From: cliff at meraki.com (Cliff Frey)
Date: Sun, 6 Jan 2013 08:33:51 -0800
Subject: [Click] About Classifier
In-Reply-To: <20130106082247.5B7244780FC@webmail.sinamail.sina.com.cn>
References: <20130106082247.5B7244780FC@webmail.sinamail.sina.com.cn>
Message-ID: <CAFtVOq=DhbQZWY0BgDYhi9ArJmsC5Y6OOPc5VN9N=zCAdubUUw@mail.gmail.com>

I would use a config like this:

Classifier(12/0800)
-> CheckIPHeader
-> IPClassifier(proto IP-ENCAP) // you could also use the value "4" instead
of "IP-ENCAP"

If you then wanted to do things with the encapsulated IP packet, you could
do something like

-> StripIPHeader
-> CheckIPHeader(0)
-> IPClassifier( ...)

Hope that this helps!

Cliff

On Sun, Jan 6, 2013 at 12:22 AM, <jiangmeng1272 at sina.com> wrote:

> Hi,
> I am trying to develop a pragram with IPEncap. But when I want to use the
> element of Classifier, I am confused. I only know
> 12/0806 20/0001 represent ARP requests; 12/0806 20/0002 represent ARP
> reples; 12/0800  represent IP packets and - represent others. But I don't
> know  which "offset/value" can represent IP-in-IP packets.Like following
> picture,how to represent each kind ?
> please help me.
>
> Thank you
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>
>

From vladimir.olteanu at cs.pub.ro  Mon Jan  7 01:37:20 2013
From: vladimir.olteanu at cs.pub.ro (Vladimir Olteanu)
Date: Mon, 07 Jan 2013 08:37:20 +0200
Subject: [Click] netmap support?
In-Reply-To: <CALQsBOXw6oSWauT5sRabymxHDWOk_rNWbbqgHy0hd8hMj9J60A@mail.gmail.com>
References: <CALQsBOXw6oSWauT5sRabymxHDWOk_rNWbbqgHy0hd8hMj9J60A@mail.gmail.com>
Message-ID: <50EA6D20.9060209@cs.pub.ro>

Hi,

A subset of the pcap api (pcap_inject etc.) has been implemented using 
netmap (check Luigi's website). You just need to change LD_LIBRARY_PATH 
before running Click.

BTW be sure to place "METHOD pcap" in the config strings of all 
FromDevice and ToDevice elements.

Vlad

On 01/06/2013 04:52 PM, Ashok Anand wrote:
> Hi,
>
> I was wondering if netmap has been integrated with click, and is available
> to use. please let me know.
>
> Regards,
> Ashok
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click


From pearce at cs.berkeley.edu  Mon Jan  7 20:51:58 2013
From: pearce at cs.berkeley.edu (Paul Pearce)
Date: Mon, 7 Jan 2013 17:51:58 -0800
Subject: [Click] [Bug] patchless click misbehaving with recent Linux
	kernel vlan changes
In-Reply-To: <CAOUgPvT-oxzqK66jOsKbhoyY3ie4uW6nFcDgm_KjeE98fLHdxw@mail.gmail.com>
References: <CAOUgPvT-oxzqK66jOsKbhoyY3ie4uW6nFcDgm_KjeE98fLHdxw@mail.gmail.com>
Message-ID: <CAOUgPvSMmV7RmRjaBJYNX0A+x1UgvgWN4FYgr4oG6V9mqgCBBg@mail.gmail.com>

Follow up.

After digging into the click source I found that click is simply
calling pcap_inject() on these packets. After tracing through the
libpcap source it looks like this may be another bug in the Linux
kernel. I've started a thread on linux-netdev relating to the issue.

http://marc.info/?l=linux-netdev&m=135760359019679&w=3

On Fri, Dec 21, 2012 at 2:07 PM, Paul Pearce <pearce at cs.berkeley.edu> wrote:
> Hello folks,
>
> Summary:
> Vlan tagged packets emitted by patchless click do not have the same
> properties as other vlan tagged packets on the same interface as of
> Linux 3.x.
>
> This is a bit long, so please indulge me.
>
> Background thread from the libpcap devs:
> http://www.mail-archive.com/tcpdump-workers at lists.tcpdump.org/msg06698.html
>
> Summary of the background thread:
> * In April 2011 (net-dev commit
> bcc6d47903612c3861201cc3a866fb604f26b8b2 ) the Linux kernel began
> stripping vlan information from packet *HEADERS* (not from the raw
> packets themselves) and inserting that information into the skb
> metadata prior to it reaching the filters.
> * As of today (12/21/2012) Berkeley Packet Filter (bpf) facilities
> don't have the ability to access the vlan meta-data (although such a
> patch is under review in net-next).
> * Also as of today (12/21/2012) libpcap has no way to do kernel-level
> filtering of packets based on vlan tags (this means capturing packets
> based on vlan tags on live interfaces). Although they're working on
> it.
>
> How does this impact click?
>
> Click packets are emitted with the vlan header information intact
> rather than being stripped and added to the skb metadata.
>
> **This means vlan tagged packets on the same interface have a mix of
> stripped and non-stripped headers. This causes a variety of problems
> including difficulty filtering packets**
>
> This problem manifests itself when you try to use a "vlan" tcpdump
> filter on a live interface. I realize tcpdump picking up the packets
> or not is a libpcap problem, not a click problem. I'm just using this
> to demonstrate that the click-emitted packets have different
> properties.
>
> The rest of this email documents tests to demonstrate the problem
> along with more info about the ramifications.
>
> **********
>
> Sample click config (run from click git commit
> 9200a743a27f4a0e8f40299e5f8d865e248282b1 Nov 9 2012):
> -----------------------------------------------------
> InfiniteSource(PAYLOAD, LIMIT 1)
>         // This isn't a properly formatted ARP packet, but it doesn't
> matter for this test.
>         -> EtherVLANEncap(0x0806, 1:1:1:1:1:1, 2:2:2:2:2:2, 99)
>         -> Queue
>         -> ToDevice(eth3);
> -----------------------------------------------------
>
> For the test I externally send a single real arp packet from another
> machine to eth3 with a vlan tag of 5. I then turn on click so it emits
> one vlan 99 tagged packet.
>
> Output of `tcpdump -i eth3 -e -n -XX`:
> -------------------------------------------------------------
>
> 13:28:02.011785 00:50:56:9c:4c:82 > Broadcast, ethertype 802.1Q
> (0x8100), length 64: vlan 5, p 0, ethertype ARP, Request who-has
> 10.3.0.3 tell 10.3.9.111, length 46
> 0x0000:  ffff ffff ffff 0050 569c 4c82 8100 0005  .......PV.L.....
> 0x0010:  0806 0001 0800 0604 0001 0050 569c 4c82  ...........PV.L.
> 0x0020:  0a03 096f 0000 0000 0000 0a03 0003 0000  ...o............
> 0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>
> 13:28:03.710886 01:01:01:01:01:01 > 02:02:02:02:02:02, ethertype
> 802.1Q (0x8100), length 25: vlan 99, p 0, ethertype ARP, [|ARP]
> 0x0000:  0202 0202 0202 0101 0101 0101 8100 0063  ...............c
> 0x0010:  0806 5041 594c 4f41 44                   ..PAYLOAD
>
> -------------------------------------------------------------
> This is expected, we see the actual packet as well as the generated
> packet from our infinite source since we aren't using any filters
>
> Output of tcpdump -i eth3 -e -n -XX "vlan":
> -------------------------------------------------------------
>
> 13:28:03.710882 01:01:01:01:01:01 > 02:02:02:02:02:02, ethertype
> 802.1Q (0x8100), length 25: vlan 99, p 0, ethertype ARP, [|ARP]
> 0x0000:  0202 0202 0202 0101 0101 0101 8100 0063  ...............c
> 0x0010:  0806 5041 594c 4f41 44                   ..PAYLOAD
>
> --------------------------------------------------------------
>
> This is the problem. The correct behavior (believe it or not) is to
> not see anything.
>
> If click conformed to the new Linux behavior of stripped headers and
> skb meta data we'd not see anything since libpcap hasn't updated to
> conform to the new standard. If click doesn't conform to the new Linux
> behavior once libpcap and bpf's update these packets will be lost.
>
> At present because of the mix of stripped and non-stripped headers
> when click is in use it's impossible to write a single packet filter
> that will match both classes of packets. For example if I wanted to
> filter arp packets, I'd need the filter "arp" for the real vlan tagged
> packets, and the filter "vlan and arp" for the click emitted vlan
> packets.
>
> If this behavior can't be avoided for some reason I think a big
> documentation warning is necessary at the least.
>
> Ugh. What a mess. =(
>
> -Paul Pearce
>
> Security Graduate Student
> Computer Science
> University of California, Berkeley

From mkarthick19 at gmail.com  Tue Jan  8 05:28:53 2013
From: mkarthick19 at gmail.com (karthick m)
Date: Tue, 8 Jan 2013 15:58:53 +0530
Subject: [Click] Click router
Message-ID: <CACeiqXQywrjxvmRXuE25k7GyQz=wNb2uB6NCfajeKmZp=j=VDg@mail.gmail.com>

Hi,

   I want to implement my own architecture using Click router in a small
scale real time testbed using 10 machines.  My question is,

How to connect two machines using click router?
Is there any documentation for doing that?

From kyr.zarifis at gmail.com  Wed Jan  9 23:33:49 2013
From: kyr.zarifis at gmail.com (Kyriakos Zarifis)
Date: Thu, 10 Jan 2013 04:33:49 +0000
Subject: [Click] Some packets emitted but not received across the wire
Message-ID: <CAHUnSZoXuxDR-UUiccAd0Nz-o=36Lo6RSG78mzduJybAuLiu2g@mail.gmail.com>

Hi all,

I just recently started using Click (and I love it!)

For experimentation/practice, I am playing with a toy element that bounces
random packets to a port other than the one they are destined to, with a
10% chance.

I have this topology:

    s1
     |
    s0
  /     \
A       B

I send single pings from A to B. The expected behavior is to see most echo
replies/requests go only through s0, but 10% of the packets should be
bounced to s1, back to s0, and then to their destination.

The problem I am seeing is that this works _sometimes_, but most of the
times when a packet is bounced to s1, it disappears on its way back to s0.
This happens both in user and kernel space.
I can verify that the bounced packet seems to be leaving s1 both by tcpdump
(in userspace) and by IPPrints(in kernelspace), but then it never appears
on s0's interface (neither in tcpdumps nor in click Print logs).

When the bounce works, the tcpdumps/logs show it was bounced just fine, but
I get very few successful bounces (maybe 10%), while most in most cases the
bounced packet disappears on its way back.


I went through the list archives and saw a few people had some similar
problem where they couldn't emit packets to ToDevice if the same interface
had been initialized with FromDevice, and in some cases that was resolved
by using "METHOD LINUX". I tried that in user level but got the same
behavior. Also, in my case the packets disappear *most* of the time, but
not *always*, so I'm not sure if this is the same issue.


This has been troubling me all day, and most of all I'm confused by the
fact that it works sometimes, but I haven't been able to see a pattern,
other than maybe that the successful bounce rate seems to be a bit higher
right after the switch has been restarted (but I don't know how this can be
related so it's probably just my impression)

Any ideas would be very welcome, thanks.



A simplified version of s0.click looks something like this:

q0 :: Queue(10);
q1 :: Queue(10);
q2 :: Queue(10);
s :: LinearIPLookup(10.1.1.1/32 0,
10.1.1.2/32 1);
b0 :: Bouncer();   //outputs to b[0] with 90%, to b[1] with 10%
b1 :: Bouncer();
classifier1::Classifier(12/0806 20/0001, 12/0806 20/0002, 12/0800, -);
FromDevice(eth0, PROMISC true) -> [0]classifier1;
FromDevice(eth1, PROMISC true) -> [0]classifier1;
FromDevice(eth2, PROMISC true) -> [0]classifier1;
classifier[0]->Discard;
classifier[1]->Discard;
classifier[2]->Strip(14)->CheckIPHeader(INTERFACES 10.0.0.0/8)-
>IPPrint("in")->[0]s;
classifier1[3]->Discard;
s[0] -> Unstrip(14)->b0;
s[1] -> Unstrip(14)->b1;

b0[0]->q0;   //forward to h0 normally
b0[1]->q2;   //bounce to s1
b1[0]->q1;   //forward to h1
b0[1]->q2;   //bounce to s1

q0->ToDevice(eth0);
q1->ToDevice(eth1);
q2->IPPrint("bounced")->ToDevice(eth2);


and s1.click looks like this:

q0 :: Queue(100);
s :: LinearIPLookup(10.1.1.1/32 0,
10.1.1.2/32 0);
classifier1::Classifier(12/0806 20/0001, 12/0806 20/0002, 12/0800, -);
FromDevice(eth0, PROMISC true) -> [0]classifier;
classifier[0]->Discard;
classifier[1]->Discard;
classifier[2]->Strip(14)->CheckIPHeader(INTERFACES 10.0.0.0/8)-
>IPPrint("in")->[0]s;
classifier[3]->Discard;
s[0] -> Unstrip(14)->q1;

q1->IPPrint("out q1")->ToDevice(eth0);


Thanks!

From lichtbla at informatik.hu-berlin.de  Thu Jan 10 18:26:36 2013
From: lichtbla at informatik.hu-berlin.de (=?ISO-8859-1?Q?Bj=F6rn_Lichtblau?=)
Date: Fri, 11 Jan 2013 00:26:36 +0100
Subject: [Click] Args::read_or_set
Message-ID: <50EF4E2C.7080609@informatik.hu-berlin.de>

Hi,


Args::read_or_set does not work for me (actually it is not used 
anywhere), the default is not set when the argument is not given and 
parsing fails.
Seems like _read_status should be set before going into postparse (see 
attached patch) ?

Regards, Bj?rn





-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-FIX-Args-read_or_set.patch
Type: text/x-patch
Size: 869 bytes
Desc: not available
Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20130111/d5fb3e02/attachment-0001.bin 

From kyr.zarifis at gmail.com  Thu Jan 10 19:27:36 2013
From: kyr.zarifis at gmail.com (Kyriakos Zarifis)
Date: Fri, 11 Jan 2013 00:27:36 +0000
Subject: [Click] Some packets emitted but not received across the wire
In-Reply-To: <CAHUnSZoXuxDR-UUiccAd0Nz-o=36Lo6RSG78mzduJybAuLiu2g@mail.gmail.com>
References: <CAHUnSZoXuxDR-UUiccAd0Nz-o=36Lo6RSG78mzduJybAuLiu2g@mail.gmail.com>
Message-ID: <CAHUnSZpQuVQYwk69B67pQacuvwW50wuwT34QfrOOz=wC7o+RJw@mail.gmail.com>

A small follow up, I'm verifying that bounced packets leave s0 but don't
come back to it:
(these are stats before/after the ping)

s0> ifconfig eth3
          RX packets:136 errors:0 dropped:0 overruns:0 frame:0
          TX packets:151 errors:0 dropped:0 overruns:0 carrier:0
s0> ifconfig eth3
          RX packets:136 errors:0 dropped:0 overruns:0 frame:0
          TX packets:152 errors:0 dropped:0 overruns:0 carrier:0

..although they get in and back out of s1 (towards s0)
s1> ifconfig eth2
          RX packets:197 errors:0 dropped:0 overruns:0 frame:0
          TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
s1> ifconfig eth2
          RX packets:198 errors:0 dropped:0 overruns:0 frame:0
          TX packets:161 errors:0 dropped:0 overruns:0 carrier:0


... I am confused.


On Thu, Jan 10, 2013 at 4:33 AM, Kyriakos Zarifis <kyr.zarifis at gmail.com>wrote:

> Hi all,
>
> I just recently started using Click (and I love it!)
>
> For experimentation/practice, I am playing with a toy element that bounces
> random packets to a port other than the one they are destined to, with a
> 10% chance.
>
> I have this topology:
>
>     s1
>      |
>     s0
>   /     \
> A       B
>
> I send single pings from A to B. The expected behavior is to see most echo
> replies/requests go only through s0, but 10% of the packets should be
> bounced to s1, back to s0, and then to their destination.
>
> The problem I am seeing is that this works _sometimes_, but most of the
> times when a packet is bounced to s1, it disappears on its way back to s0.
> This happens both in user and kernel space.
> I can verify that the bounced packet seems to be leaving s1 both by
> tcpdump (in userspace) and by IPPrints(in kernelspace), but then it never
> appears on s0's interface (neither in tcpdumps nor in click Print logs).
>
> When the bounce works, the tcpdumps/logs show it was bounced just fine,
> but I get very few successful bounces (maybe 10%), while most in most cases
> the bounced packet disappears on its way back.
>
>
> I went through the list archives and saw a few people had some similar
> problem where they couldn't emit packets to ToDevice if the same interface
> had been initialized with FromDevice, and in some cases that was resolved
> by using "METHOD LINUX". I tried that in user level but got the same
> behavior. Also, in my case the packets disappear *most* of the time, but
> not *always*, so I'm not sure if this is the same issue.
>
>
> This has been troubling me all day, and most of all I'm confused by the
> fact that it works sometimes, but I haven't been able to see a pattern,
> other than maybe that the successful bounce rate seems to be a bit higher
> right after the switch has been restarted (but I don't know how this can be
> related so it's probably just my impression)
>
> Any ideas would be very welcome, thanks.
>
>
>
> A simplified version of s0.click looks something like this:
>
> q0 :: Queue(10);
> q1 :: Queue(10);
> q2 :: Queue(10);
> s :: LinearIPLookup(10.1.1.1/32 0,
> 10.1.1.2/32 1);
> b0 :: Bouncer();   //outputs to b[0] with 90%, to b[1] with 10%
> b1 :: Bouncer();
> classifier1::Classifier(12/0806 20/0001, 12/0806 20/0002, 12/0800, -);
> FromDevice(eth0, PROMISC true) -> [0]classifier1;
> FromDevice(eth1, PROMISC true) -> [0]classifier1;
> FromDevice(eth2, PROMISC true) -> [0]classifier1;
> classifier[0]->Discard;
> classifier[1]->Discard;
> classifier[2]->Strip(14)->CheckIPHeader(INTERFACES 10.0.0.0/8)-
> >IPPrint("in")->[0]s;
> classifier1[3]->Discard;
> s[0] -> Unstrip(14)->b0;
> s[1] -> Unstrip(14)->b1;
>
> b0[0]->q0;   //forward to h0 normally
> b0[1]->q2;   //bounce to s1
> b1[0]->q1;   //forward to h1
> b0[1]->q2;   //bounce to s1
>
> q0->ToDevice(eth0);
> q1->ToDevice(eth1);
> q2->IPPrint("bounced")->ToDevice(eth2);
>
>
> and s1.click looks like this:
>
> q0 :: Queue(100);
> s :: LinearIPLookup(10.1.1.1/32 0,
> 10.1.1.2/32 0);
> classifier1::Classifier(12/0806 20/0001, 12/0806 20/0002, 12/0800, -);
> FromDevice(eth0, PROMISC true) -> [0]classifier;
> classifier[0]->Discard;
> classifier[1]->Discard;
> classifier[2]->Strip(14)->CheckIPHeader(INTERFACES 10.0.0.0/8)-
> >IPPrint("in")->[0]s;
> classifier[3]->Discard;
> s[0] -> Unstrip(14)->q1;
>
> q1->IPPrint("out q1")->ToDevice(eth0);
>
>
> Thanks!
>

From ekohler at gmail.com  Fri Jan 11 12:46:59 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Fri, 11 Jan 2013 12:46:59 -0500
Subject: [Click] Args::read_or_set
In-Reply-To: <50EF4E2C.7080609@informatik.hu-berlin.de>
References: <50EF4E2C.7080609@informatik.hu-berlin.de>
Message-ID: <CAF0C5SL8VAaPNo-ZmCQdDvxSdW=NeMmLfncdKBc0KzfEx1zw=g@mail.gmail.com>

Nice patch. Thanks for it! It's applied.


On Thu, Jan 10, 2013 at 6:26 PM, Bj?rn Lichtblau
<lichtbla at informatik.hu-berlin.de> wrote:
> Hi,
>
>
> Args::read_or_set does not work for me (actually it is not used anywhere),
> the default is not set when the argument is not given and parsing fails.
> Seems like _read_status should be set before going into postparse (see
> attached patch) ?
>
> Regards, Bj?rn
>
>
>
>
>
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>


From ekohler at gmail.com  Tue Jan 15 14:52:38 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Tue, 15 Jan 2013 14:52:38 -0500
Subject: [Click] netmap support?
In-Reply-To: <50EA6D20.9060209@cs.pub.ro>
References: <CALQsBOXw6oSWauT5sRabymxHDWOk_rNWbbqgHy0hd8hMj9J60A@mail.gmail.com>
	<50EA6D20.9060209@cs.pub.ro>
Message-ID: <50F5B386.6070403@gmail.com>

Click also has preliminary support for native netmap. Configure with 
--with-netmap and report any bugs here.

Eddie


On 1/7/13 1:37 AM, Vladimir Olteanu wrote:
> Hi,
>
> A subset of the pcap api (pcap_inject etc.) has been implemented using
> netmap (check Luigi's website). You just need to change LD_LIBRARY_PATH
> before running Click.
>
> BTW be sure to place "METHOD pcap" in the config strings of all
> FromDevice and ToDevice elements.
>
> Vlad
>
> On 01/06/2013 04:52 PM, Ashok Anand wrote:
>> Hi,
>>
>> I was wondering if netmap has been integrated with click, and is available
>> to use. please let me know.
>>
>> Regards,
>> Ashok
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From ekohler at gmail.com  Tue Jan 15 14:53:39 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Tue, 15 Jan 2013 14:53:39 -0500
Subject: [Click] Error when Trying to Compile Click
In-Reply-To: <SNT002-W205F33CBA5A1111770538BCC03C0@phx.gbl>
References: <SNT002-W205F33CBA5A1111770538BCC03C0@phx.gbl>
Message-ID: <50F5B3C3.9040606@gmail.com>

You should look at the output of ./configure, which probably told you 
what the problem was.


On 12/30/12 7:23 PM, - ??Ruolin Fan wrote:
> Hi, when trying to compile CLICK linux modules under the VCORE-4.4 VM environment, I get the following message:
> core at vcore:~/Desktop/click-2.0.1/linuxmodule$ makeecho "linuxmodule  analysis app aqm ethernet icmp ip simple standard tcpudp test threads" | ../click-buildtool findelem -r linuxmodule -p .. -X ./elements.exclude  > elements.conf../click-buildtool elem2make -x "addressinfo.o alignmentinfo.o errorelement.o portinfo.o scheduleinfo.o" < elements.conf > elements.mk  CXX ../lib/string.ccIn file included from ../include/click/atomic.hh:5:0,                 from ../include/click/string.hh:5,                 from ../lib/string.cc:22:../include/click/glue.hh:25:27: fatal error: linux/skbuff.h: No such file or directorycompilation terminated.make: *** [string.o] Error 1
> Not sure why there's a missing header problem. Any help would be greatly appreciated. Note that when compiling from the main directory "click-2.0.1", there are no errors, but the click-install command does not work.
> Thank you,
> Ruolin 		 	   		
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From ekohler at gmail.com  Tue Jan 15 14:56:45 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Tue, 15 Jan 2013 14:56:45 -0500
Subject: [Click] [Bug] patchless click misbehaving with recent Linux
 kernel vlan changes
In-Reply-To: <CAOUgPvSMmV7RmRjaBJYNX0A+x1UgvgWN4FYgr4oG6V9mqgCBBg@mail.gmail.com>
References: <CAOUgPvT-oxzqK66jOsKbhoyY3ie4uW6nFcDgm_KjeE98fLHdxw@mail.gmail.com>
	<CAOUgPvSMmV7RmRjaBJYNX0A+x1UgvgWN4FYgr4oG6V9mqgCBBg@mail.gmail.com>
Message-ID: <50F5B47D.1090909@gmail.com>

Hi Paul,

It sounds like you are running at userlevel, and that you are using 
METHOD PCAP (which is the default in recent versions)? Do let us know if 
you discover more. You could also try METHOD LINUX, although this is 
slower than pcap I believe.

Eddie


On 1/7/13 8:51 PM, Paul Pearce wrote:
> Follow up.
>
> After digging into the click source I found that click is simply
> calling pcap_inject() on these packets. After tracing through the
> libpcap source it looks like this may be another bug in the Linux
> kernel. I've started a thread on linux-netdev relating to the issue.
>
> http://marc.info/?l=linux-netdev&m=135760359019679&w=3
>
> On Fri, Dec 21, 2012 at 2:07 PM, Paul Pearce <pearce at cs.berkeley.edu> wrote:
>> Hello folks,
>>
>> Summary:
>> Vlan tagged packets emitted by patchless click do not have the same
>> properties as other vlan tagged packets on the same interface as of
>> Linux 3.x.
>>
>> This is a bit long, so please indulge me.
>>
>> Background thread from the libpcap devs:
>> http://www.mail-archive.com/tcpdump-workers at lists.tcpdump.org/msg06698.html
>>
>> Summary of the background thread:
>> * In April 2011 (net-dev commit
>> bcc6d47903612c3861201cc3a866fb604f26b8b2 ) the Linux kernel began
>> stripping vlan information from packet *HEADERS* (not from the raw
>> packets themselves) and inserting that information into the skb
>> metadata prior to it reaching the filters.
>> * As of today (12/21/2012) Berkeley Packet Filter (bpf) facilities
>> don't have the ability to access the vlan meta-data (although such a
>> patch is under review in net-next).
>> * Also as of today (12/21/2012) libpcap has no way to do kernel-level
>> filtering of packets based on vlan tags (this means capturing packets
>> based on vlan tags on live interfaces). Although they're working on
>> it.
>>
>> How does this impact click?
>>
>> Click packets are emitted with the vlan header information intact
>> rather than being stripped and added to the skb metadata.
>>
>> **This means vlan tagged packets on the same interface have a mix of
>> stripped and non-stripped headers. This causes a variety of problems
>> including difficulty filtering packets**
>>
>> This problem manifests itself when you try to use a "vlan" tcpdump
>> filter on a live interface. I realize tcpdump picking up the packets
>> or not is a libpcap problem, not a click problem. I'm just using this
>> to demonstrate that the click-emitted packets have different
>> properties.
>>
>> The rest of this email documents tests to demonstrate the problem
>> along with more info about the ramifications.
>>
>> **********
>>
>> Sample click config (run from click git commit
>> 9200a743a27f4a0e8f40299e5f8d865e248282b1 Nov 9 2012):
>> -----------------------------------------------------
>> InfiniteSource(PAYLOAD, LIMIT 1)
>>          // This isn't a properly formatted ARP packet, but it doesn't
>> matter for this test.
>>          -> EtherVLANEncap(0x0806, 1:1:1:1:1:1, 2:2:2:2:2:2, 99)
>>          -> Queue
>>          -> ToDevice(eth3);
>> -----------------------------------------------------
>>
>> For the test I externally send a single real arp packet from another
>> machine to eth3 with a vlan tag of 5. I then turn on click so it emits
>> one vlan 99 tagged packet.
>>
>> Output of `tcpdump -i eth3 -e -n -XX`:
>> -------------------------------------------------------------
>>
>> 13:28:02.011785 00:50:56:9c:4c:82 > Broadcast, ethertype 802.1Q
>> (0x8100), length 64: vlan 5, p 0, ethertype ARP, Request who-has
>> 10.3.0.3 tell 10.3.9.111, length 46
>> 0x0000:  ffff ffff ffff 0050 569c 4c82 8100 0005  .......PV.L.....
>> 0x0010:  0806 0001 0800 0604 0001 0050 569c 4c82  ...........PV.L.
>> 0x0020:  0a03 096f 0000 0000 0000 0a03 0003 0000  ...o............
>> 0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>>
>> 13:28:03.710886 01:01:01:01:01:01 > 02:02:02:02:02:02, ethertype
>> 802.1Q (0x8100), length 25: vlan 99, p 0, ethertype ARP, [|ARP]
>> 0x0000:  0202 0202 0202 0101 0101 0101 8100 0063  ...............c
>> 0x0010:  0806 5041 594c 4f41 44                   ..PAYLOAD
>>
>> -------------------------------------------------------------
>> This is expected, we see the actual packet as well as the generated
>> packet from our infinite source since we aren't using any filters
>>
>> Output of tcpdump -i eth3 -e -n -XX "vlan":
>> -------------------------------------------------------------
>>
>> 13:28:03.710882 01:01:01:01:01:01 > 02:02:02:02:02:02, ethertype
>> 802.1Q (0x8100), length 25: vlan 99, p 0, ethertype ARP, [|ARP]
>> 0x0000:  0202 0202 0202 0101 0101 0101 8100 0063  ...............c
>> 0x0010:  0806 5041 594c 4f41 44                   ..PAYLOAD
>>
>> --------------------------------------------------------------
>>
>> This is the problem. The correct behavior (believe it or not) is to
>> not see anything.
>>
>> If click conformed to the new Linux behavior of stripped headers and
>> skb meta data we'd not see anything since libpcap hasn't updated to
>> conform to the new standard. If click doesn't conform to the new Linux
>> behavior once libpcap and bpf's update these packets will be lost.
>>
>> At present because of the mix of stripped and non-stripped headers
>> when click is in use it's impossible to write a single packet filter
>> that will match both classes of packets. For example if I wanted to
>> filter arp packets, I'd need the filter "arp" for the real vlan tagged
>> packets, and the filter "vlan and arp" for the click emitted vlan
>> packets.
>>
>> If this behavior can't be avoided for some reason I think a big
>> documentation warning is necessary at the least.
>>
>> Ugh. What a mess. =(
>>
>> -Paul Pearce
>>
>> Security Graduate Student
>> Computer Science
>> University of California, Berkeley
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From ekohler at gmail.com  Tue Jan 15 14:57:26 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Tue, 15 Jan 2013 14:57:26 -0500
Subject: [Click] Warnings when compiling latest version of Click on
 Linux 2.6.24.7
In-Reply-To: <A6831FD3-ABFD-4482-8E9B-7CBFA56F71D9@eecs.berkeley.edu>
References: <A6831FD3-ABFD-4482-8E9B-7CBFA56F71D9@eecs.berkeley.edu>
Message-ID: <50F5B4A6.2090205@gmail.com>

You're using the patch I guess...? Yes, that warning can be ignored. If 
you were using a more recent Click version I don't think you'd even see it.

Eddie


On 12/30/12 2:37 PM, David Zats wrote:
> Hi,
>
> I get the following warning message when trying to compile click on Linux 2.6.24.7:
>
> cc1plus: warning: command line option "-ffreestanding" is valid for C/ObjC but not for C++
> In file included from /lib/modules/2.6.24.7-click/build/include/linux/timer.h:7,
>                   from /lib/modules/2.6.24.7-click/build/include/linux/workqueue.h:8,
>                   from /lib/modules/2.6.24.7-click/build/include/linux/slub_def.h:11,
>                   from /lib/modules/2.6.24.7-click/build/include/linux/slab.h:118,
>                   from /lib/modules/2.6.24.7-click/build/include/linux/percpu.h:5,
>                   from /lib/modules/2.6.24.7-click/build/include/asm/desc_32.h:11,
>                   from /lib/modules/2.6.24.7-click/build/include/asm/desc.h:2,
>                   from /lib/modules/2.6.24.7-click/build/include/asm/elf.h:80,
>                   from /lib/modules/2.6.24.7-click/build/include/linux/elf.h:6,
>                   from /lib/modules/2.6.24.7-click/build/include/linux/module.h:14,
>                   from /lib/modules/2.6.24.7-click/build/include/linux/textsearch.h:9,
>                   from /lib/modules/2.6.24.7-click/build/include/linux/skbuff.h:26,
>                   from /clicknode/newclick/linuxmodule/../include/click/glue.hh:25,
>                   from /clicknode/newclick/linuxmodule/../include/click/atomic.hh:5,
>                   from /clicknode/newclick/linuxmodule/../include/click/string.hh:5,
>                   from /clicknode/newclick/linuxmodule/../include/click/error.hh:4,
>                   from /clicknode/newclick/linuxmodule/../lib/error.cc:22:
> /lib/modules/2.6.24.7-click/build/include/linux/hrtimer.h: In function ?void timer_stats_account_hrtimer(hrtimer*)?:
> /lib/modules/2.6.24.7-click/build/include/linux/hrtimer.h:338: warning: invalid conversion from ?hrtimer_restart (*)(hrtimer*)? to ?void*?
> /lib/modules/2.6.24.7-click/build/include/linux/hrtimer.h:338: warning:   initializing argument 4 of ?void timer_stats_update_stats(void*, pid_t, void*, void*, char*, unsigned int)?
>
> The compilation does complete, but I was wondering if these warnings can be safely ignored.
>
> Thank you!
> David Zats
>
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From mkarthick19 at gmail.com  Tue Jan 15 15:08:16 2013
From: mkarthick19 at gmail.com (karthick m)
Date: Wed, 16 Jan 2013 01:38:16 +0530
Subject: [Click] Args::read_or_set
In-Reply-To: <CAF0C5SL8VAaPNo-ZmCQdDvxSdW=NeMmLfncdKBc0KzfEx1zw=g@mail.gmail.com>
References: <50EF4E2C.7080609@informatik.hu-berlin.de>
	<CAF0C5SL8VAaPNo-ZmCQdDvxSdW=NeMmLfncdKBc0KzfEx1zw=g@mail.gmail.com>
Message-ID: <CACeiqXRuVD0jW+jk-EP4fSWA51429XFgc5bNSwhJrULO0aDMkg@mail.gmail.com>

Hi,

   I want to implement my own publish-subscribe architecture in a small
scale testbed (say with 10 machines) using click router. Could anyone
please tell me how to start with click router. I have visited the click
router main website and also some sample codes. But I am facing difficulty
with that. For Omnet++, we have tictoc tutorial. Do we have something
similar for click router?  Please let me know.

From giorgio.calarco at unibo.it  Tue Jan 15 15:35:45 2013
From: giorgio.calarco at unibo.it (Giorgio Calarco)
Date: Tue, 15 Jan 2013 21:35:45 +0100
Subject: [Click] [Bug] patchless click misbehaving with recent Linux
 kernel vlan changes
In-Reply-To: <50F5B47D.1090909@gmail.com>
References: <CAOUgPvT-oxzqK66jOsKbhoyY3ie4uW6nFcDgm_KjeE98fLHdxw@mail.gmail.com>
	<CAOUgPvSMmV7RmRjaBJYNX0A+x1UgvgWN4FYgr4oG6V9mqgCBBg@mail.gmail.com>
	<50F5B47D.1090909@gmail.com>
Message-ID: <CAOCbBQNdL0uBOcNvJqHcW42pUE_JSqqNw4Kc38SkHLKjKqhJvg@mail.gmail.com>

Hi all,

last year (may and november ?) I already reported about this problem with
pcap
and linux 3.0.x kernels. I did not follow the problem
in depth, however I previously found out that
 the pcap method used to send packets by ToDevice
(pcap_inject, not sure but I think so) seems not to be
existing anymore. Therefore, ToDevice (which default method is actually
PCAP)
simply stucks and sends nothing. What I found confusing is that
at the ./configure stage, since pcap_inject is not found within
the pcap library, it is substituted by a dummy method (which does
nothing) and the compilation goes on as if everything was fine.
This can be misleading, and some messages from the stdout
would be helpful, since the problem can then be determined only
by examining the (long) configure.log file.

Moreover, I'm not sure if this is really a bug, maybe there's a new pcap
method to call to xmit a packet now ?

(The kernel development is becoming overwhelming, I think)

My regards,
Giorgio


On Tue, Jan 15, 2013 at 8:56 PM, Eddie Kohler <ekohler at gmail.com> wrote:

> Hi Paul,
>
> It sounds like you are running at userlevel, and that you are using
> METHOD PCAP (which is the default in recent versions)? Do let us know if
> you discover more. You could also try METHOD LINUX, although this is
> slower than pcap I believe.
>
> Eddie
>
>
> On 1/7/13 8:51 PM, Paul Pearce wrote:
> > Follow up.
> >
> > After digging into the click source I found that click is simply
> > calling pcap_inject() on these packets. After tracing through the
> > libpcap source it looks like this may be another bug in the Linux
> > kernel. I've started a thread on linux-netdev relating to the issue.
> >
> > http://marc.info/?l=linux-netdev&m=135760359019679&w=3
> >
> > On Fri, Dec 21, 2012 at 2:07 PM, Paul Pearce <pearce at cs.berkeley.edu>
> wrote:
> >> Hello folks,
> >>
> >> Summary:
> >> Vlan tagged packets emitted by patchless click do not have the same
> >> properties as other vlan tagged packets on the same interface as of
> >> Linux 3.x.
> >>
> >> This is a bit long, so please indulge me.
> >>
> >> Background thread from the libpcap devs:
> >>
> http://www.mail-archive.com/tcpdump-workers at lists.tcpdump.org/msg06698.html
> >>
> >> Summary of the background thread:
> >> * In April 2011 (net-dev commit
> >> bcc6d47903612c3861201cc3a866fb604f26b8b2 ) the Linux kernel began
> >> stripping vlan information from packet *HEADERS* (not from the raw
> >> packets themselves) and inserting that information into the skb
> >> metadata prior to it reaching the filters.
> >> * As of today (12/21/2012) Berkeley Packet Filter (bpf) facilities
> >> don't have the ability to access the vlan meta-data (although such a
> >> patch is under review in net-next).
> >> * Also as of today (12/21/2012) libpcap has no way to do kernel-level
> >> filtering of packets based on vlan tags (this means capturing packets
> >> based on vlan tags on live interfaces). Although they're working on
> >> it.
> >>
> >> How does this impact click?
> >>
> >> Click packets are emitted with the vlan header information intact
> >> rather than being stripped and added to the skb metadata.
> >>
> >> **This means vlan tagged packets on the same interface have a mix of
> >> stripped and non-stripped headers. This causes a variety of problems
> >> including difficulty filtering packets**
> >>
> >> This problem manifests itself when you try to use a "vlan" tcpdump
> >> filter on a live interface. I realize tcpdump picking up the packets
> >> or not is a libpcap problem, not a click problem. I'm just using this
> >> to demonstrate that the click-emitted packets have different
> >> properties.
> >>
> >> The rest of this email documents tests to demonstrate the problem
> >> along with more info about the ramifications.
> >>
> >> **********
> >>
> >> Sample click config (run from click git commit
> >> 9200a743a27f4a0e8f40299e5f8d865e248282b1 Nov 9 2012):
> >> -----------------------------------------------------
> >> InfiniteSource(PAYLOAD, LIMIT 1)
> >>          // This isn't a properly formatted ARP packet, but it doesn't
> >> matter for this test.
> >>          -> EtherVLANEncap(0x0806, 1:1:1:1:1:1, 2:2:2:2:2:2, 99)
> >>          -> Queue
> >>          -> ToDevice(eth3);
> >> -----------------------------------------------------
> >>
> >> For the test I externally send a single real arp packet from another
> >> machine to eth3 with a vlan tag of 5. I then turn on click so it emits
> >> one vlan 99 tagged packet.
> >>
> >> Output of `tcpdump -i eth3 -e -n -XX`:
> >> -------------------------------------------------------------
> >>
> >> 13:28:02.011785 00:50:56:9c:4c:82 > Broadcast, ethertype 802.1Q
> >> (0x8100), length 64: vlan 5, p 0, ethertype ARP, Request who-has
> >> 10.3.0.3 tell 10.3.9.111, length 46
> >> 0x0000:  ffff ffff ffff 0050 569c 4c82 8100 0005  .......PV.L.....
> >> 0x0010:  0806 0001 0800 0604 0001 0050 569c 4c82  ...........PV.L.
> >> 0x0020:  0a03 096f 0000 0000 0000 0a03 0003 0000  ...o............
> >> 0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
> >>
> >> 13:28:03.710886 01:01:01:01:01:01 > 02:02:02:02:02:02, ethertype
> >> 802.1Q (0x8100), length 25: vlan 99, p 0, ethertype ARP, [|ARP]
> >> 0x0000:  0202 0202 0202 0101 0101 0101 8100 0063  ...............c
> >> 0x0010:  0806 5041 594c 4f41 44                   ..PAYLOAD
> >>
> >> -------------------------------------------------------------
> >> This is expected, we see the actual packet as well as the generated
> >> packet from our infinite source since we aren't using any filters
> >>
> >> Output of tcpdump -i eth3 -e -n -XX "vlan":
> >> -------------------------------------------------------------
> >>
> >> 13:28:03.710882 01:01:01:01:01:01 > 02:02:02:02:02:02, ethertype
> >> 802.1Q (0x8100), length 25: vlan 99, p 0, ethertype ARP, [|ARP]
> >> 0x0000:  0202 0202 0202 0101 0101 0101 8100 0063  ...............c
> >> 0x0010:  0806 5041 594c 4f41 44                   ..PAYLOAD
> >>
> >> --------------------------------------------------------------
> >>
> >> This is the problem. The correct behavior (believe it or not) is to
> >> not see anything.
> >>
> >> If click conformed to the new Linux behavior of stripped headers and
> >> skb meta data we'd not see anything since libpcap hasn't updated to
> >> conform to the new standard. If click doesn't conform to the new Linux
> >> behavior once libpcap and bpf's update these packets will be lost.
> >>
> >> At present because of the mix of stripped and non-stripped headers
> >> when click is in use it's impossible to write a single packet filter
> >> that will match both classes of packets. For example if I wanted to
> >> filter arp packets, I'd need the filter "arp" for the real vlan tagged
> >> packets, and the filter "vlan and arp" for the click emitted vlan
> >> packets.
> >>
> >> If this behavior can't be avoided for some reason I think a big
> >> documentation warning is necessary at the least.
> >>
> >> Ugh. What a mess. =(
> >>
> >> -Paul Pearce
> >>
> >> Security Graduate Student
> >> Computer Science
> >> University of California, Berkeley
> > _______________________________________________
> > click mailing list
> > click at amsterdam.lcs.mit.edu
> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> >
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From wbsun at cs.utah.edu  Tue Jan 15 15:50:08 2013
From: wbsun at cs.utah.edu (wbsun)
Date: Tue, 15 Jan 2013 13:50:08 -0700
Subject: [Click] =?utf-8?q?netmap_support=3F?=
In-Reply-To: <CALQsBOXw6oSWauT5sRabymxHDWOk_rNWbbqgHy0hd8hMj9J60A@mail.gmail.com>
References: <CALQsBOXw6oSWauT5sRabymxHDWOk_rNWbbqgHy0hd8hMj9J60A@mail.gmail.com>
Message-ID: <9c9158c5f23edfa2c93cd20a09103578@cs.utah.edu>

Current netmap support in Click is very simple.
Its buffer recycling mechanism is not MT safe; at high packet rate, it 
can easily run out of netmap buffers so that Click has to copy netmap's 
buffer content to make a new Packet; and the integration doesn't support 
rx/tx from a particular ring of the RSS-enable NIC.

I've been working on improving this for a while, and so far all the 
above problems have been solved. You can take a look at 
https://github.com/wbsun/glick , it includes my modification to netmap 
integration and FromDevice/ToDevice support for single ring rx/tx, it 
also support pin Click thread to a particular CPU core so that you can 
benefit from RSS by setting NIC interruption affinity. It requires a 
modified Netmap which is at https://github.com/wbsun/nm . This netmap 
version supports allocating spare buffers for userspace pool to avoid 
buffer-run-out in Click, and also supports more slot buffers.

That modified Click has something related to GPU, I plan to make them 
loosely-coupled after finishing my current work on hand and try to make 
a pull request at github for merging into Click source.
If you want to use it now, you need to remove my GPU related elements 
under elements/local/ so as to avoid compilation errors. To identify 
them, they all include my 'g4c.h' header, so simply remove any elements 
needing the 'g4c.h' header. Some files outside elements/local/ also need 
'g4c.h' header, but they just need macros inside it, you can get that 
header file from https://github.com/wbsun/g4c .

Hope this can help a little bit.

On 2013-01-06 07:52, Ashok Anand wrote:
> Hi,
>
> I was wondering if netmap has been integrated with click, and is 
> available
> to use. please let me know.
>
> Regards,
> Ashok
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click

From giorgio.calarco at unibo.it  Tue Jan 15 15:58:55 2013
From: giorgio.calarco at unibo.it (Giorgio Calarco)
Date: Tue, 15 Jan 2013 21:58:55 +0100
Subject: [Click] netmap support?
In-Reply-To: <50F5B386.6070403@gmail.com>
References: <CALQsBOXw6oSWauT5sRabymxHDWOk_rNWbbqgHy0hd8hMj9J60A@mail.gmail.com>
	<50EA6D20.9060209@cs.pub.ro> <50F5B386.6070403@gmail.com>
Message-ID: <CAOCbBQPQ1ykj9_AKtwOgrf07UyKxK1hv_J4K-w08FxrVTvcMEg@mail.gmail.com>

Hi,

if I am not wrong, the From/ToDevice has to be reconfigured, too,
using METHOD NETMAP explicitly.
However, METHOD PCAP should work too, but I suppose that
you would exploit the netmap-based libpcap emulation, which
should be  slower.


Regarding the NETMAP METHOD.
I can report  that I haven't been able to make a standard IP
router to work (I was using a 3.0.x kernel), for no good reason.
(But I had not much time to go in depth.)
At the best of my knowledge, Luigi Rizzo has not published
any performance report related to a complete IP router configuration yet
(only bridging configurations), maybe he can help to
clarify .

However,  I have been able to use it Click over Netmap
 as a packet generator: performance were good (1.2Mpps with
a 1 Gb/s e1000 NIC using a single 2.4 GHz core on a NUMA
 dual xeon quad core platform), but it was not fully saturated
 as Luigi Rizzo had reported. Moreover, performance were
not so reliable/repeatable, and after a few attempts the packet
generator was stucked (or hanged for 20-30 secs before starting),
and I was compelled to discharge the module, swith off
the card, and restart again, a bit annoying.
However, the NIC I was using was a bit different from his,
maybe it could be a hardware problem.

Ciao, Giorgio



On Tue, Jan 15, 2013 at 8:52 PM, Eddie Kohler <ekohler at gmail.com> wrote:

> Click also has preliminary support for native netmap. Configure with
> --with-netmap and report any bugs here.
>
> Eddie
>
>
> On 1/7/13 1:37 AM, Vladimir Olteanu wrote:
> > Hi,
> >
> > A subset of the pcap api (pcap_inject etc.) has been implemented using
> > netmap (check Luigi's website). You just need to change LD_LIBRARY_PATH
> > before running Click.
> >
> > BTW be sure to place "METHOD pcap" in the config strings of all
> > FromDevice and ToDevice elements.
> >
> > Vlad
> >
> > On 01/06/2013 04:52 PM, Ashok Anand wrote:
> >> Hi,
> >>
> >> I was wondering if netmap has been integrated with click, and is
> available
> >> to use. please let me know.
> >>
> >> Regards,
> >> Ashok
> >> _______________________________________________
> >> click mailing list
> >> click at amsterdam.lcs.mit.edu
> >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> >
> > _______________________________________________
> > click mailing list
> > click at amsterdam.lcs.mit.edu
> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> >
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From wbsun at cs.utah.edu  Tue Jan 15 16:14:20 2013
From: wbsun at cs.utah.edu (wbsun)
Date: Tue, 15 Jan 2013 14:14:20 -0700
Subject: [Click] =?utf-8?q?netmap_support=3F?=
In-Reply-To: <CAOCbBQPQ1ykj9_AKtwOgrf07UyKxK1hv_J4K-w08FxrVTvcMEg@mail.gmail.com>
References: <CALQsBOXw6oSWauT5sRabymxHDWOk_rNWbbqgHy0hd8hMj9J60A@mail.gmail.com>
	<50EA6D20.9060209@cs.pub.ro> <50F5B386.6070403@gmail.com>
	<CAOCbBQPQ1ykj9_AKtwOgrf07UyKxK1hv_J4K-w08FxrVTvcMEg@mail.gmail.com>
Message-ID: <c2aac695b2f05b070fe1b6d67de3173d@cs.utah.edu>

This sounds interesting.

I haven't tried a complete IP router, but with a simplified one which 
doesn't care ARP and ICMP, it works well. Things may be different 
because I am using my own modified Click and it is hard for me to figure 
out which change makes this work in a short time..

I've got the same problem that after running Click once and killing it 
for a new settings, it was stuck so I had to reload the NIC driver and 
netmap module and re-setup the network configuration. But my performance 
result is good, for a simple forwarding configuration, it achieves a 
13.1Mpps peak performance with a 10Gb Intel 82599 NIC on an old Intel 
Core i7 930 CPU (two of four cores used).

Weibin Sun

On 2013-01-15 13:58, Giorgio Calarco wrote:
> Hi,
>
> if I am not wrong, the From/ToDevice has to be reconfigured, too,
> using METHOD NETMAP explicitly.
> However, METHOD PCAP should work too, but I suppose that
> you would exploit the netmap-based libpcap emulation, which
> should be  slower.
>
>
> Regarding the NETMAP METHOD.
> I can report  that I haven't been able to make a standard IP
> router to work (I was using a 3.0.x kernel), for no good reason.
> (But I had not much time to go in depth.)
> At the best of my knowledge, Luigi Rizzo has not published
> any performance report related to a complete IP router configuration 
> yet
> (only bridging configurations), maybe he can help to
> clarify .
>
> However,  I have been able to use it Click over Netmap
>  as a packet generator: performance were good (1.2Mpps with
> a 1 Gb/s e1000 NIC using a single 2.4 GHz core on a NUMA
>  dual xeon quad core platform), but it was not fully saturated
>  as Luigi Rizzo had reported. Moreover, performance were
> not so reliable/repeatable, and after a few attempts the packet
> generator was stucked (or hanged for 20-30 secs before starting),
> and I was compelled to discharge the module, swith off
> the card, and restart again, a bit annoying.
> However, the NIC I was using was a bit different from his,
> maybe it could be a hardware problem.
>
> Ciao, Giorgio
>
>
>
> On Tue, Jan 15, 2013 at 8:52 PM, Eddie Kohler <ekohler at gmail.com> 
> wrote:
>
>> Click also has preliminary support for native netmap. Configure with
>> --with-netmap and report any bugs here.
>>
>> Eddie
>>
>>
>> On 1/7/13 1:37 AM, Vladimir Olteanu wrote:
>> > Hi,
>> >
>> > A subset of the pcap api (pcap_inject etc.) has been implemented 
>> using
>> > netmap (check Luigi's website). You just need to change 
>> LD_LIBRARY_PATH
>> > before running Click.
>> >
>> > BTW be sure to place "METHOD pcap" in the config strings of all
>> > FromDevice and ToDevice elements.
>> >
>> > Vlad
>> >
>> > On 01/06/2013 04:52 PM, Ashok Anand wrote:
>> >> Hi,
>> >>
>> >> I was wondering if netmap has been integrated with click, and is
>> available
>> >> to use. please let me know.
>> >>
>> >> Regards,
>> >> Ashok
>> >> _______________________________________________
>> >> click mailing list
>> >> click at amsterdam.lcs.mit.edu
>> >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>> >
>> > _______________________________________________
>> > click mailing list
>> > click at amsterdam.lcs.mit.edu
>> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>> >
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click

From pearce at cs.berkeley.edu  Tue Jan 15 16:15:22 2013
From: pearce at cs.berkeley.edu (Paul Pearce)
Date: Tue, 15 Jan 2013 13:15:22 -0800
Subject: [Click] [Bug] patchless click misbehaving with recent Linux
 kernel vlan changes
In-Reply-To: <50F5B47D.1090909@gmail.com>
References: <CAOUgPvT-oxzqK66jOsKbhoyY3ie4uW6nFcDgm_KjeE98fLHdxw@mail.gmail.com>
	<CAOUgPvSMmV7RmRjaBJYNX0A+x1UgvgWN4FYgr4oG6V9mqgCBBg@mail.gmail.com>
	<50F5B47D.1090909@gmail.com>
Message-ID: <CAOUgPvRtixXjrJTEBRPX2ypeDnOz=SdrHY8zS8f_oivwABFWsg@mail.gmail.com>

Thanks for the response.

> It sounds like you are running at userlevel, and that you are using METHOD
> PCAP (which is the default in recent versions)? Do let us know if you
> discover more. You could also try METHOD LINUX, although this is slower than
> pcap I believe.

Yes I am at userlevel and was using METHOD PCAP.

I just tried using METHOD LINUX and the problem persists.

Summary: The problem is still not resolved by either the linux kernel
or libpcap, and although it's not directly a click problem, it does
impact packets generated by click.

Details:

-In Linux 3.0 and later RX packets had their vlan headers stripped and
added to the skb meta data (skb->vlan_tci). This created a bug where
libpcap was unable to perform any kernel based filtering based on
vlans.
-In Linux 3.8 a new BPF ancillary function will be introduced to give
BPF access to the skb->vlan_tci
-A RFC's patch on the libpcap mailing list gives libpcap the ability
to generate kernel packet filters that use skb->vlan_tci
-TX packets (**which is the category injected click packets fall
into**) do not have skb->vlan_tci set, which is the current sticking
point.

The current issue is the libpcap developers feel that TX packets
should have the same properties as RX packet. They feel that libpcap
should be able to generate a single filter that looks at
skb->vlan_tci. The linux kernel developers disagree and suggest that
libpcap generate filter code that checks skb->vlan_tci, and if that is
not set falls back to the old method of probing the headers. I do not
think I'm knowledgeable enough of either code base to comment on which
side is right. Although I will say I'm a bit confused about why TX
skb->vlan_tci isn't set.

And that's where the issue stands. Neither side is commenting on the
issue further, and no patches have been submitted. As far as I can
tell I'm the only one who has a vested interest in fixing this. =)

As a temporary workaround I discovered if I Tee all packets and send
them to a fake TUN interface (ToHost) and attach libpcap to that
interface, all packets have skb->vlan_tci set and the RFC's libpcap
patch works. So I've been using that as a stop-gap.

From pearce at cs.berkeley.edu  Tue Jan 15 16:34:29 2013
From: pearce at cs.berkeley.edu (Paul Pearce)
Date: Tue, 15 Jan 2013 13:34:29 -0800
Subject: [Click] [Bug] patchless click misbehaving with recent Linux
 kernel vlan changes
In-Reply-To: <CAOCbBQNdL0uBOcNvJqHcW42pUE_JSqqNw4Kc38SkHLKjKqhJvg@mail.gmail.com>
References: <CAOUgPvT-oxzqK66jOsKbhoyY3ie4uW6nFcDgm_KjeE98fLHdxw@mail.gmail.com>
	<CAOUgPvSMmV7RmRjaBJYNX0A+x1UgvgWN4FYgr4oG6V9mqgCBBg@mail.gmail.com>
	<50F5B47D.1090909@gmail.com>
	<CAOCbBQNdL0uBOcNvJqHcW42pUE_JSqqNw4Kc38SkHLKjKqhJvg@mail.gmail.com>
Message-ID: <CAOUgPvRbmxFL564PJ-deP-yYh+2b6tS1VmzJ=PqefwZF=+Cyow@mail.gmail.com>

> last year (may and november ?) I already reported about this problem with
> pcap
> and linux 3.0.x kernels. I did not follow the problem
> in depth, however I previously found out that
>  the pcap method used to send packets by ToDevice
> (pcap_inject, not sure but I think so) seems not to be
> existing anymore. Therefore, ToDevice (which default method is actually
> PCAP)
> simply stucks and sends nothing. What I found confusing is that
> at the ./configure stage, since pcap_inject is not found within
> the pcap library, it is substituted by a dummy method (which does
> nothing) and the compilation goes on as if everything was fine.
> This can be misleading, and some messages from the stdout
> would be helpful, since the problem can then be determined only
> by examining the (long) configure.log file.

I don't have this problem when built the latest libpcap and linux 3.6.
I'm still using pcap_inject().

I think the behavior you describe occurs when you pass a bad libpcap
path to ./configure.

From giorgio.calarco at unibo.it  Wed Jan 16 03:50:56 2013
From: giorgio.calarco at unibo.it (Giorgio Calarco)
Date: Wed, 16 Jan 2013 09:50:56 +0100
Subject: [Click] [Bug] patchless click misbehaving with recent Linux
 kernel vlan changes
In-Reply-To: <CAOUgPvRbmxFL564PJ-deP-yYh+2b6tS1VmzJ=PqefwZF=+Cyow@mail.gmail.com>
References: <CAOUgPvT-oxzqK66jOsKbhoyY3ie4uW6nFcDgm_KjeE98fLHdxw@mail.gmail.com>
	<CAOUgPvSMmV7RmRjaBJYNX0A+x1UgvgWN4FYgr4oG6V9mqgCBBg@mail.gmail.com>
	<50F5B47D.1090909@gmail.com>
	<CAOCbBQNdL0uBOcNvJqHcW42pUE_JSqqNw4Kc38SkHLKjKqhJvg@mail.gmail.com>
	<CAOUgPvRbmxFL564PJ-deP-yYh+2b6tS1VmzJ=PqefwZF=+Cyow@mail.gmail.com>
Message-ID: <CAOCbBQO+DDYPHNVYRd6TFEYp_JT+0+z4=f4X2XK0k7ak=hCpyw@mail.gmail.com>

Well, at this point I don't know and probably
it doesn't matter anymore, seen that everything
is fine with a 3.6 kernel - thanks for reporting this !
(however the path to libpcap was ok, it was checked
during the configuration and the other methods were
found and correctly compiled and used)

Ciao, Giorgio


On Tue, Jan 15, 2013 at 10:34 PM, Paul Pearce <pearce at cs.berkeley.edu>wrote:

> > last year (may and november ?) I already reported about this problem with
> > pcap
> > and linux 3.0.x kernels. I did not follow the problem
> > in depth, however I previously found out that
> >  the pcap method used to send packets by ToDevice
> > (pcap_inject, not sure but I think so) seems not to be
> > existing anymore. Therefore, ToDevice (which default method is actually
> > PCAP)
> > simply stucks and sends nothing. What I found confusing is that
> > at the ./configure stage, since pcap_inject is not found within
> > the pcap library, it is substituted by a dummy method (which does
> > nothing) and the compilation goes on as if everything was fine.
> > This can be misleading, and some messages from the stdout
> > would be helpful, since the problem can then be determined only
> > by examining the (long) configure.log file.
>
> I don't have this problem when built the latest libpcap and linux 3.6.
> I'm still using pcap_inject().
>
> I think the behavior you describe occurs when you pass a bad libpcap
> path to ./configure.
>

From ekohler at gmail.com  Wed Jan 16 12:20:37 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Wed, 16 Jan 2013 12:20:37 -0500
Subject: [Click] [Bug] patchless click misbehaving with recent Linux
 kernel vlan changes
In-Reply-To: <CAOCbBQNdL0uBOcNvJqHcW42pUE_JSqqNw4Kc38SkHLKjKqhJvg@mail.gmail.com>
References: <CAOUgPvT-oxzqK66jOsKbhoyY3ie4uW6nFcDgm_KjeE98fLHdxw@mail.gmail.com>
	<CAOUgPvSMmV7RmRjaBJYNX0A+x1UgvgWN4FYgr4oG6V9mqgCBBg@mail.gmail.com>
	<50F5B47D.1090909@gmail.com>
	<CAOCbBQNdL0uBOcNvJqHcW42pUE_JSqqNw4Kc38SkHLKjKqhJvg@mail.gmail.com>
Message-ID: <50F6E165.10305@gmail.com>

By the way:

On 1/15/13 3:35 PM, Giorgio Calarco wrote:
> simply stucks and sends nothing. What I found confusing is that
> at the ./configure stage, since pcap_inject is not found within
> the pcap library, it is substituted by a dummy method (which does
> nothing) and the compilation goes on as if everything was fine.

No. ToDevice calls pcap_sendpacket(), which I thought was the right 
thing to do. If it's not I'd appreciate a patch.

Eddie



> This can be misleading, and some messages from the stdout
> would be helpful, since the problem can then be determined only
> by examining the (long) configure.log file.
>
> Moreover, I'm not sure if this is really a bug, maybe there's a new pcap
> method to call to xmit a packet now ?
>
> (The kernel development is becoming overwhelming, I think)
>
> My regards,
> Giorgio
>
>
> On Tue, Jan 15, 2013 at 8:56 PM, Eddie Kohler <ekohler at gmail.com
> <mailto:ekohler at gmail.com>> wrote:
>
>     Hi Paul,
>
>     It sounds like you are running at userlevel, and that you are using
>     METHOD PCAP (which is the default in recent versions)? Do let us know if
>     you discover more. You could also try METHOD LINUX, although this is
>     slower than pcap I believe.
>
>     Eddie
>
>
>     On 1/7/13 8:51 PM, Paul Pearce wrote:
>      > Follow up.
>      >
>      > After digging into the click source I found that click is simply
>      > calling pcap_inject() on these packets. After tracing through the
>      > libpcap source it looks like this may be another bug in the Linux
>      > kernel. I've started a thread on linux-netdev relating to the issue.
>      >
>      > http://marc.info/?l=linux-netdev&m=135760359019679&w=3
>      >
>      > On Fri, Dec 21, 2012 at 2:07 PM, Paul Pearce
>     <pearce at cs.berkeley.edu <mailto:pearce at cs.berkeley.edu>> wrote:
>      >> Hello folks,
>      >>
>      >> Summary:
>      >> Vlan tagged packets emitted by patchless click do not have the same
>      >> properties as other vlan tagged packets on the same interface as of
>      >> Linux 3.x.
>      >>
>      >> This is a bit long, so please indulge me.
>      >>
>      >> Background thread from the libpcap devs:
>      >>
>     http://www.mail-archive.com/tcpdump-workers at lists.tcpdump.org/msg06698.html
>      >>
>      >> Summary of the background thread:
>      >> * In April 2011 (net-dev commit
>      >> bcc6d47903612c3861201cc3a866fb604f26b8b2 ) the Linux kernel began
>      >> stripping vlan information from packet *HEADERS* (not from the raw
>      >> packets themselves) and inserting that information into the skb
>      >> metadata prior to it reaching the filters.
>      >> * As of today (12/21/2012) Berkeley Packet Filter (bpf) facilities
>      >> don't have the ability to access the vlan meta-data (although such a
>      >> patch is under review in net-next).
>      >> * Also as of today (12/21/2012) libpcap has no way to do
>     kernel-level
>      >> filtering of packets based on vlan tags (this means capturing
>     packets
>      >> based on vlan tags on live interfaces). Although they're working on
>      >> it.
>      >>
>      >> How does this impact click?
>      >>
>      >> Click packets are emitted with the vlan header information intact
>      >> rather than being stripped and added to the skb metadata.
>      >>
>      >> **This means vlan tagged packets on the same interface have a mix of
>      >> stripped and non-stripped headers. This causes a variety of problems
>      >> including difficulty filtering packets**
>      >>
>      >> This problem manifests itself when you try to use a "vlan" tcpdump
>      >> filter on a live interface. I realize tcpdump picking up the packets
>      >> or not is a libpcap problem, not a click problem. I'm just using
>     this
>      >> to demonstrate that the click-emitted packets have different
>      >> properties.
>      >>
>      >> The rest of this email documents tests to demonstrate the problem
>      >> along with more info about the ramifications.
>      >>
>      >> **********
>      >>
>      >> Sample click config (run from click git commit
>      >> 9200a743a27f4a0e8f40299e5f8d865e248282b1 Nov 9 2012):
>      >> -----------------------------------------------------
>      >> InfiniteSource(PAYLOAD, LIMIT 1)
>      >>          // This isn't a properly formatted ARP packet, but it
>     doesn't
>      >> matter for this test.
>      >>          -> EtherVLANEncap(0x0806, 1:1:1:1:1:1, 2:2:2:2:2:2, 99)
>      >>          -> Queue
>      >>          -> ToDevice(eth3);
>      >> -----------------------------------------------------
>      >>
>      >> For the test I externally send a single real arp packet from another
>      >> machine to eth3 with a vlan tag of 5. I then turn on click so it
>     emits
>      >> one vlan 99 tagged packet.
>      >>
>      >> Output of `tcpdump -i eth3 -e -n -XX`:
>      >> -------------------------------------------------------------
>      >>
>      >> 13:28:02.011785 00:50:56:9c:4c:82 > Broadcast, ethertype 802.1Q
>      >> (0x8100), length 64: vlan 5, p 0, ethertype ARP, Request who-has
>      >> 10.3.0.3 tell 10.3.9.111, length 46
>      >> 0x0000:  ffff ffff ffff 0050 569c 4c82 8100 0005  .......PV.L.....
>      >> 0x0010:  0806 0001 0800 0604 0001 0050 569c 4c82  ...........PV.L.
>      >> 0x0020:  0a03 096f 0000 0000 0000 0a03 0003 0000  ...o............
>      >> 0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>      >>
>      >> 13:28:03.710886 01:01:01:01:01:01 > 02:02:02:02:02:02, ethertype
>      >> 802.1Q (0x8100), length 25: vlan 99, p 0, ethertype ARP, [|ARP]
>      >> 0x0000:  0202 0202 0202 0101 0101 0101 8100 0063  ...............c
>      >> 0x0010:  0806 5041 594c 4f41 44                   ..PAYLOAD
>      >>
>      >> -------------------------------------------------------------
>      >> This is expected, we see the actual packet as well as the generated
>      >> packet from our infinite source since we aren't using any filters
>      >>
>      >> Output of tcpdump -i eth3 -e -n -XX "vlan":
>      >> -------------------------------------------------------------
>      >>
>      >> 13:28:03.710882 01:01:01:01:01:01 > 02:02:02:02:02:02, ethertype
>      >> 802.1Q (0x8100), length 25: vlan 99, p 0, ethertype ARP, [|ARP]
>      >> 0x0000:  0202 0202 0202 0101 0101 0101 8100 0063  ...............c
>      >> 0x0010:  0806 5041 594c 4f41 44                   ..PAYLOAD
>      >>
>      >> --------------------------------------------------------------
>      >>
>      >> This is the problem. The correct behavior (believe it or not) is to
>      >> not see anything.
>      >>
>      >> If click conformed to the new Linux behavior of stripped headers and
>      >> skb meta data we'd not see anything since libpcap hasn't updated to
>      >> conform to the new standard. If click doesn't conform to the new
>     Linux
>      >> behavior once libpcap and bpf's update these packets will be lost.
>      >>
>      >> At present because of the mix of stripped and non-stripped headers
>      >> when click is in use it's impossible to write a single packet filter
>      >> that will match both classes of packets. For example if I wanted to
>      >> filter arp packets, I'd need the filter "arp" for the real vlan
>     tagged
>      >> packets, and the filter "vlan and arp" for the click emitted vlan
>      >> packets.
>      >>
>      >> If this behavior can't be avoided for some reason I think a big
>      >> documentation warning is necessary at the least.
>      >>
>      >> Ugh. What a mess. =(
>      >>
>      >> -Paul Pearce
>      >>
>      >> Security Graduate Student
>      >> Computer Science
>      >> University of California, Berkeley
>      > _______________________________________________
>      > click mailing list
>      > click at amsterdam.lcs.mit.edu <mailto:click at amsterdam.lcs.mit.edu>
>      > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>      >
>     _______________________________________________
>     click mailing list
>     click at amsterdam.lcs.mit.edu <mailto:click at amsterdam.lcs.mit.edu>
>     https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>
>

From ekohler at gmail.com  Wed Jan 16 13:05:42 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Wed, 16 Jan 2013 13:05:42 -0500
Subject: [Click] Plans to merge pending pull requests?
In-Reply-To: <E414E9D6-6469-46BB-9BD8-C78B12C0E67E@nomadiclab.com>
References: <E414E9D6-6469-46BB-9BD8-C78B12C0E67E@nomadiclab.com>
Message-ID: <50F6EBF6.9030104@gmail.com>

Hi Jimmy,

Thanks for the reminder. I went ahead and merged your pull request, as 
well as versions of all the other outstanding pull requests. I also 
updated the patchless installation procedure and some problematic 
aspects of the Click filesystem. At this point Click can install simple 
configurations into patchless Ubuntu 8.04 (2.6.24), 10.04 (2.6.32), 
12.04 (3.2), and 12.10 (3.5) kernels. I have not verified that Click can 
send and receive packets in all these configurations, but it is a start. 
Please open issues and other pull requests as you find them.

Best,
Eddie


On 12/19/12 11:04 AM, Jimmy Kj?llman wrote:
> Eddie, other maintainers of Click,
>
> there's a number of pending pull requests in GitHub. Do you have any plans to merge them into the master branch, or to give comments about them?
>
> At least some of the locking-related issues are quite critical. I.e., in many new Linux kernels the Click module causes crashes and deadlocks very frequently without the corresponding fixes. Or, to put in another way, the module is not that useful without these fixes in its current state. Therefore it would be nice if they were included into Click.
>
> BR,
>
> Jimmy Kj?llman
>
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From ekohler at gmail.com  Wed Jan 16 13:06:16 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Wed, 16 Jan 2013 13:06:16 -0500
Subject: [Click] click 2.0.1 compatible kernel
In-Reply-To: <CALdZA=U5wT8nYUActsGqCbFSFfZk8FZgP5NTyrYkFioMo44eLw@mail.gmail.com>
References: <CALdZA=U5wT8nYUActsGqCbFSFfZk8FZgP5NTyrYkFioMo44eLw@mail.gmail.com>
Message-ID: <50F6EC18.6070904@gmail.com>

Hi Konstantin,

At this point I'd advise using git-head rather than 2.0.1. I don't 
remember which kernel was best tested in the 2.0.1 timeframe.

Eddie


On 11/19/12 10:33 AM, Konstantin Zaykalov wrote:
> Hi,
>
> An easy question (hopefully): when click 2.0.1 was released - against which
> version of linux kernel was it tested? I.e. what is the latest kernel
> version that click 2.0.1 was tested against? Also what version of gcc was
> used?
>
> Thank you,
>
> Konstantin
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From ekohler at gmail.com  Wed Jan 16 13:08:23 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Wed, 16 Jan 2013 13:08:23 -0500
Subject: [Click] FilterFailures
In-Reply-To: <201211191617.24838.sombrutz@informatik.hu-berlin.de>
References: <201211191617.24838.sombrutz@informatik.hu-berlin.de>
Message-ID: <50F6EC97.7070907@gmail.com>

Applied, thanks!

Github pull requests are preferred in future.

E


On 11/19/12 10:17 AM, Robert Sombrutzki wrote:
> Hi,
> this patch decreases the number of possible output ports of FilterFailures to
> 2, since this is the maximum number of used port in
> elements/wifi/filterfailures.cc.
>
> Best regards
> Robert
>
>
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From ekohler at gmail.com  Wed Jan 16 13:14:06 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Wed, 16 Jan 2013 13:14:06 -0500
Subject: [Click] click netmap(20120813) patch
In-Reply-To: <CAKE=LV1WMYr0QnPPAVeeYm3RHN0=fw5N6oKRZVC5G0Xk8Ks79g@mail.gmail.com>
References: <CAKE=LV1WMYr0QnPPAVeeYm3RHN0=fw5N6oKRZVC5G0Xk8Ks79g@mail.gmail.com>
Message-ID: <50F6EDEE.3040600@gmail.com>

Thanks for the patch! It's applied.

Eddie


On 10/17/12 10:55 AM, sandeep wrote:
> netmap v3 (20120813).

From ekohler at gmail.com  Wed Jan 16 13:16:14 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Wed, 16 Jan 2013 13:16:14 -0500
Subject: [Click] Compile error due to ac_cv_linuxmodule_click_skb_recycle
In-Reply-To: <CAEE35d06FDtMzrFQtk=XoQk1xpjFYtBUChm=tNYOtOtMdJpPsQ@mail.gmail.com>
References: <CAEE35d06FDtMzrFQtk=XoQk1xpjFYtBUChm=tNYOtOtMdJpPsQ@mail.gmail.com>
Message-ID: <50F6EE6E.3010703@gmail.com>

Thanks for this! The pull request got merged.

Eddie


On 9/20/12 7:16 AM, Shoban wrote:
> Configure test for ac_cv_linuxmodule_click_skb_recycle passes, even if
> skb_recycle() is not declared, with just warnings.
>
> Excerpt from config.log (https://gist.github.com/3755265)
> conftest.c:141:15: warning: implicit declaration of function
> 'skb_recycle' [-Wimplicit-function-declaration]
> conftest.c:141:29: warning: assignment makes pointer from integer
> without a cast [enabled by default]
>
> This in turn, causes a compile error for "linuxmodule/skbmgr.cc".
>
> /root/click/linuxmodule/skbmgr.cc: In member function ?void
> RecycledSkbPool::recycle(sk_buff*)?:
> /root/click/linuxmodule/skbmgr.cc:300:28: error: ?skb_recycle? was not
> declared in this scope
>
> I am trying build click for linux-2.6.34.12 in patchless mode.
>
> Perhaps adding '-Werror-implicit-function-declaration' option for this
> particular configure test would solve the problem.
>
> diff --git a/configure.in b/configure.in
> index 1618227..ecf319b 100644
> --- a/configure.in
> +++ b/configure.in
> @@ -1452,6 +1452,9 @@ void f1(int64_t) { // will fail if long long and
> int64_t are the same type
>          AC_DEFINE([HAVE_SKB_RECYCLE], [1], [Define if you have the
> skb_recycle function.])
>       fi
>
> +save_cflags="$CFLAGS"
> +CFLAGS="$save_cflags -Werror-implicit-function-declaration"
> +
>       AC_CACHE_CHECK([whether skb_recycle returns an sk_buff],
> [ac_cv_linuxmodule_click_skb_recycle],
>          [AC_LANG_C
>          AC_COMPILE_IFELSE([AC_LANG_PROGRAM([CLICK_LINUXMODULE_PROLOGUE()[
> @@ -1462,6 +1465,8 @@ void f1(int64_t) { // will fail if long long and
> int64_t are the same type
>          AC_DEFINE([HAVE_CLICK_SKB_RECYCLE], [1], [Define if your Linux
> kernel has Click skb_recycle.])
>       fi
>
> +CFLAGS="$save_cflags"
> +
>       AC_CHECK_DECL(skb_linearize, [ac_cv_skb_linearize=yes],
> [ac_cv_skb_linearize=no], [CLICK_LINUXMODULE_PROLOGUE()[
>   #include <linux/skbuff.h>]])
>       if test $ac_cv_skb_linearize = yes; then
>
> Thanks,
> Shoban
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From ekohler at gmail.com  Wed Jan 16 13:19:13 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Wed, 16 Jan 2013 13:19:13 -0500
Subject: [Click] Windows 7 compilation issue
In-Reply-To: <50612C0D.8030307@mit.edu>
References: <50612C0D.8030307@mit.edu>
Message-ID: <50F6EF21.6000800@gmail.com>

Hi Jorge,

I wouldn't expect Click to work well on Cygwin; and the error indicated 
that you didn't have the pcap library, so Click couldn't receive or send 
packets; nevertheless the compile error is fixed. Thanks for reporting it.

Eddie


On 9/24/12 11:59 PM, Jorge Simosa wrote:
> Hi,
>
> I am having trouble compiling the Click package on my laptop.
> I'm running Cygwin on a Windows 7 (64-bit) platform, with (from what I
> believe) all of the pre-requisite libraries.
> After running './configure' and 'make', I am receiving this error during
> 'make':
>
> In file included from ../elements/userlevel/fromdevice.cc:35:0:
> ../elements/userlevel/fromdevice.hh: In member function 'int
> FromDevice::fd() const':
> ../elements/userlevel/fromdevice.hh:178:37: error: '_fd' was not
> declared in this scope
> elements.mk:381: recipe for target `fromdevice.o' failed
> make[1]: *** [fromdevice.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make[1]: Leaving directory `/cygdrive/c/libs/click/userlevel'
> Makefile:55: recipe for target `userlevel' failed
> make: *** [userlevel] Error 2
>
> I would appreciate any help you can provide in resolving this issue.
> Thanks!
>
> Best regards,
> Jorge Simosa
> MIT M.Eng '13
> MIT B.S. '12
> Electrical Engineering & Computer Science
> jdsimosa at mit.edu
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From avinash.sridharan at gmail.com  Wed Jan 16 14:04:13 2013
From: avinash.sridharan at gmail.com (Avinash Sridharan)
Date: Wed, 16 Jan 2013 11:04:13 -0800
Subject: [Click] Plans to merge pending pull requests?
In-Reply-To: <50F6EBF6.9030104@gmail.com>
References: <E414E9D6-6469-46BB-9BD8-C78B12C0E67E@nomadiclab.com>
	<50F6EBF6.9030104@gmail.com>
Message-ID: <CADJyuDgdyayVPEyw5gSHxiMrD5qUUiMqXG2AcH9amY84Yax2cw@mail.gmail.com>

Hi Eddie,
 On a related note. Are there click patches available for linux kernels >
3.0 ? I was hoping to run click in kernel mode under UML (user-mode linux)
for better debuggability and understanding. On a system running kernel
3.1.0 and higher I was unable to get UML running with an older linux kernel
< 2.6.38, to apply any of the existing click kernel patches for the older
linux kernel. On the UML thread I was informed that UML compiled for older
linux kernels but doesn't play well with new version of gcc (it just
crashes on bootup).

So, I figured the cleaner solution would be to get a patch for linux kernel
> 3.0 for click. I couldn't find this when I pulled the git repository for
click. Is this something that is already available? Meanwhile I have
started applying the older patches to a 3.4 linux kernel and resolving the
conflicts. I am relatively comfortable with kernel development, but
wouldn't call myself an expert at this point. So wanted some pointers in
resolving this issue and hints on proceeding further.

Thanks,
Avinash



On Wed, Jan 16, 2013 at 10:05 AM, Eddie Kohler <ekohler at gmail.com> wrote:

> Hi Jimmy,
>
> Thanks for the reminder. I went ahead and merged your pull request, as
> well as versions of all the other outstanding pull requests. I also
> updated the patchless installation procedure and some problematic
> aspects of the Click filesystem. At this point Click can install simple
> configurations into patchless Ubuntu 8.04 (2.6.24), 10.04 (2.6.32),
> 12.04 (3.2), and 12.10 (3.5) kernels. I have not verified that Click can
> send and receive packets in all these configurations, but it is a start.
> Please open issues and other pull requests as you find them.
>
> Best,
> Eddie
>
>
> On 12/19/12 11:04 AM, Jimmy Kj?llman wrote:
> > Eddie, other maintainers of Click,
> >
> > there's a number of pending pull requests in GitHub. Do you have any
> plans to merge them into the master branch, or to give comments about them?
> >
> > At least some of the locking-related issues are quite critical. I.e., in
> many new Linux kernels the Click module causes crashes and deadlocks very
> frequently without the corresponding fixes. Or, to put in another way, the
> module is not that useful without these fixes in its current state.
> Therefore it would be nice if they were included into Click.
> >
> > BR,
> >
> > Jimmy Kj?llman
> >
> >
> > _______________________________________________
> > click mailing list
> > click at amsterdam.lcs.mit.edu
> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> >
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From ekohler at gmail.com  Wed Jan 16 14:26:50 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Wed, 16 Jan 2013 14:26:50 -0500
Subject: [Click] Plans to merge pending pull requests?
In-Reply-To: <CADJyuDgdyayVPEyw5gSHxiMrD5qUUiMqXG2AcH9amY84Yax2cw@mail.gmail.com>
References: <E414E9D6-6469-46BB-9BD8-C78B12C0E67E@nomadiclab.com>
	<50F6EBF6.9030104@gmail.com>
	<CADJyuDgdyayVPEyw5gSHxiMrD5qUUiMqXG2AcH9amY84Yax2cw@mail.gmail.com>
Message-ID: <50F6FEFA.10303@gmail.com>

Hi Avinash,

At this point you don't need a Linux patch to compile or run Click. I 
recommend you attempt to do without it. Click hacks its way into the 
Linux packet processing chain, and that hack may not work on all 
kernels. But try it and let us know what you see.

So why still have the patch at all? Because the patch supports polling. 
I would love a later patch that supports polling!

Eddie


On 1/16/13 2:04 PM, Avinash Sridharan wrote:
> Hi Eddie,
>   On a related note. Are there click patches available for linux kernels
>  > 3.0 ? I was hoping to run click in kernel mode under UML (user-mode
> linux) for better debuggability and understanding. On a system running
> kernel 3.1.0 and higher I was unable to get UML running with an older
> linux kernel < 2.6.38, to apply any of the existing click kernel patches
> for the older linux kernel. On the UML thread I was informed that UML
> compiled for older linux kernels but doesn't play well with new version
> of gcc (it just crashes on bootup).
>
> So, I figured the cleaner solution would be to get a patch for linux
> kernel > 3.0 for click. I couldn't find this when I pulled the git
> repository for click. Is this something that is already available?
> Meanwhile I have started applying the older patches to a 3.4 linux
> kernel and resolving the conflicts. I am relatively comfortable with
> kernel development, but wouldn't call myself an expert at this point. So
> wanted some pointers in resolving this issue and hints on proceeding
> further.
>
> Thanks,
> Avinash
>
>
>
> On Wed, Jan 16, 2013 at 10:05 AM, Eddie Kohler <ekohler at gmail.com
> <mailto:ekohler at gmail.com>> wrote:
>
>     Hi Jimmy,
>
>     Thanks for the reminder. I went ahead and merged your pull request, as
>     well as versions of all the other outstanding pull requests. I also
>     updated the patchless installation procedure and some problematic
>     aspects of the Click filesystem. At this point Click can install simple
>     configurations into patchless Ubuntu 8.04 (2.6.24), 10.04 (2.6.32),
>     12.04 (3.2), and 12.10 (3.5) kernels. I have not verified that Click can
>     send and receive packets in all these configurations, but it is a start.
>     Please open issues and other pull requests as you find them.
>
>     Best,
>     Eddie
>
>
>     On 12/19/12 11:04 AM, Jimmy Kj?llman wrote:
>      > Eddie, other maintainers of Click,
>      >
>      > there's a number of pending pull requests in GitHub. Do you have
>     any plans to merge them into the master branch, or to give comments
>     about them?
>      >
>      > At least some of the locking-related issues are quite critical.
>     I.e., in many new Linux kernels the Click module causes crashes and
>     deadlocks very frequently without the corresponding fixes. Or, to
>     put in another way, the module is not that useful without these
>     fixes in its current state. Therefore it would be nice if they were
>     included into Click.
>      >
>      > BR,
>      >
>      > Jimmy Kj?llman
>      >
>      >
>      > _______________________________________________
>      > click mailing list
>      > click at amsterdam.lcs.mit.edu <mailto:click at amsterdam.lcs.mit.edu>
>      > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>      >
>     _______________________________________________
>     click mailing list
>     click at amsterdam.lcs.mit.edu <mailto:click at amsterdam.lcs.mit.edu>
>     https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>
>

From avinash.sridharan at gmail.com  Wed Jan 16 14:40:15 2013
From: avinash.sridharan at gmail.com (Avinash Sridharan)
Date: Wed, 16 Jan 2013 11:40:15 -0800
Subject: [Click] Plans to merge pending pull requests?
In-Reply-To: <50F6FEFA.10303@gmail.com>
References: <E414E9D6-6469-46BB-9BD8-C78B12C0E67E@nomadiclab.com>
	<50F6EBF6.9030104@gmail.com>
	<CADJyuDgdyayVPEyw5gSHxiMrD5qUUiMqXG2AcH9amY84Yax2cw@mail.gmail.com>
	<50F6FEFA.10303@gmail.com>
Message-ID: <CADJyuDjLQog3oi5KArJRP7ENfUhg2E7xorU9S7bYTk+X3L4eJw@mail.gmail.com>

Thanks a lot for the info Eddie.
This is really helpful. I guess I just started the patch process assuming
that click would not work with the kernel without the patch. I will try
compiling it with the newer kernel, and load it as a module and see what
happens.

Meanwhile will work on trying to get the patch working with 3.4. I noticed
that most of the click patch deals with plugging into the netif_receive_skb
and skb_recycle. I will "try" to get this working with a newer kernel.

regards,
Avinash

On Wed, Jan 16, 2013 at 11:26 AM, Eddie Kohler <ekohler at gmail.com> wrote:

> Hi Avinash,
>
> At this point you don't need a Linux patch to compile or run Click. I
> recommend you attempt to do without it. Click hacks its way into the Linux
> packet processing chain, and that hack may not work on all kernels. But try
> it and let us know what you see.
>
> So why still have the patch at all? Because the patch supports polling. I
> would love a later patch that supports polling!
>
> Eddie
>
>
>
> On 1/16/13 2:04 PM, Avinash Sridharan wrote:
>
>> Hi Eddie,
>>   On a related note. Are there click patches available for linux kernels
>>  > 3.0 ? I was hoping to run click in kernel mode under UML (user-mode
>> linux) for better debuggability and understanding. On a system running
>> kernel 3.1.0 and higher I was unable to get UML running with an older
>> linux kernel < 2.6.38, to apply any of the existing click kernel patches
>> for the older linux kernel. On the UML thread I was informed that UML
>> compiled for older linux kernels but doesn't play well with new version
>> of gcc (it just crashes on bootup).
>>
>> So, I figured the cleaner solution would be to get a patch for linux
>> kernel > 3.0 for click. I couldn't find this when I pulled the git
>> repository for click. Is this something that is already available?
>> Meanwhile I have started applying the older patches to a 3.4 linux
>> kernel and resolving the conflicts. I am relatively comfortable with
>> kernel development, but wouldn't call myself an expert at this point. So
>> wanted some pointers in resolving this issue and hints on proceeding
>> further.
>>
>> Thanks,
>> Avinash
>>
>>
>>
>> On Wed, Jan 16, 2013 at 10:05 AM, Eddie Kohler <ekohler at gmail.com
>> <mailto:ekohler at gmail.com>> wrote:
>>
>>     Hi Jimmy,
>>
>>     Thanks for the reminder. I went ahead and merged your pull request, as
>>     well as versions of all the other outstanding pull requests. I also
>>     updated the patchless installation procedure and some problematic
>>     aspects of the Click filesystem. At this point Click can install
>> simple
>>     configurations into patchless Ubuntu 8.04 (2.6.24), 10.04 (2.6.32),
>>     12.04 (3.2), and 12.10 (3.5) kernels. I have not verified that Click
>> can
>>     send and receive packets in all these configurations, but it is a
>> start.
>>     Please open issues and other pull requests as you find them.
>>
>>     Best,
>>     Eddie
>>
>>
>>     On 12/19/12 11:04 AM, Jimmy Kj?llman wrote:
>>      > Eddie, other maintainers of Click,
>>      >
>>      > there's a number of pending pull requests in GitHub. Do you have
>>     any plans to merge them into the master branch, or to give comments
>>     about them?
>>      >
>>      > At least some of the locking-related issues are quite critical.
>>     I.e., in many new Linux kernels the Click module causes crashes and
>>     deadlocks very frequently without the corresponding fixes. Or, to
>>     put in another way, the module is not that useful without these
>>     fixes in its current state. Therefore it would be nice if they were
>>     included into Click.
>>      >
>>      > BR,
>>      >
>>      > Jimmy Kj?llman
>>      >
>>      >
>>      > ______________________________**_________________
>>      > click mailing list
>>      > click at amsterdam.lcs.mit.edu <mailto:click at amsterdam.lcs.**mit.edu<click at amsterdam.lcs.mit.edu>
>> >
>>
>>      > https://amsterdam.lcs.mit.edu/**mailman/listinfo/click<https://amsterdam.lcs.mit.edu/mailman/listinfo/click>
>>      >
>>     ______________________________**_________________
>>     click mailing list
>>     click at amsterdam.lcs.mit.edu <mailto:click at amsterdam.lcs.**mit.edu<click at amsterdam.lcs.mit.edu>
>> >
>>     https://amsterdam.lcs.mit.edu/**mailman/listinfo/click<https://amsterdam.lcs.mit.edu/mailman/listinfo/click>
>>
>>
>>

From ekohler at gmail.com  Thu Jan 17 15:00:55 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Thu, 17 Jan 2013 15:00:55 -0500
Subject: [Click] Release 2.1
Message-ID: <CAF0C5S+i6NasTBEZY9b6ZtUUG=ou5DS2YhOtBuwU-VKKHUODFA@mail.gmail.com>

Hi all,

I plan to release Click 2.1 shortly. Let me know if there's something
outstanding from the mailing list that I should be sure to consider
first.

Eddie

From ekohler at gmail.com  Thu Jan 17 22:27:39 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Thu, 17 Jan 2013 22:27:39 -0500
Subject: [Click] Args::read_or_set
In-Reply-To: <CACeiqXRuVD0jW+jk-EP4fSWA51429XFgc5bNSwhJrULO0aDMkg@mail.gmail.com>
References: <50EF4E2C.7080609@informatik.hu-berlin.de>
	<CAF0C5SL8VAaPNo-ZmCQdDvxSdW=NeMmLfncdKBc0KzfEx1zw=g@mail.gmail.com>
	<CACeiqXRuVD0jW+jk-EP4fSWA51429XFgc5bNSwhJrULO0aDMkg@mail.gmail.com>
Message-ID: <CAF0C5SLsd37b+ueiyKCEfHFzw5MM0oX00HsBdfAKVmeQbYZKtA@mail.gmail.com>

Try the resources here:

http://read.cs.ucla.edu/click/learning



On Tue, Jan 15, 2013 at 3:08 PM, karthick m <mkarthick19 at gmail.com> wrote:
> Hi,
>
>    I want to implement my own publish-subscribe architecture in a small
> scale testbed (say with 10 machines) using click router. Could anyone please
> tell me how to start with click router. I have visited the click router main
> website and also some sample codes. But I am facing difficulty with that.
> For Omnet++, we have tictoc tutorial. Do we have something similar for click
> router?  Please let me know.
>

From jopen at informatik.uni-bonn.de  Fri Jan 18 04:17:51 2013
From: jopen at informatik.uni-bonn.de (Sascha Alexander Jopen)
Date: Fri, 18 Jan 2013 10:17:51 +0100
Subject: [Click] Release 2.1
In-Reply-To: <CAF0C5S+i6NasTBEZY9b6ZtUUG=ou5DS2YhOtBuwU-VKKHUODFA@mail.gmail.com>
References: <CAF0C5S+i6NasTBEZY9b6ZtUUG=ou5DS2YhOtBuwU-VKKHUODFA@mail.gmail.com>
Message-ID: <50F9133F.7080206@informatik.uni-bonn.de>

Hi Eddie,

i still have outstanding patches to click. At least the random number
support with ns3 patch, see
http://www.mail-archive.com/click at amsterdam.lcs.mit.edu/msg05860.html.

However, i would like to review this patch, because ns3 random number
handling has slightly changed meanwhile. This should only affect the ns3
part of the patch. This should be ready by monday.

Sascha

On 17.01.2013 21:00, Eddie Kohler wrote:
> Hi all,
> 
> I plan to release Click 2.1 shortly. Let me know if there's something
> outstanding from the mailing list that I should be sure to consider
> first.
> 
> Eddie
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> 


-- 
Dipl.-Inform. Sascha Jopen

University of Bonn                     Tel.:   +49-228-73-54219
Institute of Computer Science 4        Fax:    +49-228-73-4571
Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
D-53113 Bonn, Germany

From jopen at informatik.uni-bonn.de  Mon Jan 21 06:16:16 2013
From: jopen at informatik.uni-bonn.de (Sascha Alexander Jopen)
Date: Mon, 21 Jan 2013 12:16:16 +0100
Subject: [Click] nsclick rng support for ns3
Message-ID: <50FD2380.6020101@informatik.uni-bonn.de>

Hey,

please find attached a patchset for click and ns3 which adds support for
drawing random numbers within click simulations from the underlying ns3
random number generator. Each simulated click node has its own uniformly
distributed random number stream (as opposed to my previously submitted
patch). This way all nodes have independent random number streams.

Setting the seed or run numbers is done within the simulation by means of

RngSeedManager::SetSeed ();
RngSeedManager::SetRun ();

or with environment variables or command line parameters.
See http://www.nsnam.org/docs/manual/html/random-variables.html

I still have no ns2 available. Currently, missing rng support from the
simulator side is detected and reported but no random numbers are
available to the simulation. Implementing a fallback method should be
possible, however. Maybe someone who uses ns2 could provide this?

click-ns3-rng.diff is for the click side and ns3-nsclick-rng.diff for
the ns3 side.

Regards,
Sascha

-- 
Dipl.-Inform. Sascha Jopen

University of Bonn                     Tel.:   +49-228-73-54219
Institute of Computer Science 4        Fax:    +49-228-73-4571
Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
D-53113 Bonn, Germany
-------------- next part --------------
diff --git a/include/click/glue.hh b/include/click/glue.hh
index a908496..eed522b 100644
--- a/include/click/glue.hh
+++ b/include/click/glue.hh
@@ -70,6 +70,7 @@ CLICK_CXX_UNPROTECT
 # include <sys/time.h>
 # if CLICK_NS
 extern "C" int simclick_gettimeofday(struct timeval *);
+extern "C" uint32_t simclick_random();
 # endif
 # if HAVE_MULTITHREAD
 #  include <pthread.h>
@@ -132,6 +133,8 @@ void click_random_srandom();
 
 #if CLICK_BSDMODULE
 # define CLICK_RAND_MAX 0x7FFFFFFFU
+#elif CLICK_NS
+# define CLICK_RAND_MAX 0xFFFFFFFEU
 #elif !CLICK_LINUXMODULE && RAND_MAX >= 0x7FFFFFFFU
 # define CLICK_RAND_MAX RAND_MAX
 #else
@@ -145,6 +148,8 @@ inline uint32_t click_random() {
 #elif CLICK_LINUXMODULE
     click_random_seed = click_random_seed * 69069L + 5;
     return (click_random_seed ^ jiffies) & CLICK_RAND_MAX; // XXX jiffies??
+#elif CLICK_NS
+    return simclick_random();
 #elif HAVE_RANDOM && CLICK_RAND_MAX == RAND_MAX
     return random();
 #else
@@ -155,6 +160,9 @@ inline uint32_t click_random() {
 inline void click_srandom(uint32_t seed) {
 #if CLICK_BSDMODULE
     srandom(seed);
+#elif CLICK_NS
+    // do nothing, seeding is done by the ns seed manager
+    (void) seed;
 #elif !CLICK_LINUXMODULE && HAVE_RANDOM && CLICK_RAND_MAX == RAND_MAX
     srandom(seed);
 #elif !CLICK_LINUXMODULE && CLICK_RAND_MAX == RAND_MAX
diff --git a/include/click/simclick.h b/include/click/simclick.h
index 972a977..863d827 100644
--- a/include/click/simclick.h
+++ b/include/click/simclick.h
@@ -106,6 +106,7 @@ int simclick_gettimeofday(struct timeval* tv);
 #define SIMCLICK_CHANGE_CHANNEL		11 // int ifid, int channelid
 #define SIMCLICK_IF_PROMISC		12 // int ifid
 #define SIMCLICK_IPPREFIX_FROM_NAME	13 // const char *ifname, char *buf, int len
+#define SIMCLICK_RANDOM				14 // none
 
 int simclick_sim_command(simclick_node_t *sim, int cmd, ...);
 int simclick_click_command(simclick_node_t *sim, int cmd, ...);
diff --git a/ns/nsclick.cc b/ns/nsclick.cc
index 1e00b32..a2b54fc 100644
--- a/ns/nsclick.cc
+++ b/ns/nsclick.cc
@@ -153,6 +154,23 @@ int simclick_gettimeofday(struct timeval* tv) {
   }
 }
 
+uint32_t simclick_random() {
+	static bool sim_rng_support = simclick_sim_command(NULL, SIMCLICK_SUPPORTS, SIMCLICK_RANDOM);
+
+	if (sim_rng_support) {
+		if (cursimnode) {
+			uint32_t random_number;
+			simclick_sim_command(cursimnode, SIMCLICK_RANDOM, &random_number);
+			return random_number;
+		} else {
+		    click_chatter("simclick_random: call without simstate set");
+		}
+	} else {
+	    click_chatter("simclick_random: simulator has no random number support");
+	}
+	return 0;
+}
+
 int simclick_click_send(simclick_node_t *simnode,
 			int ifid,int type,const unsigned char* data,int len,
 			simclick_simpacketinfo* pinfo) {
-------------- next part --------------
diff -r fd38b9505eb9 src/click/model/ipv4-click-routing.cc
--- a/src/click/model/ipv4-click-routing.cc	Mon Jan 14 09:39:06 2013 -0800
+++ b/src/click/model/ipv4-click-routing.cc	Mon Jan 21 10:27:06 2013 +0100
@@ -24,6 +24,7 @@
 #include "ns3/node.h"
 #include "ns3/simulator.h"
 #include "ns3/log.h"
+#include "ns3/random-variable.h"
 #include "ns3/mac48-address.h"
 #include "ns3/ipv4-interface.h"
 #include "ns3/ipv4-l3-click-protocol.h"
@@ -63,6 +64,7 @@
   : m_nonDefaultName (false),
     m_ipv4 (0)
 {
+  m_random = CreateObject<UniformRandomVariable> ();
 }
 
 Ipv4ClickRouting::~Ipv4ClickRouting ()
@@ -111,6 +113,12 @@
   m_ipv4 = ipv4;
 }
 
+Ptr<UniformRandomVariable>
+Ipv4ClickRouting::GetRandom (void)
+{
+  return m_random;
+}
+
 void
 Ipv4ClickRouting::DoDispose ()
 {
@@ -606,7 +614,7 @@
     case SIMCLICK_SUPPORTS:
       {
         int othercmd = va_arg (val, int);
-        retval = (othercmd >= SIMCLICK_VERSION && othercmd <= SIMCLICK_GET_NODE_ID);
+        retval = (othercmd >= SIMCLICK_VERSION && othercmd <= SIMCLICK_RANDOM);
         break;
       }
 
@@ -738,6 +746,16 @@
         NS_LOG_DEBUG (clickInstance->GetNodeName () << " Received a call for SIMCLICK_GET_NODE_ID");
         break;
       }
+
+    case SIMCLICK_RANDOM:
+      {
+        uint32_t *random_value = va_arg (val, uint32_t *);
+
+        *random_value = clickInstance->GetRandom ()->GetInteger (0, 0xFFFFFFFEU);
+        retval = 0;
+        NS_LOG_DEBUG (clickInstance->GetNodeName () << " SIMCLICK_RANDOM: " << *random_value << " " << ns3::Simulator::Now ());
+        break;
+      }
     }
   return retval;
 }
diff -r fd38b9505eb9 src/click/model/ipv4-click-routing.h
--- a/src/click/model/ipv4-click-routing.h	Mon Jan 14 09:39:06 2013 -0800
+++ b/src/click/model/ipv4-click-routing.h	Mon Jan 21 10:27:06 2013 +0100
@@ -25,6 +25,7 @@
 #include "ns3/packet.h"
 #include "ns3/ipv4.h"
 #include "ns3/ipv4-routing-protocol.h"
+#include "ns3/random-variable-stream.h"
 #include "ns3/test.h"
 
 #include <sys/time.h>
@@ -63,6 +64,7 @@
   Ipv4ClickRouting ();
   virtual ~Ipv4ClickRouting ();
 
+  Ptr<UniformRandomVariable> GetRandom (void);
 protected:
   virtual void DoStart (void);
 
@@ -255,6 +257,7 @@
   bool m_nonDefaultName;
 
   Ptr<Ipv4> m_ipv4;
+  Ptr<UniformRandomVariable> m_random;
 #endif /* NS3_CLICK */
 };
 

From jopen at informatik.uni-bonn.de  Mon Jan 21 06:30:06 2013
From: jopen at informatik.uni-bonn.de (Sascha Alexander Jopen)
Date: Mon, 21 Jan 2013 12:30:06 +0100
Subject: [Click] Click defines in ns3
Message-ID: <50FD26BE.9090406@informatik.uni-bonn.de>

Hi again,

Both for userlevel and linuxmodule click drivers, it is possible to set
defines for the click configurations with commandline options. The
attached patchset adds this ability to the ns3 click driver, too. It is
possible to set the defines for each click node within ns3 by

Ipv4ClickRouting::SetDefines (std::map<std::string, std::string> defines);

with defines being a key/value mapping for the defines to be set.

click-ns3-defines.diff is a small patch for click side, adding a new
function to create a click node instance with defines set.

ns3-nsclick-defines.diff adds support to the ns3 simulator side.

ns2 should still run without modification. It simply doesn't use the new
function, until someone provides a patch.

If this extension is interesting to you, please review the patch and
apply it if its ok.

Regards,
Sascha

-- 
Dipl.-Inform. Sascha Jopen

University of Bonn                     Tel.:   +49-228-73-54219
Institute of Computer Science 4        Fax:    +49-228-73-4571
Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
D-53113 Bonn, Germany
-------------- next part --------------
diff --git a/include/click/simclick.h b/include/click/simclick.h
index 972a977..5d896fa 100644
--- a/include/click/simclick.h
+++ b/include/click/simclick.h
@@ -48,6 +48,10 @@ typedef struct simclick_node {
 
 int simclick_click_create(simclick_node_t *sim, const char *router_file);
 
+int simclick_click_create_defines(simclick_node_t *simnode,
+	const char* router_file,
+	const char **defines);
+
 int simclick_click_send(simclick_node_t *sim,
 			int ifid,int type,const unsigned char* data,int len,
 			simclick_simpacketinfo* pinfo);
diff --git a/ns/nsclick.cc b/ns/nsclick.cc
index 1e00b32..de28bc2 100644
--- a/ns/nsclick.cc
+++ b/ns/nsclick.cc
@@ -79,20 +80,25 @@ static void setsimstate(simclick_node_t *newstate) {
     cursimnode = newstate;
 }
 
+static void init() {
+    static bool didinit = false;
+
+    if (!didinit) {
+    	click_static_initialize();
+    	didinit = true;
+    }
+}
+
 // functions for packages
 
 
 extern "C" {
 
 int simclick_click_create(simclick_node_t *simnode, const char* router_file) {
-    static bool didinit = false;
 
     setsimstate(simnode);
 
-    if (!didinit) {
-	click_static_initialize();
-	didinit = true;
-    }
+    init();
 
     bool warnings = true;
 
@@ -114,6 +120,21 @@ int simclick_click_create(simclick_node_t *simnode, const char* router_file) {
     return 0;
 }
 
+int simclick_click_create_defines(simclick_node_t *simnode, const char* router_file, const char **defines) {
+	setsimstate(simnode);
+	init();
+	if (defines) {
+		while (*defines) {
+			ErrorHandler *errh = ErrorHandler::default_handler();
+			if (!click_lexer()->global_scope().define(*defines, *(defines + 1), false)) {
+				errh->error("parameter %s multiply defined", *defines);
+			}
+			defines += 2;
+		}
+	}
+	return simclick_click_create(simnode, router_file);
+}
+
 /*
  * XXX Need to actually implement this a little more intelligenetly...
  */
-------------- next part --------------
diff -r 22bd9c407531 src/click/helper/click-internet-stack-helper.cc
--- a/src/click/helper/click-internet-stack-helper.cc	Mon Jan 21 10:43:46 2013 +0100
+++ b/src/click/helper/click-internet-stack-helper.cc	Mon Jan 21 10:46:30 2013 +0100
@@ -125,6 +125,21 @@
 }
 
 void
+ClickInternetStackHelper::SetDefines (NodeContainer c, std::map<std::string, std::string> defines)
+{
+  for (NodeContainer::Iterator i = c.Begin (); i != c.End (); ++i)
+    {
+	  SetDefines (*i, defines);
+    }
+}
+
+void
+ClickInternetStackHelper::SetDefines (Ptr<Node> node, std::map<std::string, std::string> defines)
+{
+  m_nodeToDefinesMap.insert (std::make_pair (node, defines));
+}
+
+void
 ClickInternetStackHelper::SetRoutingTableElement (NodeContainer c, std::string rt)
 {
   for (NodeContainer::Iterator i = c.Begin (); i != c.End (); ++i)
@@ -193,6 +208,13 @@
           ipv4Routing->SetClickFile (it->second);
         }
 
+      std::map<Ptr<Node>, std::map<std::string, std::string> >::const_iterator definesIt;
+      definesIt = m_nodeToDefinesMap.find (node);
+      if (definesIt != m_nodeToDefinesMap.end ())
+        {
+          ipv4Routing->SetDefines (definesIt->second);
+        }
+
       it = m_nodeToRoutingTableElementMap.find (node);
       if (it != m_nodeToRoutingTableElementMap.end ())
         {
diff -r 22bd9c407531 src/click/helper/click-internet-stack-helper.h
--- a/src/click/helper/click-internet-stack-helper.h	Mon Jan 21 10:43:46 2013 +0100
+++ b/src/click/helper/click-internet-stack-helper.h	Mon Jan 21 10:46:30 2013 +0100
@@ -143,6 +143,20 @@
   void SetClickFile (Ptr<Node> node, std::string clickfile);
 
   /**
+   * \brief Set defines to be used for a group of nodes.
+   * \param c NodeContainer of nodes
+   * \param defines Defines mapping to be used
+   */
+  void SetDefines (NodeContainer c, std::map<std::string, std::string> defines);
+
+  /**
+   * \brief Set defines to be used for a node.
+   * \param node Node for which the defines are to be set
+   * \param defines Defines mapping to be used
+   */
+  void SetDefines (Ptr<Node> node, std::map<std::string, std::string> defines);
+
+  /**
    * \brief Set a Click routing table element for a group of nodes.
    * \param c NodeContainer of nodes
    * \param rt Click Routing Table element name
@@ -219,6 +233,11 @@
   std::map < Ptr<Node>, std::string  > m_nodeToClickFileMap;
 
   /**
+   * \brief Node to Click defines mapping
+   */
+  std::map < Ptr<Node>, std::map<std::string, std::string>  > m_nodeToDefinesMap;
+
+  /**
    * \brief Node to Routing Table Element mapping
    */
   std::map < Ptr<Node>, std::string  > m_nodeToRoutingTableElementMap;
diff -r 22bd9c407531 src/click/model/ipv4-click-routing.cc
--- a/src/click/model/ipv4-click-routing.cc	Mon Jan 21 10:43:46 2013 +0100
+++ b/src/click/model/ipv4-click-routing.cc	Mon Jan 21 10:46:30 2013 +0100
@@ -90,9 +90,23 @@
 
   NS_ASSERT (m_clickFile.length () > 0);
 
+  // Create NULL-terminated array with click defines
+  const char **defines = new const char*[(m_defines.size () + 1) * 2];
+  unsigned int i = 0;
+  std::map<std::string, std::string>::const_iterator it = m_defines.begin ();
+  while (it != m_defines.end ())
+  {
+    defines[i] = it->first.c_str ();
+    defines[i+1] = it->second.c_str ();
+    i += 2;
+    it++;
+  }
+  defines[i] = 0;
+  defines[i+1] = 0;
+
   // Even though simclick_click_create() will halt programme execution
   // if it is unable to initialise a Click router, we play safe
-  if (simclick_click_create (m_simNode, m_clickFile.c_str ()) >= 0)
+  if (simclick_click_create_defines (m_simNode, m_clickFile.c_str (), defines) >= 0)
     {
       NS_LOG_DEBUG (m_nodeName << " has initialised a Click Router");
       m_clickInitialised = true;
@@ -103,6 +117,8 @@
       m_clickInitialised = false;
     }
 
+  delete[] defines;
+
   NS_ASSERT (m_clickInitialised == true);
   simclick_click_run (m_simNode);
 }
@@ -138,6 +154,12 @@
 }
 
 void
+Ipv4ClickRouting::SetDefines (std::map<std::string, std::string> defines)
+{
+  m_defines = defines;
+}
+
+void
 Ipv4ClickRouting::SetClickRoutingTableElement (std::string name)
 {
   m_clickRoutingTableElement = name;
diff -r 22bd9c407531 src/click/model/ipv4-click-routing.h
--- a/src/click/model/ipv4-click-routing.h	Mon Jan 21 10:43:46 2013 +0100
+++ b/src/click/model/ipv4-click-routing.h	Mon Jan 21 10:46:30 2013 +0100
@@ -78,6 +78,12 @@
   void SetClickFile (std::string clickfile);
 
   /**
+  * \brief Click defines to be used by the node's Click Instance.
+  * \param defines mapping of defines for .click configuration file parsing
+  */
+  void SetDefines (std::map<std::string, std::string> defines);
+
+  /**
    * \brief Name of the node as to be used by Click. Required for Click Dumps.
    * \param name Name to be assigned to the node.
    */
@@ -246,6 +252,7 @@
 
 private:
   std::string m_clickFile;
+  std::map < std::string, std::string > m_defines;
   std::string m_nodeName;
   std::string m_clickRoutingTableElement;
 

From suresh.lalith at gmail.com  Mon Jan 21 07:07:05 2013
From: suresh.lalith at gmail.com (Lalith Suresh)
Date: Mon, 21 Jan 2013 13:07:05 +0100
Subject: [Click] Click defines in ns3
In-Reply-To: <50FD26BE.9090406@informatik.uni-bonn.de>
References: <50FD26BE.9090406@informatik.uni-bonn.de>
Message-ID: <CAOj7qWb1CFg3508a5zZOD8e8An640xZ0m53QadOiUa2pT1+QtA@mail.gmail.com>

Hi Sascha,

On Mon, Jan 21, 2013 at 12:30 PM, Sascha Alexander Jopen
<jopen at informatik.uni-bonn.de> wrote:
> Hi again,
>
> Both for userlevel and linuxmodule click drivers, it is possible to set
> defines for the click configurations with commandline options. The
> attached patchset adds this ability to the ns3 click driver, too. It is
> possible to set the defines for each click node within ns3 by
>
> Ipv4ClickRouting::SetDefines (std::map<std::string, std::string> defines);
>
> with defines being a key/value mapping for the defines to be set.
>
> click-ns3-defines.diff is a small patch for click side, adding a new
> function to create a click node instance with defines set.
>
> ns3-nsclick-defines.diff adds support to the ns3 simulator side.
>
> ns2 should still run without modification. It simply doesn't use the new
> function, until someone provides a patch.
>
> If this extension is interesting to you, please review the patch and
> apply it if its ok.
>

Thanks for the two sets of patches. I'll give them a spin by tomorrow
and get back to you.

> Regards,
> Sascha
>
> --
> Dipl.-Inform. Sascha Jopen
>
> University of Bonn                     Tel.:   +49-228-73-54219
> Institute of Computer Science 4        Fax:    +49-228-73-4571
> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
> D-53113 Bonn, Germany
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>



-- 
Lalith Suresh
www.lalith.in

From suresh.lalith at gmail.com  Wed Jan 23 03:52:00 2013
From: suresh.lalith at gmail.com (Lalith Suresh)
Date: Wed, 23 Jan 2013 09:52:00 +0100
Subject: [Click] nsclick rng support for ns3
In-Reply-To: <50FD2380.6020101@informatik.uni-bonn.de>
References: <50FD2380.6020101@informatik.uni-bonn.de>
Message-ID: <CAOj7qWaEoS_ZRj5o_csRTBvKM9U3EjvBGUsTDKh_6_y4sQm3jg@mail.gmail.com>

Hi,

On Mon, Jan 21, 2013 at 12:16 PM, Sascha Alexander Jopen
<jopen at informatik.uni-bonn.de> wrote:
> Hey,
>
> please find attached a patchset for click and ns3 which adds support for
> drawing random numbers within click simulations from the underlying ns3
> random number generator. Each simulated click node has its own uniformly
> distributed random number stream (as opposed to my previously submitted
> patch). This way all nodes have independent random number streams.
>
> Setting the seed or run numbers is done within the simulation by means of
>
> RngSeedManager::SetSeed ();
> RngSeedManager::SetRun ();
>
> or with environment variables or command line parameters.
> See http://www.nsnam.org/docs/manual/html/random-variables.html
>
> I still have no ns2 available. Currently, missing rng support from the
> simulator side is detected and reported but no random numbers are
> available to the simulation. Implementing a fallback method should be
> possible, however. Maybe someone who uses ns2 could provide this?
>
> click-ns3-rng.diff is for the click side and ns3-nsclick-rng.diff for
> the ns3 side.
>

I had a look through this patch. For clarity, my comment is to rename
the simclick command to SIMCLICK_GET_RANDOM_INT and the
Ipv4ClickRouting method's name to GetRandomVariable(). Otherwise, it
looks good.

I can push this to ns-3-dev when the click side gets committed.

> Regards,
> Sascha
>
> --
> Dipl.-Inform. Sascha Jopen
>
> University of Bonn                     Tel.:   +49-228-73-54219
> Institute of Computer Science 4        Fax:    +49-228-73-4571
> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
> D-53113 Bonn, Germany
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>



-- 
Lalith Suresh
www.lalith.in

From suresh.lalith at gmail.com  Wed Jan 23 03:57:04 2013
From: suresh.lalith at gmail.com (Lalith Suresh)
Date: Wed, 23 Jan 2013 09:57:04 +0100
Subject: [Click] Click defines in ns3
In-Reply-To: <50FD26BE.9090406@informatik.uni-bonn.de>
References: <50FD26BE.9090406@informatik.uni-bonn.de>
Message-ID: <CAOj7qWb-UhRFXCydNyY0bV=EHN28+hwTi4E=99K3M7PuRNBo3w@mail.gmail.com>

Hi again,

On Mon, Jan 21, 2013 at 12:30 PM, Sascha Alexander Jopen
<jopen at informatik.uni-bonn.de> wrote:
> Hi again,
>
> Both for userlevel and linuxmodule click drivers, it is possible to set
> defines for the click configurations with commandline options. The
> attached patchset adds this ability to the ns3 click driver, too. It is
> possible to set the defines for each click node within ns3 by
>
> Ipv4ClickRouting::SetDefines (std::map<std::string, std::string> defines);
>
> with defines being a key/value mapping for the defines to be set.
>
> click-ns3-defines.diff is a small patch for click side, adding a new
> function to create a click node instance with defines set.
>
> ns3-nsclick-defines.diff adds support to the ns3 simulator side.
>
> ns2 should still run without modification. It simply doesn't use the new
> function, until someone provides a patch.
>
> If this extension is interesting to you, please review the patch and
> apply it if its ok.
>

The simclick API can be named "simclick_click_create_with_defines" for
clarity. But +1 otherwise.

It would be good if you could send me an ns-3 example script that uses
this API that will go into src/click/model/examples/. I can update the
docs to reflect the new API.

Thanks for the patches!


> Regards,
> Sascha
>
> --
> Dipl.-Inform. Sascha Jopen
>
> University of Bonn                     Tel.:   +49-228-73-54219
> Institute of Computer Science 4        Fax:    +49-228-73-4571
> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
> D-53113 Bonn, Germany
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>



-- 
Lalith Suresh
www.lalith.in

From jopen at informatik.uni-bonn.de  Wed Jan 23 06:56:55 2013
From: jopen at informatik.uni-bonn.de (Sascha Alexander Jopen)
Date: Wed, 23 Jan 2013 12:56:55 +0100
Subject: [Click] Click defines in ns3
In-Reply-To: <CACeiqXTWKAX0q9Dr1xky=YQPjM0o+-6sUGm0cvYWxiz0VJ2bJA@mail.gmail.com>
References: <50FD26BE.9090406@informatik.uni-bonn.de>
	<CACeiqXTWKAX0q9Dr1xky=YQPjM0o+-6sUGm0cvYWxiz0VJ2bJA@mail.gmail.com>
Message-ID: <50FFD007.8060503@informatik.uni-bonn.de>

Hi,

i think this has nothing to do with the Click defines patchset. Please
use a new thread for your questions.

How packet processing is done in your application depends on the type
and format of your packets. There are standard elements in click to deal
with Ethernet or IP packets, for example. See
http://read.cs.ucla.edu/click/elements
For processing of application layer data, you have to write your own
elements. See http://www.read.cs.ucla.edu/gitweb?p=click;a=blob;f=FAQ
and http://www.read.cs.ucla.edu/click/learning

Regards,
Sascha

On 23.01.2013 11:46, karthick m wrote:
> Hi sascha,
> 
>             I am implementing my own publish subscribe architecture using
> click router. For that i need to work on packets. Say a publisher is
> sending a publish packet, i have to see the packet data and process packet
> according to the data and route it.  The problem is that, i do not find any
> element which does packet processing for example. Could you please give me
> a pointer to it. Thanks in advance.
> 


-- 
Dipl.-Inform. Sascha Jopen

University of Bonn                     Tel.:   +49-228-73-54219
Institute of Computer Science 4        Fax:    +49-228-73-4571
Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
D-53113 Bonn, Germany

From ekohler at gmail.com  Wed Jan 23 10:46:48 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Wed, 23 Jan 2013 10:46:48 -0500
Subject: [Click] Click defines in ns3
In-Reply-To: <50FFD007.8060503@informatik.uni-bonn.de>
References: <50FD26BE.9090406@informatik.uni-bonn.de>
	<CACeiqXTWKAX0q9Dr1xky=YQPjM0o+-6sUGm0cvYWxiz0VJ2bJA@mail.gmail.com>
	<50FFD007.8060503@informatik.uni-bonn.de>
Message-ID: <CAF0C5SJR56kdNazV639WRAVPOdRxq0GJ2dbLGyO9enQF8T_chw@mail.gmail.com>

Hey,

I'm always bummed out by API changes that require people to keep two
packages precisely up to date and will therefore request some changes.

(1) Add a new SIMCLICK comamnd constant, SIMCLICK_DEFINE or
SIMCLICK_CREATE_DEFINE, your choice.
(2) Change simclick_click_command so that SIMCLICK_SUPPORTS reports
true for SIMCLICK_DEFINE
(3) Implement definition support via SIMCLICK_DEFINE, which will
require changes to click and to ns.

Make sense?
Eddie


On Wed, Jan 23, 2013 at 6:56 AM, Sascha Alexander Jopen
<jopen at informatik.uni-bonn.de> wrote:
> Hi,
>
> i think this has nothing to do with the Click defines patchset. Please
> use a new thread for your questions.
>
> How packet processing is done in your application depends on the type
> and format of your packets. There are standard elements in click to deal
> with Ethernet or IP packets, for example. See
> http://read.cs.ucla.edu/click/elements
> For processing of application layer data, you have to write your own
> elements. See http://www.read.cs.ucla.edu/gitweb?p=click;a=blob;f=FAQ
> and http://www.read.cs.ucla.edu/click/learning
>
> Regards,
> Sascha
>
> On 23.01.2013 11:46, karthick m wrote:
>> Hi sascha,
>>
>>             I am implementing my own publish subscribe architecture using
>> click router. For that i need to work on packets. Say a publisher is
>> sending a publish packet, i have to see the packet data and process packet
>> according to the data and route it.  The problem is that, i do not find any
>> element which does packet processing for example. Could you please give me
>> a pointer to it. Thanks in advance.
>>
>
>
> --
> Dipl.-Inform. Sascha Jopen
>
> University of Bonn                     Tel.:   +49-228-73-54219
> Institute of Computer Science 4        Fax:    +49-228-73-4571
> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
> D-53113 Bonn, Germany
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click

From ekohler at gmail.com  Wed Jan 23 10:52:14 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Wed, 23 Jan 2013 10:52:14 -0500
Subject: [Click] nsclick rng support for ns3
In-Reply-To: <CAOj7qWaEoS_ZRj5o_csRTBvKM9U3EjvBGUsTDKh_6_y4sQm3jg@mail.gmail.com>
References: <50FD2380.6020101@informatik.uni-bonn.de>
	<CAOj7qWaEoS_ZRj5o_csRTBvKM9U3EjvBGUsTDKh_6_y4sQm3jg@mail.gmail.com>
Message-ID: <CAF0C5SLJUeGhRC=23uzkOTe78XLXDdY+SVBgR7eM4O7s895poQ@mail.gmail.com>

Hey,

Two comments.
- Breaking random numbers except for nses that export random numbers
considered lame. Why not fall back to the normal random number
generator?
- The RAND_MAX value seems odd. (-2??) Why this value?

Eddie

On Wed, Jan 23, 2013 at 3:52 AM, Lalith Suresh <suresh.lalith at gmail.com> wrote:
> Hi,
>
> On Mon, Jan 21, 2013 at 12:16 PM, Sascha Alexander Jopen
> <jopen at informatik.uni-bonn.de> wrote:
>> Hey,
>>
>> please find attached a patchset for click and ns3 which adds support for
>> drawing random numbers within click simulations from the underlying ns3
>> random number generator. Each simulated click node has its own uniformly
>> distributed random number stream (as opposed to my previously submitted
>> patch). This way all nodes have independent random number streams.
>>
>> Setting the seed or run numbers is done within the simulation by means of
>>
>> RngSeedManager::SetSeed ();
>> RngSeedManager::SetRun ();
>>
>> or with environment variables or command line parameters.
>> See http://www.nsnam.org/docs/manual/html/random-variables.html
>>
>> I still have no ns2 available. Currently, missing rng support from the
>> simulator side is detected and reported but no random numbers are
>> available to the simulation. Implementing a fallback method should be
>> possible, however. Maybe someone who uses ns2 could provide this?
>>
>> click-ns3-rng.diff is for the click side and ns3-nsclick-rng.diff for
>> the ns3 side.
>>
>
> I had a look through this patch. For clarity, my comment is to rename
> the simclick command to SIMCLICK_GET_RANDOM_INT and the
> Ipv4ClickRouting method's name to GetRandomVariable(). Otherwise, it
> looks good.
>
> I can push this to ns-3-dev when the click side gets committed.
>
>> Regards,
>> Sascha
>>
>> --
>> Dipl.-Inform. Sascha Jopen
>>
>> University of Bonn                     Tel.:   +49-228-73-54219
>> Institute of Computer Science 4        Fax:    +49-228-73-4571
>> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
>> D-53113 Bonn, Germany
>>
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
>
>
>
> --
> Lalith Suresh
> www.lalith.in
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click

From jopen at informatik.uni-bonn.de  Wed Jan 23 11:36:19 2013
From: jopen at informatik.uni-bonn.de (Sascha Alexander Jopen)
Date: Wed, 23 Jan 2013 17:36:19 +0100
Subject: [Click] Click defines in ns3
In-Reply-To: <CAF0C5SJR56kdNazV639WRAVPOdRxq0GJ2dbLGyO9enQF8T_chw@mail.gmail.com>
References: <50FD26BE.9090406@informatik.uni-bonn.de>
	<CACeiqXTWKAX0q9Dr1xky=YQPjM0o+-6sUGm0cvYWxiz0VJ2bJA@mail.gmail.com>
	<50FFD007.8060503@informatik.uni-bonn.de>
	<CAF0C5SJR56kdNazV639WRAVPOdRxq0GJ2dbLGyO9enQF8T_chw@mail.gmail.com>
Message-ID: <51001183.4010704@informatik.uni-bonn.de>

Hey,

with the current implementation on the ns3 side, using
simclick_click_command is only possible after an instance of the click
router has been created (Ipv4ClickRouting::DoStart ()). However, we
already need the defines at this time to instantiate the router.
I'll try to rearrange this and implement defines the way you suggested,
keeping the API stable.

Sascha

On 23.01.2013 16:46, Eddie Kohler wrote:
> Hey,
> 
> I'm always bummed out by API changes that require people to keep two
> packages precisely up to date and will therefore request some changes.
> 
> (1) Add a new SIMCLICK comamnd constant, SIMCLICK_DEFINE or
> SIMCLICK_CREATE_DEFINE, your choice.
> (2) Change simclick_click_command so that SIMCLICK_SUPPORTS reports
> true for SIMCLICK_DEFINE
> (3) Implement definition support via SIMCLICK_DEFINE, which will
> require changes to click and to ns.
> 
> Make sense?
> Eddie
> 
> 
> On Wed, Jan 23, 2013 at 6:56 AM, Sascha Alexander Jopen
> <jopen at informatik.uni-bonn.de> wrote:
>> Hi,
>>
>> i think this has nothing to do with the Click defines patchset. Please
>> use a new thread for your questions.
>>
>> How packet processing is done in your application depends on the type
>> and format of your packets. There are standard elements in click to deal
>> with Ethernet or IP packets, for example. See
>> http://read.cs.ucla.edu/click/elements
>> For processing of application layer data, you have to write your own
>> elements. See http://www.read.cs.ucla.edu/gitweb?p=click;a=blob;f=FAQ
>> and http://www.read.cs.ucla.edu/click/learning
>>
>> Regards,
>> Sascha
>>
>> On 23.01.2013 11:46, karthick m wrote:
>>> Hi sascha,
>>>
>>>             I am implementing my own publish subscribe architecture using
>>> click router. For that i need to work on packets. Say a publisher is
>>> sending a publish packet, i have to see the packet data and process packet
>>> according to the data and route it.  The problem is that, i do not find any
>>> element which does packet processing for example. Could you please give me
>>> a pointer to it. Thanks in advance.
>>>
>>
>>
>> --
>> Dipl.-Inform. Sascha Jopen
>>
>> University of Bonn                     Tel.:   +49-228-73-54219
>> Institute of Computer Science 4        Fax:    +49-228-73-4571
>> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
>> D-53113 Bonn, Germany
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click


-- 
Dipl.-Inform. Sascha Jopen

University of Bonn                     Tel.:   +49-228-73-54219
Institute of Computer Science 4        Fax:    +49-228-73-4571
Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
D-53113 Bonn, Germany

From jopen at informatik.uni-bonn.de  Wed Jan 23 12:35:06 2013
From: jopen at informatik.uni-bonn.de (Sascha Alexander Jopen)
Date: Wed, 23 Jan 2013 18:35:06 +0100
Subject: [Click] nsclick rng support for ns3
In-Reply-To: <CAF0C5SLJUeGhRC=23uzkOTe78XLXDdY+SVBgR7eM4O7s895poQ@mail.gmail.com>
References: <50FD2380.6020101@informatik.uni-bonn.de>
	<CAOj7qWaEoS_ZRj5o_csRTBvKM9U3EjvBGUsTDKh_6_y4sQm3jg@mail.gmail.com>
	<CAF0C5SLJUeGhRC=23uzkOTe78XLXDdY+SVBgR7eM4O7s895poQ@mail.gmail.com>
Message-ID: <51001F4A.9030205@informatik.uni-bonn.de>

Hi Eddie,

I did not implement a fallback method, because i was not sure how to
handle CLICK_RAND_MAX in case a fall back is necessary. In
include/click/glue.hh CLICK_RAND_MAX is defined as the maximum value
supported by the ns3 implementation. However, if we find the simulator
not supporting random numbers at runtime, falling back to random() or
rand() could lead to a RAND_MAX, which is different from the defined
CLICK_RAND_MAX. This could lead to unexpected simulation behaviour. Any
comments, how to handle this?

Regarding the CLICK_RAND_MAX value itself, i can change the maximum
value to 0xFFFFFFFFU.

I used 0xFFFFFFFEU in the first place, because, although the ns3
documentation says, that calling

  uint32_t GetInteger(uint32_t min, uint32_t max)

returns an integer in the range [min,max], this seems not to be true for
max = 0xFFFFFFFFU. Because this calls internally another method, with
GetValue(min, max + 1), this results in an overflow. So 0xFFFFFFFEU
would be the largest possible integer. See around line 187 in file
src/core/model/random-variable-stream.cc. Either i'm wrong, or this is
something to report to the ns3 team.

However, i certainly missed the alternative call with a cast of the max
value 0xFFFFFFFFU to double and back to uint32_t after a call to the
double based GetValue function. This would lead to a RAND_MAX of
0xFFFFFFFFU. I will fix this.

Thanks for reviewing,
Sascha

On 23.01.2013 16:52, Eddie Kohler wrote:
> Hey,
> 
> Two comments.
> - Breaking random numbers except for nses that export random numbers
> considered lame. Why not fall back to the normal random number
> generator?
> - The RAND_MAX value seems odd. (-2??) Why this value?
> 
> Eddie
> 
> On Wed, Jan 23, 2013 at 3:52 AM, Lalith Suresh <suresh.lalith at gmail.com> wrote:
>> Hi,
>>
>> On Mon, Jan 21, 2013 at 12:16 PM, Sascha Alexander Jopen
>> <jopen at informatik.uni-bonn.de> wrote:
>>> Hey,
>>>
>>> please find attached a patchset for click and ns3 which adds support for
>>> drawing random numbers within click simulations from the underlying ns3
>>> random number generator. Each simulated click node has its own uniformly
>>> distributed random number stream (as opposed to my previously submitted
>>> patch). This way all nodes have independent random number streams.
>>>
>>> Setting the seed or run numbers is done within the simulation by means of
>>>
>>> RngSeedManager::SetSeed ();
>>> RngSeedManager::SetRun ();
>>>
>>> or with environment variables or command line parameters.
>>> See http://www.nsnam.org/docs/manual/html/random-variables.html
>>>
>>> I still have no ns2 available. Currently, missing rng support from the
>>> simulator side is detected and reported but no random numbers are
>>> available to the simulation. Implementing a fallback method should be
>>> possible, however. Maybe someone who uses ns2 could provide this?
>>>
>>> click-ns3-rng.diff is for the click side and ns3-nsclick-rng.diff for
>>> the ns3 side.
>>>
>>
>> I had a look through this patch. For clarity, my comment is to rename
>> the simclick command to SIMCLICK_GET_RANDOM_INT and the
>> Ipv4ClickRouting method's name to GetRandomVariable(). Otherwise, it
>> looks good.
>>
>> I can push this to ns-3-dev when the click side gets committed.
>>
>>> Regards,
>>> Sascha
>>>
>>> --
>>> Dipl.-Inform. Sascha Jopen
>>>
>>> University of Bonn                     Tel.:   +49-228-73-54219
>>> Institute of Computer Science 4        Fax:    +49-228-73-4571
>>> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
>>> D-53113 Bonn, Germany
>>>
>>> _______________________________________________
>>> click mailing list
>>> click at amsterdam.lcs.mit.edu
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>
>>
>>
>>
>> --
>> Lalith Suresh
>> www.lalith.in
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click


-- 
Dipl.-Inform. Sascha Jopen

University of Bonn                     Tel.:   +49-228-73-54219
Institute of Computer Science 4        Fax:    +49-228-73-4571
Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
D-53113 Bonn, Germany

From ekohler at gmail.com  Wed Jan 23 12:54:46 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Wed, 23 Jan 2013 12:54:46 -0500
Subject: [Click] nsclick rng support for ns3
In-Reply-To: <51001F4A.9030205@informatik.uni-bonn.de>
References: <50FD2380.6020101@informatik.uni-bonn.de>
	<CAOj7qWaEoS_ZRj5o_csRTBvKM9U3EjvBGUsTDKh_6_y4sQm3jg@mail.gmail.com>
	<CAF0C5SLJUeGhRC=23uzkOTe78XLXDdY+SVBgR7eM4O7s895poQ@mail.gmail.com>
	<51001F4A.9030205@informatik.uni-bonn.de>
Message-ID: <510023E6.3070301@seas.harvard.edu>

Why not just set the CLICK_RAND_MAX to 0x7FFFFFFFU, which NS can handle 
as well as normal code?

Eddie


On 1/23/13 12:35 PM, Sascha Alexander Jopen wrote:
> Hi Eddie,
>
> I did not implement a fallback method, because i was not sure how to
> handle CLICK_RAND_MAX in case a fall back is necessary. In
> include/click/glue.hh CLICK_RAND_MAX is defined as the maximum value
> supported by the ns3 implementation. However, if we find the simulator
> not supporting random numbers at runtime, falling back to random() or
> rand() could lead to a RAND_MAX, which is different from the defined
> CLICK_RAND_MAX. This could lead to unexpected simulation behaviour. Any
> comments, how to handle this?
>
> Regarding the CLICK_RAND_MAX value itself, i can change the maximum
> value to 0xFFFFFFFFU.
>
> I used 0xFFFFFFFEU in the first place, because, although the ns3
> documentation says, that calling
>
>    uint32_t GetInteger(uint32_t min, uint32_t max)
>
> returns an integer in the range [min,max], this seems not to be true for
> max = 0xFFFFFFFFU. Because this calls internally another method, with
> GetValue(min, max + 1), this results in an overflow. So 0xFFFFFFFEU
> would be the largest possible integer. See around line 187 in file
> src/core/model/random-variable-stream.cc. Either i'm wrong, or this is
> something to report to the ns3 team.
>
> However, i certainly missed the alternative call with a cast of the max
> value 0xFFFFFFFFU to double and back to uint32_t after a call to the
> double based GetValue function. This would lead to a RAND_MAX of
> 0xFFFFFFFFU. I will fix this.
>
> Thanks for reviewing,
> Sascha
>
> On 23.01.2013 16:52, Eddie Kohler wrote:
>> Hey,
>>
>> Two comments.
>> - Breaking random numbers except for nses that export random numbers
>> considered lame. Why not fall back to the normal random number
>> generator?
>> - The RAND_MAX value seems odd. (-2??) Why this value?
>>
>> Eddie
>>
>> On Wed, Jan 23, 2013 at 3:52 AM, Lalith Suresh <suresh.lalith at gmail.com> wrote:
>>> Hi,
>>>
>>> On Mon, Jan 21, 2013 at 12:16 PM, Sascha Alexander Jopen
>>> <jopen at informatik.uni-bonn.de> wrote:
>>>> Hey,
>>>>
>>>> please find attached a patchset for click and ns3 which adds support for
>>>> drawing random numbers within click simulations from the underlying ns3
>>>> random number generator. Each simulated click node has its own uniformly
>>>> distributed random number stream (as opposed to my previously submitted
>>>> patch). This way all nodes have independent random number streams.
>>>>
>>>> Setting the seed or run numbers is done within the simulation by means of
>>>>
>>>> RngSeedManager::SetSeed ();
>>>> RngSeedManager::SetRun ();
>>>>
>>>> or with environment variables or command line parameters.
>>>> See http://www.nsnam.org/docs/manual/html/random-variables.html
>>>>
>>>> I still have no ns2 available. Currently, missing rng support from the
>>>> simulator side is detected and reported but no random numbers are
>>>> available to the simulation. Implementing a fallback method should be
>>>> possible, however. Maybe someone who uses ns2 could provide this?
>>>>
>>>> click-ns3-rng.diff is for the click side and ns3-nsclick-rng.diff for
>>>> the ns3 side.
>>>>
>>>
>>> I had a look through this patch. For clarity, my comment is to rename
>>> the simclick command to SIMCLICK_GET_RANDOM_INT and the
>>> Ipv4ClickRouting method's name to GetRandomVariable(). Otherwise, it
>>> looks good.
>>>
>>> I can push this to ns-3-dev when the click side gets committed.
>>>
>>>> Regards,
>>>> Sascha
>>>>
>>>> --
>>>> Dipl.-Inform. Sascha Jopen
>>>>
>>>> University of Bonn                     Tel.:   +49-228-73-54219
>>>> Institute of Computer Science 4        Fax:    +49-228-73-4571
>>>> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
>>>> D-53113 Bonn, Germany
>>>>
>>>> _______________________________________________
>>>> click mailing list
>>>> click at amsterdam.lcs.mit.edu
>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>
>>>
>>>
>>>
>>> --
>>> Lalith Suresh
>>> www.lalith.in
>>> _______________________________________________
>>> click mailing list
>>> click at amsterdam.lcs.mit.edu
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>
>

From mkarthick19 at gmail.com  Thu Jan 24 03:12:42 2013
From: mkarthick19 at gmail.com (karthick m)
Date: Thu, 24 Jan 2013 13:42:42 +0530
Subject: [Click] Click Packet
Message-ID: <CACeiqXRN3g0iRHUGzxks-4KhzhWrAqAXMVHdBPmhFG501Zp1eQ@mail.gmail.com>

Hi,

  I am a beginner to click router.  I have read the documentation. But
still I have some doubts like how to define my own packet or
how to add variables in a class Packet etc. In InfiniteSource function, the
packet is declared in hex. So If I have to send a packet with data say
10000, do I need to convert this into hex and send. Thanks.

From bart.braem at ua.ac.be  Thu Jan 24 03:48:34 2013
From: bart.braem at ua.ac.be (Braem Bart)
Date: Thu, 24 Jan 2013 08:48:34 +0000
Subject: [Click] Click Packet
In-Reply-To: <CACeiqXRN3g0iRHUGzxks-4KhzhWrAqAXMVHdBPmhFG501Zp1eQ@mail.gmail.com>
References: <CACeiqXRN3g0iRHUGzxks-4KhzhWrAqAXMVHdBPmhFG501Zp1eQ@mail.gmail.com>
Message-ID: <A2982E817BCF1E4EBA4B1CB114AE457C0104B17C63@xmail33.ad.ua.ac.be>

Hi,

Please take a look at <http://www.pats.ua.ac.be/software/click/> for more documentation.
If you are not sure about packet formats, Wireshark is your friends.

regards,
Bart

On 24 Jan 2013, at 09:12, karthick m <mkarthick19 at gmail.com> wrote:

> Hi,
> 
>  I am a beginner to click router.  I have read the documentation. But
> still I have some doubts like how to define my own packet or
> how to add variables in a class Packet etc. In InfiniteSource function, the
> packet is declared in hex. So If I have to send a packet with data say
> 10000, do I need to convert this into hex and send. Thanks.
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click



From bart.braem at ua.ac.be  Thu Jan 24 04:54:42 2013
From: bart.braem at ua.ac.be (Braem Bart)
Date: Thu, 24 Jan 2013 09:54:42 +0000
Subject: [Click] Click Packet
In-Reply-To: <CACeiqXSHYArwHn70Ab8B-riAMZCXeZLUWz9TCkiPN2kdY5v_2Q@mail.gmail.com>
References: <CACeiqXRN3g0iRHUGzxks-4KhzhWrAqAXMVHdBPmhFG501Zp1eQ@mail.gmail.com>
	<A2982E817BCF1E4EBA4B1CB114AE457C0104B17C63@xmail33.ad.ua.ac.be>
	<CACeiqXSHYArwHn70Ab8B-riAMZCXeZLUWz9TCkiPN2kdY5v_2Q@mail.gmail.com>
Message-ID: <A2982E817BCF1E4EBA4B1CB114AE457C0104B17FAA@xmail33.ad.ua.ac.be>

Please reply to the mailing list.
Take a look at <http://read.cs.ucla.edu/click/doxygen/class_element.html> under initialisation phases.

Bart

On 24 Jan 2013, at 10:50, karthick m <mkarthick19 at gmail.com<mailto:mkarthick19 at gmail.com>>
 wrote:

Thanks Braem!

I have one more question. In which order the functions are called in a element.  Say Print element has configure,
simple_action, add_handlers etc. Does configure function called first?




From jopen at informatik.uni-bonn.de  Fri Jan 25 07:06:46 2013
From: jopen at informatik.uni-bonn.de (Sascha Alexander Jopen)
Date: Fri, 25 Jan 2013 13:06:46 +0100
Subject: [Click] nsclick rng support for ns3
In-Reply-To: <510023E6.3070301@seas.harvard.edu>
References: <50FD2380.6020101@informatik.uni-bonn.de>
	<CAOj7qWaEoS_ZRj5o_csRTBvKM9U3EjvBGUsTDKh_6_y4sQm3jg@mail.gmail.com>
	<CAF0C5SLJUeGhRC=23uzkOTe78XLXDdY+SVBgR7eM4O7s895poQ@mail.gmail.com>
	<51001F4A.9030205@informatik.uni-bonn.de>
	<510023E6.3070301@seas.harvard.edu>
Message-ID: <51027556.2060106@informatik.uni-bonn.de>

Hey,

i just tested this new patchset for random number support. It includes
fallback to userlevel random() or rand() in case of lacking support on
the ns3 side. Furthermore, ns3 returns random numbers in the range [0,
CLICK_RAND_MAX] whatever CLICK_RAND_MAX is on the platform where click
was compiled, as long as CLICK_RAND_MAX <= 0xFFFFFFFFU. This is done by
sending the actual CLICK_RAND_MAX value along with simclick_sim_command.
The ns3 side patch includes the changes suggested by Lalith.
Is this an acceptable solution?

Regards,
Sascha

On 23.01.2013 18:54, Eddie Kohler wrote:
> Why not just set the CLICK_RAND_MAX to 0x7FFFFFFFU, which NS can handle
> as well as normal code?
> 
> Eddie
> 
> 
> On 1/23/13 12:35 PM, Sascha Alexander Jopen wrote:
>> Hi Eddie,
>>
>> I did not implement a fallback method, because i was not sure how to
>> handle CLICK_RAND_MAX in case a fall back is necessary. In
>> include/click/glue.hh CLICK_RAND_MAX is defined as the maximum value
>> supported by the ns3 implementation. However, if we find the simulator
>> not supporting random numbers at runtime, falling back to random() or
>> rand() could lead to a RAND_MAX, which is different from the defined
>> CLICK_RAND_MAX. This could lead to unexpected simulation behaviour. Any
>> comments, how to handle this?
>>
>> Regarding the CLICK_RAND_MAX value itself, i can change the maximum
>> value to 0xFFFFFFFFU.
>>
>> I used 0xFFFFFFFEU in the first place, because, although the ns3
>> documentation says, that calling
>>
>>    uint32_t GetInteger(uint32_t min, uint32_t max)
>>
>> returns an integer in the range [min,max], this seems not to be true for
>> max = 0xFFFFFFFFU. Because this calls internally another method, with
>> GetValue(min, max + 1), this results in an overflow. So 0xFFFFFFFEU
>> would be the largest possible integer. See around line 187 in file
>> src/core/model/random-variable-stream.cc. Either i'm wrong, or this is
>> something to report to the ns3 team.
>>
>> However, i certainly missed the alternative call with a cast of the max
>> value 0xFFFFFFFFU to double and back to uint32_t after a call to the
>> double based GetValue function. This would lead to a RAND_MAX of
>> 0xFFFFFFFFU. I will fix this.
>>
>> Thanks for reviewing,
>> Sascha
>>
>> On 23.01.2013 16:52, Eddie Kohler wrote:
>>> Hey,
>>>
>>> Two comments.
>>> - Breaking random numbers except for nses that export random numbers
>>> considered lame. Why not fall back to the normal random number
>>> generator?
>>> - The RAND_MAX value seems odd. (-2??) Why this value?
>>>
>>> Eddie
>>>
>>> On Wed, Jan 23, 2013 at 3:52 AM, Lalith Suresh
>>> <suresh.lalith at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On Mon, Jan 21, 2013 at 12:16 PM, Sascha Alexander Jopen
>>>> <jopen at informatik.uni-bonn.de> wrote:
>>>>> Hey,
>>>>>
>>>>> please find attached a patchset for click and ns3 which adds
>>>>> support for
>>>>> drawing random numbers within click simulations from the underlying
>>>>> ns3
>>>>> random number generator. Each simulated click node has its own
>>>>> uniformly
>>>>> distributed random number stream (as opposed to my previously
>>>>> submitted
>>>>> patch). This way all nodes have independent random number streams.
>>>>>
>>>>> Setting the seed or run numbers is done within the simulation by
>>>>> means of
>>>>>
>>>>> RngSeedManager::SetSeed ();
>>>>> RngSeedManager::SetRun ();
>>>>>
>>>>> or with environment variables or command line parameters.
>>>>> See http://www.nsnam.org/docs/manual/html/random-variables.html
>>>>>
>>>>> I still have no ns2 available. Currently, missing rng support from the
>>>>> simulator side is detected and reported but no random numbers are
>>>>> available to the simulation. Implementing a fallback method should be
>>>>> possible, however. Maybe someone who uses ns2 could provide this?
>>>>>
>>>>> click-ns3-rng.diff is for the click side and ns3-nsclick-rng.diff for
>>>>> the ns3 side.
>>>>>
>>>>
>>>> I had a look through this patch. For clarity, my comment is to rename
>>>> the simclick command to SIMCLICK_GET_RANDOM_INT and the
>>>> Ipv4ClickRouting method's name to GetRandomVariable(). Otherwise, it
>>>> looks good.
>>>>
>>>> I can push this to ns-3-dev when the click side gets committed.
>>>>
>>>>> Regards,
>>>>> Sascha
>>>>>
>>>>> -- 
>>>>> Dipl.-Inform. Sascha Jopen
>>>>>
>>>>> University of Bonn                     Tel.:   +49-228-73-54219
>>>>> Institute of Computer Science 4        Fax:    +49-228-73-4571
>>>>> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
>>>>> D-53113 Bonn, Germany
>>>>>
>>>>> _______________________________________________
>>>>> click mailing list
>>>>> click at amsterdam.lcs.mit.edu
>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Lalith Suresh
>>>> www.lalith.in
>>>> _______________________________________________
>>>> click mailing list
>>>> click at amsterdam.lcs.mit.edu
>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
>>


-- 
Dipl.-Inform. Sascha Jopen

University of Bonn                     Tel.:   +49-228-73-54219
Institute of Computer Science 4        Fax:    +49-228-73-4571
Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
D-53113 Bonn, Germany
-------------- next part --------------
diff --git a/include/click/glue.hh b/include/click/glue.hh
index a908496..92ec28c 100644
--- a/include/click/glue.hh
+++ b/include/click/glue.hh
@@ -70,6 +70,7 @@ CLICK_CXX_UNPROTECT
 # include <sys/time.h>
 # if CLICK_NS
 extern "C" int simclick_gettimeofday(struct timeval *);
+extern "C" uint32_t simclick_random();
 # endif
 # if HAVE_MULTITHREAD
 #  include <pthread.h>
@@ -139,16 +140,26 @@ void click_random_srandom();
 extern uint32_t click_random_seed;
 #endif
 
+#if !CLICK_LINUXMODULE && !CLICK_BSDMODULE
+inline uint32_t userlevel_random() {
+# if HAVE_RANDOM && CLICK_RAND_MAX == RAND_MAX
+    return random();
+# else
+    return rand();
+# endif
+}
+#endif
+
 inline uint32_t click_random() {
 #if CLICK_BSDMODULE
     return random();
 #elif CLICK_LINUXMODULE
     click_random_seed = click_random_seed * 69069L + 5;
     return (click_random_seed ^ jiffies) & CLICK_RAND_MAX; // XXX jiffies??
-#elif HAVE_RANDOM && CLICK_RAND_MAX == RAND_MAX
-    return random();
+#elif CLICK_NS
+    return simclick_random();
 #else
-    return rand();
+    return userlevel_random();
 #endif
 }
 
diff --git a/include/click/simclick.h b/include/click/simclick.h
index 972a977..938501e 100644
--- a/include/click/simclick.h
+++ b/include/click/simclick.h
@@ -106,6 +106,7 @@ int simclick_gettimeofday(struct timeval* tv);
 #define SIMCLICK_CHANGE_CHANNEL		11 // int ifid, int channelid
 #define SIMCLICK_IF_PROMISC		12 // int ifid
 #define SIMCLICK_IPPREFIX_FROM_NAME	13 // const char *ifname, char *buf, int len
+#define SIMCLICK_GET_RANDOM_INT		14 // uint32_t *randomvalue, uint32_t  maxvalue
 
 int simclick_sim_command(simclick_node_t *sim, int cmd, ...);
 int simclick_click_command(simclick_node_t *sim, int cmd, ...);
diff --git a/ns/nsclick.cc b/ns/nsclick.cc
index 1e00b32..5fce515 100644
--- a/ns/nsclick.cc
+++ b/ns/nsclick.cc
@@ -153,6 +153,23 @@ int simclick_gettimeofday(struct timeval* tv) {
   }
 }
 
+uint32_t simclick_random() {
+  static bool sim_rng_support = simclick_sim_command(NULL, SIMCLICK_SUPPORTS, SIMCLICK_GET_RANDOM_INT);
+
+  if (sim_rng_support) {
+    if (cursimnode) {
+      uint32_t random_number;
+      simclick_sim_command(cursimnode, SIMCLICK_GET_RANDOM_INT, &random_number, CLICK_RAND_MAX);
+      return random_number;
+    } else {
+      click_chatter("simclick_random: call without simstate set");
+    }
+  } else {
+    return userlevel_random();
+  }
+  return 0;
+}
+
 int simclick_click_send(simclick_node_t *simnode,
 			int ifid,int type,const unsigned char* data,int len,
 			simclick_simpacketinfo* pinfo) {
-------------- next part --------------
diff -r fd38b9505eb9 src/click/model/ipv4-click-routing.cc
--- a/src/click/model/ipv4-click-routing.cc	Mon Jan 14 09:39:06 2013 -0800
+++ b/src/click/model/ipv4-click-routing.cc	Fri Jan 25 12:53:04 2013 +0100
@@ -24,6 +24,7 @@
 #include "ns3/node.h"
 #include "ns3/simulator.h"
 #include "ns3/log.h"
+#include "ns3/random-variable-stream.h"
 #include "ns3/mac48-address.h"
 #include "ns3/ipv4-interface.h"
 #include "ns3/ipv4-l3-click-protocol.h"
@@ -63,6 +64,7 @@
   : m_nonDefaultName (false),
     m_ipv4 (0)
 {
+  m_random = CreateObject<UniformRandomVariable> ();
 }
 
 Ipv4ClickRouting::~Ipv4ClickRouting ()
@@ -111,6 +113,12 @@
   m_ipv4 = ipv4;
 }
 
+Ptr<UniformRandomVariable>
+Ipv4ClickRouting::GetRandomVariable (void)
+{
+  return m_random;
+}
+
 void
 Ipv4ClickRouting::DoDispose ()
 {
@@ -606,7 +614,7 @@
     case SIMCLICK_SUPPORTS:
       {
         int othercmd = va_arg (val, int);
-        retval = (othercmd >= SIMCLICK_VERSION && othercmd <= SIMCLICK_GET_NODE_ID);
+        retval = (othercmd >= SIMCLICK_VERSION && othercmd <= SIMCLICK_GET_RANDOM_INT);
         break;
       }
 
@@ -738,6 +746,17 @@
         NS_LOG_DEBUG (clickInstance->GetNodeName () << " Received a call for SIMCLICK_GET_NODE_ID");
         break;
       }
+
+    case SIMCLICK_GET_RANDOM_INT:
+      {
+        uint32_t *randomValue = va_arg (val, uint32_t *);
+        uint32_t maxValue = va_arg (val, uint32_t);
+
+        *randomValue = static_cast<uint32_t> (clickInstance->GetRandomVariable ()->GetValue (0.0, static_cast<double> (maxValue) + 1.0));
+        retval = 0;
+        NS_LOG_DEBUG (clickInstance->GetNodeName () << " SIMCLICK_RANDOM: " << *randomValue << " " << maxValue << " " << ns3::Simulator::Now ());
+        break;
+      }
     }
   return retval;
 }
diff -r fd38b9505eb9 src/click/model/ipv4-click-routing.h
--- a/src/click/model/ipv4-click-routing.h	Mon Jan 14 09:39:06 2013 -0800
+++ b/src/click/model/ipv4-click-routing.h	Fri Jan 25 12:53:04 2013 +0100
@@ -44,6 +44,8 @@
 * This section documents the API of the ns-3 click module. For a generic functional description, please refer to the ns-3 manual.
 */
 
+class UniformRandomVariable;
+
 /**
 * \ingroup click
 * \brief Class to allow a node to use Click for external routing
@@ -63,6 +65,7 @@
   Ipv4ClickRouting ();
   virtual ~Ipv4ClickRouting ();
 
+  Ptr<UniformRandomVariable> GetRandomVariable (void);
 protected:
   virtual void DoStart (void);
 
@@ -255,6 +258,7 @@
   bool m_nonDefaultName;
 
   Ptr<Ipv4> m_ipv4;
+  Ptr<UniformRandomVariable> m_random;
 #endif /* NS3_CLICK */
 };
 

From sakship1234 at gmail.com  Fri Jan 25 07:38:03 2013
From: sakship1234 at gmail.com (Sakshi K)
Date: Fri, 25 Jan 2013 18:08:03 +0530
Subject: [Click] Adding Route - Click Router
Message-ID: <CAJoniY5h7AHWD3Cc9c19+uKVwAfFgaVw0_zn+ScL1bnnPXGkvg@mail.gmail.com>

Hi,

  I want to add a route in the routing table dynamically. I have read the
documentation but did not find any function to do that.  Please tell me how
can I do the same.

From ekohler at gmail.com  Fri Jan 25 09:34:35 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Fri, 25 Jan 2013 09:34:35 -0500
Subject: [Click] nsclick rng support for ns3
In-Reply-To: <51027556.2060106@informatik.uni-bonn.de>
References: <50FD2380.6020101@informatik.uni-bonn.de>
	<CAOj7qWaEoS_ZRj5o_csRTBvKM9U3EjvBGUsTDKh_6_y4sQm3jg@mail.gmail.com>
	<CAF0C5SLJUeGhRC=23uzkOTe78XLXDdY+SVBgR7eM4O7s895poQ@mail.gmail.com>
	<51001F4A.9030205@informatik.uni-bonn.de>
	<510023E6.3070301@seas.harvard.edu>
	<51027556.2060106@informatik.uni-bonn.de>
Message-ID: <CAF0C5SLgCFm2tZRRpjPBYZd4aq_3+=Xoem53t8sHpzLWzFBxkg@mail.gmail.com>

Hi Sascha!

I like this one much better, and checked in a version of it with a few changes.
- Explicit case for srandom() which does nothing
- Don't chatter if no node, just fall back to user level
- No userlevel_random(), just put click_random() in ns/nsclick.cc

I hope it works for you. If it doesn't, send a pull request?
E

On Fri, Jan 25, 2013 at 7:06 AM, Sascha Alexander Jopen
<jopen at informatik.uni-bonn.de> wrote:
> Hey,
>
> i just tested this new patchset for random number support. It includes
> fallback to userlevel random() or rand() in case of lacking support on
> the ns3 side. Furthermore, ns3 returns random numbers in the range [0,
> CLICK_RAND_MAX] whatever CLICK_RAND_MAX is on the platform where click
> was compiled, as long as CLICK_RAND_MAX <= 0xFFFFFFFFU. This is done by
> sending the actual CLICK_RAND_MAX value along with simclick_sim_command.
> The ns3 side patch includes the changes suggested by Lalith.
> Is this an acceptable solution?
>
> Regards,
> Sascha
>
> On 23.01.2013 18:54, Eddie Kohler wrote:
>> Why not just set the CLICK_RAND_MAX to 0x7FFFFFFFU, which NS can handle
>> as well as normal code?
>>
>> Eddie
>>
>>
>> On 1/23/13 12:35 PM, Sascha Alexander Jopen wrote:
>>> Hi Eddie,
>>>
>>> I did not implement a fallback method, because i was not sure how to
>>> handle CLICK_RAND_MAX in case a fall back is necessary. In
>>> include/click/glue.hh CLICK_RAND_MAX is defined as the maximum value
>>> supported by the ns3 implementation. However, if we find the simulator
>>> not supporting random numbers at runtime, falling back to random() or
>>> rand() could lead to a RAND_MAX, which is different from the defined
>>> CLICK_RAND_MAX. This could lead to unexpected simulation behaviour. Any
>>> comments, how to handle this?
>>>
>>> Regarding the CLICK_RAND_MAX value itself, i can change the maximum
>>> value to 0xFFFFFFFFU.
>>>
>>> I used 0xFFFFFFFEU in the first place, because, although the ns3
>>> documentation says, that calling
>>>
>>>    uint32_t GetInteger(uint32_t min, uint32_t max)
>>>
>>> returns an integer in the range [min,max], this seems not to be true for
>>> max = 0xFFFFFFFFU. Because this calls internally another method, with
>>> GetValue(min, max + 1), this results in an overflow. So 0xFFFFFFFEU
>>> would be the largest possible integer. See around line 187 in file
>>> src/core/model/random-variable-stream.cc. Either i'm wrong, or this is
>>> something to report to the ns3 team.
>>>
>>> However, i certainly missed the alternative call with a cast of the max
>>> value 0xFFFFFFFFU to double and back to uint32_t after a call to the
>>> double based GetValue function. This would lead to a RAND_MAX of
>>> 0xFFFFFFFFU. I will fix this.
>>>
>>> Thanks for reviewing,
>>> Sascha
>>>
>>> On 23.01.2013 16:52, Eddie Kohler wrote:
>>>> Hey,
>>>>
>>>> Two comments.
>>>> - Breaking random numbers except for nses that export random numbers
>>>> considered lame. Why not fall back to the normal random number
>>>> generator?
>>>> - The RAND_MAX value seems odd. (-2??) Why this value?
>>>>
>>>> Eddie
>>>>
>>>> On Wed, Jan 23, 2013 at 3:52 AM, Lalith Suresh
>>>> <suresh.lalith at gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On Mon, Jan 21, 2013 at 12:16 PM, Sascha Alexander Jopen
>>>>> <jopen at informatik.uni-bonn.de> wrote:
>>>>>> Hey,
>>>>>>
>>>>>> please find attached a patchset for click and ns3 which adds
>>>>>> support for
>>>>>> drawing random numbers within click simulations from the underlying
>>>>>> ns3
>>>>>> random number generator. Each simulated click node has its own
>>>>>> uniformly
>>>>>> distributed random number stream (as opposed to my previously
>>>>>> submitted
>>>>>> patch). This way all nodes have independent random number streams.
>>>>>>
>>>>>> Setting the seed or run numbers is done within the simulation by
>>>>>> means of
>>>>>>
>>>>>> RngSeedManager::SetSeed ();
>>>>>> RngSeedManager::SetRun ();
>>>>>>
>>>>>> or with environment variables or command line parameters.
>>>>>> See http://www.nsnam.org/docs/manual/html/random-variables.html
>>>>>>
>>>>>> I still have no ns2 available. Currently, missing rng support from the
>>>>>> simulator side is detected and reported but no random numbers are
>>>>>> available to the simulation. Implementing a fallback method should be
>>>>>> possible, however. Maybe someone who uses ns2 could provide this?
>>>>>>
>>>>>> click-ns3-rng.diff is for the click side and ns3-nsclick-rng.diff for
>>>>>> the ns3 side.
>>>>>>
>>>>>
>>>>> I had a look through this patch. For clarity, my comment is to rename
>>>>> the simclick command to SIMCLICK_GET_RANDOM_INT and the
>>>>> Ipv4ClickRouting method's name to GetRandomVariable(). Otherwise, it
>>>>> looks good.
>>>>>
>>>>> I can push this to ns-3-dev when the click side gets committed.
>>>>>
>>>>>> Regards,
>>>>>> Sascha
>>>>>>
>>>>>> --
>>>>>> Dipl.-Inform. Sascha Jopen
>>>>>>
>>>>>> University of Bonn                     Tel.:   +49-228-73-54219
>>>>>> Institute of Computer Science 4        Fax:    +49-228-73-4571
>>>>>> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
>>>>>> D-53113 Bonn, Germany
>>>>>>
>>>>>> _______________________________________________
>>>>>> click mailing list
>>>>>> click at amsterdam.lcs.mit.edu
>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lalith Suresh
>>>>> www.lalith.in
>>>>> _______________________________________________
>>>>> click mailing list
>>>>> click at amsterdam.lcs.mit.edu
>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>
>>>
>
>
> --
> Dipl.-Inform. Sascha Jopen
>
> University of Bonn                     Tel.:   +49-228-73-54219
> Institute of Computer Science 4        Fax:    +49-228-73-4571
> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
> D-53113 Bonn, Germany

From jopen at informatik.uni-bonn.de  Fri Jan 25 10:32:13 2013
From: jopen at informatik.uni-bonn.de (Sascha Alexander Jopen)
Date: Fri, 25 Jan 2013 16:32:13 +0100
Subject: [Click] nsclick rng support for ns3
In-Reply-To: <CAF0C5SLgCFm2tZRRpjPBYZd4aq_3+=Xoem53t8sHpzLWzFBxkg@mail.gmail.com>
References: <50FD2380.6020101@informatik.uni-bonn.de>
	<CAOj7qWaEoS_ZRj5o_csRTBvKM9U3EjvBGUsTDKh_6_y4sQm3jg@mail.gmail.com>
	<CAF0C5SLJUeGhRC=23uzkOTe78XLXDdY+SVBgR7eM4O7s895poQ@mail.gmail.com>
	<51001F4A.9030205@informatik.uni-bonn.de>
	<510023E6.3070301@seas.harvard.edu>
	<51027556.2060106@informatik.uni-bonn.de>
	<CAF0C5SLgCFm2tZRRpjPBYZd4aq_3+=Xoem53t8sHpzLWzFBxkg@mail.gmail.com>
Message-ID: <5102A57D.30709@informatik.uni-bonn.de>

Hi Eddie,

but shouldn't we allow seeding the userlevel random number generator, in
case there is no support for ns3 random numbers?

I do not have any git repositories and do not understand git workflows
very well. Do i have to create a github repository as a fork of the
click git repository to issue pull requests? Or does any other git
repository work, too?

Sascha

On 25.01.2013 15:34, Eddie Kohler wrote:
> Hi Sascha!
> 
> I like this one much better, and checked in a version of it with a few changes.
> - Explicit case for srandom() which does nothing
> - Don't chatter if no node, just fall back to user level
> - No userlevel_random(), just put click_random() in ns/nsclick.cc
> 
> I hope it works for you. If it doesn't, send a pull request?
> E
> 
> On Fri, Jan 25, 2013 at 7:06 AM, Sascha Alexander Jopen
> <jopen at informatik.uni-bonn.de> wrote:
>> Hey,
>>
>> i just tested this new patchset for random number support. It includes
>> fallback to userlevel random() or rand() in case of lacking support on
>> the ns3 side. Furthermore, ns3 returns random numbers in the range [0,
>> CLICK_RAND_MAX] whatever CLICK_RAND_MAX is on the platform where click
>> was compiled, as long as CLICK_RAND_MAX <= 0xFFFFFFFFU. This is done by
>> sending the actual CLICK_RAND_MAX value along with simclick_sim_command.
>> The ns3 side patch includes the changes suggested by Lalith.
>> Is this an acceptable solution?
>>
>> Regards,
>> Sascha
>>
>> On 23.01.2013 18:54, Eddie Kohler wrote:
>>> Why not just set the CLICK_RAND_MAX to 0x7FFFFFFFU, which NS can handle
>>> as well as normal code?
>>>
>>> Eddie
>>>
>>>
>>> On 1/23/13 12:35 PM, Sascha Alexander Jopen wrote:
>>>> Hi Eddie,
>>>>
>>>> I did not implement a fallback method, because i was not sure how to
>>>> handle CLICK_RAND_MAX in case a fall back is necessary. In
>>>> include/click/glue.hh CLICK_RAND_MAX is defined as the maximum value
>>>> supported by the ns3 implementation. However, if we find the simulator
>>>> not supporting random numbers at runtime, falling back to random() or
>>>> rand() could lead to a RAND_MAX, which is different from the defined
>>>> CLICK_RAND_MAX. This could lead to unexpected simulation behaviour. Any
>>>> comments, how to handle this?
>>>>
>>>> Regarding the CLICK_RAND_MAX value itself, i can change the maximum
>>>> value to 0xFFFFFFFFU.
>>>>
>>>> I used 0xFFFFFFFEU in the first place, because, although the ns3
>>>> documentation says, that calling
>>>>
>>>>    uint32_t GetInteger(uint32_t min, uint32_t max)
>>>>
>>>> returns an integer in the range [min,max], this seems not to be true for
>>>> max = 0xFFFFFFFFU. Because this calls internally another method, with
>>>> GetValue(min, max + 1), this results in an overflow. So 0xFFFFFFFEU
>>>> would be the largest possible integer. See around line 187 in file
>>>> src/core/model/random-variable-stream.cc. Either i'm wrong, or this is
>>>> something to report to the ns3 team.
>>>>
>>>> However, i certainly missed the alternative call with a cast of the max
>>>> value 0xFFFFFFFFU to double and back to uint32_t after a call to the
>>>> double based GetValue function. This would lead to a RAND_MAX of
>>>> 0xFFFFFFFFU. I will fix this.
>>>>
>>>> Thanks for reviewing,
>>>> Sascha
>>>>
>>>> On 23.01.2013 16:52, Eddie Kohler wrote:
>>>>> Hey,
>>>>>
>>>>> Two comments.
>>>>> - Breaking random numbers except for nses that export random numbers
>>>>> considered lame. Why not fall back to the normal random number
>>>>> generator?
>>>>> - The RAND_MAX value seems odd. (-2??) Why this value?
>>>>>
>>>>> Eddie
>>>>>
>>>>> On Wed, Jan 23, 2013 at 3:52 AM, Lalith Suresh
>>>>> <suresh.lalith at gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, Jan 21, 2013 at 12:16 PM, Sascha Alexander Jopen
>>>>>> <jopen at informatik.uni-bonn.de> wrote:
>>>>>>> Hey,
>>>>>>>
>>>>>>> please find attached a patchset for click and ns3 which adds
>>>>>>> support for
>>>>>>> drawing random numbers within click simulations from the underlying
>>>>>>> ns3
>>>>>>> random number generator. Each simulated click node has its own
>>>>>>> uniformly
>>>>>>> distributed random number stream (as opposed to my previously
>>>>>>> submitted
>>>>>>> patch). This way all nodes have independent random number streams.
>>>>>>>
>>>>>>> Setting the seed or run numbers is done within the simulation by
>>>>>>> means of
>>>>>>>
>>>>>>> RngSeedManager::SetSeed ();
>>>>>>> RngSeedManager::SetRun ();
>>>>>>>
>>>>>>> or with environment variables or command line parameters.
>>>>>>> See http://www.nsnam.org/docs/manual/html/random-variables.html
>>>>>>>
>>>>>>> I still have no ns2 available. Currently, missing rng support from the
>>>>>>> simulator side is detected and reported but no random numbers are
>>>>>>> available to the simulation. Implementing a fallback method should be
>>>>>>> possible, however. Maybe someone who uses ns2 could provide this?
>>>>>>>
>>>>>>> click-ns3-rng.diff is for the click side and ns3-nsclick-rng.diff for
>>>>>>> the ns3 side.
>>>>>>>
>>>>>>
>>>>>> I had a look through this patch. For clarity, my comment is to rename
>>>>>> the simclick command to SIMCLICK_GET_RANDOM_INT and the
>>>>>> Ipv4ClickRouting method's name to GetRandomVariable(). Otherwise, it
>>>>>> looks good.
>>>>>>
>>>>>> I can push this to ns-3-dev when the click side gets committed.
>>>>>>
>>>>>>> Regards,
>>>>>>> Sascha
>>>>>>>
>>>>>>> --
>>>>>>> Dipl.-Inform. Sascha Jopen
>>>>>>>
>>>>>>> University of Bonn                     Tel.:   +49-228-73-54219
>>>>>>> Institute of Computer Science 4        Fax:    +49-228-73-4571
>>>>>>> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
>>>>>>> D-53113 Bonn, Germany
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> click mailing list
>>>>>>> click at amsterdam.lcs.mit.edu
>>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Lalith Suresh
>>>>>> www.lalith.in
>>>>>> _______________________________________________
>>>>>> click mailing list
>>>>>> click at amsterdam.lcs.mit.edu
>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>
>>>>
>>
>>
>> --
>> Dipl.-Inform. Sascha Jopen
>>
>> University of Bonn                     Tel.:   +49-228-73-54219
>> Institute of Computer Science 4        Fax:    +49-228-73-4571
>> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
>> D-53113 Bonn, Germany


-- 
Dipl.-Inform. Sascha Jopen

University of Bonn                     Tel.:   +49-228-73-54219
Institute of Computer Science 4        Fax:    +49-228-73-4571
Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
D-53113 Bonn, Germany

From ekohler at gmail.com  Fri Jan 25 14:01:00 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Fri, 25 Jan 2013 14:01:00 -0500
Subject: [Click] nsclick rng support for ns3
In-Reply-To: <5102A57D.30709@informatik.uni-bonn.de>
References: <50FD2380.6020101@informatik.uni-bonn.de>
	<CAOj7qWaEoS_ZRj5o_csRTBvKM9U3EjvBGUsTDKh_6_y4sQm3jg@mail.gmail.com>
	<CAF0C5SLJUeGhRC=23uzkOTe78XLXDdY+SVBgR7eM4O7s895poQ@mail.gmail.com>
	<51001F4A.9030205@informatik.uni-bonn.de>
	<510023E6.3070301@seas.harvard.edu>
	<51027556.2060106@informatik.uni-bonn.de>
	<CAF0C5SLgCFm2tZRRpjPBYZd4aq_3+=Xoem53t8sHpzLWzFBxkg@mail.gmail.com>
	<5102A57D.30709@informatik.uni-bonn.de>
Message-ID: <CAF0C5SK3FWfWSMYKbXSMstmbhsKcUbLpMzjTuXpm=G0v+oFmJA@mail.gmail.com>

It's well worth your time to learn Git. It's very, very easy to "fork"
a repository on Github?sign up, and then it's one click.

That said I'm happy to take patches if that's much easier for you.

I felt it was better to have uniform seeding behavior on NS: seeding
*never* works. That's more self consistent (& we could imagine a
warning). But it'd be fine to seed the userlevel RNG too.
E


On Fri, Jan 25, 2013 at 10:32 AM, Sascha Alexander Jopen
<jopen at informatik.uni-bonn.de> wrote:
> Hi Eddie,
>
> but shouldn't we allow seeding the userlevel random number generator, in
> case there is no support for ns3 random numbers?
>
> I do not have any git repositories and do not understand git workflows
> very well. Do i have to create a github repository as a fork of the
> click git repository to issue pull requests? Or does any other git
> repository work, too?
>
> Sascha
>
> On 25.01.2013 15:34, Eddie Kohler wrote:
>> Hi Sascha!
>>
>> I like this one much better, and checked in a version of it with a few changes.
>> - Explicit case for srandom() which does nothing
>> - Don't chatter if no node, just fall back to user level
>> - No userlevel_random(), just put click_random() in ns/nsclick.cc
>>
>> I hope it works for you. If it doesn't, send a pull request?
>> E
>>
>> On Fri, Jan 25, 2013 at 7:06 AM, Sascha Alexander Jopen
>> <jopen at informatik.uni-bonn.de> wrote:
>>> Hey,
>>>
>>> i just tested this new patchset for random number support. It includes
>>> fallback to userlevel random() or rand() in case of lacking support on
>>> the ns3 side. Furthermore, ns3 returns random numbers in the range [0,
>>> CLICK_RAND_MAX] whatever CLICK_RAND_MAX is on the platform where click
>>> was compiled, as long as CLICK_RAND_MAX <= 0xFFFFFFFFU. This is done by
>>> sending the actual CLICK_RAND_MAX value along with simclick_sim_command.
>>> The ns3 side patch includes the changes suggested by Lalith.
>>> Is this an acceptable solution?
>>>
>>> Regards,
>>> Sascha
>>>
>>> On 23.01.2013 18:54, Eddie Kohler wrote:
>>>> Why not just set the CLICK_RAND_MAX to 0x7FFFFFFFU, which NS can handle
>>>> as well as normal code?
>>>>
>>>> Eddie
>>>>
>>>>
>>>> On 1/23/13 12:35 PM, Sascha Alexander Jopen wrote:
>>>>> Hi Eddie,
>>>>>
>>>>> I did not implement a fallback method, because i was not sure how to
>>>>> handle CLICK_RAND_MAX in case a fall back is necessary. In
>>>>> include/click/glue.hh CLICK_RAND_MAX is defined as the maximum value
>>>>> supported by the ns3 implementation. However, if we find the simulator
>>>>> not supporting random numbers at runtime, falling back to random() or
>>>>> rand() could lead to a RAND_MAX, which is different from the defined
>>>>> CLICK_RAND_MAX. This could lead to unexpected simulation behaviour. Any
>>>>> comments, how to handle this?
>>>>>
>>>>> Regarding the CLICK_RAND_MAX value itself, i can change the maximum
>>>>> value to 0xFFFFFFFFU.
>>>>>
>>>>> I used 0xFFFFFFFEU in the first place, because, although the ns3
>>>>> documentation says, that calling
>>>>>
>>>>>    uint32_t GetInteger(uint32_t min, uint32_t max)
>>>>>
>>>>> returns an integer in the range [min,max], this seems not to be true for
>>>>> max = 0xFFFFFFFFU. Because this calls internally another method, with
>>>>> GetValue(min, max + 1), this results in an overflow. So 0xFFFFFFFEU
>>>>> would be the largest possible integer. See around line 187 in file
>>>>> src/core/model/random-variable-stream.cc. Either i'm wrong, or this is
>>>>> something to report to the ns3 team.
>>>>>
>>>>> However, i certainly missed the alternative call with a cast of the max
>>>>> value 0xFFFFFFFFU to double and back to uint32_t after a call to the
>>>>> double based GetValue function. This would lead to a RAND_MAX of
>>>>> 0xFFFFFFFFU. I will fix this.
>>>>>
>>>>> Thanks for reviewing,
>>>>> Sascha
>>>>>
>>>>> On 23.01.2013 16:52, Eddie Kohler wrote:
>>>>>> Hey,
>>>>>>
>>>>>> Two comments.
>>>>>> - Breaking random numbers except for nses that export random numbers
>>>>>> considered lame. Why not fall back to the normal random number
>>>>>> generator?
>>>>>> - The RAND_MAX value seems odd. (-2??) Why this value?
>>>>>>
>>>>>> Eddie
>>>>>>
>>>>>> On Wed, Jan 23, 2013 at 3:52 AM, Lalith Suresh
>>>>>> <suresh.lalith at gmail.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Mon, Jan 21, 2013 at 12:16 PM, Sascha Alexander Jopen
>>>>>>> <jopen at informatik.uni-bonn.de> wrote:
>>>>>>>> Hey,
>>>>>>>>
>>>>>>>> please find attached a patchset for click and ns3 which adds
>>>>>>>> support for
>>>>>>>> drawing random numbers within click simulations from the underlying
>>>>>>>> ns3
>>>>>>>> random number generator. Each simulated click node has its own
>>>>>>>> uniformly
>>>>>>>> distributed random number stream (as opposed to my previously
>>>>>>>> submitted
>>>>>>>> patch). This way all nodes have independent random number streams.
>>>>>>>>
>>>>>>>> Setting the seed or run numbers is done within the simulation by
>>>>>>>> means of
>>>>>>>>
>>>>>>>> RngSeedManager::SetSeed ();
>>>>>>>> RngSeedManager::SetRun ();
>>>>>>>>
>>>>>>>> or with environment variables or command line parameters.
>>>>>>>> See http://www.nsnam.org/docs/manual/html/random-variables.html
>>>>>>>>
>>>>>>>> I still have no ns2 available. Currently, missing rng support from the
>>>>>>>> simulator side is detected and reported but no random numbers are
>>>>>>>> available to the simulation. Implementing a fallback method should be
>>>>>>>> possible, however. Maybe someone who uses ns2 could provide this?
>>>>>>>>
>>>>>>>> click-ns3-rng.diff is for the click side and ns3-nsclick-rng.diff for
>>>>>>>> the ns3 side.
>>>>>>>>
>>>>>>>
>>>>>>> I had a look through this patch. For clarity, my comment is to rename
>>>>>>> the simclick command to SIMCLICK_GET_RANDOM_INT and the
>>>>>>> Ipv4ClickRouting method's name to GetRandomVariable(). Otherwise, it
>>>>>>> looks good.
>>>>>>>
>>>>>>> I can push this to ns-3-dev when the click side gets committed.
>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Sascha
>>>>>>>>
>>>>>>>> --
>>>>>>>> Dipl.-Inform. Sascha Jopen
>>>>>>>>
>>>>>>>> University of Bonn                     Tel.:   +49-228-73-54219
>>>>>>>> Institute of Computer Science 4        Fax:    +49-228-73-4571
>>>>>>>> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
>>>>>>>> D-53113 Bonn, Germany
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> click mailing list
>>>>>>>> click at amsterdam.lcs.mit.edu
>>>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Lalith Suresh
>>>>>>> www.lalith.in
>>>>>>> _______________________________________________
>>>>>>> click mailing list
>>>>>>> click at amsterdam.lcs.mit.edu
>>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Dipl.-Inform. Sascha Jopen
>>>
>>> University of Bonn                     Tel.:   +49-228-73-54219
>>> Institute of Computer Science 4        Fax:    +49-228-73-4571
>>> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
>>> D-53113 Bonn, Germany
>
>
> --
> Dipl.-Inform. Sascha Jopen
>
> University of Bonn                     Tel.:   +49-228-73-54219
> Institute of Computer Science 4        Fax:    +49-228-73-4571
> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
> D-53113 Bonn, Germany


From ekohler at gmail.com  Fri Jan 25 14:47:00 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Fri, 25 Jan 2013 14:47:00 -0500
Subject: [Click] Adding Route - Click Router
In-Reply-To: <CAJoniY5h7AHWD3Cc9c19+uKVwAfFgaVw0_zn+ScL1bnnPXGkvg@mail.gmail.com>
References: <CAJoniY5h7AHWD3Cc9c19+uKVwAfFgaVw0_zn+ScL1bnnPXGkvg@mail.gmail.com>
Message-ID: <5102E134.6070606@gmail.com>

You need to use a routing table such as RadixIPLookup, and then access 
its "add" or "set" handlers. For example, if using kernel Click, you 
might do:

echo 1.0.0.0/8 1.0.0.1 2 > /click/radix_ip_lookup/add

See;
http://read.cs.ucla.edu/click/elements/radixiplookup


On 1/25/13 7:38 AM, Sakshi K wrote:
> Hi,
>
>    I want to add a route in the routing table dynamically. I have read the
> documentation but did not find any function to do that.  Please tell me how
> can I do the same.
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From sakship1234 at gmail.com  Fri Jan 25 15:29:45 2013
From: sakship1234 at gmail.com (Sakshi K)
Date: Sat, 26 Jan 2013 01:59:45 +0530
Subject: [Click] Adding Route - Click Router
In-Reply-To: <5102E134.6070606@gmail.com>
References: <CAJoniY5h7AHWD3Cc9c19+uKVwAfFgaVw0_zn+ScL1bnnPXGkvg@mail.gmail.com>
	<5102E134.6070606@gmail.com>
Message-ID: <CAJoniY4zNNx8O7d=NVf3qGaVGy=Fxh3yThAVfVw+KrnEk4CxOg@mail.gmail.com>

Thank you sir.
I have one more doubt. How can I create a packet with source address and
other parameters as packet contents and how do I parse the contents ?
Eg: I want to create a packet with data, "10.0.4.1 1001 publish" as
entries. I am facing difficulty with that.

I have looked *print.cc *code for parsing the contents and still finding it
difficult. Please help me, sir.




On Sat, Jan 26, 2013 at 1:17 AM, Eddie Kohler <ekohler at gmail.com> wrote:

> You need to use a routing table such as RadixIPLookup, and then access its
> "add" or "set" handlers. For example, if using kernel Click, you might do:
>
> echo 1.0.0.0/8 1.0.0.1 2 > /click/radix_ip_lookup/add
>
> See;
> http://read.cs.ucla.edu/click/**elements/radixiplookup<http://read.cs.ucla.edu/click/elements/radixiplookup>
>
>
>
> On 1/25/13 7:38 AM, Sakshi K wrote:
>
>> Hi,
>>
>>    I want to add a route in the routing table dynamically. I have read the
>> documentation but did not find any function to do that.  Please tell me
>> how
>> can I do the same.
>> ______________________________**_________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/**mailman/listinfo/click<https://amsterdam.lcs.mit.edu/mailman/listinfo/click>
>>
>>

From ekohler at gmail.com  Fri Jan 25 15:43:57 2013
From: ekohler at gmail.com (Eddie Kohler)
Date: Fri, 25 Jan 2013 15:43:57 -0500
Subject: [Click] Adding Route - Click Router
In-Reply-To: <CAJoniY4zNNx8O7d=NVf3qGaVGy=Fxh3yThAVfVw+KrnEk4CxOg@mail.gmail.com>
References: <CAJoniY5h7AHWD3Cc9c19+uKVwAfFgaVw0_zn+ScL1bnnPXGkvg@mail.gmail.com>
	<5102E134.6070606@gmail.com>
	<CAJoniY4zNNx8O7d=NVf3qGaVGy=Fxh3yThAVfVw+KrnEk4CxOg@mail.gmail.com>
Message-ID: <CAF0C5SJzOxaAcY_ycYWJf_4PvS2TtC4qpc9WeWsnuMsoOR31SA@mail.gmail.com>

Investigate FromIPSummaryDump.


On Fri, Jan 25, 2013 at 3:29 PM, Sakshi K <sakship1234 at gmail.com> wrote:
> Thank you sir.
> I have one more doubt. How can I create a packet with source address and
> other parameters as packet contents and how do I parse the contents ?
> Eg: I want to create a packet with data, "10.0.4.1 1001 publish" as entries.
> I am facing difficulty with that.
>
> I have looked print.cc code for parsing the contents and still finding it
> difficult. Please help me, sir.
>
>
>
>
> On Sat, Jan 26, 2013 at 1:17 AM, Eddie Kohler <ekohler at gmail.com> wrote:
>>
>> You need to use a routing table such as RadixIPLookup, and then access its
>> "add" or "set" handlers. For example, if using kernel Click, you might do:
>>
>> echo 1.0.0.0/8 1.0.0.1 2 > /click/radix_ip_lookup/add
>>
>> See;
>> http://read.cs.ucla.edu/click/elements/radixiplookup
>>
>>
>>
>> On 1/25/13 7:38 AM, Sakshi K wrote:
>>>
>>> Hi,
>>>
>>>    I want to add a route in the routing table dynamically. I have read
>>> the
>>> documentation but did not find any function to do that.  Please tell me
>>> how
>>> can I do the same.
>>> _______________________________________________
>>> click mailing list
>>> click at amsterdam.lcs.mit.edu
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>
>

From jopen at informatik.uni-bonn.de  Sat Jan 26 14:28:17 2013
From: jopen at informatik.uni-bonn.de (Sascha Alexander Jopen)
Date: Sat, 26 Jan 2013 20:28:17 +0100
Subject: [Click] Click defines in ns3
In-Reply-To: <51001183.4010704@informatik.uni-bonn.de>
References: <50FD26BE.9090406@informatik.uni-bonn.de>
	<CACeiqXTWKAX0q9Dr1xky=YQPjM0o+-6sUGm0cvYWxiz0VJ2bJA@mail.gmail.com>
	<50FFD007.8060503@informatik.uni-bonn.de>
	<CAF0C5SJR56kdNazV639WRAVPOdRxq0GJ2dbLGyO9enQF8T_chw@mail.gmail.com>
	<51001183.4010704@informatik.uni-bonn.de>
Message-ID: <51042E51.4040400@informatik.uni-bonn.de>

Hi,

this is another version of the click defines for ns3 patchset. It makes
use of simclick_sim_command to fetch the defines from ns3 at click
router instantiation time. This way ns2 or older ns3 variants are not
affected, they only do not provide defines.

This patchset is to be applied on top of the rng support patchset.
Please  review this one for inclusion into click and ns3.

Sascha

On 23.01.2013 17:36, Sascha Alexander Jopen wrote:
> Hey,
> 
> with the current implementation on the ns3 side, using
> simclick_click_command is only possible after an instance of the click
> router has been created (Ipv4ClickRouting::DoStart ()). However, we
> already need the defines at this time to instantiate the router.
> I'll try to rearrange this and implement defines the way you suggested,
> keeping the API stable.
> 
> Sascha
> 
> On 23.01.2013 16:46, Eddie Kohler wrote:
>> Hey,
>>
>> I'm always bummed out by API changes that require people to keep two
>> packages precisely up to date and will therefore request some changes.
>>
>> (1) Add a new SIMCLICK comamnd constant, SIMCLICK_DEFINE or
>> SIMCLICK_CREATE_DEFINE, your choice.
>> (2) Change simclick_click_command so that SIMCLICK_SUPPORTS reports
>> true for SIMCLICK_DEFINE
>> (3) Implement definition support via SIMCLICK_DEFINE, which will
>> require changes to click and to ns.
>>
>> Make sense?
>> Eddie
>>
>>
>> On Wed, Jan 23, 2013 at 6:56 AM, Sascha Alexander Jopen
>> <jopen at informatik.uni-bonn.de> wrote:
>>> Hi,
>>>
>>> i think this has nothing to do with the Click defines patchset. Please
>>> use a new thread for your questions.
>>>
>>> How packet processing is done in your application depends on the type
>>> and format of your packets. There are standard elements in click to deal
>>> with Ethernet or IP packets, for example. See
>>> http://read.cs.ucla.edu/click/elements
>>> For processing of application layer data, you have to write your own
>>> elements. See http://www.read.cs.ucla.edu/gitweb?p=click;a=blob;f=FAQ
>>> and http://www.read.cs.ucla.edu/click/learning
>>>
>>> Regards,
>>> Sascha
>>>
>>> On 23.01.2013 11:46, karthick m wrote:
>>>> Hi sascha,
>>>>
>>>>             I am implementing my own publish subscribe architecture using
>>>> click router. For that i need to work on packets. Say a publisher is
>>>> sending a publish packet, i have to see the packet data and process packet
>>>> according to the data and route it.  The problem is that, i do not find any
>>>> element which does packet processing for example. Could you please give me
>>>> a pointer to it. Thanks in advance.
>>>>
>>>
>>>
>>> --
>>> Dipl.-Inform. Sascha Jopen
>>>
>>> University of Bonn                     Tel.:   +49-228-73-54219
>>> Institute of Computer Science 4        Fax:    +49-228-73-4571
>>> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
>>> D-53113 Bonn, Germany
>>> _______________________________________________
>>> click mailing list
>>> click at amsterdam.lcs.mit.edu
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> 
> 


-- 
Dipl.-Inform. Sascha Jopen

University of Bonn                     Tel.:   +49-228-73-54219
Institute of Computer Science 4        Fax:    +49-228-73-4571
Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
D-53113 Bonn, Germany
-------------- next part --------------
diff --git a/include/click/simclick.h b/include/click/simclick.h
index b421641..bc9f4d6 100644
--- a/include/click/simclick.h
+++ b/include/click/simclick.h
@@ -107,6 +107,7 @@ int simclick_gettimeofday(struct timeval* tv);
 #define SIMCLICK_IF_PROMISC		12 // int ifid
 #define SIMCLICK_IPPREFIX_FROM_NAME	13 // const char *ifname, char *buf, int len
 #define SIMCLICK_GET_RANDOM_INT		14 // uint32_t *result, uint32_t max
+#define SIMCLICK_GET_DEFINES		15 // char *buf, size_t *size
 
 int simclick_sim_command(simclick_node_t *sim, int cmd, ...);
 int simclick_click_command(simclick_node_t *sim, int cmd, ...);
diff --git a/ns/nsclick.cc b/ns/nsclick.cc
index 0d682c0..3ebc61c 100644
--- a/ns/nsclick.cc
+++ b/ns/nsclick.cc
@@ -120,6 +120,29 @@ int simclick_click_create(simclick_node_t *simnode, const char* router_file) {
     ErrorHandler *errh = ErrorHandler::default_handler();
     int before = errh->nerrors();
 
+    // Get the defines from the simulator, if supported.
+    if (simclick_sim_command(simnode, SIMCLICK_SUPPORTS, SIMCLICK_GET_DEFINES)) {
+        size_t defines_size = 512;
+        char *defines = (char *) malloc(defines_size);
+        if ((simclick_sim_command(simnode, SIMCLICK_GET_DEFINES, defines, &defines_size) == -1)) {
+            // Our buffer was too small, resize and try again.
+            defines = (char *) realloc(defines, defines_size);
+            simclick_sim_command(simnode, SIMCLICK_GET_DEFINES, defines, &defines_size);
+        }
+
+        // Process defines for click file parsing.
+        size_t defines_offset = 0;
+        while (defines_offset < defines_size) {
+            char *key = defines + defines_offset;
+            char *value = key + strlen(key) + 1;
+            defines_offset += (size_t) (value + strlen(value) + 1 - defines);
+            if (!click_lexer()->global_scope().define(key, value, false)) {
+                errh->error("parameter %s multiply defined", key);
+            }
+        }
+        free(defines);
+    }
+
     Router *r = click_read_router(router_file, false, errh, false);
     simnode->clickinfo = r;
     if (!r)
-------------- next part --------------
diff -r 774f8d9ab488 src/click/examples/nsclick-defines.cc
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/src/click/examples/nsclick-defines.cc	Sat Jan 26 20:02:30 2013 +0100
@@ -0,0 +1,66 @@
+/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation;
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * Authors: Sascha Jopen <jopen at cs.uni-bonn.de>
+ */
+
+
+#include "ns3/core-module.h"
+#include "ns3/ipv4-click-routing.h"
+#include "ns3/click-internet-stack-helper.h"
+#include <map>
+
+using namespace ns3;
+
+NS_LOG_COMPONENT_DEFINE ("NsclickRouting");
+
+int
+main (int argc, char *argv[])
+{
+#ifdef NS3_CLICK
+
+//
+// Explicitly create the nodes required by the topology (shown above).
+//
+  NS_LOG_INFO ("Create a node.");
+  NodeContainer n;
+  n.Create (1);
+
+//
+// Install Click on the nodes
+//
+  std::map<std::string, std::string> defines;
+// Strings, especially with blanks in it, have to be enclosed in quotation
+// marks, like in click configuration files.
+  defines["OUTPUT"] = "\"Hello World!\"";
+  
+  ClickInternetStackHelper clickinternet;
+  clickinternet.SetClickFile (n, "src/click/examples/nsclick-defines.click");
+  clickinternet.SetRoutingTableElement (n, "rt");
+  clickinternet.SetDefines(n, defines);
+  clickinternet.Install (n);
+
+//
+// Now, do the actual simulation.
+//
+  NS_LOG_INFO ("Run Simulation.");
+  Simulator::Stop (Seconds (20.0));
+  Simulator::Run ();
+  Simulator::Destroy ();
+  NS_LOG_INFO ("Done.");
+#else
+  NS_FATAL_ERROR ("Can't use ns-3-click without NSCLICK compiled in");
+#endif
+}
diff -r 774f8d9ab488 src/click/examples/nsclick-defines.click
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/src/click/examples/nsclick-defines.click	Sat Jan 26 20:02:30 2013 +0100
@@ -0,0 +1,9 @@
+define($OUTPUT "This is a default value for OUTPUT");
+define($UNDEFINED "UNDEFINED is an undefined variable");
+
+// It is mandatory to use an IPRouteTable element with ns-3-click
+rt :: LinearIPLookup ();
+Idle -> rt;
+
+output :: Message($OUTPUT);
+undefined :: Message($UNDEFINED);
diff -r 774f8d9ab488 src/click/examples/wscript
--- a/src/click/examples/wscript	Sat Jan 26 15:54:08 2013 +0100
+++ b/src/click/examples/wscript	Sat Jan 26 20:02:30 2013 +0100
@@ -20,3 +20,7 @@
    obj = bld.create_ns3_program('nsclick-routing',
                                 ['click', 'csma', 'internet', 'applications'])
    obj.source = 'nsclick-routing.cc'
+
+   obj = bld.create_ns3_program('nsclick-defines',
+                                ['click'])
+   obj.source = 'nsclick-defines.cc'
diff -r 774f8d9ab488 src/click/helper/click-internet-stack-helper.cc
--- a/src/click/helper/click-internet-stack-helper.cc	Sat Jan 26 15:54:08 2013 +0100
+++ b/src/click/helper/click-internet-stack-helper.cc	Sat Jan 26 20:02:30 2013 +0100
@@ -125,6 +125,21 @@
 }
 
 void
+ClickInternetStackHelper::SetDefines (NodeContainer c, std::map<std::string, std::string> defines)
+{
+  for (NodeContainer::Iterator i = c.Begin (); i != c.End (); ++i)
+    {
+	  SetDefines (*i, defines);
+    }
+}
+
+void
+ClickInternetStackHelper::SetDefines (Ptr<Node> node, std::map<std::string, std::string> defines)
+{
+  m_nodeToDefinesMap.insert (std::make_pair (node, defines));
+}
+
+void
 ClickInternetStackHelper::SetRoutingTableElement (NodeContainer c, std::string rt)
 {
   for (NodeContainer::Iterator i = c.Begin (); i != c.End (); ++i)
@@ -193,6 +208,13 @@
           ipv4Routing->SetClickFile (it->second);
         }
 
+      std::map<Ptr<Node>, std::map<std::string, std::string> >::const_iterator definesIt;
+      definesIt = m_nodeToDefinesMap.find (node);
+      if (definesIt != m_nodeToDefinesMap.end ())
+        {
+          ipv4Routing->SetDefines (definesIt->second);
+        }
+
       it = m_nodeToRoutingTableElementMap.find (node);
       if (it != m_nodeToRoutingTableElementMap.end ())
         {
diff -r 774f8d9ab488 src/click/helper/click-internet-stack-helper.h
--- a/src/click/helper/click-internet-stack-helper.h	Sat Jan 26 15:54:08 2013 +0100
+++ b/src/click/helper/click-internet-stack-helper.h	Sat Jan 26 20:02:30 2013 +0100
@@ -143,6 +143,20 @@
   void SetClickFile (Ptr<Node> node, std::string clickfile);
 
   /**
+   * \brief Set defines to be used for a group of nodes.
+   * \param c NodeContainer of nodes
+   * \param defines Defines mapping to be used
+   */
+  void SetDefines (NodeContainer c, std::map<std::string, std::string> defines);
+
+  /**
+   * \brief Set defines to be used for a node.
+   * \param node Node for which the defines are to be set
+   * \param defines Defines mapping to be used
+   */
+  void SetDefines (Ptr<Node> node, std::map<std::string, std::string> defines);
+
+  /**
    * \brief Set a Click routing table element for a group of nodes.
    * \param c NodeContainer of nodes
    * \param rt Click Routing Table element name
@@ -219,6 +233,11 @@
   std::map < Ptr<Node>, std::string  > m_nodeToClickFileMap;
 
   /**
+   * \brief Node to Click defines mapping
+   */
+  std::map < Ptr<Node>, std::map<std::string, std::string>  > m_nodeToDefinesMap;
+
+  /**
    * \brief Node to Routing Table Element mapping
    */
   std::map < Ptr<Node>, std::string  > m_nodeToRoutingTableElementMap;
diff -r 774f8d9ab488 src/click/model/ipv4-click-routing.cc
--- a/src/click/model/ipv4-click-routing.cc	Sat Jan 26 15:54:08 2013 +0100
+++ b/src/click/model/ipv4-click-routing.cc	Sat Jan 26 20:02:30 2013 +0100
@@ -65,6 +65,10 @@
     m_ipv4 (0)
 {
   m_random = CreateObject<UniformRandomVariable> ();
+  m_simNode = new simclick_node_t;
+  timerclear (&m_simNode->curtime);
+
+  AddSimNodeToClickMapping ();
 }
 
 Ipv4ClickRouting::~Ipv4ClickRouting ()
@@ -83,11 +87,6 @@
       m_nodeName = name.str ();
     }
 
-  m_simNode = new simclick_node_t;
-  timerclear (&m_simNode->curtime);
-
-  AddSimNodeToClickMapping ();
-
   NS_ASSERT (m_clickFile.length () > 0);
 
   // Even though simclick_click_create() will halt programme execution
@@ -138,6 +137,18 @@
 }
 
 void
+Ipv4ClickRouting::SetDefines (std::map<std::string, std::string> defines)
+{
+  m_defines = defines;
+}
+
+std::map<std::string, std::string>
+Ipv4ClickRouting::GetDefines (void)
+{
+  return m_defines;
+}
+
+void
 Ipv4ClickRouting::SetClickRoutingTableElement (std::string name)
 {
   m_clickRoutingTableElement = name;
@@ -614,7 +625,7 @@
     case SIMCLICK_SUPPORTS:
       {
         int othercmd = va_arg (val, int);
-        retval = (othercmd >= SIMCLICK_VERSION && othercmd <= SIMCLICK_GET_RANDOM_INT);
+        retval = (othercmd >= SIMCLICK_VERSION && othercmd <= SIMCLICK_GET_DEFINES);
         break;
       }
 
@@ -757,6 +768,48 @@
         NS_LOG_DEBUG (clickInstance->GetNodeName () << " SIMCLICK_RANDOM: " << *randomValue << " " << maxValue << " " << ns3::Simulator::Now ());
         break;
       }
+
+    case SIMCLICK_GET_DEFINES:
+      {
+        char *buf = va_arg (val, char *);
+        size_t *size = va_arg (val, size_t *);
+        uint32_t required = 0;
+
+        // Try to fill the buffer with up to size bytes.
+        // If this is not enough space, write the required buffer size into
+        // the size variable and return an error code.
+        // Otherwise return the bytes actually writte into the buffer in size.
+
+        // Append key/value pair, seperated by \0.
+        std::map<std::string, std::string> defines = clickInstance->GetDefines ();
+        std::map<std::string, std::string>::const_iterator it = defines.begin ();
+        while (it != defines.end ())
+          {
+            size_t available = *size - required;
+            if (it->first.length() + it->second.length() + 2 <= available)
+              {
+                simstrlcpy(buf + required, available, it->first);
+                required += it->first.length() + 1;
+                available -= it->first.length() + 1;
+                simstrlcpy(buf + required, available, it->second);
+                required += it->second.length() + 1;
+              }
+            else
+              {
+                required += it->first.length() + it->second.length() + 2;
+              }
+            it++;
+          }
+        if (required > *size)
+          {
+            retval = -1;
+          }
+        else
+          {
+            retval = 0;
+          }
+        *size = required;
+      }
     }
   return retval;
 }
diff -r 774f8d9ab488 src/click/model/ipv4-click-routing.h
--- a/src/click/model/ipv4-click-routing.h	Sat Jan 26 15:54:08 2013 +0100
+++ b/src/click/model/ipv4-click-routing.h	Sat Jan 26 20:02:30 2013 +0100
@@ -79,6 +79,12 @@
   void SetClickFile (std::string clickfile);
 
   /**
+  * \brief Click defines to be used by the node's Click Instance.
+  * \param defines mapping of defines for .click configuration file parsing
+  */
+  void SetDefines (std::map<std::string, std::string> defines);
+
+  /**
    * \brief Name of the node as to be used by Click. Required for Click Dumps.
    * \param name Name to be assigned to the node.
    */
@@ -132,6 +138,12 @@
 
 public:
   /**
+   * \brief Provides for SIMCLICK_GET_DEFINES
+   * \return The defines mapping for .click configuration file parsing
+   */
+  std::map<std::string, std::string> GetDefines (void);
+
+  /**
    * \brief Provides for SIMCLICK_IFID_FROM_NAME
    * \param ifname The name of the interface
    * \return The interface ID which corresponds to ifname
@@ -247,6 +259,7 @@
 
 private:
   std::string m_clickFile;
+  std::map < std::string, std::string > m_defines;
   std::string m_nodeName;
   std::string m_clickRoutingTableElement;