tag:blogger.com,1999:blog-210752112024-03-08T07:53:18.629-08:00Charles N Wyble - Tempest in a teapotCharles Wyblehttp://www.blogger.com/profile/00778958548657424658noreply@blogger.comBlogger99125tag:blogger.com,1999:blog-21075211.post-87128249831862972622009-08-16T09:47:00.001-07:002009-08-16T09:47:39.956-07:00[Fwd: RF performance of a AR2317 based SoC device - was: Re: Questions about the Mesh Potato]Interesting bit of info...<p>-------- Original Message --------<br>Subject: RF performance of a AR2317 based SoC device - was: Re: <br>Questions about the Mesh Potato<br>Date: Sun, 16 Aug 2009 11:56:38 +0200<br>From: elektra <<a href="mailto:onelektra@gmx.net">onelektra@gmx.net</a>><br>Reply-To: <a href="mailto:village-telco-dev@googlegroups.com">village-telco-dev@googlegroups.com</a><br>To: <a href="mailto:village-telco-dev@googlegroups.com">village-telco-dev@googlegroups.com</a><br>References: <br><<a href="mailto:6b08b4a5-6847-4784-9828-bb9603d5bb94@w6g2000yqw.googlegroups.com">6b08b4a5-6847-4784-9828-bb9603d5bb94@w6g2000yqw.googlegroups.com</a>> <br><1250382825.31167.14.camel@localhost><p><br>Hello Lew!<p>As the Mesh-Potato hasn't reached the state of its first mass production<br>design we don't have exact figures of transmitter and receiver performance<br>yet.<p>But let me show you some example calculations based on the D-Link DIR-300.<p>The Mesh-Potato is based on the Atheros AR2317 Wireless SoC (SoC = <br>System on<br>Chip) integrated circuit. The D-Link DIR-300 is a commodity product for <br>SOHO<br>(Small Office / Home Office) applications, which is using the same chip. <br>The<br>D-Link DIR-300 manual contains these specs regarding transmit (TX) and<br>receive (RX) performance:<p>TX power: 15 dBm +/- 2 dBm<p>RX sensitivity:<br>• 54 Mbit/s OFDM, 10 % PER, -68 dBm)<br>• 48 Mbit/s OFDM, 10 % PER, -68 dBm)<br>• 36 Mbit/s OFDM, 10 % PER, -75 dBm)<br>• 24 Mbit/s OFDM, 10 % PER, -79 dBm)<br>• 18 Mbit/s OFDM, 10 % PER, -82 dBm)<br>• 12 Mbit/s OFDM, 10 % PER, -84 dBm)<br>• 11 Mbit/s CCK, 8% PER, -82 dBm)<br>• 9 Mbit/s OFDM, 10 % PER, -87 dBm)<br>• 6 Mbit/s OFDM, 10 % PER, -88 dBm)<br>• 5,5 Mbit/s CCK, 8% PER, -85 dBm)<br>• 2 Mbit/s QPSK, 8% PER, -86 dBm)<br>• 1 Mbit/s BPSK, 8% PER, -89 dBm)<p>PER = Packet Error Rate<p>Let's do some simple and optimistic radio performance calculations based on<br>these figures.<p>The DIR-300 is shipped with a sleeve dipole antenna, which - if implemented<br>well - should have a gain of 2.15 dBi. It would be nitpicking to <br>mention the<br>0.2dB loss of the R-SMA antenna plug ;-) So we can just assume a antenna <br>gain<br>of 2dBi.<p>I guess the values given by D-Link refer to the performance measured at the<br>antenna socket, but I could be wrong.<p>Based on these figures one can make a quick range / data rate estimation<br>between two DIR-300 under ideal conditions (free fresnel zone, considering<br>attenuation caused by free space loss only, no interference on the radio<br>channel). If you want to make calculations with obstructions in the<br>propagation path I'd strongly recommend playing with the free "radio <br>mobile"<br>software, if you don't know that software already. It is a truly amazing<br>software.<p>A 1 km radio link under ideal conditions (clear fresnel zone) has a free <br>space<br>attenuation of ~100 dB @ 2.45 GHz, 2km attenuation is ~106 dB, 4 km<br>attenuation is ~112 dB, 8 km is ~118 dB and so on.<p>With 15 dBm effective radiated transmit power the signal after 1 km is down<br>at -85 dBm (subtracting 100 dB free space loss). Taking the gain of the<br>antennas into account (+2 dB when we transmit on one side, + 2 dB when we<br>receive on the other side) we should have a signal level at the antenna <br>port<br>of the RX side of -81 dBm, which should be good enough to decode 18 <br>Mbit. If<br>we double the distance to 2km we can still operate at 6 or 9 Mbit (-87 <br>dBm).<br>Increasing the distance by 50 % more would add 3 dB more free space <br>loss, so<br>we end up at -90 dBm signal level after 3km. This is now lower than the -89<br>dBm for the lowest bitrate of 1 Mbit. However at 1 Mbit the TX power is<br>slightly higher, so with a bit of luck the connectivity will be at its<br>absolute edge after 3 km, but still there.<p>Keep in mind these estimations are based under the assumption of ideal<br>conditions: No rain or hail storm. No interference from other radios. Low<br>noise floor. Absolutely no obstructions or reflections in the fresnel zone.<br>No birds sitting on the antennas. The specs provided are assumed to be<br>correct. The timing of the MAC layer must be adjusted with the athctrl<br>utility for distances greater than 1 km.<p>However the DIR-300 is just a commodity product intended to be used indoors<br>and not a reference design intended to show off with brilliant radio<br>performance. Its design goal is least cost with moderate radio <br>performance. I<br>can buy those devices for ~27 € per unit retail in Germany via mail-order<br>plus shipping, which is really cheap. Actually the AR2317 chipset can <br>perform<br>better than the specs of the DIR-300, but it is good enough for the market<br>and the application, given the price.<p>The MP is not a SOHO product. It will be primarily used outdoors in densely<br>and sparsely populated areas (and anything in between, of course). The <br>great<br>many will be used in densely populated areas, but it should be also capable<br>to make a difference in rural areas. For both applications good receiver<br>performance is critical. In densely populated areas the network should<br>operate at the highest possible bitrate - simply to keep the amount of<br>airtime consumed by each transmission low and the channel capacity high.<br>Good receiver performance helps to keep the data rate fast and allows to <br>keep<br>the TX power levels low. The radios need to detect and coordinate <br>channel use<br>to avoid collisions on the radio channels as well. Low receiver performance<br>will have a negative effect on channel capacity and increase the noise <br>floor.<p>The TX power of the MP can be adjusted to 8 different levels:<p> 0 dBm (1 mW)<br> 5 dBm (3 mW)<br> 7 dBm (5 mW)<br> 9 dBm (7 mW)<br> 11 dBm (12 mW)<br> 13 dBm (19 mW)<br> 15 dBm (31 mW)<br> 17 dBm (50 mW)<p>In densely populated areas where people live door by door a few mW TX power<br>can be enough.<p>In sparsely populated areas good RX performance helps to achieve good <br>range,<br>as we have seen before. Interference from other wireless networks is not so<br>critical, so if we put the devices high enough we can often work with <br>good RF<br>conditions. A internal antenna with a slight gain of 3 dBi would be <br>compliant<br>with the regulatory limit of 20 dBm effective radiated power present in <br>many<br>countries.<p>Cheers,<br>Elektra<p>--~--~---------~--~----~------------~-------~--~----~<br>You received this message because you are subscribed to the Google <br>Groups "village-telco-dev" group.<br>To post to this group, send email to <a href="mailto:village-telco-dev@googlegroups.com">village-telco-dev@googlegroups.com</a><br>To unsubscribe from this group, send email to <br><a href="mailto:village-telco-dev%2Bunsubscribe@googlegroups.com">village-telco-dev+unsubscribe@googlegroups.com</a><br>For more options, visit this group at <br><a href="http://groups.google.com/group/village-telco-dev?hl=en">http://groups.google.com/group/village-telco-dev?hl=en</a><br>-~----------~----~----~----~------~----~------~--~---Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-56114840263726483822009-08-06T13:02:00.000-07:002009-08-08T10:58:20.068-07:00First socalwifi.net production deploymentOn June 16th, 2009 socalwifi.net received a request for service. We were asked to provide WiFI for the T<a href="http://www.tafesilafai.org/">afesilafa'i 2009 Pacific Islanders festival</a>, located on the front lawn of the Long Beach Aquarium.<br /><br />On July 28th, 2009 socalwifi.net deployed the gear and provided wifi coverage for the duration of the festival. <br /><br />In the time between request for service, and deployment of the gear we performed several tasks. <br /><br />More details later.Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-15026575163688206102009-07-27T09:34:00.000-07:002009-07-27T09:53:03.335-07:00Moving to the cloudRecently I have been thinking about moving 100% to the cloud. <br /><br />I have the best DSL connection one can purchase from AT&T (business class 6mbps down/768k up), a very nice server hosting virtual machines (8 gigs ram, 4 core CPU).<br /><br />How am I currently taking advantage of that?<br /><br />I have a few sets of virtual machines:<br /><br />1) A Ubuntu virtual machine that hosts things like trac and orangehrm and serves as a file server. <br /><br />2) 4 Ubuntu virtual machines (dev,dev integration,qa, production) for freeswitch development. One of my VOIP engineers is developing on that set. <br /><br />3) A Centos VM hosting openvz instances for freeswitch development. Another one of my VOIP engineers uses those.<br /><br />4) 3 Ubuntu virtual machines (dev integration,qa, production) for socalwifi front end development. I have my primary software engineer using those. <br /><br />So now I want to move my daily tasks into a virtual machine that I can access from any device. I have plenty of resources available via that server and want to take advantage of them as much as possible. <br /><br />I like my MacBook pro, but it doesn't have the computing power to handle running Netbeans/Eclipse/gis tools/vista vm/ubuntu vm at the same time. I plan to move my dev/gis/linux stuff into the VM as I can give it the necessary resources to run everything comfortably. I'm looking into using NX for the access methodology.<br /><br />I also plan to spin up a Vista VM and RDP to it. <br /><br />Then I can be completely device independent. I hope to be able to use my ipod touch a lot more, as it has an RDP and VNC client. Need to see if I can find an NX client for it.Anonymousnoreply@blogger.com2tag:blogger.com,1999:blog-21075211.post-9005945464161418812009-07-22T18:52:00.001-07:002009-07-22T18:52:39.129-07:00[Fwd: [Fwd: Achieved 10Gbit/s bidirectional routing]]Cisco..... be afraid. Be very afraid.<p>Vyata... send the sharks!<p>-------- Original Message --------<br>Subject: [Fwd: Achieved 10Gbit/s bidirectional routing]<br>Date: Wed, 22 Jul 2009 12:25:36 +0200<br>From: Jesper Dangaard Brouer <<a href="mailto:jdb@comx.dk">jdb@comx.dk</a>><br>Reply-To: <a href="mailto:jdb@comx.dk">jdb@comx.dk</a><br>Organization: ComX Networks A/S<br>To: Bifrost <<a href="mailto:bifrost@slu.se">bifrost@slu.se</a>><p><br>Realized that my mail to the bifrost list got blocked... here is a<br>forward of my mail...<p>See also<br> <a href="http://lkml.org/lkml/2009/7/15/234">http://lkml.org/lkml/2009/7/15/234</a><p> <a href="http://lkml.org/lkml/2009/7/16/108">http://lkml.org/lkml/2009/7/16/108</a><p><br>-- <br>Med venlig hilsen / Best regards<br> Jesper Brouer<br> ComX Networks A/S<br> Linux Network developer<br> Cand. Scient Datalog / MSc.<br> Author of <a href="http://adsl-optimizer.dk">http://adsl-optimizer.dk</a><br> LinkedIn: <a href="http://www.linkedin.com/in/brouer">http://www.linkedin.com/in/brouer</a>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-10249019382324263742009-07-22T09:35:00.001-07:002009-07-22T09:35:08.303-07:00[Fwd: [WISPA] Does wireless have a chance or future?]Folks might dig this...<p><br><a href="http://www.cable360.net/ct/news/thewire/ABI-20-Million-Wireless-TVs-To-Ship-in-2011_36713.html">http://www.cable360.net/ct/news/thewire/ABI-20-Million-Wireless-TVs-To-Ship-in-2011_36713.html</a><p><a href="http://www.cable360.net/ct/news/thewire/Frost-and-Sullivan-Fiber-is-the-Future_36722.html">http://www.cable360.net/ct/news/thewire/Frost-and-Sullivan-Fiber-is-the-Future_36722.html</a><p><a href="http://www.cedmagazine.com/News-Research-worldwide-broadband-households-2013-072109.aspx">http://www.cedmagazine.com/News-Research-worldwide-broadband-households-2013-072109.aspx</a><p><a href="http://www.cedmagazine.com/News-Netgear-help-Internet-subscribers-measure-use-072109.aspx">http://www.cedmagazine.com/News-Netgear-help-Internet-subscribers-measure-use-072109.aspx</a><p>(from the WISPA list)Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-8357190353766362182009-07-22T08:46:00.001-07:002009-07-22T08:46:21.774-07:00[Fwd: Re: [WISPA] FW: Introducing Bullet M: 100+Mbps Real TCP/IP Throughput]UBNT.... there is something called capital financing. You should totally <br>look into it.<p>With the demand for your products, credit should be a cinch.<p><p>-------- Original Message --------<br>Subject: Re: [WISPA] FW: Introducing Bullet M: 100+Mbps Real TCP/IP <br>Throughput<br>Date: Wed, 22 Jul 2009 10:24:16 -0400<br>From: Robert West <<a href="mailto:robert.west@just-micro.com">robert.west@just-micro.com</a>><br>Reply-To: WISPA General List <<a href="mailto:wireless@wispa.org">wireless@wispa.org</a>><br>To: 'WISPA General List' <<a href="mailto:wireless@wispa.org">wireless@wispa.org</a>><br>References: <br><!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAKOYKZpUWpEOMStm8neZo/<a href="mailto:MKAAAAQAAAANJpGtTpFGkWNqyeDacUc1QEAAAAA@midcoast.com">MKAAAAQAAAANJpGtTpFGkWNqyeDacUc1QEAAAAA@midcoast.com</a>> <br><4A66BD9B.4050408@NorthTech.US> <8731430859182187877@unknownmsgid> <br><<a href="mailto:f0efcfa10907220644l847d0d7j42b3e430ca02d405@mail.gmail.com">f0efcfa10907220644l847d0d7j42b3e430ca02d405@mail.gmail.com</a>><p>Actually, I am forced to at times due to lack of availability. As I said in<br>an earlier post, in my opinion, Ubiquiti makes very good and reliable<br>equipment. Given a choice I would pick the NS2 and 5's for all CPEs, XR<br>cards for the Mikrotik and the bullets for quick, down and dirty installs on<br>the fly. However.......... I have found myself waiting 6 months or more<br>for things and it seems that the availability varies between vendors. For<br>instance, I have been on backorder for some 2.4ghz Ubiquiti Airview2s since<br>March with one vendor we use yet it's now available at many other vendors<br>with just a click. We also have a load of Ubiquiti cards and boards back<br>ordered with yet another vendor since February. That order I have since<br>given up on and replaced with product from Mikrotik (including radio cards)<br>and I have slowly ordered the same products that are on backorder with one<br>vendor from other vendors. And this is not always new products. (How many<br>posts have we seen from people begging for NS2s?) Now I know one is saying,<br>"Why use so many vendors?" but the reason is because we have to in order to<br>have a decent supply stream. In that respect, I guess it spreads the love<br>amongst the dealers.<p>My post, however, was tongue in cheek. Just because I have an issue with<br>the way a certain company operates doesn't mean I need to pack my bags and<br>take my business elsewhere. Not at all. Besides, I'm trying to keep our<br>equipment list simple, consistent and with quality equipment, not a<br>hodgepodge of whatever I can afford or what is available today. I was just<br>voicing my frustration, not trashing a company. "Love it or leave it" is no<br>way to be. There is no place in life where you can agree with everything<br>100%.<p>So to sum it up........<p>Chill.<p>Bob-<br>Just Micro Digital Services Inc.<p><br>-----Original Message-----<br>From: <a href="mailto:wireless-bounces@wispa.org">wireless-bounces@wispa.org</a> [mailto:<a href="mailto:wireless-bounces@wispa.org">wireless-bounces@wispa.org</a>] On<br>Behalf Of Jayson Baker<br>Sent: Wednesday, July 22, 2009 9:45 AM<br>To: WISPA General List<br>Subject: Re: [WISPA] FW: Introducing Bullet M: 100+Mbps Real TCP/IP<br>Throughput<p>If you don't like their marketing and distribution methods, you could always<br>buy someone elses equipment.<br>It's a known fact Ubiquiti announces new equipment long before they start<br>manufacturing it.<p>On Wed, Jul 22, 2009 at 7:30 AM, Robert West<br><<a href="mailto:robert.west@just-micro.com">robert.west@just-micro.com</a>>wrote:<p>> Is this the same reason they only make electricity available in Iraq for 2<br>> hours a day?<br>><br>> Also.....<br>><br>> I was thinking, if that sort of marketing makes good sense, I should raise<br>> my prices 50%, only give wireless access on every other day between the<br>> hours of 11:00am and 2:00pm and again at 6:45pm and 11:20pm. Porn sites<br>> will be given access only on a Wednesday and YouTube once a month. With<br>> this marketing idea, I just can't go wrong! :)<br>><br>> -----Original Message-----<br>> From: <a href="mailto:wireless-bounces@wispa.org">wireless-bounces@wispa.org</a> [mailto:<a href="mailto:wireless-bounces@wispa.org">wireless-bounces@wispa.org</a>] On<br>> Behalf Of Bradley D. Thornton<br>> Sent: Wednesday, July 22, 2009 3:20 AM<br>> To: WISPA General List<br>> Subject: Re: [WISPA] FW: Introducing Bullet M: 100+Mbps Real TCP/IP<br>> Throughput<br>><br>> That's Datsun.<br>><br>> the 240Z got everyone into a frenzy because, by design of Nissan, they<br>> made sure that everyone had to get on a waiting list for one. It's been<br>> a marketing tool ever since for desireable things.<br>><br>><br>> Robert West wrote:<br>> > I was looking at it myself. Everyone is negative stock-wise. At least<br>> > that's what I see. Just like Ubiquiti to release a product with zero<br>> stock.<br>> ><br>> > Darn good products but I swear, they must have got their marketing ideas<br>> > from the Nintendo, PlayStation and McRib sandwich. Create a demand by<br>> > having your products available sporadically.<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > -----Original Message-----<br>> > From: <a href="mailto:wireless-bounces@wispa.org">wireless-bounces@wispa.org</a> [mailto:<a href="mailto:wireless-bounces@wispa.org">wireless-bounces@wispa.org</a>] On<br>> > Behalf Of Cameron Kilton<br>> > Sent: Tuesday, July 21, 2009 5:34 PM<br>> > To: <a href="mailto:wireless@wispa.org">wireless@wispa.org</a><br>> > Subject: [WISPA] FW: Introducing Bullet M: 100+Mbps Real TCP/IP<br>> Throughput<br>> ><br>> > <<a href="http://e2ma.net/oz/2226372211/2026197/10197/spacer.gif">http://e2ma.net/oz/2226372211/2026197/10197/spacer.gif</a>><br>> > <<a href="http://e2ma.net/oz/2226372211/2026197/10197/spacer.gif">http://e2ma.net/oz/2226372211/2026197/10197/spacer.gif</a>><br>> > If you're having trouble viewing this email, you may see it online<br>> > <<a href="http://e2ma.net/map/view=CampaignPublic/id=10197.2226372211/rid=0bb40cf">http://e2ma.net/map/view=CampaignPublic/id=10197.2226372211/rid=0bb40cf</a><br>> > d2aa52f2df60569807ae43a20> .<br>> ><br>> > <<a href="http://e2ma.net/map/view=Forward/ID=10197.2226372211/rid=0bb40cfd2aa52f">http://e2ma.net/map/view=Forward/ID=10197.2226372211/rid=0bb40cfd2aa52f</a><br>> > 2df60569807ae43a20/send_to_friend> Forward this message to a friend<br>> ><br>> ><br>> > Anybody heard anything about this yet or where you can get to try?<br>> ><br>> ><br>> ><br>> > -Cam<br>> ><br>> ><br>> ><br>> > -----Original Message-----<br>> > From: Ubiquiti Networks Inc. [mailto:<a href="mailto:sales@ubnt.com">sales@ubnt.com</a>]<br>> > Sent: Tuesday, July 21, 2009 4:06 PM<br>> > To: <a href="mailto:cam@midcoast.com">cam@midcoast.com</a><br>> > Subject: Introducing Bullet M: 100+Mbps Real TCP/IP Throughput<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867791/10197/goto:http:/www.ubn">http://e2ma.net/go/2226372211/2026197/75867791/10197/goto:http:/www.ubn</a><br>> > <a href="http://t.com">t.com</a>> Ubiquiti Home Page<br>> ><br>> > <<a href="http://www.ubnt.com/company/newsletter/0109/images/0109_linktop.gif">http://www.ubnt.com/company/newsletter/0109/images/0109_linktop.gif</a>><br>> ><br>> ><br>> ><br>> ><br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867794/10197/goto:http:/www.ubn">http://e2ma.net/go/2226372211/2026197/75867794/10197/goto:http:/www.ubn</a><br>> > <a href="http://t.com/company">t.com/company</a>> Company<br>> ><br>> ><br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867796/10197/goto:http:/www.ubn">http://e2ma.net/go/2226372211/2026197/75867796/10197/goto:http:/www.ubn</a><br>> > <a href="http://t.com/products">t.com/products</a>> Products<br>> ><br>> ><br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867798/10197/goto:http:/www.ubn">http://e2ma.net/go/2226372211/2026197/75867798/10197/goto:http:/www.ubn</a><br>> > <a href="http://t.com/purchase">t.com/purchase</a>> Purchase<br>> ><br>> ><br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867800/10197/goto:http:/forum.u">http://e2ma.net/go/2226372211/2026197/75867800/10197/goto:http:/forum.u</a><br>> > <a href="http://bnt.com">bnt.com</a>> Forum<br>> ><br>> ><br>> > <<a href="http://www.ubnt.com/company/newsletter/0109/images/0109_linkbot.gif">http://www.ubnt.com/company/newsletter/0109/images/0109_linkbot.gif</a>><br>> ><br>> ><br>> ><br>> ><br>> > Introducting Bullet M<br>> > <<a href="http://www.ubnt.com/company/newsletter/0113/images/0113_text_title1_bul">http://www.ubnt.com/company/newsletter/0113/images/0113_text_title1_bul</a><br>> > let.gif><br>> ><br>> > 100+Mbps Real TCP/IP Throughput over multi-km links<br>> ><br>> > AirView<br>> > <<a href="http://www.ubnt.com/company/newsletter/0113/images/0113_bm.jpg">http://www.ubnt.com/company/newsletter/0113/images/0113_bm.jpg</a>><br>> ><br>> > Introducing the revolutionary 802.11n based Bullet M. Available in<br>> > 2.4GHz (Bullet M2 HP) and 5GHz (Bullet M5 HP) versions.<br>> ><br>> ><br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867802/10197/goto:http:/www.ubn">http://e2ma.net/go/2226372211/2026197/75867802/10197/goto:http:/www.ubn</a><br>> > <a href="http://t.com/products/bulletm.php">t.com/products/bulletm.php</a>> Read More<br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867804/10197/goto:http:/ubnt.co">http://e2ma.net/go/2226372211/2026197/75867804/10197/goto:http:/ubnt.co</a><br>> > m/forum/viewtopic.php?p=43290> Discuss<br>> ><br>> > HiPower, Long-Range<br>> > <<a href="http://www.ubnt.com/company/newsletter/0113/images/0113_text_title2_hp">http://www.ubnt.com/company/newsletter/0113/images/0113_text_title2_hp</a>.<br>> > gif><br>> ><br>> > XR1 <<a href="http://www.ubnt.com/company/newsletter/0113/images/0113_map.jpg">http://www.ubnt.com/company/newsletter/0113/images/0113_map.jpg</a>><br>> ><br>> > With up to 600mW of power and enhanced receiver design, the Bullet M is<br>> > ideal for long-distance links.<br>> ><br>> ><br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867806/10197/goto:http:/www.ubn">http://e2ma.net/go/2226372211/2026197/75867806/10197/goto:http:/www.ubn</a><br>> > <a href="http://t.com/products/bulletm.php">t.com/products/bulletm.php</a>> Read More<br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867808/10197/goto:http:/www.ubn">http://e2ma.net/go/2226372211/2026197/75867808/10197/goto:http:/www.ubn</a><br>> > <a href="http://t.com/forum/">t.com/forum/</a>> Discuss<br>> ><br>> > Zero Variable Deployment<br>> > <<a href="http://www.ubnt.com/company/newsletter/0113/images/0113_text_title3_zer">http://www.ubnt.com/company/newsletter/0113/images/0113_text_title3_zer</a><br>> > o.gif><br>> ><br>> > XR1 <<a href="http://www.ubnt.com/company/newsletter/0113/images/0113_z.jpg">http://www.ubnt.com/company/newsletter/0113/images/0113_z.jpg</a>><br>> ><br>> > No host boards, no mini-PCI Cards, no cables, no assembly. With the<br>> > Bullet, operators can just plug and go.<br>> ><br>> ><br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867810/10197/goto:http:/www.ubn">http://e2ma.net/go/2226372211/2026197/75867810/10197/goto:http:/www.ubn</a><br>> > <a href="http://t.com/products/bulletm.php">t.com/products/bulletm.php</a>> Read More<br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867812/10197/goto:http:/www.ubn">http://e2ma.net/go/2226372211/2026197/75867812/10197/goto:http:/www.ubn</a><br>> > <a href="http://t.com/forum/">t.com/forum/</a>> Discuss<br>> ><br>> > 100Mbps+ Speed with no Special Antenna Required<br>> > <<a href="http://www.ubnt.com/company/newsletter/0113/images/0113_text_title4_tp">http://www.ubnt.com/company/newsletter/0113/images/0113_text_title4_tp</a>.<br>> > gif><br>> ><br>> > SR71-X, 802.11n Xpress Card<br>> > <<a href="http://www.ubnt.com/company/newsletter/0113/images/0113_tp.jpg">http://www.ubnt.com/company/newsletter/0113/images/0113_tp.jpg</a>><br>> ><br>> > The Bullet M series can be paired with any antenna to deliver 100Mbps+<br>> > of real TCP/IP speed over the air. The first cost-effective outdoor<br>> > device in the world to do so.<br>> ><br>> ><br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867813/10197/goto:http:/www.ubn">http://e2ma.net/go/2226372211/2026197/75867813/10197/goto:http:/www.ubn</a><br>> > <a href="http://t.com/products/bulletm.php">t.com/products/bulletm.php</a>> Read More<br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867814/10197/goto:http:/www.ubn">http://e2ma.net/go/2226372211/2026197/75867814/10197/goto:http:/www.ubn</a><br>> > <a href="http://t.com/forum/">t.com/forum/</a>> Discuss<br>> ><br>> > Introducting AirOS V<br>> > <<a href="http://www.ubnt.com/company/newsletter/0113/images/0113_text_title5_air">http://www.ubnt.com/company/newsletter/0113/images/0113_text_title5_air</a><br>> > os.gif><br>> ><br>> > SR71-X, 802.11n Xpress Card<br>> > <<a href="http://www.ubnt.com/company/newsletter/0113/images/0113_a5.jpg">http://www.ubnt.com/company/newsletter/0113/images/0113_a5.jpg</a>><br>> ><br>> > Ubiquiti Networks introduces AirOS V, the latest evolution in Ubiquiti's<br>> > AirOS interface. AirOS V maximizes the wireless performance of Ubiquiti<br>> > M Series products.<br>> ><br>> ><br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867815/10197/goto:http:/www.ubn">http://e2ma.net/go/2226372211/2026197/75867815/10197/goto:http:/www.ubn</a><br>> > <a href="http://t.com/products/bulletm.php">t.com/products/bulletm.php</a>> Read More<br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867816/10197/goto:http:/www.ubn">http://e2ma.net/go/2226372211/2026197/75867816/10197/goto:http:/www.ubn</a><br>> > <a href="http://t.com/forum/">t.com/forum/</a>> Discuss<br>> ><br>> ><br>> > <<a href="http://e2ma.net/go/2226372211/2026197/75867817/10197/goto:http:/www.ubn">http://e2ma.net/go/2226372211/2026197/75867817/10197/goto:http:/www.ubn</a><br>> > <a href="http://t.com/">t.com/</a>> Ubiquiti Networks, Inc. 91 E. Tasman Dr., San Jose, CA 95134 -<br>> > Vol. No.13 - July 20, 2009<br>> ><br>> ><br>> ><br>> > This email was sent to <a href="mailto:cam@midcoast.com">cam@midcoast.com</a>. To ensure that you continue<br>> > receiving our emails, please add us to your address book or safe list.<br>> ><br>> ><br>> > <<a href="http://e2ma.net/map/view=Manage/signupId=17227/id=10197.2226372211/rid=">http://e2ma.net/map/view=Manage/signupId=17227/id=10197.2226372211/rid=</a><br>> > 0bb40cfd2aa52f2df60569807ae43a20> manage your preferences |<br>> > <<a href="http://e2ma.net/map/view=OptOut/signupId=17227/ID=10197.2226372211/rid=">http://e2ma.net/map/view=OptOut/signupId=17227/ID=10197.2226372211/rid=</a><br>> > 0bb40cfd2aa52f2df60569807ae43a20> opt out using TrueRemoveR.<br>> ><br>> > Got this as a forward?<br>> > <<a href="http://e2ma.net/map/view=Join/signupId=17227/mailingId=2026197/acctId=1">http://e2ma.net/map/view=Join/signupId=17227/mailingId=2026197/acctId=1</a><br>> > 0197> Sign up to receive our future emails.<br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>><br>><br>----------------------------------------------------------------------------<br>> > ----<br>> > WISPA Wants You! Join today!<br>> > <a href="http://signup.wispa.org/">http://signup.wispa.org/</a><br>> ><br>><br>><br>----------------------------------------------------------------------------<br>> > ----<br>> ><br>> > WISPA Wireless List: <a href="mailto:wireless@wispa.org">wireless@wispa.org</a><br>> ><br>> > Subscribe/Unsubscribe:<br>> > <a href="http://lists.wispa.org/mailman/listinfo/wireless">http://lists.wispa.org/mailman/listinfo/wireless</a><br>> ><br>> > Archives: <a href="http://lists.wispa.org/pipermail/wireless/">http://lists.wispa.org/pipermail/wireless/</a><br>> ><br>> ><br>> ><br>> ><br>><br>><br>----------------------------------------------------------------------------<br>> ----<br>> > WISPA Wants You! Join today!<br>> > <a href="http://signup.wispa.org/">http://signup.wispa.org/</a><br>> ><br>><br>><br>----------------------------------------------------------------------------<br>> ----<br>> ><br>> > WISPA Wireless List: <a href="mailto:wireless@wispa.org">wireless@wispa.org</a><br>> ><br>> > Subscribe/Unsubscribe:<br>> > <a href="http://lists.wispa.org/mailman/listinfo/wireless">http://lists.wispa.org/mailman/listinfo/wireless</a><br>> ><br>> > Archives: <a href="http://lists.wispa.org/pipermail/wireless/">http://lists.wispa.org/pipermail/wireless/</a><br>> ><br>> ><br>> ><br>><br>> --<br>> Bradley D. Thornton<br>> Manager Network Services<br>> NorthTech Computer<br>> TEL: +1.949.544.1931<br>> <a href="http://NorthTech.US">http://NorthTech.US</a><br>><br>><br>><br>><br>><br>----------------------------------------------------------------------------<br>> ----<br>> WISPA Wants You! Join today!<br>> <a href="http://signup.wispa.org/">http://signup.wispa.org/</a><br>><br>><br>----------------------------------------------------------------------------<br>> ----<br>><br>> WISPA Wireless List: <a href="mailto:wireless@wispa.org">wireless@wispa.org</a><br>><br>> Subscribe/Unsubscribe:<br>> <a href="http://lists.wispa.org/mailman/listinfo/wireless">http://lists.wispa.org/mailman/listinfo/wireless</a><br>><br>> Archives: <a href="http://lists.wispa.org/pipermail/wireless/">http://lists.wispa.org/pipermail/wireless/</a><br>><br>><br>><br>><br>><br>----------------------------------------------------------------------------<br>----<br>> WISPA Wants You! Join today!<br>> <a href="http://signup.wispa.org/">http://signup.wispa.org/</a><br>><br>><br>----------------------------------------------------------------------------<br>----<br>><br>> WISPA Wireless List: <a href="mailto:wireless@wispa.org">wireless@wispa.org</a><br>><br>> Subscribe/Unsubscribe:<br>> <a href="http://lists.wispa.org/mailman/listinfo/wireless">http://lists.wispa.org/mailman/listinfo/wireless</a><br>><br>> Archives: <a href="http://lists.wispa.org/pipermail/wireless/">http://lists.wispa.org/pipermail/wireless/</a><br>><p><br>----------------------------------------------------------------------------<br>----<br>WISPA Wants You! Join today!<br><a href="http://signup.wispa.org/">http://signup.wispa.org/</a><br>----------------------------------------------------------------------------<br>----<p>WISPA Wireless List: <a href="mailto:wireless@wispa.org">wireless@wispa.org</a><p>Subscribe/Unsubscribe:<br><a href="http://lists.wispa.org/mailman/listinfo/wireless">http://lists.wispa.org/mailman/listinfo/wireless</a><p>Archives: <a href="http://lists.wispa.org/pipermail/wireless/">http://lists.wispa.org/pipermail/wireless/</a><p><p>--------------------------------------------------------------------------------<br>WISPA Wants You! Join today!<br><a href="http://signup.wispa.org/">http://signup.wispa.org/</a><br>--------------------------------------------------------------------------------<p>WISPA Wireless List: <a href="mailto:wireless@wispa.org">wireless@wispa.org</a><p>Subscribe/Unsubscribe:<br><a href="http://lists.wispa.org/mailman/listinfo/wireless">http://lists.wispa.org/mailman/listinfo/wireless</a><p>Archives: <a href="http://lists.wispa.org/pipermail/wireless/">http://lists.wispa.org/pipermail/wireless/</a>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-91820063048214469502009-07-09T10:32:00.001-07:002009-07-09T10:32:30.718-07:00[Fwd: Re: Point to Point Ethernet]BEST NANOG POST EVER!<p><br>> History shows us that Layer 2 winds up being IEEE, and Layer 3 IETF.<p>mplsAnonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-14309500423800256192009-07-06T20:10:00.001-07:002009-07-06T20:10:51.684-07:00[Fwd: Re: [outages] Verizon Southern California issues?]FYI<p><source redacted><p>VERIZON CONFIDENTIAL<br> FLASH SUMMARY<br></N.B.><p>=====<p>VERIZON CONFIDENTIAL<br> FLASH SUMMARY<p>FLASH NUMBER <redacted><br>RGANIZATION NSMC<br>SEVERITY LEVEL CATA<br>CRITERIA HSI - HSI outage impacting 2500 or more customers<br>IMPACT LOSS OF DATA AND/OR CONNECTIVITY<br>NETWORK HSI<br>SUBNETWORK ROUTER<br>SPECIAL SERVICES<br>STATE CA<br>CITY THOUSAND OAKS<br>COUNTRY USA<p>OUTAGE START DATE 07-06-2009<br>OUTAGE START TIME 17:10:00 GMT<br>OUTAGE END DATE 07-06-2009<br>OUTAGE END TIME 22:26:00 GMT<br>DURATION 5:16:00<p>EQUIPMENT N/A<p>CAUSE OF OUTAGE FIBER/CABLE OUTAGE - OUTSIDE<br>CORRECTIVE ACTION Fiber spliced.<p>TICKET SOURCE WHITEBOARD<br>TICKET NUMBER 92475<br>LEC/OCC TICKET<br>PVC/CKT Affected<p><br>WEBSITE <a href="http://oasis.vzbi.com">oasis.vzbi.com</a><p>COMMENTS<br>07-06-2009 18:34 GMT<br>Thousand Oaks, CA - HSI - Informational Bridge: (517) 477-3482 pc<br>865-5190. NSMC reports 3500 HSI customers are down. There is a fiber<br>cut located 1.3 miles outside of the Camarillo Central Office on<br>Dawson Drive. Approximately 1000 feet of fiber has been damaged.<br>There is no estimated time of restoral. Number of Trouble Tickets =<br>107 -----------<br>07-06-2009 19:45 GMT<br>NSMC reports that there are 252 attached tickets. Construction is<br>currently prepping the fiber with an ETA of new fiber onsite at 1:23<br>PM PT.<br>07-06-2009 21:24 GMT<br>NSMC reports that there are 345 attached tickets. All fiber is onsite<br>and pulled through duct, splicing commencing in approximately 5<br>minutes.<br>07-06-2009 22:49 GMT<br>NSMC reports construction spliced the fiber. HSI service restored.<br>406 Attached tickets.<br>_______________________________________________<br>outages mailing list<br><a href="mailto:outages@outages.org">outages@outages.org</a><br><a href="https://puck.nether.net/mailman/listinfo/outages">https://puck.nether.net/mailman/listinfo/outages</a>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-27102221582456724132009-07-03T10:02:00.000-07:002009-07-03T10:03:03.187-07:00[Fwd: [Ripple-protocol] [Fwd: [Finanzsystem] hackathon money]]ec30 keeps getting easier...<p>-------- Original Message --------<br>Subject: [Ripple-protocol] [Fwd: [Finanzsystem] hackathon money]<br>Date: Fri, 03 Jul 2009 00:11:02 +0200<br>From: Klaus Mueller <<a href="mailto:m@klml.de">m@klml.de</a>><br>Reply-To: Ripple concept and protocol development <br><<a href="mailto:ripple-protocol@lists.sourceforge.net">ripple-protocol@lists.sourceforge.net</a>><br>To: Ripple concept and protocol development <br><<a href="mailto:ripple-protocol@lists.sourceforge.net">ripple-protocol@lists.sourceforge.net</a>><p>Hi folks,<p>fyi;)<p>hackathon money<p>In 48 hours a group of hackers and creative minds will create free, open<br>source software that allows anyone to issue and exchange money - Digital<br>Bearer Certificates that are the basis for free, decentralized currencies<br>in virtual worlds, social networks and real life.<p>What can be your contribution? Your skills and talent are valuable! We<br>need enhusiasts in the fields of coding, security, administration,<br>identity design, web design, blogging, video editing, photography, writing<br>...<p>hackathon money_ is a wonderful opportunity to get together with great<br>minds, have fun, do what you love and create something meaningful - in<br>other words, a perfect weekend :)<p>Gastgeber: metalab / Andreas Pizsa<br>Beginn: Freitag, 24. Juli 2009 um 19:00<br>Ende: Sonntag, 26. Juli 2009 um 19:00<br>Ort: metalab<br>Straße: Rathausstraße 6<br>Stadt/Ort: Vienna, Austria<p><a href="http://www.facebook.com/event.php?eid=94447637156">http://www.facebook.com/event.php?eid=94447637156</a><br>Metalab: <a href="http://metalab.at/">http://metalab.at/</a><p><br>greetz<br>klml<p>-- <br>Klaus Mueller<br>Heßstraße 90<br>80797 München<p>+49 89 18 98 58 21<br>+49 178 54 38 400<br><a href="http://klml.de">klml.de</a><p><br>------------------------------------------------------------------------------<br>_______________________________________________<br>Ripple-protocol mailing list<br><a href="mailto:Ripple-protocol@lists.sourceforge.net">Ripple-protocol@lists.sourceforge.net</a><br><a href="https://lists.sourceforge.net/lists/listinfo/ripple-protocol">https://lists.sourceforge.net/lists/listinfo/ripple-protocol</a>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-74520431139960533812009-07-01T10:08:00.001-07:002009-07-01T10:08:52.157-07:00[Fwd: CE200 DSLAM observations]The OpenSDSL project lives on!<p><br>-------- Original Message --------<br>Subject: CE200 DSLAM observations<br>Date: Wed, 1 Jul 2009 07:10:45 GMT<br>From: <a href="mailto:msokolov@ivan.Harhan.ORG">msokolov@ivan.Harhan.ORG</a> (Michael Sokolov)<br>Reply-To: <a href="mailto:opensdsl@ifctfvax.Harhan.ORG">opensdsl@ifctfvax.Harhan.ORG</a><br>To: <a href="mailto:opensdsl@ifctfvax.Harhan.ORG">opensdsl@ifctfvax.Harhan.ORG</a><p>Update on the bring-up of our test DSLAM: I have received the new fan<br>module from David at Routerspot and both fans are now running fine.<br>The DSLAM's Ethernet port is now connected to the Harhan shop network<br>and has an IP address assigned. The configuration save operation worked<br>fine as well (see below).<p>The next step is to bring out the DSL output and look at it with our<br>various hacky tools while configuring different encapsulations and<br>netmodels on the DSLAM. I want to determine experimentally exactly what<br>this DSLAM is able to serve out on the subscriber loops when it's being<br>used by itself without a Redback router on the other end of a DS3 ATM<br>pipe.<p>With Rhythms and NorthPoint being gone, it seems that the only remaining<br>network which operates CM DSLAMs with the luxury of DS3 backhaul and<br>Redback aggregation routers is MegaPath aka former DSL.net on the<br>Atlantic coast. (If there are any others, I would like to know who they<br>are!) All other remaining CM DSLAM operators seem to be small<br>independents like RRIC. If a network operator has a bunch of DSLAMs<br>deployed in different COs and has DS3 links connecting them to an even<br>more central "MegaPOP", they can afford to use each DSLAM as nothing<br>more than a Layer 2 device and provision each subscriber as a separate<br>PVC from the "MegaPOP" side. However, if you have a single DSLAM and<br>you want to serve a local contingent of customers from it, you would<br>simply want to feed raw upstream bandwidth to it and have the DSLAM do<br>the rest, right? Hence my desire to find out exactly what this DSLAM is<br>able to serve out when one can't use the Cross-Connect netmodel because<br>there's nothing to cross-connect to.<p>The CE200 DSLAM puts its subscriber loops out on 50-pin Amphenol<br>connectors commonly known as "female telcos". Tomorrow I'll be heading<br>to the local telco gear warehouse to pick up the right cable for that;<br>I already have an M66 block with Amphenol breakout.<p>I have also taken a little peek at the internals of this DSLAM. As I<br>had already observed a while back, it has two internal buses: CompactPCI<br>and a proprietary line card bus. The Buffer Control Module is basically<br>the bridge between these two buses. The line card bus interconnects all<br>line card slots and the two redundant BCM slots. There two cPCI buses,<br>one on each side of the chassis for the redundant configuration. Each<br>cPCI complex consists of the System Control Module, WAN modules and the<br>BCM which links it to the line card bus and manages the redundancy<br>feature. My CE200 has a single cPCI complex on the left side, the<br>redundant slots on the right are unpopulated - apparently not too many<br>of these DSLAMs were shipped with the redundancy feature. (I've been<br>told they are so reliable that the redundant cPCI complex isn't really<br>needed.)<p>The SCM is an off-the-shelf Pentium SBC (single board computer) made by<br>Ziatech. (CM's documentation mentions there being 3 different versions<br>of the CE200 SCM and mine appears to match the description of version 1.)<br>The system's main CPU being an off-the-shelf SBC obviously raises the<br>next question of hacker's curiosity: what OS is it running? Well, I now<br>have the answer: it's VxWorks.<p>One of my past bosses at an embedded software engineering company has<br>referred to VxWorks as the "Microsoft of the embedded world", but that<br>was referring mostly to their proprietary licensing model. Those issues<br>aside, in purely technical terms VxWorks doesn't seem to be all that bad<br>when one needs a very complex and very specialized embedded system with<br>functionality markedly different from general purpose computer OSes.<br>But then perhaps I make a poor judge in this matter as I'm not very<br>familiar with VxWorks beyond hearsay.<p>There are two DE9 serial ports on the SCM, labeled "craft" and<br>"diagnostic". (According to CM's docs on SCM version 3 they've been<br>replaced with RJ45s using Cisco pinout, but I've never seen one with my<br>own eyes.) CM's docs talk only about the craft port and tell you to<br>leave the other one alone. Well, connecting to the diagnostic port like<br>CM tells you not to, one sees that it's the console port for VxWorks<br>running on the CPU. One can interact with the boot ROM, tell it to boot<br>a different image, and once it's booted, interact with the VxWorks<br>kernel and see the debug output from various processes. The craft port<br>in contrast is fully sanitized, all you see there is exactly what you<br>see when you telnet to a running DSLAM, no low-level debug output of any<br>kind. Basically the craft port is a way to get to the management CLI<br>when the IP stack isn't up and usable.<p>There is one part of this DSLAM design that is likely suffering from a<br>blemish though, and that is the flash file system. Flash memory on the<br>SCM is used to store the software/firmware images for all the boards in<br>the system as well as the config.txt or config.tgz (DOS-ified config.txt.gz,<br>see below) file which contains all persistent configuration. My contact<br>at MegaPath has told me that just about the only failure mode seen on<br>these DSLAMs is that after a certain while the SCM loses the ability to<br>save its running configuration to persist across power cycles, and after<br>taking a peek at how its internal file system is implemented, I think I<br>have a guess as to why that happens.<p>The two file systems supported by VxWorks are DOS and RT-11. Well,<br>there is nothing fundamentally wrong with using either of these file<br>systems in an embedded system (I particularly like the RT-11 fs), except<br>one little problem: both file systems are designed for regular block<br>devices, not for flash.<p>The file system used by CM on the SCM is DOS, or at least it has all the<br>appearance of a DOS file system: drive letters, 8.3 filenames, backslash<br>as the path separator, DOS-looking directory listings, all filenames<br>converted to uppercase as the canonical form. SCM version 1 (the one I<br>have) has only one kind of flash on it (VxWorks drive letter P:) and it<br>appears to be NOR flash. According to CM's docs SCM version 2 adds an<br>IDE flash drive under letter Q:.<p>Well, as someone who does embedded system consulting for a living<br>outside of the telecom hobby, I can tell you that NOR flash is rather<br>delicate and that it's designed for directly executable code, not for<br>making a file system out of it. Implementing a reliable flash file<br>system on top of NOR flash is certainly possible (jffs2 in Linux is a<br>good example), but it takes certain care, and I have never heard of<br>anyone implementing a DOS file system on top of NOR flash.<p>Being designed for traditional disk devices with 512-byte sectors, the<br>DOS file system is totally unsuited for NOR flash. The only way to<br>implement such a thing would be to build a software emulation layer that<br>makes a virtual block device out of NOR flash, and that is tricky. If<br>one does the dumb thing of implementing writes of 512-byte "sectors" by<br>taking the much larger flash sector, stashing it away in RAM, erasing it<br>and reprogramming it in flash, the resulting system will not only wear<br>the flash out very very shortly, but will also be vulnerable to<br>catastrophic fs corruption should the power go out in the middle of that<br>operation. I sure hope that CM's implementation of their DOS fs isn't<br>*that* dumb, but given all those field reports with the symptoms of<br>flash wearing out prematurely, who knows... Even if it isn't super-dumb,<br>it sure seems very suboptimal. There is the FTL standard that tells you<br>how to do it "right", but I'm not familiar with the details off the top<br>of my head and I still don't know how good it is - I would choose jffs2<br>over FTL any day in any system I design.<p>I have a guess that the reason why CM had added an IDE flash drive to<br>version 2 of their SCM was not because they needed more room, but simply<br>to avoid the configuration save flash wear problem. (Apparently when<br>that IDE flash drive is present, only the SCM code image stays on P: and<br>all other images and the config file move to Q:.) But they could have<br>fixed it by improving their software instead of throwing in more<br>unnecessary hardware!<p>Well, it's getting late here and I'm heading to bed. I will post more<br>when I wire up the DSL output from the beastie and play with some<br>configurations.<p>MSAnonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-76106242832602630232009-06-26T19:57:00.000-07:002009-06-26T19:58:07.450-07:00[Fwd: A Few Random Thoughts...]Good thoughts<p>-------- Original Message --------<br>Subject: A Few Random Thoughts...<br>Date: Fri, 26 Jun 2009 10:42:49 -0400<br>From: R.A. Hettinga <<a href="mailto:rah@shipwright.com">rah@shipwright.com</a>><br>To: Gold Silver Crypto <<a href="mailto:gold-silver-crypto@rayservers.com">gold-silver-crypto@rayservers.com</a>>, NANOG list <br><<a href="mailto:nanog@nanog.org">nanog@nanog.org</a>>, <a href="mailto:cypherpunks@al-qaeda.net">cypherpunks@al-qaeda.net</a>, Cryptography <br><<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>><br>References: <<a href="mailto:20090626134321.GH23524@leitl.org">20090626134321.GH23524@leitl.org</a>><p><br>As with anonymous remailers, or any other anonymous system, the exit<br>node of an onion-routing system is the sin-eater for the rest of the<br>network.<p>And, without cash settlement, you get what you pay for. :-).<p>Cheers,<br>RAH<br>-------<p>Begin forwarded message:<p>From: Eugen Leitl <<a href="mailto:eugen@leitl.org">eugen@leitl.org</a>><br>Date: June 26, 2009 9:43:21 AM GMT-04:00<br>To: <a href="mailto:tt@postbiota.org">tt@postbiota.org</a>, <a href="mailto:info@postbiota.org">info@postbiota.org</a>, <a href="mailto:cypherpunks@al-qaeda.net">cypherpunks@al-qaeda.net</a><br>Subject: A Few Random Thoughts...<p>----- Forwarded message from Michael <<a href="mailto:cozzi@cozziconsulting.com">cozzi@cozziconsulting.com</a>> -----<p>From: Michael <<a href="mailto:cozzi@cozziconsulting.com">cozzi@cozziconsulting.com</a>><br>Date: Fri, 26 Jun 2009 08:16:00 -0400<br>To: <a href="mailto:or-talk@seul.org">or-talk@seul.org</a><br>Subject: A Few Random Thoughts...<br>User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)<br>Reply-To: <a href="mailto:or-talk@freehaven.net">or-talk@freehaven.net</a><p><br> Hi all,<p> As one of those lucky souls with access to almost limitless<br>bandwidth and the skills (or stupidity) to use it, I suppose an apology<br>is in order:<p> I'm sorry- after reviewing what *could* be the consequences, I have<br>to whimp out based on professional risk factors... I can't run an exit<br>node. So I have to leave it to other folks who have a different<br>situation to do the heavy lifting.<p> What I *am* doing is deploying a couple of heavy iron closed relays<br>on OC3 or better bandwidth. The first is now deployed after a lot of up<br>and down testing, and I'll get to the second in due time.<p> I've been watching Tor for a long time and just recently decided to<br>get involved. The Iran situation cemented that decision.<p> Anyhow, here are some random thoughts:<p> On the "Who uses Tor?" section of the website, I see no mention of<br>IT people. I've used the Tor network for many practical uses as an IT<br>Director. These range from bypassing my own firewall to test incoming<br>connections, to helping my legal department do research on a pending<br>lawsuit without the opposition *knowing* we even looked at their<br>website. Having a random and easily accessible IP to initiate<br>connections from is a priceless testing tool. Especially when dealing<br>with niggling routing problems.<p> On one occasion my ISP was having routing/DNS problems, and Tor was<br>able to find an entrance node and allow me to work even though I<br>couldn't get to my remote servers directly. This saved my client a lot<br>of downtime, and might have saved me the account. Also, my employer's<br>R&D department sometimes needs to look at things they don't want anyone<br>to know they looked at (All quite legal mind you).<p> Quite frankly Tor is an undervalued IT tool and it's capabilities<br>should be trumpeted loudly on the web page. You might also find IT guys<br>like me throwing up some relays in exchange. After all- who has the<br>bandwidth anyway?<p> And before anyone accuses me of it, I'm not nearly stupid enough to<br>do a port scan over Tor. Phew.<p> One of the issues I ran into when looking into running an exit relay<br>had to do with not only the legalities, but identifying a server vendor<br>that was offshore from my home country and friendly to a Tor exit. In<br>order for me to run an exit node, I have to be completely shielded.<p> As it stands now, I can probably run an exit for instant messaging-<br>and that's it. However, if Tor itself had a relationship with someone<br>who rents hardware, perhaps a partnership, Tor could get the exit nodes<br>it needs, and the server vendor could get lots of cash. From my<br>standpoint, it doesn't matter whether I rent or colocate my hardware. So<br>if Tor as an organization had a partnership with a few server rental<br>whores (in multiple countries), it would simplify getting more exits. I<br>need servers, Tor runs with little impact on my server, I could care<br>less where my remote hardware is provisioned from. Bingo- more exits.<p> I read back about 6 months in the or-talk list and there were a<br>couple of suggestions inferring that *everyone* should be forced to be<br>an exit node. I think this is a very bad idea, and hurts the security of<br>the person trying to remain anonymous by causing an identifiable change<br>in bandwidth usage that could infer Tor usage (Information leakage).<p> Simply speaking, on a default Windows/Vidalia installation, outgoing<br>Tor traffic usually looks like https traffic, but on a forced exit, now<br>Tor is identified by relatively matched traffic on port 443 both in and<br>out of the client's connection (Unless it's entrance node is a *nix<br>variant). This could mean death (literal) for a political dissident who<br>is now identified as having an in/out matching traffic pattern assuming<br>his entrance node is on Windows. It is more likely, that a country<br>monitoring it's citizens would miss simple https traffic. But even<br>myself as a lowly IT director, would have alarm bells going off if https<br>was initiating in two directions from the same machine. Alternative<br>ports can also set off alarm bells. But given the nature of Onion<br>Routing, two way traffic needs to be avoided in the most sensitive<br>sensitive situations. Forcing exit nodes is a bad idea for users. It<br>will also drive away anyone who cannot provide an exit node.... that's<br>chasing away bandwidth as non exit relays run for the hills.<p> Long post. Too much coffee and too much time staring at routing<br>tables.<p> Michael<p>----- End forwarded message -----<br>-- <br>Eugen* Leitl <a href="<a href="http://leitl.org">http://leitl.org</a>">leitl</a> <a href="http://leitl.org">http://leitl.org</a><br>______________________________________________________________<br>ICBM: 48.07100, 11.36820 <a href="http://www.ativel.com">http://www.ativel.com</a> <a href="http://postbiota.org">http://postbiota.org</a><br>8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BEAnonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-81483832980187302672009-06-26T19:53:00.001-07:002009-06-26T19:53:48.942-07:00[Fwd: Some initial investigation on GPRS support]Happy hacking indeed...<p>-------- Original Message --------<br>Subject: Some initial investigation on GPRS support<br>Date: Thu, 25 Jun 2009 21:16:59 +0200<br>From: Harald Welte <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>><br>To: <a href="mailto:openbsc@lists.gnumonks.org">openbsc@lists.gnumonks.org</a><p>Hi!<p>I've started to analyze GPRS and was actually even starting to write <br>some code<br>for it, but then have given up for the time being - it's much more work than<br>anticipated.<p>Given the long todo list of OpenBSC right now, I think I'll have put <br>aside GPRS<br>for some time :(<p>Based on looking at protocol traces, I have figured out the nanoBTS <br>GPRS/EDGE<br>implementation roughly looks as follows:<p>* make sure we allow the BTS to activate the GPRS software components<br> in abis_nm / OML activation!<br>* BTS will use a UDP connection on port 23000 for the GPRS related frames.<br> The GSM specs will consider this type of connection between the PCU (part<br> of the nanoBTS) and the SGSN. The establishment/configuration of the<br> UDP port number and SGSN ip address has not yet been identified. <br>Probably<br> similar to how the RSL link is activated via OML.<p> The protocol stack looks like:<p> IP : UDP : NSIP : BSSGP : LLC : higher-layer<p> IP and UDP you should know and/or not care about ;)<br> NSIP is a IP-enabled version of NS as specified in TS 08.16<br> BSSGP is specified in TS 08.18<br> LLC is as specified in TS 04.64<p> the higher-layer depends on the SAPI value of the LLC and can be<br> * GMM (GPRS Mobility Management as specified in 04.08)<br> * User Data (actual IP packets, e.g.)<br> * SMS<p>So what is weird about this is that the GPRS MM is actually part of <br>04.08, but<br>it is not terminated at the BSC but rather at the SGSN. Also, the deep <br>stack<br>comprised of many headers is really weird. Furthermore, it seems that a lot<br>of the packet scheduling and timeslot allocation is happening inside the<br>nanoBTS - very unlike the GSM side of things.<p>I have not yet managed to figure out how to allocate/dedicate resources to<br>GPRS.. after all, the BTS needs to know how many timeslots it can use <br>for it,<br>etc.<p>If anyone wants to dig deeper, you're most welcome to do so. A list of<br>relevant specs:<p>01.61 GPRS cipher algorithm requirements<br>03.60 Overall GRPS logical architecture (above RL and MAC)<br>03.64 GPRS radio interface<br>04.60 RLC/MAC on PDCH<br>04.64 MS-SGSN LLC spec (on top of RLC/MAC)<br>04.65 SGSN SNDCP<br>08.14 BSS SGSN Gb Layer 1<br>08.16 BSS SGSN Gb Layer 2<br>08.18 BSS SGSN BSS GPRS protocol<br>09.95 Interworking between modified PLMN supporting legacy GPRS and GPRS <br>mobiles<br>22.060 GPRS Service Spec<br>23.060 GPRS Radio Service Spec<br>29.016 SGSN - VLR Interface Gs network interface spec<br>29.018 SGSN - VLR Interface Gs layer3 interface spec<br>29.060 GPRS Tunneling (GTP) over Gn and Gp<p>Happy hacking,<br>-- <br>- Harald Welte <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> <a href="http://laforge.gnumonks.org/">http://laforge.gnumonks.org/</a><br>============================================================================<br>"Privacy in residential applications is a desirable marketing option."<br> (ETSI EN 300 175-7 <br>Ch. A6)Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-69770655165027891232009-06-12T12:44:00.001-07:002009-06-12T12:44:08.840-07:00[Fwd: TechNet Plus Subscription Deactivation]Was fun while it lasted.<p>-------- Original Message --------<br>Subject: TechNet Plus Subscription Deactivation<br>Date: Fri, 12 Jun 2009 20:26:31 +0100<br>From: IT Advisory Council <<a href="mailto:ITAdvisoryCouncil@thinkintrepid.com">ITAdvisoryCouncil@thinkintrepid.com</a>><br>To: <<a href="mailto:charles@thewybles.com">charles@thewybles.com</a>><p><p>Intrepid.bmp<p><p>Dear Charles,<p><p>Microsoft contracted with us, Intrepid Consultants, Inc, to conduct the<br>TechNet Plus Pilot Study program research and manage the activities of<br>the pilot study. Our records show that you have recently signed up for a<br>free TechNet Plus subscription through a registration link that was made<br>available without authorization on a public blog.<p><p>The registration link is part of a proprietary study and the party that<br>shared the information was in violation of the terms and conditions to<br>which they agreed to participate in the study. Membership to the Pilot<br>study is limited and all members of the program are required to first<br>meet survey requirements and then complete tasks and assignments over a<br>two month period in order to qualify for and have access to the free<br>TechNet Plus subscription. Since this was a privately conducted pilot<br>study, at no time was it ever intended that a free TechNet Plus<br>registration link would appear on a public internet site, which was done<br>in violation of the terms to which participants agreed upon registering<br>to participate in the pilot study.<p><p>We are very sorry for the inconvenience, but for this reason, we have<br>deactivated your subscription, as well as all other subscriptions<br>resulting from the unauthorized publication of the TechNet Plus Pilot<br>Study program registration link on a public blog. Again, we apologize<br>for any inconvenience.<p><p>Kind regards,<p><p>The Intrepid Consultants Team<p><p><p>If you are interested in a TechNet Plus subscription, please follow the<br>link to purchase:<br><a href="http://technet.microsoft.com/en-us/subscriptions/renew.aspx">http://technet.microsoft.com/en-us/subscriptions/renew.aspx</a><p><p><br>This e-mail and all files transmitted within are confidential and<br>intended solely for the use of the individual or entity to whom they are<br>addressed. Please do not reproduce, print or forward any material<br>received unless granted express permission by the sender. Thank you,<br>Intrepid Consultants, Inc.<p>The research and communications administered by Intrepid Consultants,<br>Inc is conducted according to the highest standards of the Market<br>Research Society's code of conduct. Your information will not be shared<br>with any third party for any reason.<p><p>Microsoft is committed to protecting your privacy and has commissioned<br>Intrepid <<a href="http://www.thinkintrepid.com">http://www.thinkintrepid.com</a>> and its partners (click here<br><<a href="http://www.thinkintrepid.com/privacy">http://www.thinkintrepid.com/privacy</a>> to read Intrepid's privacy<br>statement) to oversee the Survey and collect survey responses and<br>communicate with interested respondents and individuals. Should you wish<br>to no longer receive e-mails from Intrepid Consultants, please send an<br>e-mail to <a href="mailto:technetpilot@thinkintrepid.com">technetpilot@thinkintrepid.com</a> with the word "remove" in the<br>subject line.<p>Please notify us if you are receiving this message in error at<br><a href="mailto:ITAdvisoryCouncil@thinkintrepid.com">ITAdvisoryCouncil@thinkintrepid.com</a> and delete all contents of this email.<p>Review Microsoft's Privacy Statement here<br><<a href="http://www.microsoft.com/info/cpyright.mspx">http://www.microsoft.com/info/cpyright.mspx</a>>.<p><p>For information, please call 1-866-625-1409<p>Intrepid Consultants, Inc<p>124 NW Canal St, 2^nd Fl<p>Seattle WA 98107Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-80944612758343115152009-06-12T12:14:00.000-07:002009-06-12T12:20:17.380-07:00All your ID belong to usSo lately I've become something of a federal ID/clearance junkie.<br /><br />I completed my CVI clearance process last night.<br /><br />Now I'm obtaining TWIC.<br /><br />Then NEXUS and FAST.<br /><br />Fun stuff.<br /><br />Will update this post as I complete the process etc.Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-27326498019179328542009-06-08T10:39:00.001-07:002009-06-08T10:39:09.178-07:00[Fwd: Re: [Cabletv-list] Cabletv-list Digest, Vol 27, Issue 5]Television.... funny business...<p>-------- Original Message --------<br>Subject: Re: [Cabletv-list] Cabletv-list Digest, Vol 27, Issue 5<br>Date: Mon, 8 Jun 2009 12:16:13 -0500 (CDT)<br>From: Steve Dyche <<a href="mailto:sdyche@npgco.com">sdyche@npgco.com</a>><br>Reply-To: CableTV-List <<a href="mailto:cabletv-list@cabletv.org">cabletv-list@cabletv.org</a>><br>To: <<a href="mailto:cabletv-list@cabletv.org">cabletv-list@cabletv.org</a>><br>References: <<a href="mailto:mailman.1.1244480401.24012.cabletv-list@cabletv.org">mailman.1.1244480401.24012.cabletv-list@cabletv.org</a>><p>All my recent experience with the service indicates that it is alive and<br>well. That is dealing with that division of TV Guide/ Macrovision and<br>whatever their new name is.<br>We have had to deal with some interestng situations, the data source on<br>the VBI of one of our imported PBS stations did not keep the service when<br>they switched over to their DTV channel. Instead the service is available<br>on another network television station in town which we do not carry or<br>import.<p>We transport the data service which is on a another PBS station from a<br>remote site and the common carrier could not accommodate keeping the VBI<br>intact during the transport. We contacted TV Guide Plus and they provided<br>a data inserter, we provided a phone line. They download guide data<br>regularly via telephone, the data inserter puts it back onto the<br>transported but stripped VBI PBS channel.<p>We have quite a few elderly customers, non-converter that insist on having<br>the service.<p>----------------------------------------------------------------------<p>Message: 1<br>Date: Mon, 8 Jun 2009 08:36:48 -0500<br>From: "Matt Schonlau" <<a href="mailto:matt@pioncomm.net">matt@pioncomm.net</a>><br>Subject: [Cabletv-list] Guide +<br>To: "SCTE-List" <<a href="mailto:SCTE-List@SCTE-LIST.ORG">SCTE-List@SCTE-LIST.ORG</a>>, "CableTV-List"<br> <<a href="mailto:cabletv-list@cabletv.org">cabletv-list@cabletv.org</a>><br>Message-ID:<br> <br><<a href="mailto:D271DAC1E8DE4A439400EF8644EB314A015257FA@pionexch2003.pioncomm.net">D271DAC1E8DE4A439400EF8644EB314A015257FA@pionexch2003.pioncomm.net</a>><br>Content-Type: text/plain; charset="us-ascii"<p>Can anyone direct me to more information on Guide+. How long will it be<br>supported?<p>Matt Schonlau, Switching & Transmission Mgr.<br>Pioneer Communications<br>120 W. Kansas<br>Ulysses, KS 67880<br>620-356-7146<br><a href="http://www.pioncomm.net/">http://www.pioncomm.net/</a><p><p>------------------------------<p>_______________________________________________<br>Cabletv-list mailing list<br><a href="mailto:Cabletv-list@cabletv.org">Cabletv-list@cabletv.org</a><br>To change subscription options or to donate:<br><a href="http://cabletv.org/mailman/listinfo/cabletv-list">http://cabletv.org/mailman/listinfo/cabletv-list</a><br>for other cable telecom info, see <a href="http://www.scte.org">www.scte.org</a> and <a href="http://www.scte.org.uk">www.scte.org.uk</a><p>End of Cabletv-list Digest, Vol 27, Issue 5<br>*******************************************<br>_______________________________________________<br>Cabletv-list mailing list<br><a href="mailto:Cabletv-list@cabletv.org">Cabletv-list@cabletv.org</a><br>To change subscription options or to donate: <br><a href="http://cabletv.org/mailman/listinfo/cabletv-list">http://cabletv.org/mailman/listinfo/cabletv-list</a><br>for other cable telecom info, see <a href="http://www.scte.org">www.scte.org</a> and <a href="http://www.scte.org.uk">www.scte.org.uk</a>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-55862194368173485322009-06-07T20:22:00.001-07:002009-06-07T20:22:06.067-07:00Re: [WISPA] Electronic SignaturesThe big carriers don't require a signature on a contract. They also <br>don't do (free/near free) installs either. I don't know if there is a <br>signed contract if you pay for an install.<p>Yes I realize this is a very important differentiator that we can <br>provide, however I don't feel a signed contract is necessary. An AUP is <br>an excellent idea as a general rule, however if they are transiting bits <br>on your network, you have the right and obligation to defend that <br>network. If you don't, you risk other operators dropping traffic from <br>your IP rnage /AS.<p><br>Your free to enforce your AUP with impunity. Failure to do so is the <br>sole reason that "bits of evil" reach our border routers. A few simple <br>route filters, and spam/botnets would be stopped. Subscribe to the Don't <br>Route Or Peer List from Spamhaus <br>(<a href="http://www.spamhaus.org/drop/index.lasso">http://www.spamhaus.org/drop/index.lasso</a>), and monitor outbound traffic.<p><br>*sighs*<p><p>Martha Huizenga wrote:<br>> Exactly, we send the contract with the install and then get it back when <br>> the install is done. Works fine.<br>> <br>> Jason Hensley wrote:<br>>> Wow. Seems like a waste of time and resources. If I mailed contracts like<br>>> that here I'd lose half my install opportunities because they would never<br>>> send the contract back. Send a contract with the installer, get them to<br>>> sign it before they install, give one copy to customer, bring one back, done<br>>> deal. If nothing else, get an electronic as an initial confirmation, then<br>>> get an actual signature at install. <br>>><br>>><br>>><br>>> -----Original Message-----<br>>> From: <a href="mailto:wireless-bounces@wispa.org">wireless-bounces@wispa.org</a> [mailto:<a href="mailto:wireless-bounces@wispa.org">wireless-bounces@wispa.org</a>] On<br>>> Behalf Of Scott Reed<br>>> Sent: Saturday, June 06, 2009 6:42 AM<br>>> To: WISPA General List<br>>> Subject: [WISPA] Electronic Signatures<br>>><br>>> We currently use a two-year contract for customers. Right now we gather <br>>> the information, generate a contract, USMail it to the customer and wait <br>>> for them to USMail it back after they sign it before we schedule an <br>>> installation. We would like to reduce the time from initial contact to <br>>> installation. One option we are looking at is "electronic signature" on <br>>> the contract. We have done some research into doing this, but thought it <br>>> would be good to get some other input.<br>>> If you do electronic signatures, how do you do it?<br>>> If you use a third party to "certify" the signatures, who do you use? <br>>> What is good about them? What is not so good?<br>>><br>>> <br>> <br>> <br>> --------------------------------------------------------------------------------<br>> WISPA Wants You! Join today!<br>> <a href="http://signup.wispa.org/">http://signup.wispa.org/</a><br>> --------------------------------------------------------------------------------<br>> <br>> WISPA Wireless List: <a href="mailto:wireless@wispa.org">wireless@wispa.org</a><br>> <br>> Subscribe/Unsubscribe:<br>> <a href="http://lists.wispa.org/mailman/listinfo/wireless">http://lists.wispa.org/mailman/listinfo/wireless</a><br>> <br>> Archives: <a href="http://lists.wispa.org/pipermail/wireless/">http://lists.wispa.org/pipermail/wireless/</a><br>>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-27012333131965744252009-06-05T20:58:00.001-07:002009-06-05T20:58:13.492-07:00[Fwd: Re: [SGVLUG] Secure "one time" passwords -- oh really?]Folks might dig this...<p><p><br>Emerson, Tom (*IC) wrote:<br>> OK, now that I've got John busy reconfiguring his security system,<p><br>*snickers*<p> I've got a question for the rest of you: how "secure" do you think the<br>"safeword" password token generator is?<p><br>I haven't worked with this one in particular, but am familiar with the<br>RSA brand.<p>They are quite secure.<p><br>> <br>> [trick question, I know, because safeword was bought by McAfee]<p>:)<p>Let me clarify my above statement. The theory is sound, and the<br>particular reduction to practice by RSA inc is considered to be quite<br>secure.<p><br>> <br>> On the surface, I'm not convinced (as you might guess, I've recently been assigned one of these) There are two models they talk about - one that you need only "push a button" to get the (next) "one-time" password token, and another where you need to enter a "pin" and it will generate the next token for that PIN. (and a third option is proprietary software loaded onto your system or blackberry/phone) <p>The ones from RSA automatically produce the next number, others have you<br>request it.<p><p> In some of the documents, they mention that the tokens can be either<br>"time based" or "event based". (and I presume "event" means "token<br>generated", since I don't see any way the fob you carry and back-end<br>"validating" server would otherwise agree on what an "event" is)<p>I would say this is a correct analysis, but am not familiar with the<br>particular reduction to practice used by your vendor.<p><br>> <br>> The card generates what appears to be a 6 (hexadecimal) digit value (i.e., 3 bytes) I have the one where you enter a 4 (decimal) digit PIN (and per related documents I've received, if you get the pin "wrong", it generates an invalid token) Just breaking it down on that aspect alone, the token generator can generate up to 2^24 tokens of which (for the PIN based ones) 1 in 10000 are legit -- someone please check my math, because I only come up with 1677 valid passwords for the life of the token generator! (2^24 / 10000) heavy use of the device (10 validations/day) would kill that in less than half a year! (though I suspect "typical use" might be twice a day/weekdays only/50 work-weeks per year, or about 3 years of useful life [2 * 5 * 50 = 500 uses/year])<br>> <p>They are reissued every N years as a matter of course. Your correct. I<br>didn't validate your math, but 3 to 5 years is par for the course. Again<br>your particular implementation should be verified by your organizations<br>security personnel against their specific policies.<p>> Then there is the challenge of tracking "use" of the tokens - I can think of two methods (and I have an idea as to which was used) The "validating" server can generate every valid token and store that as some form of list, "crossing off" each token as it is used [more realistically, a 16-million-bit bitmask with "1"'s set for each valid token; as they are used, they get reset to 0] OR you prepare a database with 1677 blank entries, filling in each one "as used" (and doing a search each time a token is presented to see if it's been used) Either would work because the entire range of "valid" tokens pretty much "has to be" generated programmatically (and possibly modulated based on the time-and-date that the token is generated, but this "complication" only makes it more difficult for a "human" -- see below)<p>To my knowledge the seed is site/time specific.<p><br>> <br>> Since the guy that was activating my card indicated "this next step takes some time", I imagine the list is pre-generated (if you use a "bitmask" it would only need to be 2 megabytes long -- years ago, that would be a showstopper, but in today's age of terabyte drives...) I don't know offhand if my card is also time-based (but that's easy to test...)<br>> <br>> In any case, I can see that the "push for a new token" card wouldn't be terribly secure (if it is only "event" based) as someone could copy a block of tokens should they get ahold of the card (and since there is no indication of how many tokens have been generated, the user wouldn't necessarily know that he'd been compromised) The pin-based one is a little better as a "random guess" only has a 1-in-10000 chance of getting the correct PIN (or to put it another way, for an attacker to store off potential tokens for later use, they would have to generate/store 9999 other tokens as well) Of course, should the PIN be compromised, the device is no more secure than the single-push version [though, a thought occurs -- if the "PIN" that you enter is used in some way to modify the token generated, and that "method" becomes known, it would be trivial to convert any given result to what it would be with a different PIN - the attacker need only store tokens generated for PIN 0000...]<p><br>> <br>> The "time based" ones are, again, only marginally more secure since (I imagine...) there has to be some set algorithm to convert a "good" token to "good at /this/ moment" token, and if that's the case, chances are pretty good this algorithm can be reversed, and again, someone could extract any number of tokens and "adjust" for the time of day (by first back-converting to the base token, then at the time you wish to break in, convert any base value token to a current-time version...)<br>> <br>> Oh well, food for thought for the weekend... Gotta go...<br>> <p>Thanks for the post.<p>I don't do a lot of security work anymore, as I got tired of the very<br>long audit sessions and stating my name/position/responsibilities etc<br>for the permanent record, as well as the in depth background checks<br>required. However I have been directly responsible for some very large,<br>high profile security implementations, and consulted for several others.<br> So I hope I answered your questions. Perhaps someone can do a<br>presentation on two factor VPN authentication with open source software<br>at SGVLUG?<p>Apologies for the formal nature of my response, but I take security and<br>the protection of privacy as very serious matters (even though some of<br>my previous posts to the list today, may have not seemed so.:)) I'm<br>guessing you and the organization issuing you the key fob do as well.<p>I don't know your particular situation beyond the details provided here,<br>and claim no responsibility for, or accuracy of anything said above.<br>Please please please onsult with your organizations security and legal<br>professionals on the security/legal/privacy/compliance implications of<br>your particular solution and it's reduction to practice.<p>I really really really care when I'm paid to care, and I take reasonable<br>precautions during online activity of a non employment related nature.Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-63892401282856051372009-06-02T13:49:00.001-07:002009-06-02T13:49:04.703-07:00[Fwd: .ORG is signed]Huyah!!!!<p>-------- Original Message --------<br>Subject: .ORG is signed<br>Date: Tue, 2 Jun 2009 16:44:47 -0400<br>From: Dave Knight <<a href="mailto:dknight@ca.afilias.info">dknight@ca.afilias.info</a>><br>To: <a href="mailto:nanog@nanog.org">nanog@nanog.org</a><p>-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1<p>Colleagues,<p>On behalf of PIR Technical Support I would like to announce that as of<br>today, 2009-06-02, at 16:00 UTC .ORG is DNSSEC signed.<p>The following KSK is now valid for .ORG<p>org. IN DNSKEY 257 3 7 (<br> AwEAAYpYfj3aaRzzkxWQqMdl7YExY81NdYSv+qayuZDo<br> dnZ9IMh0bwMcYaVUdzNAbVeJ8gd6jq1sR3VvP/SR36mm<br> GssbV4Udl5ORDtqiZP2TDNDHxEnKKTX+jWfytZeT7d3A<br> bSzBKC0v7uZrM6M2eoJnl6id66rEUmQC2p9DrrDg9F6t<br> XC9CD/zC7/y+BNNpiOdnM5DXk7HhZm7ra9E7ltL13h2m<br> x7kEgU8e6npJlCoXjraIBgUDthYs48W/sdTDLu7N59rj<br> CG+bpil+c8oZ9f7NR3qmSTpTP1m86RqUQnVErifrH8Kj<br> DqL+3wzUdF5ACkYwt1XhPVPU+wSIlzbaAQN49PU=<br> ) ; key id = 21366<p>Please note that due to the use of NSEC3 this key should not be used<br>with BIND versions less than 9.6.0.<p>Please refer to <a href="http://www.pir.org/dnssec">http://www.pir.org/dnssec</a> for more information.<p>As always, please report operational concerns with any Afilias-hosted<br>zone to <<a href="mailto:noc@afilias-nst.info">noc@afilias-nst.info</a>><p>dave<p>- --<br>Dave Knight<br>Director, Resolution Services<br>Afilias<p>PIR Technical Support<br>URL: <a href="http://www.pir.org">http://www.pir.org</a><br>E-mail: <a href="mailto:techsupport@pir.org">techsupport@pir.org</a><br>Phone: +1.416.646.3308<br>Fax: +1.416.646.3305<p>-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.4.8 (Darwin)<p>iEYEARECAAYFAkoljz8ACgkQVFeEx/p946ad1ACfRgX0xjsA19jEgv8FC5ol7CME<br>8qUAoOx39+ZB/GIQj0/qHPnAA843iVqa<br>=stCt<br>-----END PGP SIGNATURE-----Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-40306612314362379822009-05-27T15:44:00.001-07:002009-05-27T15:44:40.104-07:00[Fwd: [CAnet - news] Must read - radically new data transfer protocol - SNDTP]Cute...<p>-------- Original Message --------<br>Subject: [CAnet - news] Must read - radically new data transfer<br>protocol - SNDTP<br>Date: Wed, 27 May 2009 09:01:58 -0400<br>From: Bill St. Arnaud <<a href="mailto:bill.st.arnaud@canarie.ca">bill.st.arnaud@canarie.ca</a>><br>Reply-To: <a href="mailto:bill.st.arnaud@canarie.ca">bill.st.arnaud@canarie.ca</a><br>Organization: CANARIE Inc<br>To: <<a href="mailto:news@canarie.ca">news@canarie.ca</a>><p><p>For more information on this item please visit my blog at<p><a href="http://green-broadband.blogspot.com/">http://green-broadband.blogspot.com/</a> or <a href="http://billstarnaud.blogspot.com">http://billstarnaud.blogspot.com</a><p>-------------------------------------------<p><p><p><br> From International Science Grid Week<p><br> <a href="http://www.isgtw.org/?pid=1001810">http://www.isgtw.org/?pid=1001810</a><p>------------------------------------------------------------------------<p><<a href="http://www.isgtw.org/images/2009/Snail_L.jpg">http://www.isgtw.org/images/2009/Snail_L.jpg</a>><p>The snail-based system in feed-forward action. /Image courtesy Herbert<br>Bishko. Photo on front page courtesy Lysanne Ooteman, stock.exchng /<p>If you think you have problems with the sometimes slow pace at which<br>information travels from one computer to another, then consider the<br>solution offered by this scientific paper: "Snail-based Data Transfer<br>Protocol<br><<a href="http://improbable.com/pages/airchives/paperair/volume11/v11i4/sluggish-data-11-4.pdf">http://improbable.com/pages/airchives/paperair/volume11/v11i4/sluggish-data-11-4.pdf</a>>."<p>It describes an experiment in data transfer using real, genuine, live<br>snails, along with a "lettuce-based guidance system."<p>No lie.<p><br>The papers' authors, Shimon Schocken, dean of Efi Arazi School of<br>Computer Science <<a href="http://www.flatstories.com/arazi/arazi.htm">http://www.flatstories.com/arazi/arazi.htm</a>> Herzliya,<br>and Revital Ben-David-Zaslow of the Department of Zoology at Tel Aviv<br>University <<a href="http://www.tau.ac.il/lifesci/departments/zoology/">http://www.tau.ac.il/lifesci/departments/zoology/</a>>, Israel,<br>reported that their experiment delivered a 37 million bits-per-second<br><<a href="http://www.isgtw.org/?pid=1001622#B">http://www.isgtw.org/?pid=1001622#B</a>> data transfer rate — faster than ADSL.<p>[….]<p>The paper does admit to a drawback: "In some regions, most notably<br>France, culinary habits may pose a denial-of-service (DOS) problem."<p><p><p>-------------------------------------<p>To subscribe or unsubscribe send e-mail to <a href="mailto:bill.st.arnaud@canarie.ca">bill.st.arnaud@canarie.ca</a><br><mailto:<a href="mailto:bill.st.arnaud@canarie.ca">bill.st.arnaud@canarie.ca</a>><p><p>These news items and comments are mine alone and do not necessarily<br>reflect those of the CANARIE board or management<p>------<p><a href="mailto:Bill.St.Arnaud@gmail.com">Bill.St.Arnaud@gmail.com</a><p><a href="mailto:Bill@st-arnaud.org">Bill@st-arnaud.org</a><p><a href="http://billstarnaud.blogspot.com/">http://billstarnaud.blogspot.com/</a>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-79353258588548182402009-05-23T18:23:00.000-07:002009-05-23T18:24:32.716-07:00Fw: First Phone call over MP ArchitectureAnother first.
<br>
<br>It joins other greats like the first time linux booted or the first time samba shared a file.
<br>
<br>
<br>Sent via BlackBerry from T-Mobile
<br>
<br>-----Original Message-----
<br>From: David Rowe <<a href="mailto:david@rowetel.com">david@rowetel.com</a>>
<br>
<br>Date: Sun, 24 May 2009 06:34:47
<br>To: <<a href="mailto:village-telco-dev@googlegroups.com">village-telco-dev@googlegroups.com</a>>
<br>Subject: First Phone call over MP Architecture
<br>
<br>
<br>
<br>Hello,
<br>
<br>A few days ago we made the first phone call over the Mesh Potato
<br>Architecture - a mash up of various hardware components and drivers that
<br>are very close to the prototype Mesh Potato hardware:
<br>
<br><a href="http://www.villagetelco.org/2009/05/first-phone-call-on-mp-architecture/">http://www.villagetelco.org/2009/05/first-phone-call-on-mp-architecture/</a>
<br>
<br>We are due to start testing the first MP prototype in a few weeks.
<br>
<br>Cheers,
<br>
<br>David
<br>
<br>
<br>--
<br>Free Telephony Project
<br>open embedded IP-PBX hardware and software
<br><a href="http://www.rowetel.com/ucasterisk">http://www.rowetel.com/ucasterisk</a>
<br>
<br>
<br>--~--~---------~--~----~------------~-------~--~----~
<br>You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
<br>To post to this group, send email to <a href="mailto:village-telco-dev@googlegroups.com">village-telco-dev@googlegroups.com</a>
<br>To unsubscribe from this group, send email to <a href="mailto:village-telco-dev%2Bunsubscribe@googlegroups.com">village-telco-dev+unsubscribe@googlegroups.com</a>
<br>For more options, visit this group at <a href="http://groups.google.com/group/village-telco-dev?hl=en">http://groups.google.com/group/village-telco-dev?hl=en</a>
<br>-~----------~----~----~----~------~----~------~--~---Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-59830650223466205272009-05-22T10:57:00.001-07:002009-05-22T10:57:29.805-07:00[Fwd: Re: Local Peering and Transit - BGP multihoming]I love nanog!!!!<p>-------- Original Message --------<br>Subject: Re: Local Peering and Transit - BGP multihoming<br>Date: Fri, 22 May 2009 04:29:06 -0500<br>From: jamie rishaw <<a href="mailto:j@arpa.com">j@arpa.com</a>><br>To: Raymond Dijkxhoorn <<a href="mailto:raymond@prolocation.net">raymond@prolocation.net</a>><br>CC: ty chan <<a href="mailto:chanty_kh@yahoo.com">chanty_kh@yahoo.com</a>>, <a href="mailto:nanog@nanog.org">nanog@nanog.org</a><br>References: <br><1184640185-1242970936-cardhu_decombobulator_blackberry.rim.net-1583315332-@bxe1087.bisx.prod.on.blackberry> <br><<a href="mailto:537479.73764.qm@web52308.mail.re2.yahoo.com">537479.73764.qm@web52308.mail.re2.yahoo.com</a>> <br><<a href="mailto:alpine.LFD.2.00.0905221054480.12708@control.prolocation.net">alpine.LFD.2.00.0905221054480.12708@control.prolocation.net</a>> <br><<a href="mailto:20090522090033.GG25561@besserwisser.org">20090522090033.GG25561@besserwisser.org</a>> <br><<a href="mailto:alpine.LFD.2.00.0905221101060.12708@control.prolocation.net">alpine.LFD.2.00.0905221101060.12708@control.prolocation.net</a>><p>on issues like this :<p>[1] JFGI<br> -> if fail :<br>[2] man smartnet<br> -> if fail :<br>[3] go back to studying to get that A+ and consider perhaps a yob in redmond<p><p>On Fri, May 22, 2009 at 4:01 AM, Raymond Dijkxhoorn <<a href="mailto:raymond@prolocation.net">raymond@prolocation.net</a><br>> wrote:<p>> Hi!<br>><br>> Yes, i can get sample of configuration via Google search.<br>>>>> but i am looking for best practices and from experience people.<br>>>>><br>>>><br>> Then post your suggested config and ask for comments.<br>>>><br>>><br>> ...on a suitable list, dedicated to Cisco gear..<br>>><br>><br>> Sorry, yes. :-) Plenty of Cisco lists there to answer 'questions' :-)<br>><br>> Bye,<br>> Raymond.<br>><br>><p><br>-- <br>Jamie Rishaw // .com.arpa@j <- reverse it. ish.<br>[Impressive C-level Title Here], arpa / arpa labsAnonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-20753287505901504962009-05-18T10:40:00.000-07:002009-05-18T10:42:28.711-07:00[Fwd: Introducing Monitoring, Auto Scaling and Elastic Load Balancing for Amazon EC2]Is Rightscale and folks about to get squashed?<p>-------- Original Message --------<br>Subject: Introducing Monitoring, Auto Scaling and Elastic Load<br>Balancing for Amazon EC2<br>Date: Mon, 18 May 2009 01:14:24 -0700 (PDT)<br>From: Amazon Web Services <<a href="mailto:no-reply-aws@amazon.com">no-reply-aws@amazon.com</a>><br>To: <a href="mailto:charles@thewybles.com">charles@thewybles.com</a> <<a href="mailto:charles@thewybles.com">charles@thewybles.com</a>><p><p><<a href="http://www.amazon.com/gp/r.html?R=2RR2ERLLKZ3M3&C=395VUOR2S1USV&H=M3MNKZSLPIVG7WIBQJXBBSIEQYCA&T=C&U=http%3A%2F%2Faws.amazon.com">http://www.amazon.com/gp/r.html?R=2RR2ERLLKZ3M3&C=395VUOR2S1USV&H=M3MNKZSLPIVG7WIBQJXBBSIEQYCA&T=C&U=http%3A%2F%2Faws.amazon.com</a>><p>Dear Amazon Web Services Customer,<p>We are excited to announce the public beta of several new features for<br>the Amazon Elastic Compute Cloud (Amazon EC2): Amazon CloudWatch, a web<br>service for monitoring AWS cloud resources, Auto Scaling for<br>automatically growing and shrinking Amazon EC2 capacity based on demand,<br>and Elastic Load Balancing for distributing incoming traffic across<br>Amazon EC2 compute instances. Together, these capabilities provide you<br>with visibility into the health and usage of your AWS compute resources,<br>enhance application performance, and lower costs.<p>*Monitoring*<p>Amazon CloudWatch is a web service that provides monitoring for AWS<br>cloud resources, starting with Amazon EC2. It provides customers with<br>visibility into resource utilization, operational performance, and<br>overall demand patterns -- including metrics such as CPU utilization,<br>disk reads and writes, and network traffic. To use Amazon CloudWatch,<br>simply select the Amazon EC2 instances that you'd like to monitor;<br>within minutes, Amazon CloudWatch will begin aggregating and storing<br>monitoring data that can be accessed using web service APIs or Command<br>Line Tools.<p>*Auto Scaling*<p>Auto Scaling allows you to automatically scale your Amazon EC2 capacity<br>up or down according to conditions you define. With Auto Scaling, you<br>can ensure that the number of Amazon EC2 instances you're using scales<br>up seamlessly during demand spikes to maintain performance, and scales<br>down automatically during demand lulls to minimize costs. Auto Scaling<br>is particularly well suited for applications that experience hourly,<br>daily, or weekly variability in usage. Auto Scaling is enabled by Amazon<br>CloudWatch and available at no additional charge beyond Amazon<br>CloudWatch fees.<p>*Elastic Load Balancing*<p>Elastic Load Balancing automatically distributes incoming application<br>traffic across multiple Amazon EC2 instances. It enables you to achieve<br>even greater fault tolerance in your applications, seamlessly providing<br>the amount of load balancing capacity needed in response to incoming<br>application traffic. Elastic Load Balancing detects unhealthy instances<br>within a pool and automatically reroutes traffic to healthy instances<br>until the unhealthy instances have been restored. Customers can enable<br>Elastic Load Balancing within a single Availability Zone or across<br>multiple zones for even more consistent application performance.<p>Like all Amazon Web Services and features, Amazon CloudWatch and Elastic<br>Load Balancing are available on a pay-as-you-go basis with no up-front<br>fee, minimum spend or long term commitment. Auto Scaling is free to<br>Amazon CloudWatch customers. Each instance launched by Auto Scaling is<br>automatically enabled for monitoring and the Amazon CloudWatch<br>monitoring charge will be applied.<p>For more information on these new features and details on how to start<br>using them, please see the resources listed below:<p># Amazon EC2 Detail Page<br><<a href="http://www.amazon.com/gp/r.html?R=2RR2ERLLKZ3M3&C=395VUOR2S1USV&H=RX1EAAZNZHUTBZWKAYEKMO3OIDGA&T=C&U=http%3A%2F%2Faws.amazon.com%2Fec2">http://www.amazon.com/gp/r.html?R=2RR2ERLLKZ3M3&C=395VUOR2S1USV&H=RX1EAAZNZHUTBZWKAYEKMO3OIDGA&T=C&U=http%3A%2F%2Faws.amazon.com%2Fec2</a>> <p><br># Release Notes <a><p>These have been among the most requested Amazon EC2 features by our<br>customers. We hope they prove useful to you, and we look forward to your<br>feedback.<p>Sincerely,<p>The Amazon Web Services Team<p>We hope you enjoyed receiving this message. If you wish to remove<br>yourself from receiving future product announcements or the AWS<br>Newsletter, please update your communication preferences<br><<a href="http://www.amazon.com/gp/r.html?R=2RR2ERLLKZ3M3&C=395VUOR2S1USV&H=GNJTFPOACJ1D1N4NKAHWCNDKB2IA&T=C&U=https%3A%2F%2Faws-portal.amazon.com%2Fgp%2Faws%2Fdeveloper%2Faccount%2Findex.html%2F104-4543842-2170300%3Fie%3DUTF8%26action%3Dedit-communication-preferences">http://www.amazon.com/gp/r.html?R=2RR2ERLLKZ3M3&C=395VUOR2S1USV&H=GNJTFPOACJ1D1N4NKAHWCNDKB2IA&T=C&U=https%3A%2F%2Faws-portal.amazon.com%2Fgp%2Faws%2Fdeveloper%2Faccount%2Findex.html%2F104-4543842-2170300%3Fie%3DUTF8%26action%3Dedit-communication-preferences</a>>. <p><p>Amazon Web Services LLC is a subsidiary of Amazon.com, Inc. Amazon.com<br>is a registered trademark of Amazon.com, Inc. This message produced and<br>distributed by Amazon Web Services, LLC, 1200 12th Ave South, Seattle,<br>WA 98144.Anonymousnoreply@blogger.com2tag:blogger.com,1999:blog-21075211.post-41161415827757747042009-05-14T13:12:00.001-07:002009-05-14T13:12:14.144-07:00[Fwd: [SCCUG] Cisco Solution Design Clinic - May 27th at the LA Cisco Office]I'm going. Looks like a good seminar. Encourage folks to sign up.<p>-------- Original Message --------<br>Subject: [SCCUG] Cisco Solution Design Clinic - May 27th at the LA Cisco <br>Office<br>Date: Thu, 14 May 2009 02:02:44 -0000<br>From: <a href="mailto:ryee@bluespud.com">ryee@bluespud.com</a> <<a href="mailto:ryee@bluespud.com">ryee@bluespud.com</a>><br>Reply-To: <a href="mailto:SCCUG@yahoogroups.com">SCCUG@yahoogroups.com</a><br>To: <a href="mailto:SCCUG@yahoogroups.com">SCCUG@yahoogroups.com</a><p>Hi All,<p>I wanted to invite you to come down the to the Cisco office for a <br>Solution Design Clinic focused on Catalyst featues.<p>Topics will include:<p>Architectural Design – Best Practices<br>- Leverage existing infrastructure, high availability and resilient <br>design approach<br>- Planning and design before adding services to the network<br>- Virtual Switching System (CORE – VSS)<br>- Supervisor Engines – Stateful Switch Over and Non-Stop Forwarding <br>(SSO/NSF)<br>- Smart Call Home feature<br>- 802.11N / PoE<p>Optimize and Simplify<br>- Leverage Cisco Catalyst switching advanced features to manage, <br>optimize, and simplify network events<br>- Using Embedded Event Manager (EEM) features, scripting<br>- SmartPorts<br>- Security features<p>Operations Management<br>- Network management, monitoring and application performance visibility <br>and management<br>- IP SLA – application aware and network monitoring<br>- Rogue wireless access points – switchport tracing<p>If you would liketo attend, you can register here:<br><a href="http://www.cisco.com/pcgi-bin/sreg2/register/regdetail_private.pl?LANGUAGE=E&METHOD=E&TOPIC_CODE=10154&PRIORITY_CODE=165715_1">http://www.cisco.com/pcgi-bin/sreg2/register/regdetail_private.pl?LANGUAGE=E&METHOD=E&TOPIC_CODE=10154&PRIORITY_CODE=165715_1</a><p><p><p><br>------------------------------------<p>Web Site: <a href="http://www.sccug.org">http://www.sccug.org</a><br>Community email addresses:<br> Post message: <a href="mailto:SCCUG@onelist.com">SCCUG@onelist.com</a><br> Subscribe: <a href="mailto:SCCUG-subscribe@onelist.com">SCCUG-subscribe@onelist.com</a><br> Unsubscribe: <a href="mailto:SCCUG-unsubscribe@onelist.com">SCCUG-unsubscribe@onelist.com</a><br> List owner: <a href="mailto:SCCUG-owner@onelist.com">SCCUG-owner@onelist.com</a><p>Shortcut URL to this page:<br> <a href="http://www.onelist.com/community/SCCUGYahoo">http://www.onelist.com/community/SCCUGYahoo</a>! Groups Links<p><*> To visit your group on the web, go to:<br> <a href="http://groups.yahoo.com/group/SCCUG/">http://groups.yahoo.com/group/SCCUG/</a><p><*> Your email settings:<br> Individual Email | Traditional<p><*> To change settings online go to:<br> <a href="http://groups.yahoo.com/group/SCCUG/join">http://groups.yahoo.com/group/SCCUG/join</a><br> (Yahoo! ID required)<p><*> To change settings via email:<br> mailto:<a href="mailto:SCCUG-digest@yahoogroups.com">SCCUG-digest@yahoogroups.com</a><br> mailto:<a href="mailto:SCCUG-fullfeatured@yahoogroups.com">SCCUG-fullfeatured@yahoogroups.com</a><p><*> To unsubscribe from this group, send an email to:<br> <a href="mailto:SCCUG-unsubscribe@yahoogroups.com">SCCUG-unsubscribe@yahoogroups.com</a><p><*> Your use of Yahoo! Groups is subject to:<br> <a href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-42079117440982825532009-05-14T13:11:00.001-07:002009-05-14T13:11:28.031-07:00[Fwd: IEEE, OCEN, 5-30 Event, Stimulus Money...]FYI<p>I'm signed up and plan to go. Looks interesting. Two stimulus seminars <br>in one month! :)<p>-------- Original Message --------<br>Subject: IEEE, OCEN, 5-30 Event, Stimulus Money...<br>Date: Sun, 3 May 2009 20:45:38 -0700<br>From: Dan Noël <<a href="mailto:Dan.Noel@ieee.org">Dan.Noel@ieee.org</a>><br>To: Dan Noel <<a href="mailto:dan.uu.noel@earthlink.net">dan.uu.noel@earthlink.net</a>><p><p>Dear OCEN member or supporter:<p>Do you have a *promising technical idea*? Would you like to develop it?<br>Are you *worried about financing*? What if the U.S. government's<br>*economic stimulus* was right there for you to pick off?<p><br> *If you like these ideas, here it is:*<p> * *What*: *Accessing Government Stimulus Funding..."Show me the<br> Money!"* presentations and Q&A's<br> * *Who*: a panel of experts<br> * *When*: Saturday 5-30, from 8:30 a.m. to 12 noon<br> * *Organized by*: IEEE's Orange County's Entrepreneurs' Network<br> * *Sponsored by*: Knobbe, Martens, Olson & Bear; IEEE's Orange<br> County Consultants' Network; IEEE's Los Angeles Area Consultants'<br> Network<br> * *Where*: Irvine, near the 405 and McArthur<br> * *Cost*: $15 on the web, $25 at the door<br> * *Registration & Details*: conveniently, on the web, at<br> <a href="https://www.123signup.com/event?id=zrryg">https://www.123signup.com/event?id=zrryg</a><p><br> *Program Description:*<p>The IEEE's Orange County Entrepreneurs' Network (OCEN) presents a panel<br>of experts who will review, for a *full 3 hours*, the *$789 Billion<br>*Government Stimulus Package intended to rebuild the U.S. economy and<br>attain national self-sufficiency and leadership in *renewable energy*.<br>Presentations will clarify funding available to scientists, engineers,<br>and entrepreneurs and provide *practical tips* to explore the websites<br>relevant to budding entrepreneurs. Several *interactive Q&A* sessions<br>will provide you with an opportunity to satisfy *your specific needs*.<p><br> *Expert Panel:*<p> * *Paul Donahue*: inventor, serial business grower, green entrepreneur<br> * *Ron Oglevie*: serial new hi-tech business grower and serial SBIR<br> [U.S. government process to fund hi-tech start-ups] contract winner<br> * *Perry Oldham*: sharp patent attorney with Knobbe, Martens, Olson<br> & Bear<br> * *Dennis Wonica*: serial entrepreneur, technical guru, Defense<br> contracting expert<p><br> *Schedule:*<p>8:30 a.m. –registration and informal contacts<br>9:00 a.m. –presentations and Q&A's<br>12 noon –end<p><p>Dan Noël<br>OCEN secretary<p><p>You are receiving this Email for being on IEEE-OCEN's list; should you<br>wish to stop receiving Emails from OCEN, reply to this Email and write<br>"unsubscribe" in the subject line.Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-21075211.post-13236978543358229152009-05-14T10:36:00.001-07:002009-05-14T10:36:26.427-07:00[Fwd: Re: RE: delays to google]When you don't pay good salaries to your operations people you get sub <br>standard personnel. :)<p>They had it coming to em. Google has made several networking mistakes <br>over the past couple of years.<p>Hire some people who know what they are doing already! Oh what's that? <br>You don't want to pay them what they are worth? Oh ok. Don't then.<p><p>-------- Original Message --------<br>Subject: Re: RE: delays to google<br>Date: Thu, 14 May 2009 17:21:38 +0000<br>From: <a href="mailto:A2thaH@gmail.com">A2thaH@gmail.com</a><br>To: <a href="mailto:nanog@merit.edu">nanog@merit.edu</a><p>Google ack'da maintenance on their core network did not go as<br>planned-Forced traffic to one peer link that was unable to handle all the<br>traffic. Maintenance has been rolled back. Issue has been restored,<p>-Adam<p>On May 14, 2009 12:44pm, "Mullins, Douglas" <<a href="mailto:dmullins@covad.com">dmullins@covad.com</a>> wrote:<br>> conficker?<p><p><p>> Doug<p><p><p><p><br>> -----Original Message-----<p><br>> From: Patrick Darden [mailto:<a href="mailto:darden@armc.org">darden@armc.org</a>]<p><br>> Sent: Thursday, May 14, 2009 12:13 PM<p><br>> To: <a href="mailto:nanog@merit.edu">nanog@merit.edu</a><p><br>> Subject: Re: delays to google<p><p><p><p><br>> Fixed?<p><p><p>> 5 mins ago:<p><br>> 1 <a href="http://gw1.armc.org">gw1.armc.org</a> (68.153.29.1) 0.571 ms 0.705 ms 0.732 ms<p><br>> 2 65.14.131.185 (65.14.131.185) 2.330 ms 2.318 ms 2.308 ms<p><br>> 3 <a href="http://axr00mia-7-0-0-0.bellsouth.net">axr00mia-7-0-0-0.bellsouth.net</a> (65.83.237.92) 3.009 ms 3.001 ms 3.080<p><br>> ms<p><br>> 4 <a href="http://AXR00AEP-0-1-0.bellsouth.net">AXR00AEP-0-1-0.bellsouth.net</a> (65.83.236.50) 2.384 ms 2.370 ms 2.499 ms<p><br>> 5 65.83.238.202 (65.83.238.202) 3.148 ms 3.136 ms *<p><br>> 6 <a href="http://cr1.attga.ip.att.net">cr1.attga.ip.att.net</a> (12.122.141.22) 4.011 ms 3.769 ms 4.106 ms<p><br>> 7 12.123.22.5 (12.123.22.5) 3.735 ms 3.042 ms 3.033 ms<p><br>> 8 * * *<p><br>> 9 72.14.233.56 (72.14.233.56) 159.416 ms * *<p><br>> 10 72.14.232.213 (72.14.232.213) 163.622 ms 209.85.254.241<p><br>> (209.85.254.241) 165.287 ms 209.85.254.243 (209.85.254.243) 219.136 ms<p><br>> 11 209.85.254.6 (209.85.254.6) 170.937 ms 171.154 ms 209.85.254.10<p><br>> (209.85.254.10) 169.944 ms<p><br>> 12 * * *<p><br>> 13 * * *<p><br>> 14 * * *<p><br>> 15 * * *<p><br>> 16 * * *<p><br>> 17 * * *<p><br>> 18 * * *<p><br>> 19 * * *<p><br>> 20 * * *<p><br>> 21 * * *<p><br>> 22 * * *<p><br>> 23 * * *<p><br>> 24 * * *<p><br>> 25 * * *<p><br>> 26 * * *<p><br>> 27 * * *<p><br>> 28 * * *<p><br>> 29 * * *<p><br>> 30 * * *<p><p><p><p><br>> Now (12:11 eastern)<p><br>> [root@inetsec ~]# traceroute <a href="http://www.google.com">www.google.com</a><p><br>> traceroute to <a href="http://www.google.com">www.google.com</a> (74.125.65.99), 30 hops max, 60 byte<p><br>> packets<p><br>> 1 <a href="http://gw1.armc.org">gw1.armc.org</a> (68.153.29.1) 0.760 ms 0.884 ms 0.908 ms<p><br>> 2 65.14.131.185 (65.14.131.185) 2.345 ms 2.342 ms 3.132 ms<p><br>> 3 <a href="http://axr01asm-7-1-0-1.bellsouth.net">axr01asm-7-1-0-1.bellsouth.net</a> (65.83.237.90) 3.338 ms 3.331 ms 3.322<p><br>> ms<p><br>> 4 <a href="http://axr00msy-0-3-1.bellsouth.net">axr00msy-0-3-1.bellsouth.net</a> (65.83.236.46) 3.112 ms 3.105 ms 3.095 ms<p><br>> 5 65.83.238.202 (65.83.238.202) 3.503 ms 3.654 ms *<p><br>> 6 <a href="http://cr2.attga.ip.att.net">cr2.attga.ip.att.net</a> (12.122.140.22) 4.489 ms 3.823 ms 3.795 ms<p><br>> 7 12.123.22.129 (12.123.22.129) 3.591 ms 3.094 ms 3.079 ms<p><br>> 8 12.88.97.6 (12.88.97.6) 3.197 ms 3.172 ms 3.160 ms<p><br>> 9 72.14.233.56 (72.14.233.56) 3.322 ms 3.490 ms 72.14.233.54<p><br>> (72.14.233.54) 3.510 ms<p><br>> 10 209.85.254.249 (209.85.254.249) 16.887 ms 3.501 ms 72.14.239.127<p><br>> (72.14.239.127) 4.261 ms<p><br>> 11 209.85.253.214 (209.85.253.214) 12.987 ms 12.979 ms 209.85.253.218<p><br>> (209.85.253.218) 3.882 ms<p><br>> 12 <a href="http://gx-in-f99.google.com">gx-in-f99.google.com</a> (74.125.65.99) 4.357 ms 4.740 ms 4.481 ms<p><p><p><p><br>> --Patrick DardenAnonymousnoreply@blogger.com0