At 13:00 +0100 02/03/03, Vito Milio wrote:
>I am following the mailing list from some day and I do not know if others  have said this. I suggest in order to identify the amateur radio operator to use certifys digital them to you. This would allow to identify them in sure and sure way.

This is a very good idea, I think it's cleaner/better than MAC or IP addresses. Clubs could sign individual HAMs certificates. HAMs could then access the part97 infrastructure if they sign their packets with their individual certificate. Firewalls could enforce this easily. IPv6 has allready support for packets signing, or this could be done with IPsec over IPv4.

You may think that I change opinion often (hi), but I now think that identifing amateurs using digital certificates would be the best solution.

73s,
GFK's

--

Guillaume Filion

Logidac Tech., Beaumont, Québec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/

Use of digital certificates has been discussed.  It would need to be issued at least once for network authentication.  It's not a bad way to go.

We've also considered use of a crypto checksum associated with all packets (essentially a VPN without encryption) to verify authenticity of origination on a network.

gerry

Vito Milio wrote:
> Hello,
>
> I am following the mailing list from some day and I do not know if
> others  have said this. I suggest in order to identify the amateur
> radio operator to use certifys digital them to you.
> This would allow to identify them in sure and sure way.

> With this certificate we can identify the specific Amateur. If you it
> could seem difficult to realize this I say you that is  much simple one instead.

> Certification a Autority could be implemented simply.
> To every amateur it would assigned to a digital certificate them. The amateur radio operator would recognized in sure way this certificate.

> This increases to the guarantees nobody to outside of the amateur  will
> be able to have that certificate.
> Therefore it comes resolved the problem of who is not amateur radio
> operator who could not be authenticated without the certificate.
> The certificate will come only emitted who is titular of the patent.

> If thoughts that this is a good idea this are only the beginning.>

> Thanks for the attention

> Vito iw0gac

> ----------------------------------------------------------------------

> ------------

I got a few private emails on the setup and I'd rather answer on the list than privately. 

Here is what I'm using: 

- 3 24 dbi "grill" type commercial dishes.  They are commercial and can be typically had for between $50 and $70. Here is the link http://www.hyperlinktech.com/html/products/hg2424g.php 

- 3 Cisco BR-342 bridges. These are EOL'd by Cisco and can be readily had for between $350 and $500. They have VERY sensitive receivers and excellent management features.

- Each bridge has an R-TNC to N connector pigtail and 25 to 50 feet of LMR-400 cable between it and the antenna.

 - My mountain top link and my airport link have a 333mhz PII Compaq "mini" system that I bought surplus for $140. These systems run without a monitor and run Windows 2000. I used to run Linux (for about 8 years) but got tired of the configuration hassles and changed to Windows 2000 server a couple of years ago. Each of these systems can be completely operaterated from any other system using the remote desktop feature of Windows 2000 and WindowsXP - VERY CONVENIENT and it runs all the software I need. 

- For digital voice access to my repeaters I use a highly modified version of SpeakEasy that I modified to remove a bunch of junk I didn't need and to use input/output bits on the printer port for  COS, PTT, etc.

- My Linkcomm RLC-3 is connected to one of the serial ports of the computer. I can connect to this computer via remote desktop and run the Linkcomm controller software just as if it were local. 

- A webcam is setup at each location I don't remember the software though - I'll need to check.

This setup works RAIN or shine with no degradation on 100mw of TX power. PLEASE don't run your systems with 1 watt - you are only causing interference to others.

 73, Ron Curry N6QL

 Gents,

  It is interesting to read what the ham world has already done with 802.11b.

  ALL WiFi compatable AP's act as packet repeaters as long as they are on the same network whether they have a wire link or not. The 802.11b standard requires that newly associated clients SSID's be held in a table called a bridging table on the AP. Any client on a network can therefore access any other client on a network.

  If the question is can I stick up an AP to bridge between two networks then that requires some special software and the resulting AP is usually refered to as an outdoor router. As this case is not covered under the 802.11b standard there is no compatibility between manufactures. A better solution for Ham use is a small remote client PC with 2 802.11 cards and some bridging software, you can buy the PC for what you would save on the outdoor router.

73's,

Alex Kalish

Agere Systems

802.11b DMTS Texas

281 935-9439 (m)

281 252-9470 (o)

-----Original Message-----

From: Walt DuBose [mailto:[email protected]]

Sent: Wednesday, February 26, 2003 7:01 PM

To: [email protected]

Subject: Re: [ARRL-80211B] Protocol enhancements

 I can see how MAC forwarding would be possible and not be in violation of anything in the IEEE 802.11b standard.

 I have the O'Reilly book and the full 3-4 inches of the printed out IEEE standard...I like the O'Reilly book MUCH BETTER.

Walt

 Guillaume Filion wrote:

> At 20:52 -0500 26/02/03, Walt DuBose wrote:

> >Guillaume,

> >

> >Good stuff.

> >I know that D'Link and perhaps a couple of other vendors advertise
> >their APs as repeaters; however, each say that they only do this for
> >"their" hardware.

> I don't know if it means "only tested with their hardware" or "only
> works with their hardware". It seems to me that this should be pretty
> easy to make this work with any hardware.

>I have looked a the IEEE 802.11b standard a bit and don't see a
> >specific reference to MAC forwarding but understand the principle and
> >see MAC forwarding in the referenced text.  I just need to find out
> >more about it.

> MAC Forwarding doesn't seem to be the term used in the protocol
> specification. But when trying to find out how they are calling it, I
> stumbled on this: "An access point (AP) is a STA that provides access
> to the DS by providing DS services in addition to acting
> as a STA." (IEEE802.11-1999 p.11)

> That means that the protocol does not specify that the communication
> between two access points (AP) must be made using a wire. They say
> that it's done using a distribution system (DS). About the DS they
> say that it "enables mobile device support by providing the logical
> services necessary to handle address to destination mapping and
> seamless integration of multiple BSSs."

> That would mean that Radio MAC Forwarding could be implemented
> without breaking the protocol.

> I can't read a lot of these specs without getting dizzy, do you folks
> have any recommendation for a more readable way of understanding the
> protocol. Is the book (http://www.arrl.org/catalog/?item=8884) good?

> The readers reviews on amazon are mixed.

> >To me the main thing missing from most APs is implementation of PCF.
> "point coordination function (PCF): A class of possible coordination
> functions in which the coordination function logic is active in only
> one station in a basic service set
> (BSS) at any given time that the network
> is in operation.
> coordination function: The logical function that determines when a
> station operating within a basic service set (BSS) is permitted to
> transmit and may be able to receive protocol data units (PDUs) via the
> wireless medium (WM). The coordination function within a BSS may have
> one point coordination function
> (PCF) and will have one distributed coordination function (DCF)."
> Now my head hurts! hi
> Anyone has a less barbaric definition? From what I understand, it's a
> way of having a station decide whose turn it is to talk, rather than
> using the CSMA/CA technique. Am I right? If so, does it provide a
> real advantage over the way CSMA/CA?

> >Thanks for joining in the discussion.  I am sure this will provoke
> >much more needed discussion.

> Thanks, it's nice to see that there are people interested in this.

> 73

> GFK's

> --

> Guillaume Filion

> Logidac Tech., Beaumont, Québec, Canada - http://logidac.com/ PGP Key

> and more: http://guillaume.filion.org/

Hi all, 

I'm pretty happy to have found this group because I've been thinking about mixing Wi-Fi and HAM radio for a long time, but I had a hard time finding ressources to do it. Knowing that a ARRL group is specialised in this is great! 8)

Here are some ideas that I had in the last months about making the IEEE802.11 protocol more HAM friendly. 

Radio MAC forwarding 

IEEE 802.11 provides MAC forwarding, radio messages can be forwarded by an access point (AP) through a wire to an AP in another region. MAC forwarding requires a fixed wired infrastructure to link the AP. This might be satisfactory for most usages, but is not adequate for ad-hoc networks. A better approach would be Radio MAC forwarding, where every node of the network can be used to relay the message on the air to the destination. The protocol doesn't rely any more on a fixed infrastructure, but on all the wireless nodes on the path.

More information about MAC forwarding and Radio MAC forwarding is available in chapter 5.3 of : http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.mac.html

They talk about Wireless repeaters in the previous document, if we could manage a way of having every/most/some AP act as a wireless repeater, we could acheive Radio MAC forwarding by only changing the implementation (and not the protocol). 802.11 planet talks about making wireless repeaters with some AP: http://www.80211-planet.com/tutorials/article.php/1571601

However, as stated in the 802.11 planet article, repeaters create more traffic on the channel, so I guess a policy should be put in place to limit the number of repeaters in a particular area. It might not be a good idea to have every node on the network work as a repeater. A better approach might be in IP routing of the packets on a large scale + Radio MAC forwarding on a local scale.

Emergency packets

HAM radio communications have several levels of urgency: normal, security (TTT), pan (XXX) and mayday (SOS). It would be interesting to have this implemented in the ARRL 802.11 protocol. Radio MAC forwarding could be mandatory for emergency packets, as it is specified by law (that you must relay emergency communications).

Hopefully all this is done in the Media Access Control (MAC) or the IP layer so it could be modified in software using a driver similar to hostAP (http://hostap.epitest.fi/). hostAP is a linux driver for wireless cards based on Intersil's Prism2/2.5/3 chipset that takes care of everything except the RF and low level time critical parts of the protocol. Everything else is implemented in software in the C programming language. FreeBSD also has an implementation of hostAP.

I'm not sure about the Radio MAC Forwarding stuff, it seems like a good idea, especially when there are no fixed infrastructure, but there may be a good reason why it was not included in the protocol. As for the Emergency packets, I'm pretty sure that this would be a good thing to do.

Let me know what you think,

GFK's

--

Guillaume Filion

Logidac Tech., Beaumont, Québec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/