Re: [58crew] RE: IETF58 - Network Status
>> basic lessons previously learned were not put to use here, e.g., lowering >> the radios so wetware limits range and reduces xmtrs bandwidth fight. > Right. Like this really works. This just ensures that the folks in the > middle of the room will get really bad performance. Been there. the opposite. it allows us to put xmtrs in the middle of the room without contending with others. randy
Notes from this week's Plenaries
These are my preliminary notes from the Plenaries - neither official nor complete. Please send me corrections and misattributions! Thanks, Spencer Wednesday Night Plenary * Welcome - Harald and Leslie Doing different split than usual - report Wednesday, listen Thursday Attendance - smallest IETF since 1997, 1211 attendees far fewer countries than Vienna - 29 vs 40 severe visa problems for many contributors 256 companies Kudos for the NOC who chased down ad hoc nodes Next meeting in Korea, hosted by Samsung, organized by KIEF, Feb 28-March 5 Summer and Fall likely back in the US RFCs 3550-3645, DHCPv6, Diameter, Draft RTP, Security Considerations, many SIP documents, many others Finances don't look good, real income from meetings significantly lower than budgeted Secretariat staffing was reduced - less room for projects * Advisory Committee (ADVCOMM) Report - Leslie Daigle - IAB publishing documents - looking for input on Congestion Control for Voice Traffic, Internet Research and Evolution published RFC 3639, Security Mechanisms for the Internet, ISOC BoT Appointment Procedures - ICANN commentary on VeriSign wildcarding in .com/.net - Tony Hain appeal response Available on IAB website, IAB upheld IESG upholding AD upholding WG chairs... - IANA Report - John Crane Michelle is especially productive (headed for maternity leave) Have hired general manager at IANA and added staff New registry matrix available next week Testing workflow software Doug Barton joining IANA from Yahoo! - RFC Editor Report - Joyce Reynolds Mark Crispin - can I have nroff source back? Yes, and we are also accepting XML - don't start over! Charles Perkins - corresponding author for I-Ds approved for publication? People change jobs, or just disappear - what to do? Some authors have been removed by ADs because we can't find them - IRTF Update - Vern Paxson rch - energy and work moving to GGF ASRG - may have reverse MX ready for IETF - Paul Judge stepping down, replaced by John Levine DTNRG - coupling ad hoc IP routing and DTN store-and-forward, documents ready for publication GSEC - still meeting IMRG - bandwidth estimation workshop coming up in December, designing protocols to aid measurement, packet sampling NMRG - SMIng publishing as Experimental NSRG - closing P2P - kicking off SIREN - stalled for problem statement SMRG - actively seeking members and topics RRG - new chair, Avri Doria, routing requirements draft MOBOPTS - from Vienna, research MIP counterpart Topics - loc-id split, DDOS defenses, network intrusion detection, security mechanism evaluation/testing - please send feedback to [EMAIL PROTECTED] Melinda Shore - CFRG? didn't file summary, so don't have report, but still out there - NOMCOM - Rich Draves Watch your mail for incoming questionnaires... Still looking for nominations (noon deadline on Friday) [EMAIL PROTECTED], office hours at this meeting * Advcomm Report - Leslie Daigle participants were IETF-experienced, especially aware of the oral history of the IETF for data gathering part of the task 00 draft will be published after these plenaries, followed by final report and recommendations expect to shut down by mid-December this is NOT the reorganization effort, or the standards track change effort important support organizations aren't familiar to participants - CNRI, Foretec, USC/ISI, ICANN stress points - - informal - oral heritage of procedures and knowledge - institutional records stored across multiple organizations - manual labor and lack of coordination - negative trends in meeting attendence, hence revenue for IETF Top-down requirements, some currently met - stewardship - accountability, persistence and accessibility of records - resource management - clarity in relationships, budgetary autonomy and unity, flexibility in service provisioning, admistrative efficiency - working environment - minimal overhead and volunteer effort as our heritage, but maybe need service automation, tools Recommendations - administrative structure changes are required - IETF organization should be formalized Next Steps - report, wrap up ADVCOMM, collect comments Harald and Leslie Conclusions - IETF legal existence is irregular - good work by fellow travelers - not easy to get all this right - need to make it easier to get work done - proposing IETF and IAB chairs to run the process with support - is this OK? Scott Bradner - fuzzy "when appropriate" is fuzzy - can you clarify? - either do it at the plenary or fess up at a plenary - can't wait for a plenary for every decision, especially for detailed legal discussions - do we have the right level of accountability? - last call process used where appropriate Bob Hinden - generally supportive - need periodic status reports - not just a last call Pete Resnick - "fellow trave
Re: IETF58 - Network Status
> We also had the new overly "helpful" operating systems and a variety of > infected machines eating bandwidth. How depressing. Does anybody have any good estimate on what % of machines were infected with one or more of the usual standard-equipment pieces of bandwidth-sucking malware? It's sad that at an IETF this is a problem, "preaching to the choir" and all that. On the other hand, it's not an IETF-only problem. I was at a SANS class we were hosting a few months ago on using tcpdump. So just for grins, I set up a little tcpdump script, and after about 2 hours, right before the lunch break, I announced "We have some 280 people in this lecture hall, and so far I've seen 97 MAC addresses on the wireless talking to POP-over-SSL on port 995, and 80 or so talking cleartext POP". Some guy in the back of the room asked if I was grabbing passwords, and I told him "I'm a white hat. I was gathering *only* SYN packets for statistical purposes. I have *no* idea what anybody *else* in this 100,000 square foot building was grabbing out of the air". It was pretty easy to identify the 80 or so then... all "deer in headlights" and tapping at keyboards furiously.. :) pgp0.pgp Description: PGP signature
Re: IETF58 - Network Status
On Thu, Nov 13, 2003 at 09:33:30PM -0500, Andrew Partan wrote: > > Another suggestion - it would have been real useful if the software > on my laptop could have been told to ignore some APs (or some other > laptops pretending to be APs), or to only listen to this other set > of APs. White/black listing of APs... On Linux machines, as root type the command: iwconfig eth1 ap 00:0C:30:1A:69:A2 To force the access point to be 00:0c:30:1A:69:A2 I don't know if there's a way to make this work for those cards where the ap selection is done in firmware. - Ted
RE: IETF58 - Network Status
I would have agreed with you until I just bounced onto the aodv network - oh well Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Hoffman / IMC Sent: Thursday, November 13, 2003 6:23 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: IETF58 - Network Status Sitting in the Thursday plenary, I note none of the network-to-ad-hoc flappage that have been plaguing us the past few days. Did the attackers get bored and go home? Did the accidental ad-hocers finally get their settings right? Did someone deploy a good blocking mechanism? --Paul Hoffman, Director --Internet Mail Consortium
Re: IETF58 - Network Status
-BEGIN PGP SIGNED MESSAGE-
> "IMC" == IMC writes:
IMC> Sitting in the Thursday plenary, I note none of the network-to-ad-hoc
IMC> flappage that have been plaguing us the past few days.
IMC> Did the attackers get bored and go home?
No, you are just sitting in the wrong part of the room.
But, it is much better than it was at SAAG.
] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy"); [
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBP7REQIqHRg3pndX9AQFYUQQA76jiRGOZNwSfJV4J668xMKAQ9f9ORnbK
YcZb3mELHP6WL6Qr2hpwwZnHgjiwSUSMXWZ7xW50OJSOL0RXUgTkpaKaJOy80EzG
lM/Ta4uu4ze/E8xuDxuoHjoJtREUMeC/W4g/O/LTy5sZMAhB6k3sebtXTWW3Hjkj
WTDwhNp7aFo=
=ERVG
-END PGP SIGNATURE-
Re: IETF58 - Network Status
On 13-nov-03, at 16:44, Carsten Bormann wrote: it turned out that when I replaced my Linksys 802.11b with a brand new Motorola 802.11g the problem went away; there is a Radio Shark on the third floor of City Center that sells them for $70. Similarly, when I put a $70 Linksys WPC54G (directly supported by Mac OS X 10.2.8) into my Powerbook to override the builtin (Lucent-made) Airport card, and switched on "Interference Robustness", I got much more consistent network access. I'm still losing network access now and then, and my TCP connections mysteriously wedge sooner or later, but I'm functional. Hm, I've only really lost connectivity a few times but I did suffer from hanging TCP sessions fairly consistently when sending somewhat large amounts of data at some times in some rooms. But in those cases the packet loss was double and the RTTs to the first router triple digits. This is with a week old Powerbook with built-in 802.11g.
Re: IETF58 - Network Status
On Thu, Nov 13, 2003 at 07:57:33PM -0600, Harald Tveit Alvestrand wrote: > so rather than worrying, let's see what we can do to help > > if someone - for instance - has EFFECTIVE tools for triangulating and > locating ad-hoc stations, perhaps they can bring them to the next IETF > meeting? Another suggestion - it would have been real useful if the software on my laptop could have been told to ignore some APs (or some other laptops pretending to be APs), or to only listen to this other set of APs. White/black listing of APs... --asp
Re: IETF58 - Network Status
In message <[EMAIL PROTECTED]>, Randy Bush writes: >basic lessons previously learned were not put to use here, e.g., lowering >the radios so wetware limits range and reduces xmtrs bandwidth fight. > We also had the new overly "helpful" operating systems and a variety of infected machines eating bandwidth. --Steve Bellovin, http://www.research.att.com/~smb
RE: IETF58 - Network Status
Sitting in the Thursday plenary, I note none of the network-to-ad-hoc flappage that have been plaguing us the past few days. Did the attackers get bored and go home? Did the accidental ad-hocers finally get their settings right? Did someone deploy a good blocking mechanism? --Paul Hoffman, Director --Internet Mail Consortium
RE: IETF58 - Network Status
basic lessons previously learned were not put to use here, e.g., lowering the radios so wetware limits range and reduces xmtrs bandwidth fight. randy
RE: IETF58 - Network Status
--On 13. november 2003 21:46 +0200 "Romascanu, Dan (Dan)" <[EMAIL PROTECTED]> wrote: Yes, this looks to affect some models of cards and drivers more than other. Unfortunately, I fell this time in the unlucky category. The same model of card, driver, and OS that worked perfectly for many in many other similar events, including the last three or four IETF meetings made my work impossible this whole week with the wireless setting at this IETF network. On this respect this was - for me - by far the worst IETF since I am using wireless connectivity. Sorry guys. not been around long? I remember one of the earlier Washington IETFs a LOT fewer laptops, but even bigger problems. And that even without the misbehaviour seen today. we're living on the bleeding edge, and this time it seems we're bleeding more than usual, thanks to some problems we still don't understand fully. so rather than worrying, let's see what we can do to help if someone - for instance - has EFFECTIVE tools for triangulating and locating ad-hoc stations, perhaps they can bring them to the next IETF meeting? hARALD
Re: IETF58 - Network Status
You can probably find that info at http://personaltelco.net although I'm not sure you will be able to take advantage of the Prism2 chipset AP fuctions avialable using 80211b. Scott On Thu, 13 Nov 2003, Simon Leinen wrote: > Randy Bush writes: > >> Note that getting 802.11a works even better. > > until everybody does, and 'everbody' is twice > > as many people as now > > I think 802.11a should be able to support more than twice as many > users than 802.11b. At least in the US, the band reserved for 802.11a > has more channels available than the one for 802.11b, in particular > more non-overlapping channels. For this reason, and because of the > lack of competition from 802.11b users, 802.11a should also support > more users than 802.11g (54 Mb/s in the 2.4 GHz band). So for > settings such as IETF/NANOG etc. this seems very attractive. > > If someone knows which 802.11a PCMCIA card can be made to work reliably > under Linux (with 2.6 kernel!), I'd really like to hear about it... > -- > Simon. > > sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/
Re: [58crew] RE: IETF58 - Network Status
Brett, It would be great if you could publish all the issues that came up, how you fixed them, and a brief overview of what you deployed (at the start and end) for the event. Tim On Thu, Nov 13, 2003 at 06:50:11PM -0500, Brett Thorson wrote: > On Thursday 13 November 2003 14:46, Romascanu, Dan (Dan) wrote: > > Yes, this looks to affect some models of cards and drivers more than other. > > Unfortunately, I fell this time in the unlucky category. The same model of > > card, driver, and OS that worked perfectly for many in many other similar > > events, including the last three or four IETF meetings made my work > > impossible this whole week with the wireless setting at this IETF network. > > On this respect this was - for me - by far the worst IETF since I am using > > wireless connectivity. Sorry guys. > > The only thing thing you have to be sorry for is not coming to us sooner. If > you had come to us sooner, we could have been able to solve some of your > problems or fix it all together. > > We hope that by working together to solve these problems we can help you out. > I have heard many comments from many people that this has been a great > wireless IETF. We identified several client problems, and we saw a larger > number of infected machines. If the wireless did suffer (which I don't think > it did because of our volunteer team who worked VERY hard and configuring it) > it was due to problems simply beyond our control. > > And as always, we are happy to take in more volunteers. If there is something > you don't like, hop on board and solve the problems! > > Cheers, and I hope to hear more from you, in realtime next time these issues > pop up. > > --Brett > > > > Dan > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > Behalf Of Roland Bless > > > Sent: 13 November, 2003 7:08 PM > > > To: Randall Gellens > > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > > Subject: Re: IETF58 - Network Status > > > > > > > > > Hi Randall, > > > > > > > I have been consistently unable to maintain a connection for more > > > > than a very few minutes, usually not even long enough to > > > > > > establish a > > > > > > > VPN tunnel and fetch one message. The 802.11 coverage comes and > > > > goes; the APs seem to vanish and I see nothing for a while, > > > > eventually the network comes back but only briefly. This has been > > > > > > I can partly confirm your observations, since > > > I often see my driver reporting a signal strength of 0 for seconds. > > > The connection is somehow unstable as my log also reports > > > (NSIS meeting this morning, actually not crowded) > > > Nov 13 10:41:01 kernel: eth1: New link status: AP In Range (0005) > > > Nov 13 10:41:03 kernel: eth1: New link status: AP Changed (0003) > > > Nov 13 10:41:25 kernel: eth1: New link status: AP Out of Range (0004) > > > Nov 13 10:41:26 kernel: eth1: New link status: AP In Range (0005) > > > Nov 13 10:42:58 kernel: eth1: New link status: AP Changed (0003) > > > Nov 13 10:45:18 kernel: eth1: New link status: AP Out of Range (0004) > > > Nov 13 10:45:18 kernel: eth1: New link status: AP In Range (0005) > > > Nov 13 10:45:18 kernel: eth1: New link status: AP Changed (0003) > > > Nov 13 10:45:23 kernel: eth1: New link status: AP Out of Range (0004) > > > Nov 13 10:45:24 kernel: eth1: New link status: AP In Range (0005) > > > Nov 13 10:45:54 kernel: eth1: New link status: AP Changed (0003) > > > Nov 13 10:46:28 kernel: eth1: New link status: AP Out of Range (0004) > > > Nov 13 10:46:28 kernel: eth1: New link status: AP In Range (0005) > > > ... and so on... > > > however, it seems also to depend on the cards firmware and driver, > > > so other people may have no problems at all... > > > Inspite all the problems, it works well enough to get things > > > actually done. > > > > > > > the case in every session I've attended, as well as tonight's > > > > plenary. It doesn't seem to matter if the room is crowded > > > > > > or empty, > > > > > > > or where I sit. > > > > > > > > I have attempted to only select the 'ietf58' network, but often the > > > > network vanishes and there are no networks visible; other times the > > > > only visible "network" is an ad-hoc calling itself 'ietf58'. > > > > > > I wasn't often successful to reattach to APs after my card was > > > "hi-jacked" to ad-hoc cards announcing ietf58. Setting the > > > essid again to the same value seems to do trick, however, > > > often I see signals of strength 0 (maybe the card is confused then..). > > > Furthermore, it happens often that I don't get an IPv6 address > > > directly after activating the card (maybe the RA doesn't get through). > > > > > > Cheers, > > > Roland > > > > ___ > > 56crew mailing list > > [EMAIL PROTECTED] > > https://www1.ietf.org/mailman/listinfo/56crew >
Re: [58crew] RE: IETF58 - Network Status
On Thursday 13 November 2003 14:46, Romascanu, Dan (Dan) wrote: > Yes, this looks to affect some models of cards and drivers more than other. > Unfortunately, I fell this time in the unlucky category. The same model of > card, driver, and OS that worked perfectly for many in many other similar > events, including the last three or four IETF meetings made my work > impossible this whole week with the wireless setting at this IETF network. > On this respect this was - for me - by far the worst IETF since I am using > wireless connectivity. Sorry guys. The only thing thing you have to be sorry for is not coming to us sooner. If you had come to us sooner, we could have been able to solve some of your problems or fix it all together. We hope that by working together to solve these problems we can help you out. I have heard many comments from many people that this has been a great wireless IETF. We identified several client problems, and we saw a larger number of infected machines. If the wireless did suffer (which I don't think it did because of our volunteer team who worked VERY hard and configuring it) it was due to problems simply beyond our control. And as always, we are happy to take in more volunteers. If there is something you don't like, hop on board and solve the problems! Cheers, and I hope to hear more from you, in realtime next time these issues pop up. --Brett > > Dan > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of Roland Bless > > Sent: 13 November, 2003 7:08 PM > > To: Randall Gellens > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Re: IETF58 - Network Status > > > > > > Hi Randall, > > > > > I have been consistently unable to maintain a connection for more > > > than a very few minutes, usually not even long enough to > > > > establish a > > > > > VPN tunnel and fetch one message. The 802.11 coverage comes and > > > goes; the APs seem to vanish and I see nothing for a while, > > > eventually the network comes back but only briefly. This has been > > > > I can partly confirm your observations, since > > I often see my driver reporting a signal strength of 0 for seconds. > > The connection is somehow unstable as my log also reports > > (NSIS meeting this morning, actually not crowded) > > Nov 13 10:41:01 kernel: eth1: New link status: AP In Range (0005) > > Nov 13 10:41:03 kernel: eth1: New link status: AP Changed (0003) > > Nov 13 10:41:25 kernel: eth1: New link status: AP Out of Range (0004) > > Nov 13 10:41:26 kernel: eth1: New link status: AP In Range (0005) > > Nov 13 10:42:58 kernel: eth1: New link status: AP Changed (0003) > > Nov 13 10:45:18 kernel: eth1: New link status: AP Out of Range (0004) > > Nov 13 10:45:18 kernel: eth1: New link status: AP In Range (0005) > > Nov 13 10:45:18 kernel: eth1: New link status: AP Changed (0003) > > Nov 13 10:45:23 kernel: eth1: New link status: AP Out of Range (0004) > > Nov 13 10:45:24 kernel: eth1: New link status: AP In Range (0005) > > Nov 13 10:45:54 kernel: eth1: New link status: AP Changed (0003) > > Nov 13 10:46:28 kernel: eth1: New link status: AP Out of Range (0004) > > Nov 13 10:46:28 kernel: eth1: New link status: AP In Range (0005) > > ... and so on... > > however, it seems also to depend on the cards firmware and driver, > > so other people may have no problems at all... > > Inspite all the problems, it works well enough to get things > > actually done. > > > > > the case in every session I've attended, as well as tonight's > > > plenary. It doesn't seem to matter if the room is crowded > > > > or empty, > > > > > or where I sit. > > > > > > I have attempted to only select the 'ietf58' network, but often the > > > network vanishes and there are no networks visible; other times the > > > only visible "network" is an ad-hoc calling itself 'ietf58'. > > > > I wasn't often successful to reattach to APs after my card was > > "hi-jacked" to ad-hoc cards announcing ietf58. Setting the > > essid again to the same value seems to do trick, however, > > often I see signals of strength 0 (maybe the card is confused then..). > > Furthermore, it happens often that I don't get an IPv6 address > > directly after activating the card (maybe the RA doesn't get through). > > > > Cheers, > > Roland > > ___ > 56crew mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/56crew
Re: IETF58 - Network Status
Simon Leinen wrote: If someone knows which 802.11a PCMCIA card can be made to work reliably under Linux (with 2.6 kernel!), I'd really like to hear about it... Atheros released open-source linux drivers for their chips and the corresponding reference design. I don't know which cards use the Atheros chipset, other than ours.
Re: IETF58 - Network Status
it turned out that when I replaced my Linksys 802.11b with a brand new Motorola 802.11g the problem went away; there is a Radio Shark on the third floor of City Center that sells them for $70. Similarly, when I put a $70 Linksys WPC54G (directly supported by Mac OS X 10.2.8) into my Powerbook to override the builtin (Lucent-made) Airport card, and switched on "Interference Robustness", I got much more consistent network access. I'm still losing network access now and then, and my TCP connections mysteriously wedge sooner or later, but I'm functional. I would suspect that most people complaining are using the time-tested Lucent/Orinoco card, which is now getting a bit old. It sure makes sense to have a deck of cards available if you really need the Wi-Fi. Gruesse, Carsten
Re: IETF58 - Network Status
Randy Bush writes: >> Note that getting 802.11a works even better. > until everybody does, and 'everbody' is twice > as many people as now I think 802.11a should be able to support more than twice as many users than 802.11b. At least in the US, the band reserved for 802.11a has more channels available than the one for 802.11b, in particular more non-overlapping channels. For this reason, and because of the lack of competition from 802.11b users, 802.11a should also support more users than 802.11g (54 Mb/s in the 2.4 GHz band). So for settings such as IETF/NANOG etc. this seems very attractive. If someone knows which 802.11a PCMCIA card can be made to work reliably under Linux (with 2.6 kernel!), I'd really like to hear about it... -- Simon.
Re: IETF58 - Network Status
Joel Jaeggli <[EMAIL PROTECTED]> writes: > the map coloring problem is a lot easier with 8 non-overlaping channels. And indeed, it isn't even possible with just three. Perry
Re: IETF58 - Network Status
the map coloring problem is a lot easier with 8 non-overlaping channels. joelja On Thu, 13 Nov 2003, Randy Bush wrote: > > Note that getting 802.11a works even better. > > until everybody does, and 'everbody' is twice > as many people as now > > -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: IETF58 - Network Status
> Note that getting 802.11a works even better. until everybody does, and 'everbody' is twice as many people as now
Re: IETF58 - Network Status
Joel Jaeggli wrote: this is partially a product of your driver and it's user-interface... if you can really truely statically configure your adhesion to managed network it will work better. I don't know. I can configure my linux card to be in managed mode on ssid ietf58, but that seems to mainly achieve the situation where I don't hear any APs whatsoever. From where I sit, it looks like the APs just disappear. This could of course also be an issue with my drivers getting confused about the many other APs appearing and disappearing -- but can someone confirm that the official APs are up and running and are not crashing? Anyway, I don't want us to organize a witch hunt for the poor folks who forgot to turn of ad-hoc mode in their machines. The protocols and products should work better than this, imho. --Jari
RE: IETF58 - Network Status
Yes, this looks to affect some models of cards and drivers more than other. Unfortunately, I fell this time in the unlucky category. The same model of card, driver, and OS that worked perfectly for many in many other similar events, including the last three or four IETF meetings made my work impossible this whole week with the wireless setting at this IETF network. On this respect this was - for me - by far the worst IETF since I am using wireless connectivity. Sorry guys. Dan > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Roland Bless > Sent: 13 November, 2003 7:08 PM > To: Randall Gellens > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: IETF58 - Network Status > > > Hi Randall, > > > I have been consistently unable to maintain a connection for more > > than a very few minutes, usually not even long enough to > establish a > > VPN tunnel and fetch one message. The 802.11 coverage comes and > > goes; the APs seem to vanish and I see nothing for a while, > > eventually the network comes back but only briefly. This has been > > I can partly confirm your observations, since > I often see my driver reporting a signal strength of 0 for seconds. > The connection is somehow unstable as my log also reports > (NSIS meeting this morning, actually not crowded) > Nov 13 10:41:01 kernel: eth1: New link status: AP In Range (0005) > Nov 13 10:41:03 kernel: eth1: New link status: AP Changed (0003) > Nov 13 10:41:25 kernel: eth1: New link status: AP Out of Range (0004) > Nov 13 10:41:26 kernel: eth1: New link status: AP In Range (0005) > Nov 13 10:42:58 kernel: eth1: New link status: AP Changed (0003) > Nov 13 10:45:18 kernel: eth1: New link status: AP Out of Range (0004) > Nov 13 10:45:18 kernel: eth1: New link status: AP In Range (0005) > Nov 13 10:45:18 kernel: eth1: New link status: AP Changed (0003) > Nov 13 10:45:23 kernel: eth1: New link status: AP Out of Range (0004) > Nov 13 10:45:24 kernel: eth1: New link status: AP In Range (0005) > Nov 13 10:45:54 kernel: eth1: New link status: AP Changed (0003) > Nov 13 10:46:28 kernel: eth1: New link status: AP Out of Range (0004) > Nov 13 10:46:28 kernel: eth1: New link status: AP In Range (0005) > ... and so on... > however, it seems also to depend on the cards firmware and driver, > so other people may have no problems at all... > Inspite all the problems, it works well enough to get things > actually done. > > > the case in every session I've attended, as well as tonight's > > plenary. It doesn't seem to matter if the room is crowded > or empty, > > or where I sit. > > > > I have attempted to only select the 'ietf58' network, but often the > > network vanishes and there are no networks visible; other times the > > only visible "network" is an ad-hoc calling itself 'ietf58'. > > I wasn't often successful to reattach to APs after my card was > "hi-jacked" to ad-hoc cards announcing ietf58. Setting the > essid again to the same value seems to do trick, however, > often I see signals of strength 0 (maybe the card is confused then..). > Furthermore, it happens often that I don't get an IPv6 address > directly after activating the card (maybe the RA doesn't get through). > > Cheers, > Roland > >
Re: IETF58 - Network Status
"Michel Py" <[EMAIL PROTECTED]> writes: > I have had the same issue. Not suggesting the way I solved it is the > "right" one, it turned out that when I replaced my Linksys 802.11b with > a brand new Motorola 802.11g the problem went away; there is a Radio > Shark on the third floor of City Center that sells them for $70. Note that getting 802.11a works even better. Perry
RE: IETF58 - Network Status
> Randall Gellens wrote: > I have been consistently unable to maintain a connection > for more than a very few minutes, usually not even lon > enough to establish a VPN tunnel and fetch one message. > The 802.11 coverage comes and goes; the APs seem to > vanish and I see nothing for a while, eventually the > network comes back but only briefly. This has been > the case in every session I've attended, as well as > tonight's plenary. It doesn't seem to matter if the > room is crowded or empty, or where I sit. I have had the same issue. Not suggesting the way I solved it is the "right" one, it turned out that when I replaced my Linksys 802.11b with a brand new Motorola 802.11g the problem went away; there is a Radio Shark on the third floor of City Center that sells them for $70. If your WiFi card is a removable PCMCIA one, try to swap it temporarily with another one; some of the older card would work fine in less crowded environments but can't take the heat of the kind of WiFi we have for meetings. Michel.
Re: IETF58 - Network Status
Hi Randall, > I have been consistently unable to maintain a connection for more > than a very few minutes, usually not even long enough to establish a > VPN tunnel and fetch one message. The 802.11 coverage comes and > goes; the APs seem to vanish and I see nothing for a while, > eventually the network comes back but only briefly. This has been I can partly confirm your observations, since I often see my driver reporting a signal strength of 0 for seconds. The connection is somehow unstable as my log also reports (NSIS meeting this morning, actually not crowded) Nov 13 10:41:01 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:41:03 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:41:25 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:41:26 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:42:58 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:45:18 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:45:18 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:45:18 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:45:23 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:45:24 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:45:54 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:46:28 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:46:28 kernel: eth1: New link status: AP In Range (0005) ... and so on... however, it seems also to depend on the cards firmware and driver, so other people may have no problems at all... Inspite all the problems, it works well enough to get things actually done. > the case in every session I've attended, as well as tonight's > plenary. It doesn't seem to matter if the room is crowded or empty, > or where I sit. > > I have attempted to only select the 'ietf58' network, but often the > network vanishes and there are no networks visible; other times the > only visible "network" is an ad-hoc calling itself 'ietf58'. I wasn't often successful to reattach to APs after my card was "hi-jacked" to ad-hoc cards announcing ietf58. Setting the essid again to the same value seems to do trick, however, often I see signals of strength 0 (maybe the card is confused then..). Furthermore, it happens often that I don't get an IPv6 address directly after activating the card (maybe the RA doesn't get through). Cheers, Roland
Re[2]: IETF58 - Network Status
this is partially a product of your driver and it's user-interface... if you can really truely statically configure your adhesion to managed network it will work better. joelja On Wed, 12 Nov 2003, Cyrus Shaoul wrote: > I have seen the exact same phenomena this afternoon and evening. > > I am starting to get paranoid. Is there a vengeful person out there who > wants us to stop reading mail and listen to the WG meetings? Is there a > bit pattern that someone is broadcasting on purpose that causes this > problem? > > It is not working. It is just making everybody play with their network > settings all the time! Even less attention is going to the WG meetings! > > Oh well, > > Cyrus > > > On Wed, 12 Nov 2003 21:15:35 -0800 > Randall Gellens <[EMAIL PROTECTED]> wrote: > > randy> I have been consistently unable to maintain a connection for more > randy> than a very few minutes, usually not even long enough to establish a > randy> VPN tunnel and fetch one message. The 802.11 coverage comes and > randy> goes; the APs seem to vanish and I see nothing for a while, > randy> eventually the network comes back but only briefly. This has been > randy> the case in every session I've attended, as well as tonight's > randy> plenary. It doesn't seem to matter if the room is crowded or empty, > randy> or where I sit. > randy> > randy> I have attempted to only select the 'ietf58' network, but often the > randy> network vanishes and there are no networks visible; other times the > randy> only visible "network" is an ad-hoc calling itself 'ietf58'. > randy> -- > randy> Randall Gellens > randy> Opinions are personal;facts are suspect;I speak for myself only > randy> -- Randomly-selected tag: --- > randy> "SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of > randy> San Francisco Police Jacket, as reported by Herb Cain in SF Chronicle > randy> > randy> ___ > randy> This message was passed through [EMAIL PROTECTED], which is a sublist of > [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made > solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). > > > > > -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: Hand drumming before tonight's plenary
If you'd like to drum for a bit before we get started, I'm planning to arrive about half an hour early and drum quietly - see you near Salon D at 7:00 PM... I find myself wondering if drumming could become as much of a tradition at IETF as Nuclear War...
Re[2]: IETF58 - Network Status
I have seen the exact same phenomena this afternoon and evening. I am starting to get paranoid. Is there a vengeful person out there who wants us to stop reading mail and listen to the WG meetings? Is there a bit pattern that someone is broadcasting on purpose that causes this problem? It is not working. It is just making everybody play with their network settings all the time! Even less attention is going to the WG meetings! Oh well, Cyrus On Wed, 12 Nov 2003 21:15:35 -0800 Randall Gellens <[EMAIL PROTECTED]> wrote: randy> I have been consistently unable to maintain a connection for more randy> than a very few minutes, usually not even long enough to establish a randy> VPN tunnel and fetch one message. The 802.11 coverage comes and randy> goes; the APs seem to vanish and I see nothing for a while, randy> eventually the network comes back but only briefly. This has been randy> the case in every session I've attended, as well as tonight's randy> plenary. It doesn't seem to matter if the room is crowded or empty, randy> or where I sit. randy> randy> I have attempted to only select the 'ietf58' network, but often the randy> network vanishes and there are no networks visible; other times the randy> only visible "network" is an ad-hoc calling itself 'ietf58'. randy> -- randy> Randall Gellens randy> Opinions are personal;facts are suspect;I speak for myself only randy> -- Randomly-selected tag: --- randy> "SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of randy> San Francisco Police Jacket, as reported by Herb Cain in SF Chronicle randy> randy> ___ randy> This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]).
Re: Hand drumming before tonight's plenary
Pekka Savola wrote:
On Thu, 13 Nov 2003, Spencer Dawkins wrote:
("drumming is a healing thing, in many cultures")
Isn't it after the plenary when we'll need the healing?
Depending on people's skill level, it could be after the drumming. ;-)
--
/\
|John Stracke |[EMAIL PROTECTED] |
|Principal Engineer|http://www.centive.com |
|Centive |My opinions are my own. |
||
|A successful tool is one that was used to do something undreamed|
|of by its author. |
\/
Re: Hand drumming before tonight's plenary
I'll be happy if we don't have to do it again in mid-plenary!
- Original Message -
From: "Pekka Savola" <[EMAIL PROTECTED]>
To: "Spencer Dawkins" <[EMAIL PROTECTED]>
Cc: "IETF General Discussion Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, November 13, 2003 8:15 AM
Subject: Re: Hand drumming before tonight's plenary
> On Thu, 13 Nov 2003, Spencer Dawkins wrote:
> > ("drumming is a healing thing, in many cultures")
>
> Isn't it after the plenary when we'll need the healing?
Re: Hand drumming before tonight's plenary
On Thu, 13 Nov 2003, Spencer Dawkins wrote:
> ("drumming is a healing thing, in many cultures")
Isn't it after the plenary when we'll need the healing?
;-)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Hand drumming before tonight's plenary
If you'd like to drum for a bit before we get started, I'm planning to
arrive about half an hour early and drum quietly - see you near Salon
D at 7:00 PM...
Spencer
("drumming is a healing thing, in many cultures")
Re: IETF58 - Network Status
Just to echo Randall here - it seemed especially brutal last night, when we were all in Salon D. I didn't start Network Stumbler during the Plenary, but I did earlier in the week, and was seeing as many as 15-20 machines announcing ad-hoc ietf58. If I hadn't been typing as fast as I could, I would have suggested that we stop the plenary long enough to turn off all the offenders! But perhaps we could make this announcement tonight, after everyone gets inside and turns their machines on? Spencer - Original Message - From: "Randall Gellens" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, November 12, 2003 11:15 PM Subject: Re: IETF58 - Network Status > I have been consistently unable to maintain a connection for more > than a very few minutes, usually not even long enough to establish a > VPN tunnel and fetch one message. The 802.11 coverage comes and > goes; the APs seem to vanish and I see nothing for a while, > eventually the network comes back but only briefly. This has been > the case in every session I've attended, as well as tonight's > plenary. It doesn't seem to matter if the room is crowded or empty, > or where I sit. > > I have attempted to only select the 'ietf58' network, but often the > network vanishes and there are no networks visible; other times the > only visible "network" is an ad-hoc calling itself 'ietf58'. > -- > Randall Gellens > Opinions are personal;facts are suspect;I speak for myself only > -- Randomly-selected tag: --- > "SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of > San Francisco Police Jacket, as reported by Herb Cain in SF Chronicle > > ___ > This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]).
