I have a set of automated UI tests for our iOS app, written with XCTest.
It was required for some test cases to be verified in bad network connection conditions.
I am aware that it is possible to simulate bad network connection by using Network Link Conditioner. I know that you can enable it in settings of a real device and a simulator as well. There seem to be only manual steps involved in enabling and setting the desired state.
But, I was wondering if it was possible to automate this process - how would you go about running a suite of automated tests on the CI (if some of them are to be tested in bad network conditions)?
We are not using real devices for automated testing.
I do not have the access to the machines running test suites for CI.
I do not have a dedicated machine that could always have NLC enabled and set, nor can I manipulate network itself (router etc).
We do not use mocks in our tests.
Unfortunately, bad network connection/no network connection is not easily testable with XCTest and there is no easy way to set something like this up.
There are (generally) two ways to solve this:
1/ implement some kind of network connection issues to your network-communication methods and run them when running UI tests
2/ test on real device with slow internet connection set in settings.
Unfortunately - slow network connection cannot be set on Simulator nor on Mac server (which you are probably using for your CI) by default and 3rd party tools are not very good in this either.
Related
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 am supporting development of a client application that will be communicating to a seperate enterprise service bus. We have our own black box services to develop against. We each host multiple REST endpoints (using RESTeasy) to communicate.
One scenario we need to demonstrate to our client is sudden loss of network connectivity between my client application and their ESB with later network restoration. In the client demonstration, they plan to have separate workstations connected by a router and pull the cables for a few minutes and then reconnect them.
My question is that, while keeping both app running in eclipse on my workstation, can I temporarily block them from making successful REST requests to each other and then restore the connection? As best as possible to simulate the demonstration objective of pulling the network cables.
OS X El Capitan; Eclipse Neon; Jetty 9.2.7
Self Answer:
Not as elegant as I would like, but works because the endpoints are already compile-time configurable.
Add an entry to /etc/hosts for a volatile domain pointing to 127.0.0.1
127.0.0.1 volatileDomain
Configure my endpoints to point to volatileDomain.
Start both apps.
Edit and save /etc/hosts to comment out the volatileDomain line.
Watch disconnection logic handle the current state.
Edit and save /etc/hosts to reintroduce the volatileDomain line.
Watch reconnection logic reestablish the connected state.
Now that the WP8 Emulator is based on Hyper-V, the old method of using Fiddler to intercept network traffic doesn't work if the network uses IPSEC.
Is there a way to use Fiddler and a WP8 emulator in such a scenario?
Fiddler with exactly the same setup as on WP7 (https://fiddler2.com/fiddler/help/phone.asp) works absolutely fine for me.
You grab the traffic from the host system, so the guest (the WP8 emulator) has to bypass that too.
If it doesn't work let me know, but for me and others I know, it runs without any issues.
I finally found the answer at http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj684580(v=vs.105).aspx
On a corporate domain, the emulator appears as a separate network device that is not joined to the domain. As a result, you may also
have to get an exception from your IT department before the emulator
can connect to services that are running on the domain-joined
development computer.
A network security exception was required.
You will probably have to use something like wireshark which works at a sub-protocol level and can therefore intercept anything.
Note that analysis won't be nearly as easy as it is in Fiddler though. Also, HTTPS connections might be impossible to analyze because of the whole man-in-the-middle attack prevention brought on by the protocol and certificates and such.
With my limited resources and to aid debugging, I am doing local testing on a client-server (game) application by running both a server and one or more clients all on my Windows 7 dev PC. Both client and server are Java applications developed through Eclipse.
Is there any easy way to introduce lag given that everything is running on the same PC... maybe 'hack' the port used or something? Or is this only possible if each application is running on a separate PC (or separate VM)?
Make a feature in the server which makes a random lag within certain time range if detected connection comes from localhost. You can then switch this feature on/off as needed.
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.