[CUWiN-Dev] Deadline extension: Municipal Wireless Networks Workshop
Abdelnasser Abdelaal
mesrnile at yahoo.com
Thu Feb 22 12:56:16 CST 2007
The deadline for paper submissions to the Municipal Wireless Networks: Community-Driven Systems for Ubiquitous Connectivity (MWN-2007) workshop has been extended to April March 7.
Please, visit the following link for the recent updates.
http://www.iasted.org/conferences/cfp-575.html
--Abdelnasser Abdelaal
cu-wireless-dev-request at lists.cuwireless.net wrote: Send CU-Wireless-Dev mailing list submissions to
cu-wireless-dev at lists.cuwireless.net
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev
or, via email, send a message with subject or body 'help' to
cu-wireless-dev-request at lists.cuwireless.net
You can reach the person managing the list at
cu-wireless-dev-owner at lists.cuwireless.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CU-Wireless-Dev digest..."
Today's Topics:
1. Re: HSLSD Not Sending HSLS(9191) Packets (David Young)
2. Re: Progress towards HSLS LInux Port [from Latest Code base]
(David Young)
3. crunched: not quite, very close (Bryan Cribbs)
4. Re: crunched: not quite, very close (David Young)
5. Re: crunched: not quite, very close (Bryan Cribbs)
6. Re: crunched: not quite, very close (David Young)
7. Re: crunched: not quite, very close (Bryan Cribbs)
8. ieee802 radiotap and clock synchronization (Jeongkeun Lee)
----------------------------------------------------------------------
Message: 1
Date: Wed, 21 Feb 2007 20:06:30 -0600
From: David Young
Subject: Re: [CUWiN-Dev] HSLSD Not Sending HSLS(9191) Packets
To: cu-wireless-dev at cuwireless.net
Message-ID: <20070222020630.GK19589 at che.ojctech.com>
Content-Type: text/plain; charset=us-ascii
On Wed, Feb 21, 2007 at 09:49:12AM -0600, Bill Comisky wrote:
> On 2/21/07, David Young wrote:
> >On Tue, Feb 20, 2007 at 03:46:43PM +0200, Socrates Socrates wrote:
> >> Hi David;
> >>
> >> I've gotten the latest code as you suggested and I did my port.
> >>
> >> One thing to clear up front with regards to Zebra;
> >> Do I need to strictly use the zebra that came with the CUWiN source or
> >can I
> >> use the precompiled zebra package for my Linux distribution(Ubuntu)?
> >
> >I think it will be ok. We use version 0.99.5 of Quagga.
> >
>
> You mentioned using a precompiled 0.99.2.. the Zebra packet header
> changed between 0.99.2 and 0.99.4, and the CUWiN trunk is using the
> newer version, so that would cause a problem right? You should flip
> on the quagga debug switches and see what's going on there.
I'd forgotten about that. Thanks, Bill. Lawrence, you will need to
use 0.99.4 or later.
Dave
--
David Young OJC Technologies
dyoung at ojctech.com Urbana, IL * (217) 278-3933
------------------------------
Message: 2
Date: Thu, 22 Feb 2007 01:12:45 -0600
From: David Young
Subject: Re: [CUWiN-Dev] Progress towards HSLS LInux Port [from Latest
Code base]
To: cu-wireless-dev at cuwireless.net
Message-ID: <20070222071245.GL19589 at che.ojctech.com>
Content-Type: text/plain; charset=us-ascii
On Wed, Feb 21, 2007 at 02:39:08PM +0200, Socrates Socrates wrote:
> Hi Dave;
>
> I've resolved the last problem I had [Discussed in thread "HSLSD Not Sending
> HSLS(9191) Packets."].
>
> Now the debug messages look this:
>
> root at appletiser:/home/lawrence/work/latest_hsls/cuwin-0.7.0-src/src/hsls#
> ./run-hsls
> 20070221121114 hsls_server_create: created server 0x8091874
> 20070221121114 main: event(3) initialized
> 20070221121114 beacon_rx_socket: bound 0.0.0.0 port 9191
> 20070221121114 beacon_tx_socket: bound 169.254.237.50 port 9191
> 20070221121114 ERR RIB indicates 'connected'
> 20070221121114 rib_zpkt_header_pack: packed 1 fields in 3 bytes at
> 0xbf97118d
> 20070221121114 hsls_server_start: bound 127.0.0.1 9292
>
> Questions:
> 1. Should I be concerned with the message "20070221121114 ERR RIB indicates
> 'connected'"? That is, Does ERR RIB indicates an error?
That is ok. That means the HSLS daemon has connected to Zebra.
> After the message "20070221121114 hsls_server_start: bound 127.0.0.1 9292",
> the program hangs. Tracing leads me to event_loop() in
> libevent-0.8a/event.c.
>
> I assume at some point event_loop() should exit (which doesn't), if so:
> 1. What are the conditions/events that should cause this function to exit?
hsls_router_run() calls event_dispatch(), which repeatedly calls
event_loop(), forever, or until there are no more events scheduled, or
until there is an exception from which event_dispatch() cannot recover.
libevent has some documentation. On NetBSD, there is a manual page.
BTW, I am using version 1.0c of libevent. You may need a later version.
> 2. Are these conditions/events external to my system? In other words, the
> event would be say, receiving an hsls packet.
Right, one event is receiving a packet.
Dave
--
David Young OJC Technologies
dyoung at ojctech.com Urbana, IL * (217) 278-3933
------------------------------
Message: 3
Date: Thu, 22 Feb 2007 02:16:41 -0600
From: Bryan Cribbs
Subject: [CUWiN-Dev] crunched: not quite, very close
To: cu-wireless-dev at cuwireless.net
Message-ID: <45DD5169.7080706 at ojctech.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I'm happy to say that a crunched version of most* of cuwin is 6.5 M.
The kernel is itself is about 1 meg on top of that.
I've committed this onto a branch, and I am hoping to include the
"Makefile.image" step (to be easily loaded on low-resource hardware).
----
*this crunch excludes two crucial components: dhcp, and zebra.
Neither have been trivial to link into a crunched executable,
they desperately need work.
------------------------------
Message: 4
Date: Thu, 22 Feb 2007 02:23:19 -0600
From: David Young
Subject: Re: [CUWiN-Dev] crunched: not quite, very close
To: cu-wireless-dev at cuwireless.net
Message-ID: <20070222082319.GN19589 at che.ojctech.com>
Content-Type: text/plain; charset=us-ascii
On Thu, Feb 22, 2007 at 02:16:41AM -0600, Bryan Cribbs wrote:
> I'm happy to say that a crunched version of most* of cuwin is 6.5 M.
> The kernel is itself is about 1 meg on top of that.
This is for MIPS, right? Regardless, I am impressed. Good work!
> I've committed this onto a branch, and I am hoping to include the
> "Makefile.image" step (to be easily loaded on low-resource hardware).
>
> ----
> *this crunch excludes two crucial components: dhcp, and zebra.
> Neither have been trivial to link into a crunched executable,
> they desperately need work.
There are no two ways about it: Zebra has to go. I am not sure what to
do about DHCP: so essential, so gigantic.
Dave
--
David Young OJC Technologies
dyoung at ojctech.com Urbana, IL * (217) 278-3933
------------------------------
Message: 5
Date: Thu, 22 Feb 2007 02:44:32 -0600
From: Bryan Cribbs
Subject: Re: [CUWiN-Dev] crunched: not quite, very close
To: cu-wireless-dev at cuwireless.net
Message-ID: <45DD57F0.8090809 at ojctech.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
David Young wrote:
> On Thu, Feb 22, 2007 at 02:16:41AM -0600, Bryan Cribbs wrote:
>
>> I'm happy to say that a crunched version of most* of cuwin is 6.5 M.
>> The kernel is itself is about 1 meg on top of that.
>>
>
> This is for MIPS, right? Regardless, I am impressed. Good work!
>
>
Well... no... i386. I got tired of not being able to use basic tools
to debug things... but someone (probably me) should try a MIPS build,
I'd be surprised if it made a difference. Then again, I'm often taken
by surprise.
------------------------------
Message: 6
Date: Thu, 22 Feb 2007 02:47:22 -0600
From: David Young
Subject: Re: [CUWiN-Dev] crunched: not quite, very close
To: cu-wireless-dev at cuwireless.net
Message-ID: <20070222084722.GO19589 at che.ojctech.com>
Content-Type: text/plain; charset=us-ascii
On Thu, Feb 22, 2007 at 02:44:32AM -0600, Bryan Cribbs wrote:
> David Young wrote:
> >On Thu, Feb 22, 2007 at 02:16:41AM -0600, Bryan Cribbs wrote:
> >
> >>I'm happy to say that a crunched version of most* of cuwin is 6.5 M.
> >>The kernel is itself is about 1 meg on top of that.
> >>
> >
> >This is for MIPS, right? Regardless, I am impressed. Good work!
> >
> >
> Well... no... i386. I got tired of not being able to use basic tools
> to debug things... but someone (probably me) should try a MIPS build,
> I'd be surprised if it made a difference. Then again, I'm often taken
> by surprise.
Binaries for 32-bit RISC machines like MIPS are ordinarily going to
be bigger.
What basic debug tools were you missing?
Dave
--
David Young OJC Technologies
dyoung at ojctech.com Urbana, IL * (217) 278-3933
------------------------------
Message: 7
Date: Thu, 22 Feb 2007 03:11:58 -0600
From: Bryan Cribbs
Subject: Re: [CUWiN-Dev] crunched: not quite, very close
To: cu-wireless-dev at cuwireless.net
Message-ID: <45DD5E5E.3060909 at ojctech.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
David Young wrote:
> On Thu, Feb 22, 2007 at 02:44:32AM -0600, Bryan Cribbs wrote:
>
>> David Young wrote:
>>
>>> On Thu, Feb 22, 2007 at 02:16:41AM -0600, Bryan Cribbs wrote:
>>>
>>>
>>>> I'm happy to say that a crunched version of most* of cuwin is 6.5 M.
>>>> The kernel is itself is about 1 meg on top of that.
>>>>
>>>>
>>> This is for MIPS, right? Regardless, I am impressed. Good work!
>>>
>>>
>>>
>> Well... no... i386. I got tired of not being able to use basic tools
>> to debug things... but someone (probably me) should try a MIPS build,
>> I'd be surprised if it made a difference. Then again, I'm often taken
>> by surprise.
>>
>
> Binaries for 32-bit RISC machines like MIPS are ordinarily going to
> be bigger.
>
> What basic debug tools were you missing?
>
> Dave
>
>
I should have used the "toolchain" versions but I did not consider that
until late in my work. The tools I was referring to are all right
there, had I seen them. (nm, ar, ldd, &c), using the toolchain versions
instead of the host OS versions makes a huge difference in critical
situations, and it is very easy to miss.
------------------------------
Message: 8
Date: Thu, 22 Feb 2007 21:09:19 +0900
From: "Jeongkeun Lee"
Subject: [CUWiN-Dev] ieee802 radiotap and clock synchronization
To:
Message-ID: <04f401c7567a$4adc7830$37d82e93 at mmlabjklee>
Content-Type: text/plain; charset="us-ascii"
Thank you, Dave.
The TSF timestamp is what I want. Using pcap library, I programmed my own
sniffer application which peeks out TSFT, RSS from ieee80211_radiotap_header
and also parses UDP payload data.
But I have encountered two problems.
1. pcap does not recognize filter expressions when I set pcap's datalink
type as ieee802_11_radio. Actually this also happens with tcpdump. When I
try any filter expressions with '-y ieee802_11_radio' option, tcpdump
captures no packets.
For example, 'tcpdump -ne -y ieee802_11_radio -i ath0' itself works well,
'tcpdump port 9191' works well too. But using them together does not work
properly as follows.
--------------------------------------------------------------------------
# tcpdump -ne -y ieee802_11_radio -i ath0 port 9191
tcpdump: data link type ieee802_11_radio
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ath0, link-type IEEE802_11_RADIO (802.11 plus BSD radio
information header), capture size 96 bytes
^C
0 packets captured
13 packets received by filter
0 packets dropped by kernel
--------------------------------------------------------------------------
2. My second problem is about tsft synchronization. From capture logs, I
have realized that tsf timer of mesh nodes can exhibit asynchronous states
time to time, even though they can hear each other's beacon transmissions.
(I have five nodes in operation.) Papers have reported that 802.11 ad hoc
mode operation does not guarantee tsft synchronization because 1) stations
send beacons on a contention basis 2) stations can only set their clock
times forward and never backward. Slower clocks synchronize with faster
clocks, but faster clocks do not synchronize themselves with slower clocks
learned from neighbor's beacons.
Do we have any solution which includes driver modifications?
My current solution is to disable beacon TX of all stations. Then stations
do not change their clocks but the clock time difference between two
stations is almost linearly increasing or decreasing over time according to
my observation. So we can measure the difference changing speed and use it
to compensate the difference.
Thank you,
-- Jeongkeun
> -----Original Message-----
> From: cu-wireless-dev-bounces at lists.cuwireless.net [mailto:cu-wireless-
> dev-bounces at lists.cuwireless.net] On Behalf Of David Young
> Sent: Thursday, February 08, 2007 2:18 AM
> To: cu-wireless-dev at lists.cuwireless.net
> Subject: Re: [CUWiN-Dev] Monitor mode with Atheros
>
> On Wed, Feb 07, 2007 at 08:44:52PM +0900, Jeongkeun Lee wrote:
> > By any chance, the IEEE80211_RADIOTAP_TSFT type defined in
> > ieee80211_radiotap header has something to do with the tcpdump time
> stamp?
>
> It is the 802.11 Rx TSF timestamp. The MAC adds it. It is precisely
> the timestamp you are looking for. That is why I suggest using -y
> ieee802_11_radio. It adds a radiotap header containing the timestamp.
>
> Dave
>
> --
> David Young OJC Technologies
> dyoung at ojctech.com Urbana, IL * (217) 278-3933
> _______________________________________________
> CU-Wireless-Dev mailing list
> CU-Wireless-Dev at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev
------------------------------
_______________________________________________
CU-Wireless-Dev mailing list
CU-Wireless-Dev at lists.cuwireless.net
http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev
End of CU-Wireless-Dev Digest, Vol 34, Issue 12
***********************************************
---------------------------------
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.chambana.net/mailman/archive/cu-wireless-dev/attachments/20070222/14fc6a67/attachment-0001.html
More information about the CU-Wireless-Dev
mailing list