A topic on aw.net has me posting about this here. I'd suggested a bounty for a wireless networking framework a while back, and as people are talking about this elsewhere, I think it would be nice to see some discussion (same for all those other idle bounty proposals) to work on improving the proposal itself.
As wireless networking isn't a small thing, and this isn't going to be just porting something, this will need design work, some redefinition of Sana-II networking API for Amiga, GUI thought for user interface in scanning for and selecting access points for connection/disconnection, we need advice on a decent encryption API so we can more easily add in new encryption methods via libraries or plugins or whatever, and other features that may not be in B/G/N at home so we can add WiMax, Radius, etc. whenever we are able to do such things.
Would this need any work in the host TCP stack as well, such as Roadshow, or can a wireless framework live cleanly (without hacks) outside of that? (and thus be compatible with Miami and others as well).
What would a robust and open encryption plugin/librari API look like, so that we could have separate plugins/libraries for WEP, WPA, WPA2 (if separate from WPA1), others that I don't know to name here, and hopefully any future encryption methods that come later?
What other features need APIs? Radius? If not now, how do we make something open to enhancements like that later on in clean ways?
Anyone know anything about cell phone network stuff co comment on how that may fit into things, for uses such as cell phone tethering, cellular networking cards, SIM card data involved, etc.
What else can anyone think of?
I'd like to see some technical discussion rather than "great idea, me too" stuff.
Wireless is no longer just for portables. Many people now use it for Tivos, Nintendo Wii's, and desktops rather than running ethernet cabling through their walls.
I actually use one of these in my second bedroom to get my Amiga 4000's connected and it works very well and I don't even have to think about it once it's initially configured.
I think that there was an earlier discussion about it, and the conclusion was that we needed a proper wifi driver stack instead of SANA-II wifi drivers. This would handle all of the common things that wifi drivers must do, and provide the networking system with the additional info that is necessary for handling multiple wireless connections (enabling, for example, firewall settings to be made on a per-access-point basis, instead of a per networking device basis).
Getting a working wireless stack, device drivers and a working supplicant for amiga systems could keep the entire developer population in entire amiga land busy for years to come. In other words - it will never happen.
kolla wrote: Getting a working wireless stack, device drivers and a working supplicant for amiga systems could keep the entire developer population in entire amiga land busy for years to come. In other words - it will never happen.
Maybe if the goal were to write something from scratch. Given that Roadshow is based on the BSD network stack (just like so many networking stacks that came before), it might be possible to take existing BSD code as a starting point. That would pull the task from "many years" into the doable range.
I was only talking about the wireless stack, not the IP stack.
If you feel you have spare time you want to kill, then feel free to have a go at the various 802.11 frameworks in the various BSDs and/or Linux kernel, and port wpa_supplicant or open1x, or the opensea supplicant... come back in 5 years and show us what you have running :)
Why do I have such confidense? I've been working with wireless professionally since 2002 and have seen how long it has taken on all the widely used platforms to get things going, and none of them are by any means done yet.
I think that there was an earlier discussion about it, and the conclusion was that we needed a proper wifi driver stack instead of SANA-II wifi drivers.
The bounty proposal is for a common wireless framework/stack, not for a driver. I'd like to get discussion happening on stack API design. But seems not many here want wireless stack. :( I'm looking forward to learning more about the AROS wireless stack bounty, maybe that will suit us as a port.
Would this need any work in the host TCP stack as well, such as Roadshow, or can a wireless framework live cleanly (without hacks) outside of that? (and thus be compatible with Miami and others as well).
Chances are quite high that you would need to fix things on the IP stack as well. It depends on how well written the IP stack is, but currently on amiga, they're all pretty darn old and lacks alot of features that one can take for granted on other platforms. I can imagine the lack of tcp window scaling for example to be a problem, just to mention one issue.
Quote:
What would a robust and open encryption plugin/librari API look like, so that we could have separate plugins/libraries for WEP, WPA, WPA2 (if separate from WPA1), others that I don't know to name here, and hopefully any future encryption methods that come later?
What other features need APIs? Radius? If not now, how do we make something open to enhancements like that later on in clean ways?
You obviously don't know where radius fits in here :) RADIUS is the protocol that your access point/access controller uses to authenticate users against a radius server, nothing the supplicant (the software on your machine) needs to know anything about. This is used for WPA/WPA2 Enterprise and various EAP methods on the supplicant (EAP-TLS with client sertificate authentication, EAP-PEAP/PEAPv0 with micrsoft MSChapV2 authentication packages, EAP-TTLS with user choosable second method, MSChapV2 or PAP or whatever) where you have a sentralized user database to authenticate with. Note that for all this to work, you also need working ssl framework on the client side, typically by linking the supplicant with openssl or gnutls; the supplicant is in essense talking authentication packages inside an SSL tunnel implemented in EAP messages over RADIUS protocol with a RADIUS server.
The difference between WPA and WPA2 is on what encryptions that is used on the _radio_ signals, where WPA only has TKIP and WPA2 allows user to chose between several methods, such as CCMP/AES.
Quote:
Anyone know anything about cell phone network stuff co comment on how that may fit into things, for uses such as cell phone tethering, cellular networking cards, SIM card data involved, etc.
Tethering is just doing a dial-up and talking PPP with your cell phone - it can easily be done already if you can manage to provide a serial link between the amiga and the phone. I've done it with both UAE and Amithlon, using Miami. In other words - not related to "wireless" at all. (OTOH there are phones that also can act as wireless access points, but for those you don't need to worry about anything but wireless (WEP or WPA/WPA2 PSK) - no idea if this also goes under "tethering")
Quote:
What else can anyone think of?
I can think of quite alot, but I wont bother to list it all up here, it would be too much :)
Quote:
I'd like to see some technical discussion rather than "great idea, me too" stuff.
I can think of quite alot, but I wont bother to list it all up here, it would be too much :)
Well I do thank you for the things you did mention. No, I don't know much about Radius or a lot of things. I only had one networking communications class at university about 13 years ago, plenty of time to forget and no wireless was talked about back then, only basic TCP/IP things, so I of course cannot claim to know much. Though you seem very pessimistic, however realistic that may be from you, I will still wish for a decent wireless framework in AmigaOS.
I was only talking about the wireless stack, not the IP stack.
And I was also talking about the wireless stack too. My point was that the IP stack is based on BSD code, and so a BSD wireless stack might be a good fit. One major difficulty is that Roadshow is based on BSD4.4 (IIRC), which is from the mid-nineties. There's a good chance that this makes working on a wireless stack a waste of time until Roadshow is updated, which was discussed in the gigabit ethernet thread. I think that an updated IP stack should be a higher priority, anyway.
Quote:
If you feel you have spare time you want to kill, then feel free to have a go at the various 802.11 frameworks in the various BSDs and/or Linux kernel, and port wpa_supplicant or open1x, or the opensea supplicant... come back in 5 years and show us what you have running :)
Why do I have such confidense? I've been working with wireless professionally since 2002 and have seen how long it has taken on all the widely used platforms to get things going, and none of them are by any means done yet.
Once again, my suggestion is to leverage the work already done on another platform instead of starting from scratch. Yes, it would still be a lot of work, but it would be a lot less than writing one from scratch.
Added to this, I find people saying "it's too much work," and "it's too hard," rather annoying. I've been working on my RadeonHD driver in my spare time for two years now, and I'm still working on it. However, thanks to me just getting to work, we're now in a position where we can soon take advantage of a new motherboard with a 16x PCI-Express port. If I had been a wimp and said "this is too much work," then the A1-X1000 would be looking less enticing with a (approx. ten year old) PCI Radeon card as graphics card.
So, I encourage developers to think creatively, sub-divide the problem into manageable chunks, and work on them one by one. Take a slightly longer term view of things. If we only work on stuff that can be achieved quickly, then we're never going to move forward. Engineering is no place for wimps.
I agree that it's frustrating to see apparent discouragment of daunting tasks. If we all gave in to "it's too much work", then you're right, nothing would ever happen, and we'd all still be using MS-DOS thinking that is great stuff. Linux, AmigaOS, OSX, and Windows 7 would have never happened either. Sure, things take a lot of time, especially in tiny markets like ours here, but at least the thought process and learning experience are enjoyable to me, even if I don't get anywhere, so I will continue my ludicrous quests.
Just checked that out, and that's looking pretty good. It's been done by the same guy who wrote the prism2 driver that Amiga OS 4 users use. Still no WPA2, but WPA support is welcome.
However, it looks like it's still a SANA-II driver, and thus there's still no proper wireless stack. Still, a working SANA-II driver is much better than nothing.
Hans wrote: Still no WPA2, but WPA support is welcome.
Adding WPA2 should be reasonably straightforward, as it can be done in hardware.
Quote:
However, it looks like it's still a SANA-II driver, and thus there's still no proper wireless stack. Still, a working SANA-II driver is much better than nothing.
What would it need to be "proper"? The included WirelessManager is a port of wpa_supplicant, and this component handles scanning, association, setting up of encryption, and other management functions. It has the advantage that it should in theory work with all existing TCP/IP stacks. Enabling enterprise features is probably just a matter of linking with necessary libraries such as SSL.
Adding WPA2 should be reasonably straightforward, as it can be done in hardware.
Good to hear.
Quote:
What would it need to be "proper"? The included WirelessManager is a port of wpa_supplicant, and this component handles scanning, association, setting up of encryption, and other management functions. It has the advantage that it should in theory work with all existing TCP/IP stacks. Enabling enterprise features is probably just a matter of linking with necessary libraries such as SSL.
Oh, I thought that WirelessManager was a tool specific to that device driver. My apologies if this is not the case. Specifically what I meant was a stack that manages all wifi devices (logins, encryption, etc.), and provides the TCP/IP stack with whatever additional info wireless connections usually provide.
One thing that I think is important is to be able to have per-wireless access point firewall settings as opposed to one setting per wifi card. Yes, I know, our firewall has no GUI, but I see this as important. I can't see how you could achieve this with a SANA-II driver, or without some modifications to the TCP/IP stack.
While you're here, are you going to make an Amiga OS 4.x version?
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
