I am struggling with my code in devkitpro trying to get this program to connect to the Internet. It says it connects, it gets an IP address.
However, how do I read from the Internet and verify that it is even writing my data to the socket? This is a very tough devkit due to the lack of or quality of the documentation. I need some help on this.
EDIT: I'll post the code when asked for it. It is long and needs cleaning up.
The socket code in devkitPPC/libogc closely mirrors the BSD sockets interface. The main differences are that functions are prefixed with net_ (net_socket, net_connect, net_send, etc), net_select() is not implemented, and in most cases the error codes are returned from the functions themselves, not with errno.
If you've created a socket and connected it to a remote server, you've probably figured this out already!
However, how do I read from the Internet and verify that it is even
writing my data to the socket?
The same way you would on on a PC! Open a connection with net_socket() and net_connect(), read and write data with net_send() and net_revc(), call net_close() when done.
Check return values from these functions to determine whether the operation succeeded or failed. Most functions return < 0 when an error has occurred. You will also have to initialize the Wii network hardware and obtain an IP address first.
This is a very tough devkit due to the lack of or quality of the
documentation.
Very true. Some system headers are documented using Doxygen, unfortunately network.h isn't. However, as the interface is similar to BSD sockets, most socket tutorials or examples can be applied.
I'll post the code when asked for it. It is long and needs cleaning
up.
Post some code and I'll do my best to offer more help.
Related
On my STM32F7 I have to connect a 3G modem using serial port.
I can communicate with the modem using AT commands.
I would like to use PPPos (PPP over serial) library from LWIP to enter in PPP mode. So I take a long look at the official documentation
http://lwip.wikia.com/wiki/PPP
and
https://github.com/tabascoeye/lwip/blob/master/doc/ppp.txt
I understand the guideline but I'm really surprise there is no implementation example with serial port. Indeed, I think there is a lot of modems that have a serial interface, so I thought i can easily find an example of use.
Anyone have already done that or has an example ?
While I cannot publish my example, the general idea when it comes to integrating TCP/IP stack of your choice with its PPP driver is the same among all serial modems and all TCP/IP stacks that I've worked with.
Generally as you've mentioned, you start with configuring the modem using AT commands - things like checking whether SIM card is present, whether it requires PIN, specifying PIN if needed, checking if it has successfully registered in the network. Possibly reading additional information data such as IMEI, IMSI as well as diagnostic data: signal quality, BER etc. Once you're done, you switch the modem to "data" mode (see ATD*99), wait for the modem to respond to that command and pass the responsibility to the TCP/IP stack, as at this point the modem starts talking PPP.
When it comes to integrating your modem with the stack so it can communicate with it, the implementations I've encountered all require implementing some form of low-level API functions for the stack. For LwIP, the wiki page you've linked in the "PPP over serial" section, it is described quite well how those functions should behave. Because TCP/IP stacks are just a software library not tied to specific hardware and they can be run on almost anything (assuming sufficient resources), specific API implementations such as the one discussed are not always provided - there would have to be a ton of examples for it to provide any value. Although if you google around for it, you might find someone having done it for the MCU that you use personally. Assuming you've already done the part where you successfully comminicate with your modem using AT commands, it shouldn't be much more other than using the send/receive functions you already have. Some slight changes may be required, such as adjusting their behavior (synchronous->asynchronous or vice versa) or redirecting received data to the TCP/IP API receive function instead of your AT command parser. Nonetheless, most of the necessary hard work should be done already.
Once the TCP/IP stack takes over, you continue with the modem using provided stack PPP API. For LwIP see functions such as: pppSetAuth, pppOverSerialOpen. Those will cause the stack to internally handle the necessary communication with the modem over PPP: LCP, PAP/CHAP, IPCP. Once that part is done (you retrieve IP configuration data from the network) it becomes transparent how this operates - it becomes one (of possibly multiple) network interfaces and you use it just as any other one, for example using socket API.
I'm building an application that needs to modify DHCPv6 packets dynamically before they hit the wire. I'm doing some heavily proprietary work with DHCPv6 vendor options, and I need the ability to examine and modify those options in-memory before they are transmitted.
I've built a proof-of-concept layered service provider on top of Winsock by modifying the Microsoft sample code. It intercepts outgoing HTTP packets, changes the referrer-agent to something funny, and sends the packet on its way. Verified in Wireshark, works great.
It was also straightforward to change my installer code so that my LSP gets chained in on top of UDP/IPv6 rather than TCP/IPv4, and now, with a debugger attached, I can see myself getting callbacks with stacks leading into the DHCP server. However, I can no longer see the buffers in memory.
WSPSend and WSPConnect don't get called, since we're on a connectionless protocol--that makes sense. I do get a consistent callback in WSPSendTo but the lpBuffers member, which in my HTTP prototype contained the buffer representing the outgoing packet, is NULL.
Am I going about this completely the wrong way, or is there another Winsock operation I need to override? I'd be happy to go in another direction if an LSP is the wrong way to go, but outside libraries are a very tough sell for this application--otherwise, I'd be looking at Winpcap.
EDIT: Wow, this was a long time ago. For those coming behind me, this ultimately worked fine. I'm embarrassed to say that the issue was that I was compiling with optimizations that prevented me from seeing the correct data in the debugger. When I stopped being lazy and dumped the bytes to a file, I saw that all was well.
LSP does can only intercept Winsock traffic, DHCP is at a lower layer, you need a different technology to do this, for example: NDIS, TDI (Will not work on Win8) or WFP (Will not work on XP)
I am implementing a messaging system using C++ and Qt. After much thought, I have determined that multicasting or a multicast-style technique will work best to solve my problem. However, I have learned about UDP's unreliability and believe it to be unacceptable.
My requirements are as follows:
Messages are to be sent in a binary serialized form.
From any given node on the network, I must be able to send messages to the other nodes.
Message delivery must be insured.
I have heard of OpenPGM and NORM as alternatives for UDP. If anyone has experience with either of these, could you please share?
I am also open to the possibility of implementing "reliable" multicast by myself, in the application layer, but I would prefer not to if there is a library that already implements this.
I am using C++ and Qt, therefore .NET or Java-based solutions are not acceptable unless they are open-source and I may port them to C++.
Thank you very much.
EDIT 20120816T1853 MDT: An additional question: would either PGM or NORM have to be implemented at the hardware/IP level? Or can they be overlayed on top of existing protocols?
We have implemented our own reliable multicast protocol over UDP called RSP, since we needed something cross-platform and at the time couldn't find a good solution between Linux and Windows. The Windows PGM implementation disconnects slow clients which leave the send window, whereas our implementation throttles the sender similar to TCP. Afaik OpenPGM can be configured to do the same.
The open source NORM at http://cs.itd.nrl.navy.mil/work/norm can be built as a library and has C++ API with Python and Java language bindings. If you ping the developer (me) via the mailing list, I can help get you started.
There is a large RFC division of reliable multicast protocols, and many implementations out there. It's a long time since I looked at this but there are TRAM, LRMP, ...
I maintain an application that uses the win32 EnumPorts() function to help determine the set of serial ports installed on the computer. I have seen cases on some computers where the call to get this information fails with a GetLastError() code of 1722 (RPC server is unavailable). I assume that this has something to do with either registry settings or a required service being disabled but my search so far has been rather fruitless. Has anyonw else encountered this issue?
In answer to Euro Micelli's comments. I am specifically attempting to fill a pick list that will allow the user to choose an available picklist. To begin with, I relied exclusively on EnumPorts() to provide me a list of potential serial port names. It has proven to be unreliable, however in several senses: It has not always provided the complete set of port names and, as I have recently seen, it can fail to function altogether when the "RPC service is unavailable". Why RPC is needed to find out what ports are available on the local machine is completely beyond me but there it is. This latter problem was the final straw. So far as relying completely on the list of names provided, i filter these names using the GetDefaultCommConfig() function to determine the exact nature of each of the names that I came up with.
In my experience, the list of names provided by the previously mentioned registry key has been the most reliable method for getting port names. As a matter of fact, I can see the key get updated as I disable port drivers in the device device manager. Under normal experiences, I would agree with the assessment that relying upon a particular key is fraught with peril. In this case, however, M$ has never provided a decent mechanism to evaluate the names of available ports.
I should point out that I have already replaced the call to EnumPorts() with an algorithm that scans the registry key: HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM for serial port names. This should resolve the issue once my software is released. What I am after is pointers that can be given to customers who are using the released package at the present.
I'm not an expert on EnumPorts, but I strongly advice against relying on registry keys.
Key definitions might change in the future.
Key definitions might not be what you think.
There might be ways to "be a serial port" which don't include those keys.
The keys might not reflect up-to-date status, etc. etc.
You should always rely on the APIs available.
If an API doesn't behave for you, let's try to figure out why. Maybe with a little extra information we can help better:
What is it exactly that you need to do with the serial port?
There are a lot of weird serial ports these days: USB serial cables, Bluetooth, cell phone modems with GPS,... It might be something plugged into the computer and long forgotten since.
To find out which port is causing the problem you could try going into device manager, select "Show hidden devices" in the "View" tab and deleting them until the problem goes away. That might allow you to zero in on the problem.
I know it's not a direct answer to your question, but have you considered using a different method for enumerating the serial ports? In my applications I use the Setup API, using code from P J Naughter's website: http://www.naughter.com/enumser.html, and I find it works well.
I know this question is extremely old, but I stumbled onto it today, and noticed no-one gave an explanation.
The reason for RPC is because you're calling a spooler function - you are asking the print spooler to return a list of printer ports, which happens to include the COM ports in most cases. I believe this may explain your slightly unreliable results.
RPC is used to pass the request from your process to the active spooler process, and the RPC Server is unavailable message occurs when the spooler service is not running (or not responding properly).
I have an installation program (just a regular C++ MFC program, not Windows Installer based) that needs to set some registry values based on the type of Internet connection: broadband, dialup, and/or wireless. Right now this information is being determined by asking a series of yes or no questions. The problem is that the person doing the installations is not the same person that owns and uses the computer, so they're not always sure what the answers to these questions should be. Is there a way to programatically determine any of this information? The code is written in C++ (and optionally MFC) for Windows XP and up. .NET-based solutions are not an option because I don't want to have to determine if the framework is installed before our installation program can run.
To clarify, the issue is mainly that wireless and dialup connections are not "always-on", which creates a need for our product to behave a different way because our server is not always available. So a strictly speed-measuring solution wouldn't help, though there is a setting that's speed dependent so that the product doesn't try to send MB of information through a dialup connection as soon as it connects.
[I have no idea how to get exactly the information you asked for, but...] Maybe you could rephrase (for yourself) what you try to accomplish? Like, instead of asking "does the user have broadband or dialup", ask "how much bandwidth does the user's internet connection have" - and then you can try to answer the rephrased question without any user input (like by measuring bandwidth).
Btw. if you ask the user just for "broadband or dialup", you might encounter some problems:
what if the user has some connection type you didn't anticipate?
what if the user doesn't know (because there's just an ethernet cable going to a PPPoE DSL modem/router)?
what if the user is connected through a series of connections (VPN via dialup, to some other network which has broadband?)
Asking for "capabilities" instead of "type" might be more useful in those cases.
Use InternetGetConnectedState API to retrieve internet connection state.
I tested it and it works fine.
I found this document which can help:
http://www.pcausa.com/resources/InetActive.txt
Regarding the question "is the internet connection permanent or not?":
best way would be probably to make the app robust enough to always cope with a non-permanent connection :-) which would work the same with dialup and broadband...
alternatively, maybe you can find out how long the user's internet connection has been established already, and compare with system uptime? If the connection has been online for almost as long as the computer was running, it's probably a permanent connection.
Anyway, these heuristics will probably fail for obscure connection types.
Also, regarding the point about not sending lots of data: if people have a "broadband + low traffic limit" tariff, you shouldn't send lots of data either even if bandwidth allows :-)
Best bet would be to grab the default active network connection, ensure it is an internet connection (ping google.com or similar) and then ask it what type of device it is. You should be able to determine from that what connection the user has.
I'm fairly confident this is possible, but not sure how to go about it though.
I think you should just do a quick connection-speed test. Just download some specific sized files, time how long it takes, and you'll know the speed. I agree with the other guy, don't ask them what type of connection they have, what's more important is the speed. Perhaps next year they come out with 100mbit dialup...do you want everyone using this amazing new device to get the crappy lowbandwidth version of your app?
I would agree with oliver, as you imply: you have the functionality already to cope with connection loss, why not enable it by default.
Broadband connections can get messed up to: routersoftware that freezes (happens a lot to me), or poweradapter that fries, ...