sgstair

Ok, I just went back briefly through the code you posted here on the board and the reason you have those warnings is because you did not include all of the data from the files when you combined everything in this case you're missing information about struct sockaddr (should be in sys/socket.h) I really don't have the time to look after your project though, so if you managed to leave out other necessary stuff, you'll have to figure it out on your own. It's really not hard to use the libraries in a compiled form and there are many people on the boards and elsewhere who will be happy to help you get it working. -Stephen

bitwise or is | logical or is || you probably mean logical or, like if(a<5 || b<5) "If a is less than 5 or b is less than 5" "waranty message"? I'm not sure what you mean, can you be more specific? -Stephen

Of course, then your problem becomes how to service interrupts that happen every two clocks. Not sure you can do a great deal in that amount of time. <{POST_SNAPBACK}> blah, you don't need to service an interrupt every 2 clocks, just read whenever you like and you get a cycle accurate count. -Stephen

Technically the DS timer system can operate at a maximum resolution of about 33MHz, I think. (which is 32 times more accurate than a microsecond timer) -Stephen

Yes, or add the file to be linked into the project. -Stephen

The wifi lib is compatible with most all 802.11b APs, and many 802.11g ones as well. -Stephen

Well, good luck with that - I think it would have been a lot easier to just fix the makefile issues than to combine ALL the files into one - but hey, if it works, more power to you. You asked about a pc-side copy - the udp test app linked (udp_test.c) is for unix, but I see you're working on a windows system. I've uploaded my PC-side source to http://akkit.org/dswifi/udp_test_win.cpp - this code should compile under windows with a sufficiently recent version of winsock and a decent compiler. -Stephen

yorel: I think I begin to see your problem in doing this :\ Do you realize that the library is precompiled for general purpose use? You can just make a very small program (or base a program off of the "wifi_lib_test" source) and include the libraries. -Stephen

yorel: do a full rebuild and post all of the warnings somewhere - I beleive you have a problem with include paths, or you may have modified part of the lib to introduce some problems (either of these would cause all of those warnings) On a side note... fischju: I know you're trying to be helpful but you're not really helping - let people speak for themselves please. -Stephen

Heheee, I can type it perfectly with no trouble - maybe my calibration is more accurate or something. However, I will be adding a "string" input to allow easier sending of a single line like that, probably in the next version. -Stephen

if you don't connect via DHCP, the router may not know the DS's IP - this is ok though, it's not necessary. -Stephen

The current test library doesn't support DHCP to get an IP automaticly - this is coming soon though! In the meantime - Outgoing TCP support has been added! see the first post for more information. -Stephen

yorel: The only thing I can think of is that you have your include directories set up wrong somehow. The code in the lib compiled on my end when I posted it, though there were a number of pitfalls as far as moving the project to anyone else's computer. If you can wait a few more days, the new lib version features an all new build system which should be able to build on any computer without issue. -Stephen

Yeah, I get your idea, but this really isn't the purpose.. I'm sure someone else will write such an app once I've released the next lib though. -Stephen

well, fact is it doesn't.. it does change eventually.. and Ive seen a few 0% accesspoints on mine before too.. its all about moving away from the AP, and give it a few seconds to update the speed.. yeah <{POST_SNAPBACK}> Actually this won't take much effort to add, I'll put it in the next version. -Stephen

Yes, the packet capture option is a packet sniffer - I'm thinking about letting it write to a file on gbamp/etc too, but getting it working is the first priority -Stephen

k, see the first post again. -Stephen

Hi all, There's an available version of the wifi lib test v0.3 at akkit.org/dswifi/wifi_lib_test_.nds (Added by request: akkit.org/dswifi/wifi_lib_test_.ds.gba) This is a work in progress, several menu items do not work, but they will all be filled in when the release is done. At present: * WEP works * DNS works * Outgoing TCP Works! * incoming TCP is done, no test yet * DHCP Lives! * Connecting via WFC settings works! and, * packet capture option in menu doesn't work yet Feel free to experiment and leave your feedback here. I'll be updating this thread when more features are added In addition, I'll also be posting updates at a fairly new blog I've created. See blog.akkit.org If you want to test TCP but don't have a telnet server to connect to or don't know how to construct a valid HTTP request.... To download the website from a web server, connect to a site and type the following in (without quotes): "GET / HTTP/1.0" followed by tapping CR and CR -Stephen

Warlord: if you paid *any* attention at all, you'd know that I helped pepsiman get WEP working on dslinux in the first place. Now the only reason I haven't had it working in my lib is because a register we had no idea was even *related* to wep I had disabled in my code in the course of testing something else. Guess what? We know which register enables WEP now - but we *had* looked extensively at both codebases and not been able to find the difference. At any rate, it is working in both places now. (but PLEASE shut up about the documentation, nobody uses it, really. And, I've been modifying it *as* I modify the lib - yes, it's *already* updated with the latest knowledge I've collected and verified.) -Stephen

For the last time people, listen to me when I tell you *the DSLinux wifi driver is about 95% code from the dswifi lib* - hear that? I've said it entirely too many times now you guys (talking SPECIFICLY to you dudu & warlord because I've said the same thing multiple times around you guys and you don't seem to get it) Nobody uses the documentation; using the wifi is pain enough without it. -Stephen

You're running into the same wall I have; there are some ways around this but most of them I don't know of yet. However, the next library version (0.3) will use a trick (I'll be adding it to the documentation too - once I've verified it works) to capture all packets; it might be a good idea to build your app on the next version of the lib. (but hey, you don't have to) -Stephen

heh, this really isn't all that special yet, you know.... I mean, if you're wowed by the early 0.3 lib test.... you're going to be blown away when I actually get it done. And besides, the documentation *has* been evolving along with my release (And is posted in the usual place)... but even so, the documentation isn't *that* much better, most of the work being done is in the TCP/IP stack that comes with the lib. (seriously, nobody I know of has done anything impressive with the documentation itself, most every wifi project is based on my lib or the code to it) -Stephen

The baseband & RF chips make up the chipset that does most of the work involved in sending and receiving data. Specificly the RF chip is composed of a Phase Locked Loop translating a reference frequency into a specific transmit frequency, and a mixer, which "moves" a data signal into the RF domain. The baseband chip talks to the RF chip, and controls when to send and receive data, as well as handling buffering of the sending and receiving processes. a spinlock is a type of locking mechanism used in multithreaded interprocess communication, to ensure atomic data access. WIFI_AUTHLEVEL is an arbitrary specifier used to track the process of authenticating and then associating to an access point. BSSID is the base station SSID, or group SSID in the case of an ad-hoc network RSSI is Received Signal Strength Indicator Yes; the wifi hardware can *only* be used from the arm7. The reason I have a lot of code on the arm9 side is that I've written a transport interface that allows the arm9 to command the arm7, and tell it what to do basicly, and the data is transferred between the processors automaticly. Wifi_ProcessReceivedFrame is called whenever a frame is received; it's purpose is to detect certain types of frames (specificly: beacons, and authentication and associacion related packets) and to change the local state or local data store based on them. The function itself is large, but it's premise and layout is very simple. -Stephen

Well, while I don't think GameCop's statement is really related to the article, this is a valid example of macs being very insecure. From the article (and a quote from the hacker): "The only thing which has kept Mac OS X relatively safe up until now is the fact that the market share is significantly lower than that of Microsoft Windows or the more common UNIX platforms.… If this situation was to change, in my opinion, things could be a lot worse on Mac OS X than they currently are on other operating systems," Additionally, an excerpt from a digg thread comment: "There are many unpublished OSX flaws. I know a guy who submitted a serious vuln to them almost 8 months ago, and they are still fixing it (and asking him not to disclose until they fix). They really take their time unfortunately" This pretty much sums it up; I think Mac users presently largely fall into one of two groups: the "Sheep": apple-loving normal or technical users who if they manage to find a vulnerability, will report it to apple and happily stay quiet for however long it takes to fix, and the "Wolves": primarily technical users who have no predisposed resolution to apple, and who will be happy to keep exploits to themselves for personal gain should they find them. For PCs there's also another relatively large group that could be called the "shepherds": technical users who exist to (And are often paid to) find vulnerabilities and make a fuss about them until they're fixed - however this group is noticably absent or silent on the Mac OS platform. All of this really just says what I've been saying all along; Macs aren't safer than PCs, in fact they might be less safe. I agree completely with the hacker quoted in the article that if windows weren't the dominant operating system we'd be in FAR worse shape then we are now. On another related tangent, I despise macs too, for other reasons. Despite their claim to "just work" - when I was in high school they replaced all of our computers with imacs, and there wasn't a day I didn't have to fix less than 2 of them (not including the at least 4-5 freezes/crashes a day). Now, personally I could probably get along with a Mac just as well as I do with a PC - as it is I never have any system crashes on my PC and usually go 2-5 weeks between reboots. The simple truth is, whichever platform stupid people use, they'll screw it up. And I'll argue it's a lot easier to screw up mac osX than windows. -Stephen

C'mon indeed - I'm not being incredibly mean here, but I am being very clear. Apps that are useful to the coding community will be worked on, Apps that are not useful or interesting to the coders are just noise at the moment. Hey, given some time for the tools to mature - sure... but I've seen too much time wasted on impractical ideas and it's not a good thing until the lib / apps are more mature. As such, if you can't code you have no place asking for gigantic time investments at this time. But, hey, if some poor fool wants to try to port VLC to the ds (haha, hahaha) - heaven help 'em. -Stephen