My application communicates with several GSM electric controllers, that means that I have to send anywhere between one to twenty messages every few hours. right now I'm working with HUAWEI Mobile Connect - 3G. it is a USB device that uses a comm port for the pc communication and I'm using GSMComm to send messages and read/delete messages from the device.
Every two seconds I'm checking the device's storage, and if there is any message, I will then read it and store it locally and then clear the device's storage. I'm not sure if I'm working correctly, but it seems to me as if it is a very unreliable device:
Every time I boot my machine, I must remove the device from the USB or my machine will get stuck at the BIOS start up screen (or whatever the name is).
Very frequently the comm port can become unavailable for some reason. I have to close and re open the port, and at times that may not even help.
In the production machine of my client, when he uses one of his software's that utilize the first comm port, he will get a warning message from the software about problems in the port if the device is plugged in (the device port is around 28 or something).
If you've been using a device which you consider reliable, or have been working with the same device as I work with, or you just think that I'm doing it wrong, I'd like to get an advice from you.
Thanks.
This sounds like an issue with your modem. Have you tried any other models? Consumer USB models tend to be unreliable. The preferred method, though slightly more expensive, is using a commercial grade modem in situations where you need the reliability.
Some modems to look at:
Wavecom Fastrack
Sierra Wireless Airlink
These use a serial port or ethernet to communicate with the host which is far more reliable. Serial ports may not be available in your particular situation but even a USB to RS232 adapter will be more reliable.
One further option is to use a smartphone, there are several applications that you can act as a gateway through HTTP.
SMS Gateway for Android:
https://market.android.com/details?id=eu.apksoft.android.smsgateway&hl=en
i have not used this method, but it seems like some people are having luck with it. it may not be any more reliable then your USB modem though.
Hope that answers your question.
I have used WaveCom's modem for sending messages in bulks and found it to be reliable. One difference though, in my implementation was i used Kannel as an SMSC, so my queues were automatically handled by Kannel. But sending multiple requests like 40+ per minute didnt pose any problems for me.
Hope this helps.
Related
I have an issue where WiFi is not available on an Android device. We want to stream image data from the device using a websocket server (written using WebSocket++) through to the PC. However, I'm not sure if this is possible without operational WiFi. So, the position we are in is that we may only have the USB link available.
Someone today suggested we might be able to get Websockets working using adb port forwarding (see https://developer.android.com/studio/command-line/adb#forwardports), but I'm not sure if that's correct. Could this work, and what would that solution look like?
Are there any other reasonable options. I'm not certain if tethering is available on the device and if that could be another solution?
To make it simple, lets assume my company makes cables. I need an easy tool to validate that our cables fully support 100Mb Ethernet connection without any package lost. Is there a program / tool which can perform a full speed test of like an hour and monitor the lost packages as well?
Thanks!
You might have some luck with iPerf. It can stress-test a network connection and measure packet loss. You'd put an iPerf server at one end of the cable, and run the client on a machine at the other end.
To validate a twisted-pair cable for Cat-5e, Cat-6 or Cat-6A you need a professional cable tester (starts at 1000€ or so). Everything else is just try and error. You cannot seriously certify a cable using commodity hardware and some software.
First allow me to say that I don't have any experience developing drivers for OSX, nor drivers for Windows. So, there are a lot of things that I don't understand about how drivers work; I'm sure it'll be evident in my question.
I have a modem that is able to open and close TCP/UDP sockets using AT commands. I would like to create some kind of program (kernel extension? driver?) that implements a network driver, converting the network interface calls into AT command serial messages.
That's the basic jist of it. I'm essentially asking if anybody can point me in the right direction / give me a high level overview of how they would approach it and what Apple guides to focus on.
The XNU networking stack -- like most network stacks -- expects network devices to send and receive IP packets directly. It isn't tooled to work with network devices that handle part of the network stack (like TCP or UDP) internally -- it won't be possible to implement a network driver which uses this device.
You might have more luck exposing this device as a SOCKS proxy. You will need to write a userspace daemon which listens on a TCP port on localhost (on the computer) and relays traffic to the serial device; once that's done, you can set the computer to use that device as a SOCKS proxy in the Networking control panel.
(As an aside: most devices that implement this type of interface have a very low limit on the number of open sockets -- often fewer than 10. They're unlikely to be able to handle the network load generated by a desktop OS.)
i am working on a network discovery program which employs snmp to discover devices in the network. My program takes the router-ip as input, scans the iprotetable(iprouttenext hop),to determine if any other routers are connected to it. for non router devices (like switch) the algorithm scans the arptable (ipnettomediatable) of the router, but cant find the connected switch unless i ping from the switch to the router. is there any way where i can determine the device connected directly to the router ..?
Getting the devices connected to a router or switch is not that easy. Switches usually maintain a MAC forwarding database where it stores which MAC address has been seen on which switch port. This table can be easily read by using the bridge MIB. Unfortunately, there are several issues to take care of:
Those entries disappear again, when a device to the switch has been switched off or is simply not communicating. Usually, the entries in the MAC forwarding tables age out after 5 minutes or so.
The fact that a MAC address has been seen on a switch port doesn't mean that the device having the mac address is directly connected to the port. There might be any number of other switches, routers or hubs inbetween.
Some manufacturers like Cisco or HP use their own protocols to determine the network topology. There are several protocols (that area usually also available through a SNMP MIB):
CDP (Cisco Discovery Protocol): This is a proprietary protocol developed by Cisco to expose network topology information. Some vendors licensed this technology and implement that protocol in their products.
LLDP (Link Layer Discovery Protocol): A standard similar to CDP, but without paying Cisco license fees :-)
And many more. I know kthat Extreme Networks has their own protocols and I am pretty sure that other vendors have them as well.
The problem with those protocols is when you have a mixed environment. Cisco switches talking CDP do not understand Extremen Network's protocol and vica versa.
If your goal is to find IP addresses to discover, then you might use the ARP caches for routers. Scanning the ARP caches for switches makes no real sense, because they're operating on layer 2.
I was using broadcast message for my java snmp agent
I discovered almost accidentally that my machine was sending and receiving UDP packets to a machine in Poland. Not that I have any problem with Poland, I just don't know why my laptop has the need to communicate with a server there. Reverse DNS shows just the ISP providing the address to some end user. Using Wireshark, I can monitor the messages, which were indecipherable as they were probably encrypted. All packets sent from my machine had the same source port, so clearly the application that sent them opened this UDP socket to use it. I am searching for ways to:
1) enumerate all current sockets open in the system, including the process that created it and, for both TCP and UDP, what ports and addresses they are current bound to.
2) because applications can open these sockets, use them, and close them right away, I would love to find (or perhaps even write) a program that once started would somehow get notification each time a socket gets created, or really more importantly when bound to a source and/or destination address and port. For UDP, I would love to also be able to monitor/keep track of the destination IP addresses and ports that socket has sent messages to.
I don't want to monitor the traffic itself, I have Wireshark if I want to view the traffic. I want to be able to then cross reference to discover what application is generating the packets. I want to know if it is from a process I trust, or if it is something I need to investigate further.
Does anybody know of any applications (for the Windows platform) that can do this? If not, any ideas about a .NET or Windows API that provides this capability, should I want to write it myself?
Edit:
After further research - looks like the APIs to use are GetExtendedUdpTable and GetExtendedTcpTable, CodeProject.com has some samples wrapping these in .NET (see http://www.codeproject.com/Articles/14423/Getting-the-active-TCP-UDP-connections-using-the-G). So a combination of this API and some sniffer code would be needed to monitor and keep track of what hosts at what ports using what protocol any particular application on your machine is talking to. If I ever get some free time, I'll consider creating this, if you know of an app that does all this, please let me know.
Try SysInternals TCPView. Despite its name, it handles UDP as well.
netstat -b to enumerate all ports along with the process names.
You can try using SysInternals' Process MOnitor (ProcMon.exe or ProcMon64.exe).
It allows for filtering of Processes by "UDP Send" Operation - and provides detailed UDP Connection data, including source and destination addresses(IP) and ports etc.