testing-boun...@lists.laptop.org wrote on 12/12/2008 12:03:44 PM:
Chris Marshall wrote:
Mitch Bradley wrote:
Secondly, if you have a USB CD-ROM drive, you could help me by
testing it with OFW. To do so:
Will an external DVD-RW drive work or only a CD?
I'd like to find that
Chris Ball [EMAIL PROTECTED] wrote on 11/28/2008 04:18:11 PM:
Bugs I plan to fix:
* #2765 -- Need to turn off DCON after some time in idle suspend
* #3732 -- ARP broadcasts don't wake autosuspended laptops
This works now and Ricardo has tested it. The remaining bugs in WOL don't
affect
Martin,
I really miss the point of your tirade.
Our advice is to use 5.110.22.p18
M.
Martin Langhoff [EMAIL PROTECTED]
09/11/2008 10:15 PM
To
Ricardo Carrano [EMAIL PROTECTED]
cc
Michail Bletsas [EMAIL PROTECTED], OLPC Devel
devel@lists.laptop.org, XS Devel [EMAIL PROTECTED]
Subject
Re
Clearly, it fixes some bugs we knew about and we already know it
introduces others. I assume someone is keeping track of that info --
What bugs does it introduce?
M___
Devel mailing list
Devel@lists.laptop.org
Martin Langhoff [EMAIL PROTECTED] wrote on 09/12/2008 12:50:50
AM:
What bugs does it introduce?
That is the info I am asking -- without being involved in the Libertas
efforts I know of a few issues as discussed in this thread:
- Deepak mentions it has an incompatibility with the F9
Martin,
I really miss the point of your tirade.
Our advice is to use 5.110.22.p18
M.
Martin Langhoff [EMAIL PROTECTED]
09/11/2008 10:15 PM
To
Ricardo Carrano [EMAIL PROTECTED]
cc
Michail Bletsas [EMAIL PROTECTED], OLPC Devel
[EMAIL PROTECTED], XS Devel server-devel@lists.laptop.org
Martin Langhoff [EMAIL PROTECTED] wrote on 09/09/2008 07:04:31
PM:
After a quick check it looks like the XO images are shipping newer
Libertas firmware as you can see below. The XO builds also have a few
problems with the Firmware too, so I'm not entirely sure what to do...
- F9
[EMAIL PROTECTED] wrote on 06/17/2008 12:27:15 AM:
**Michali, I have a question for u:
In the case that some XOs are many hops away(5 and 10) from the
School, can an XO at halfway act as an MPP to practically increase the
ttl?
I can understand that it would probably work if the MPP had
[EMAIL PROTECTED] wrote on 06/08/2008 11:33:15 AM:
To clarify, there are at least seven different directions to follow
here:
a) telepathy-based collaboration on 802.11g networks
b) telepathy-with-cerebro-backend collaboration on 802.11g networks
c) cerebro-based collaboration in 802.11g
[EMAIL PROTECTED] wrote on 06/08/2008 12:00:30 PM:
one more (which may be considered a varient of d)
i) 802.11s meshing in bad RF environments
this is where there are a small number of XO machines (so you don't have
the 802.11s traffic issues), but where there are a large number of
[EMAIL PROTECTED] wrote on 06/08/2008 12:25:13 PM:
While we're talking about networking:
From discussions with the OLSRd guys, one way they made their
protocols work well in dense networks was to aggressively use *all*
the 802.11*a* as well as g channels. 802.11a has 24+ non-overlapping
[EMAIL PROTECTED] wrote on 06/03/2008 11:20:51 AM:
A necessary rectification:
Firmware updates from the driver are the only method that works
currently. If we want to name one method a disaster, we would have
to choose the userspace tool, since it will brick many of your active
[EMAIL PROTECTED] wrote on 06/03/2008 10:12:31 AM:
On Mon, 2008-06-02 at 17:12 -0700, Brian Cavagnolo wrote:
To update boot2, copy the boot2 and firmware images to /lib/firmware
and:
echo boot2_image_name /sys/class/net/eth2/lbs_boot2
echo firmware_image_name
Dan Williams [EMAIL PROTECTED] wrote on 06/03/2008 12:09:11 PM:
On Tue, 2008-06-03 at 11:30 -0400, Michail Bletsas wrote:
[EMAIL PROTECTED] wrote on 06/03/2008 11:20:51
AM:
A necessary rectification:
Firmware updates from the driver are the only method that works
Dan Williams [EMAIL PROTECTED] wrote on 06/03/2008 11:26:21 AM:
It is not a matter of Python vs C.
The userspace tool is extremely awkward to use (since it requires the
driver modules to be unloaded which in turn makes the identification
of
How does it make the ID more difficult?
Dan Williams [EMAIL PROTECTED] wrote on 06/03/2008 01:20:11 PM:
On Tue, 2008-06-03 at 13:03 -0400, Michail Bletsas wrote:
Dan Williams [EMAIL PROTECTED] wrote on 06/03/2008 11:26:21 AM:
It is not a matter of Python vs C.
The userspace tool is extremely awkward to use (since
Dan Williams [EMAIL PROTECTED] wrote on 06/03/2008 01:50:59 PM:
That's a good suggestion.
From a practical perspective though, in XOs, the onboard interface is
always eth0 these days.
Yes, but I thought the discussion was more about active antenna updates,
where you may have more
John Watlington [EMAIL PROTECTED] wrote on 05/21/2008 10:45:31 PM:
Michail is choosing a method, which will be used by NM and should be
used by other laptop tasks as well. It will almost certainly not be
SSID based.
My inclination is to just use a DNS name like schoolserver (that will
John Watlington [EMAIL PROTECTED] wrote on 05/21/2008 10:45:31 PM:
Michail is choosing a method, which will be used by NM and should be
used by other laptop tasks as well. It will almost certainly not be
SSID based.
My inclination is to just use a DNS name like schoolserver (that will
Let's not forget that you need some fixed reference points.
In commercial systems, the locations of the access points are well known.
In ad-hoc networks the best that you can hope for is a topological map.
M.
[EMAIL PROTECTED] wrote on 04/02/2008 01:45:14 AM:
Ryan,
Like Ben said,
Bryan Berry [EMAIL PROTECTED] wrote on 03/05/2008 03:07:12 AM:
Michailis, thanks for your quick reply
small schools, the school server is all that you need. In the
meantime, APs with controllable WDS behavior are recommended.
I am not an expert on access points. Can you suggest a
[EMAIL PROTECTED] wrote on 03/03/2008 02:38:00 AM:
Questions:
How many XO's can a single active antenna support? We only have two
active antennas at the moment.
The answer is always traffic depedent. Given the current status of the
collaboration software on the XO and assuming that the
],
Michail Bletsas [EMAIL PROTECTED], Chris Ball [EMAIL PROTECTED],
OLPC Developer's List [EMAIL PROTECTED], Jim Gettys [EMAIL PROTECTED],
Ricardo Carrano [EMAIL PROTECTED]
cc
Subject
Re: WDS problems observed in today's testing
Was anyone able to get a test with a different AP? We were only able
Jim Gettys [EMAIL PROTECTED] wrote on 02/21/2008 10:38:46 AM:
RFC 4795 does not cover mdns.
http://www.multicastdns.org/ covers stuff regarding mdns; it is far from
ideal for a mesh network as well. Several of us are reading the ID at
the moment.
- Jim
Yeah, let's drop everything and the kitchen sink on the radio!!
M.
John Watlington [EMAIL PROTECTED]
02/19/2008 10:10 AM
To
Chris Ball [EMAIL PROTECTED]
cc
John Watlington [EMAIL PROTECTED], Ricardo Carrano
[EMAIL PROTECTED], OLPC Devel [EMAIL PROTECTED], Michail
Bletsas [EMAIL PROTECTED
Sjoerd Simons [EMAIL PROTECTED] wrote on 01/30/2008 06:45:48 AM:
Well both avahi and salut are quite capable. I'm not sure why it hassuch
a bad
reputation with you. Probably because your only seeing it in a very very
exterme network and because there seems to be a lot of FUD about mdns
Sjoerd Simons [EMAIL PROTECTED] wrote on 01/30/2008 10:46:33 AM:
I did some research into mesh routing protocols before starting the
salut muc
work. From the research papers i've seen, proper multicast routing seems
entirely viable. Traffic and memory overhead depend on the exact
Dan Williams [EMAIL PROTECTED] wrote on 01/19/2008 12:48:06 PM:
Hmm, ok... So all the external USB 8388 dongles have a larger SPI flash
to contain both the Boot2 code and the 100K thick firmware?
yes,
M.___
Devel mailing list
John Watlington [EMAIL PROTECTED] wrote on 01/18/2008 04:56:26 PM:
Michail,
This would be 3107, right ?
3109 is when we started seeing the auto-update mode.
Yes,
M.
___
Devel mailing list
Devel@lists.laptop.org
David Woodhouse [EMAIL PROTECTED] wrote on 01/18/2008 03:31:08 PM:
Ideally, we want to just kill the auto-mesh-repeater mode, where boot2
times out after 5 seconds and loads the firmware from the internal flash
(which is obviously larger on these devices than on the XO). Can we
achieve
Dan Williams [EMAIL PROTECTED] wrote on 01/18/2008 10:08:09 AM:
On Fri, 2008-01-18 at 08:36 +0800, David Woodhouse wrote:
On Thu, 2008-01-17 at 19:16 -0500, Giannis Galanis wrote:
It must be noted that the important issue of this discussion is
how to have
the radio blocked from BEFORE
Hal Murray [EMAIL PROTECTED] wrote on 01/17/2008 12:55:47 PM:
When it comes to our radio - we *designed it* to start forward frames
soon after you initialize it and keep doing it regardless of what the
host interface does.
In the context of making the radio safe to use on airplanes...
David Woodhouse [EMAIL PROTECTED] wrote on 01/17/2008 06:26:38 PM:
It uses CMD_802_11_RADIO_CONTROL with the RADIO_OFF argument, which I
believe is the correct thing to do.
If that's the case then it does the right thing - no need to worry with
the earlier iwpriv call.
[EMAIL PROTECTED] wrote on 01/17/2008 02:17:44 PM:
I apologize if I am over simplifying:
- mesh stop was considered when we had compatibility issues with
lazy-wds routers. We addressed this, right? Do we still need this
feature? Michail?
The only reason to have this, is for debugging
Dan Williams [EMAIL PROTECTED] wrote on 01/16/2008 10:48:13 AM:
There's a long explanation for that, but the short one is that the
driver should no longer periodically run around in circles screaming,
then have an arterial hemorrhage, and collapse on the ground spurting
blood from it's ears.
A brief history of OLPC's mesh stack deviations from 802.11s:
We chose 802.11s for interoperability and its nice alignment with our
power management architecture.
Our goal has always been to produce a proper subset of the emerging
802.11s standard (in the same manner that WiFi is a subset of
John Watlington [EMAIL PROTECTED] wrote on 01/09/2008 11:34:29 AM:
Right now we have a problem with mesh portal discovery.
The DHCP procedure currently being used only discovers
the nearest mesh portal when it is first run (DHCP_DISCOVER),
not when it tries to renew (DHCP_REQUEST).
What do you propose to do about it? Throw away pointless engineering
into cobbling together some way of making Legacy IP work a bit better? I
seriously hope not. Just switch off the Legacy IP, as we should have
done months ago, and get on with making things work properly. Anything
else is a
David Woodhouse [EMAIL PROTECTED] wrote on 01/09/2008 02:40:46 PM:
We can also
check the mesh path length to the origin of each RA we see, and choose
the best one.
The way this was originally implemented in a way that can be used for any
well defined service (not just network gateways),
The DHCP server was needed anyway. And to implement shortest path
routing both for sent and received packets, we needed a mechanism for
receiving an IP address that reflected the nearest MPP anyway (or use
NAT, something we would like to avoid inside the school)
I completely fail
David Woodhouse [EMAIL PROTECTED] wrote on 01/09/2008 02:57:50 PM:
NAT-PT and proxying should solve that problem relatively simply. I
should investigate the implementation at http://tomicki.net/naptd.php
Running application proxies on every XO that wants to act as a mesh
portal?
M.
David Woodhouse [EMAIL PROTECTED] wrote on 01/09/2008 03:17:30 PM:
On Wed, 2008-01-09 at 15:15 -0500, Michail Bletsas wrote:
Running application proxies on every XO that wants to act as a mesh
portal?
Running NAT-PT. Since they're required to run NAT as it is anyway, that
shouldn't
The MPP discovery mechanism originally proposed worked great for getting
packets out of the mesh through the shortest path. The problem was
that
outside of running NAT on each MPP, there wasn't a good way to ensure
that packets sent to that laptop entered the mesh through the same MPP.
to identify
themselves (even with mDNS or a predefined anycast address) and then and
only then we can turn mDNS off.
M.
John Watlington [EMAIL PROTECTED]
12/14/2007 12:43 AM
To
Giannis Galanis [EMAIL PROTECTED]
cc
John Watlington [EMAIL PROTECTED], Michail Bletsas [EMAIL PROTECTED],
Kim Quirk
Kim,
1. I don't think that this alleged bug is related to the firmware
2. Even if it is, the benefits of 20.p47 far outweigh the risk of
(further) breaking WPA.
M.
Kim Quirk [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
12/13/2007 01:42 PM
To
Marco Pesenti Gritti [EMAIL PROTECTED]
cc
Ricardo Carrano [EMAIL PROTECTED] wrote on 12/13/2007
02:54:11 PM:
- Whatever changed between 1407 and 1416 seem to have really crashed
WPA support, I
mean, now we cannot set it to work via wpa_supplicant anymore.
Maybe something as simple as actually rebuilding wpa_supplicant?
For the shake of completeness, can you also try 5.110.17.p5 ?
Thanks,
M.
Zarro Boogs per Child [EMAIL PROTECTED]
11/04/2007 10:15 PM
Please respond to
devel@lists.laptop.org
To
[EMAIL PROTECTED]
cc
Subject
Re: #4637 BLOC Update.: OFW networking broken in Q2D03
#4637: OFW
At this point in time, having as much debug info available in the
developer console without having to remember which command-line tool
provides what, is crucial for collecting problem reports from non-expert
users and I would request that the IPv4 information remains where it is.
Michail
Dan,
Marvell and Cozybit give us firmware by posting it in the internal Wiki.
M.
Dan Williams [EMAIL PROTECTED]
07/02/2007 07:06 AM
To
Ronak Chokshi [EMAIL PROTECTED]
cc
Michail Bletsas [EMAIL PROTECTED], [EMAIL PROTECTED], Kim Quirk
[EMAIL PROTECTED], OLPC Developer's List [EMAIL
/2007 09:20 AM
To
Michail Bletsas [EMAIL PROTECTED]
cc
Dan Williams [EMAIL PROTECTED], olpc-devel devel@lists.laptop.org
Subject
Re: mesh network vs broadcast/multicast question
On Tue, 2007-06-26 at 11:34 -0400, Michail Bletsas wrote:
The key point to remember in order to derive answers
You're misunderstanding me. My concern is with waking machines up by
broadcasting this information. We don't wake up on presence, but we
do want to wake up on (some, urgent) upgrades.
That's going to be interesting, yeah. You would need to teach the
wireless firmware about it? How
51 matches
Mail list logo
