<br><br><div class="gmail_quote">On Thu, Jan 17, 2013 at 2:10 PM, Maciej Soltysiak <span dir="ltr"><<a href="mailto:maciej@soltysiak.com" target="_blank">maciej@soltysiak.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">On Thu, Jan 17, 2013 at 2:41 PM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
It turned out the igmp entries in /proc ARE being stripped out by a<br>
openwrt patch... which I killed... so I built it again....<br></blockquote></div><div>What was the purpose of the patch, do you know? </div></div></blockquote><div><br>A somewhat misguided attempt at "saving space"<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im"><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
Hopefully this will resolve the dlna issue and others.</blockquote></div><div>It does, my wired TV and my wireless client work without a single change of config!</div></div></blockquote><div><br>YEA!<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div> <br></div><div>However I got hit by the DNS / polipo bug with things like:</div>
<div>Jan 17 18:41:43 OpenWrt user.err polipo[2765]: Host <a href="http://mail.soltysiak.com" target="_blank">mail.soltysiak.com</a> lookup failed: Timeout (131072).<br>Jan 17 18:41:43 OpenWrt <a href="http://user.info" target="_blank">user.info</a> sysinit: Host <a href="http://mail.soltysiak.com" target="_blank">mail.soltysiak.com</a> lookup failed: Timeout (131072).<br>
Jan 17 18:41:44 OpenWrt user.err polipo[2765]: Host <a href="http://notify5.dropbox.com" target="_blank">notify5.dropbox.com</a> lookup failed: Timeout (131072).<br>Jan 17 18:41:44 OpenWrt <a href="http://user.info" target="_blank">user.info</a> sysinit: Host <a href="http://notify5.dropbox.com" target="_blank">notify5.dropbox.com</a> lookup failed: Timeout (131072).<br>
Jan 17 18:43:27 OpenWrt user.err polipo[2765]: Host <a href="http://notify5.dropbox.com" target="_blank">notify5.dropbox.com</a> lookup failed: Timeout (131072).<br>Jan 17 18:43:27 OpenWrt <a href="http://user.info" target="_blank">user.info</a> sysinit: Host <a href="http://notify5.dropbox.com" target="_blank">notify5.dropbox.com</a> lookup failed: Timeout (131072).<br>
</div><div>Funny is that I didn't see them with 3.7.1-1.</div><div class="im"><div></div></div></div></blockquote><div><br>As I keep noting, it seems to take time to occur. Try usednsgethostbyname = true for a while. (can't remember the capitalization)<br>
<br>I'd love to nail this bug one one day because proxies really help on wifi in particular.... but next up on my todo list this week<br>is nailing the last few traps and then thoroughly exercising ipv6. (in addition to a bunch of ns2 based sim work,<br>
which is actually my primary task)<br> <br>Some full packet captures from localhost when it starts failing would be useful. Also try it talking to localhost via ::1.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im"><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<p>BTW:<br><br>I had a little fun with uftp and uftpd with this (which are capable<br>
of thoroughly exercising multicast and igmp)<br><br><a href="http://www.tcnj.edu/%7Ebush/uftp.html" target="_blank">http://www.tcnj.edu/~bush/uftp.html</a><br><br>Basically setting up a uftpd client on a couple of machines and<br>
initiating uftp from the router, or vice versa, I was able to transfer<br>
multiple files around at the same time to multiple machines<br>over wifi and wired.<br><br>I've long yearned to have time to truly benchmark multicast<br>at scale, and that's why uftp has been in there so long...<br>
<br>To setup uftpd on cero (the file receiving deamon)<br><br>uftpd -I se00,sw00,sw10,gw00,gw10 -D /tmp # or somewhere</p></blockquote></div><div>uftp and uftpd don't seem to be in cero repository. <a href="http://downloads.openwrt.org/snapshot/trunk/." target="_blank">downloads.openwrt.org/snapshot/trunk/.</a>.. has version 3.6.1, the latest version is 3.7.1; the best thing would be to update upstream openwrt.</div>
</div></blockquote><div><br>It's there.<br><br>opkg update<br>opkg install uftpd uftp<br> <br>I uypdated my version to 3.7.1, will push the patches out to openwrt as soon as I get a few more cleanups.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">
<div> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">To send a file from somewhere to a listening uftpd<br>
<br>uftp -I the_interface thefile<br></blockquote></div><div>To be super weird, I used a 3.7.1 win32 client and 3.6.1 openwrt daemon. speed I got wasn't very high, example:</div><div> </div><div>D:\TEMP>uftp DSC00160.JPG</div>
<div>UFTP version 3.7.1 Copyright (C) 2001-2012 Dennis A. Bush<br>Starting at Thu Jan 17 20:06:33 2013<br>Transfer rate: 1000 Kbps (125 KB/s)<br>Wait between packets: 11718 us<br>Using private multicast address 230.5.5.59 Group ID: 033D43BF<br>
Initializing group<br>Sending ANNOUNCE 1<br>Received REGISTER from client 172.30.42.97<br>Received REGISTER+ from client 172.30.42.97<br>Sending REG_CONF 2.1<br>Sending ANNOUNCE 2<br>----- DSC00160.JPG -----<br>File ID: 0001 Name: DSC00160.JPG<br>
sending as: DSC00160.JPG<br>Bytes: 869125 Blocks: 602 Sections: 1<br>Sending FILEINFO 1.1<br>Received INFO_ACK from client 172.30.42.97<br>Maximum file transfer time: 20 seconds<br>Sending file...pass 1<br>Sending DONE 1.1<br>
Got COMPLETE from client 172.30.42.97<br>Average wait time = 11738.89 us<br>Received 0 distinct NAKs for pass 1<br>Transfer status:<br>Host: 172.30.42.97 Status: Completed time: 7.082 seconds NAKs: 0<br>Total elapsed time: 7.082 seconds<br>
Overall throughput: 119.84 KB/s<br>-----------------------------<br>Finishing group<br>Sending DONE 1.1<br>Got COMPLETE from client 172.30.42.97<br>Late completions:<br>Sending DONE_CONF 2.1<br>Group complete<br>uftp: Finishing at Thu Jan 17 20:06:56 2013<br>
</div><div>Regards,</div><div>Maciej</div><div> </div></div>
</blockquote></div><br>uftp is a VERY interesting protocol. For starters it defaults to a very low rate, which you can change,<br>which is what I think you just saw here. If you aren't getting NAKs you aren't saturating your network.<br>
Try a gigabit. :)<br><br>if you want to blow up your wifi, feel free to set it high. I have high hopes that fq_codel will <br>still do something of the right thing with it, but as multicast packets have a high "weight",<br>
am not particularly hopeful. Need to script a test or three with it, now that it works.<br><br>Secondly, it has a user configurable congestion control algorithm which is also very interesting,<br>and yet very primitive. <br>
<br>Thirdly, it can multicast encrypted it's content. That's a pretty unique facility.<br><br>The web page describes its primary use case (distributing articles over satellite), I have a ton of<br>others:<br><br>1) Keeping core files in sync across a network (think dns)<br>
2) generating varying loads to route across wired and wifi with the uftp-proxy<br>to test stuff with<br>3) blowing up igmp on bridges and elsewhere<br>4) sharing dns caches<br>5) co-existing with ccnx<br>6) video content (well, this is better done via vlc)<br>
7) synchronized distributed audio content (linux's sound daemons can do this)<br><br clear="all">I always liked multicast's promise, going back 2 decades now. I'll try not to fool with it too much,<br>but I have to admit it can be like wet paint once you get it working right.<br>
<br>-- <br>Dave Täht<br><br>Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a>