I have a Raspberry pi with SIM900 GSM module. currently i am using ttyUSB0 as pppd but i also want to send AT commands (send/receive SMS) to SIM900 while pppd is active. I was created multiple virtual serial ports (like gsmtty1,gsmtty2 etc) but those are not working with screen/minicom.
While these virtual serial ports might work (assuming you are talking about the kernel's 07.10 multiplexing support), your first attempt should be to use the other serial device, e.g. /dev/ttyUSB1.
This is assuming the modem provides two serial endpoints, which it is not absolutely required to do, but virtual all modems that support USB does, so I would be very surprised if it really only had one.
Notice that the 07.10 multiplexing protocol requires explicit command and implementation support from the modem and is specified in a 3GPP specification which was created in the 90-ties to cater for the lack of multiplexing in the serial interfaces that were in use at that time (RS-232, IrDA, bluetooth).
But it required dedicated driver support on the operating side, and for windows there was no default drivers supplied so you had to install something additional (and I think the quality of those were not so great either) so 07.10 never got any serious momentum. Today USB's native multiple endpoint support have in many ways obsoleted the 07.10 protocol.
Related
I'm in confusion that will an I2C device get detected in raspberry pi even when there
are no device drivers and DTS files related to it.
Will it show up when we use this command
ls /dev/i2c-*
and are we able to detect its address when I try to probe using
i2cdetect -y bus_number
In short:
... when there are no device drivers and DTS files related to it.
Will it show up when we use this command
ls /dev/i2c-*
No. This command will list available I2C buses, not devices.
and are we able to detect its address when I try to probe using
i2cdetect -y bus_number
Maybe. In most cases yes.
A bit more elaborated:
Depending of what kind of I2C device it is, and what you want to do with it, you might still be able to communicate with it.
driver - best case
If you have relevant device tree change to describe this I2C device (on what bus it is located, its address, extra signals if needed - like interrupt pin, etc) and associated driver is present (built-in or as a module, check *_defconfig options in Linux kernel source) - driver should probe device during either boot or manual module loading.
Why best case? If you have a driver you don't have to think about protocols and programming, and, as an example, reading a value from ADC device might be as simple as:
root#pi:~# cat /sys/bus/iio/devices/iio:device0/in_voltage0_raw
291
i2ctools
Another approach would be to use i2cget/i2cset tools from i2ctools package. No device tree changes needed. With these tools you can talk with any unclaimed I2C device on any enabled I2C bus in device tree.
You'll need to implement communication with I2C device by your own. From security and stability perspective - IMO this is the worst case to go, but is good for hardware debugging and, in some cases, initial bring-up.
Example is here.
Note regarding i2cdetect - this command tries to detect devices on particular bus, but gives no warranty. As per man i2cdetect:
As there is no standard I2C detection command, i2cdetect uses arbitrary SMBus commands (namely SMBus quick write and SMBus receive byte) to probe for devices.
Summary:
I am guessing that the issue here is something to do with how Windows and Linux handle TCP connections, or sockets, but I have no idea what it is. I'm initiating a TCP connection to a piece of custom hardware that someone else has developed and I am trying to understand its behaviour. In doing so, I've created a .Net core 2.2 application; run on a Windows system, I can initiate the connection successfully, but on Linux (latest Raspbian), I cannot.
It appears that it may be because Linux systems do not try to retry/retransmit a SYN after a RST, whereas Windows ones do - and this behaviour seems key to how this peculiar piece of hardware works..
Background:
We have a black box piece of hardware that can be controlled and queried over a network, by using a manufacturer-supplied Windows application. Data is unencrypted and requires no authentication to connect to it and the application has some other issues. Ultimately, we want to be able to relay data from it to another system, so we decided to make our own application.
I've spent quite a long time trying to understand the packet format and have created a library, which targets .net core 2.2, that can be used to successfully communicate with this kit. In doing so, I discovered that the device seems to require a kind of "request to connect" command to be sent, via UDP. Straight afterwards, I am able to initiate a TCP connection on port 16000, although the first TCP attempt always results in a RST,ACK being returned - so a second attempt needs to be made.
What I've developed works absolutely fine on both Windows (x86) and Linux (Raspberry Pi/ARM) systems and I can send and receive data. However, when run on the Raspbian system, there seems to be problems when initiating the TCP connection. I could have sworn that we had it working absolutely fine on a previous build, but none of the previous commits seem to work - so it may well be a system/kernel update that has changed something.
The issue:
When initiating a TCP connection to this device, it will - straight away - reset the connection. It does this even with the manufacturer-supplied software, which itself then immediately re-attempts the connection again and it succeeds; so this kind of reset-once-then-it-works-the-second-time behaviour in itself isn't a "problem" that I have any control over.
What I am trying to understand is why a Windows system immediately re-attempts the connection through a retransmission...
..but the Linux system just gives up after one attempt (this is the end of the packet capture..)
To prove it is not an application-specific issue, I've tried using ncat/netcat on both the Windows system and the Raspbian system, as well as a Kali system on a separate laptop to prove it isn't an ARM/Raspberry issue. Since the UDP "request" hasn't been sent, the connection will never succeed anyway, but this simply demonstrates different behaviour between the OSes.
Linux versions look pretty much the same as above, whereby they send a single packet that gets reset - whereas the Windows attempt demonstrates the multiple retransmissions..
So, does anyone have any answer for this behaviour difference? I am guessing it isn't a .net core specific issue, but is there any way I can set socket options to attempt a retransmission? Or can it be set at the OS level with systemctl commands or something? I did try and see if there are any SocketOptionNames, in .net, that look like they'd control attempts/retries, as this answer had me wonder, but no luck so far.
If anyone has any suggestions as to how to better align this behaviour across platforms, or can explain the reason for this difference is at all, I would very much appreciate it!
Nice find! According to this, Windows´ TCP will retry a connection if it receives a RST/ACK from the remote host after sending a SYN:
... Upon receiving the ACK/RST client from the target host, the client determines that there is indeed no service listening there. In the Microsoft Winsock implementation of TCP, a pending connection will keep attempting to issue SYN packets until a maximum retry value is reached (set in the registry, this value defaults to 3 extra times)...
The value used to limit those retries is set in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxConnectRetransmissions according to the same article. At least in Win10 Pro it doesn´t seem to be present by default.
Although this is a conveniece for Windows machines, an application still should determine its own criteria for handling a failed connect attempt IMO (i. e number of attempts, timeouts etc).
Anyhow, as I said, surprising fact! Living and learning I guess ...
Cristian.
I have a requirement to transfer/multicast a large file about >40g of file from a server to multiple clients at the same time and this will be done for only once. Is there any good protocol to do that in Linux? I tried using UFTP, but it didn't work.
UFTP should be a good tool for this situation. If the server and clients are on the same LAN, there shouldn't be any issue with them communicating. If there are one or more routers separating them, then you would either have to configure routers to allow multicast traffic to pass or you could use UFTP's proxy servers to create a bridge between different network segments.
You could use the excellent bittorrent protocol and make it private by using Bittorent Sync.
Go to Bittorrent Sync Web Site for details.
The main advantages I see are :
It's design to transport large files (if you have a network disruption it's not a problem)
It's free
It's cross plateform : Windows, Linux (i386, x64, ARM, PowerPC), FreeBSD, Mac, Android, IOS, and more ...
It's secure (you provide the encryption keys)
It's quite simple to configure
We have acquired a 4 channel GSM Gateway, model GoIPx4-G610 (the manual is titled "GoIP Series SIM Card for GSM Voice Gateway - GSM VOIP Gateway").
We are looking to develop a custom application to control the GOIP gateway. We have developed in the past custom applications that controlled simple GSM modems through AT commands for sending/receiving SMS messages in particular.
Although the gateway can be controlled through SIP we would like to control the GSM modems embedded in the gateway through AT commands if possible. This is because of the fine grained control AT commands offer and because we do not need VoIP features since we need only to send/receive SMS messages.
The gateway runs an unknown Linux instance to which we can connect through telnet. Unfortunately we do not have the credentials to authenticate to it. The gateway also has a web http administration interface to which we can authenticate but we can't find there settings/information related to channels that we can use for AT commands.
The documentation is very poor and the provider could not offer us any helpful information regarding this.
If anyone knows how we can send AT commands to the modems inside the gateway it is highly appreciated.
Up to now we have tried a brute force attack on the telnet interface to find the credentials with no success. We hope that once we can connect to the Linux instance driving the gateway we can connect from there to the modems through serial connections (to send AT commands) and we can reconfigure it to redirect the connections outside of the modem or to make an interface for sending commands to the modems.
The device has an update firmware option (through the web interface) which always gives the error "download failed". Downloaded the firmware (.pkg file) manually from their update pages and extracted the files from the embedded Linux distribution that should correspond to the ones placed on the gateway. The files were kept in the pkg file as an ROMFS compressed image which we mounted on a test station to see the files (probably the running OS on the gateway is an uClinux distribution).
Did this hoping that we can find there the /etc/passwd file which could be cracked with classic attack. However didn't found it and probably that file is placed on the gateway flash memory (contrary to the Linux files which are stored on the ROM memory). So if there is a way to erase / reset this flash memory that could be a solution (in case the gateway doesn't refuse to boot without those files). Another solution would be to be able to access the flash memory with the passwd file if there is such thing.
You might take the lid off and see what parts are inside.
If it's a general purpose processor with a published data sheet and without a lot of code security features, you might be in luck. For example, you might find:
By guessing headers or tracing from known pins, a console serial port, either logic level or RS232, hopefully with a shell listening
A boot mode pin for the micro connected to a resistor, which you could jumper to cause the micro to boot to a uart bootloader where you could download a new system image, or patch the existing one. If you are lucky the bootloader would be something known, like u-boot.
A JTAG port for the processor
A removable storage device which you could remove and alter
an SPI flash which you could carefully tap into and alter
A flash chip which you could desolder and transplant to a programmer
You could also make a GPL sources request for the kernel and whatever else from the vendor. Or even just trying to identify versions of things like a web server could help you look up any known exploits. Since it seems you have a similar system image to that which is installed, looking through it could be helpful - look for additional daemons running, listening on ports you weren't previously aware of, left over debug support, etc.
I am the developer of the GoIP you've purchased. Instead of trying to hack the GoIP, did you contact us to support your development of custom applications? Here are the updates of GoIP for you.
GoIP now supports SMPP. This could be an alternative to using AT commands to send and receive SMS.
API (Application Programming Interface) for GoIP is now available to support your custom application development.
If AT commands are still the preferred method, please contact us and I would be happy to discuss with you further.
Setup:
I have client C connecting to server S
Both C and S are on the same machine
In C the server address is hardcoded to 127.0.0.1. Likewise, in S the client address is hardcoded to 127.0.0.1
Problem:
I want to be able to sniff the traffic between the client and the server.
Due to the configuration, I cannot move the client nor the server to different locations (the address are hardcoded)
Installing the loopback interface and using tools like Wireshark+WinPcap doesn't lead anywhere (was actually already known but was worth a try)
RawCap, suggested in another topic, doesn't work. IP 127.0.0.1 is listed, but does not record any traffic.
Using rinetd to route the traffic elsewhere, as suggested here doesn't work (cannot bind on 127.0.0.1)
Not interested in using a HTTP local proxy, such as Fiddler, because I'd like to capture also other protocols
Two commercial tools work, specifically CommView and Local Network Monitor, which means it must be possible to do that ;)
How can I do to capture the traffic?
Any pointer on functions I should use or documentation I should read?
Thanks!
Basically you need to write a TDI filter driver to achieve that... for some pointers see:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff565685%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563317%28v=VS.85%29.aspx
Another option is to write a WinSock LSP.
BEWARE
Since Windows 8 it is strongly encouraged to use WFP (Windows Filtering Platform) for this sort of thing...
Although it might be more cost-effective to just use/buy an existing solution - esp. if you are not a very experienced driver developer...
Use RawCap, which can solve your concerns, see this