I wonder if ESME allows this config:
Client is connecting with same system_id as TX from one machine (first IP) and as TRX from another (second IP)
<--- TX (X.X.X.123)
[ MySRV ]
---> TRX (X.X.X.124)
As now seems that I sent Delivery reports to TX as I received it from it.
This should be programmed on software level right?
And malfunctioning is on my side?
Thanks for thoughts, just couldn't find similar situation on Google.
Regards,
Vedran
UPDATE: As I understand SMPP protocol more - if you encounter such problem you can always contact me. But at the end problem would be in your implementation.
We need to look a bit closer at your scenario.
If you use the TX session for DLRs (delivery reports) encapsulated in deliver_sm packets, then you are violating the specs and the malfuction is on your side.
A TX session is not allowed to receive deliver_sm packets. Checkout http://opensmpp.org/specs/SMPP_v3_4_Issue1_2.pdf, Section 2.3 for a list of allowed PDUs for different session states.
However it's possible to encapsulate DLRs in data_sm packets (added since smpp 3.4) too, which are allowed to be sent to a TX session. If you do this (although uncommon), it's up to you if you use the TX session or the TRX session. Do a round robin or use the session which originally sent the message, if still connected.
For compatibility reasons (as smpp 3.3 is still often used) I suggest to use deliver_sm for DLRs and therefore only send them to a RX or TRX session. So in your case it would be the TRX one.
Related
I have an application that is very simple. It sends out UDP packets to a client somewhere else on the network.
The host computer is 192.168.11.66 (Windows 10), the client device is 192.168.11.65 (proprietary device).
The host pc cannot see the client device, however I know that it is on and listening to traffic. When I send UDP packets from the host, I use Wireshark and I do not see the packets being sent out. Instead I see messages from ARP trying to locate the client. I assume because ARP is unsuccessful, the host cancels the sending of the packets.
If I change the destination address of the packets to a broadcast address, all of the packets get sent and I see everything on Wireshark. I need to be able to specify the IP address of the client and have Windows send the packets regardless of whether or not it thinks the client device is on the network or not. The client device looks for UDP traffic specifically addressed to itself and the client device has no way of making itself visible on the network.
Does anyone know how to work around this?
Thank you #Remy: instead to create your own ARP record manually. – Remy Lebeau
I did not realize that I could create manual entries in the ARP. I need to read more about ARP. Adding a manual entry solved my issue. I found that you could do it using ASP -s, or add neighbor using NETSH .
Thanks!
I am relatively new to JMeter however I have been doing Performance testing for almost a decade.
I am working with a proprietary TCP protocol that sends a keep alive periodically - through the existing TCP connection.
I am struggling to understand how I can fork the JMeter 'thread group' to handle a TCP Keep alive received over the same TCP session.
Any ideas?
Thank you brainstrust!
edit: I'm using the TCPsampler and have read the help page. I'll try to provide some more detail shortly about what's happening and how the protocol is written.
edit2: Unfortunately because it's a propriety protocol I cannot reveal the exact nature of the protocol itself but it's largely irrelevant to the problem I'm facing.
Basically, I use the 1st TCP sampler to 'start/authenticate' the session with the server. This is configured the following options:
1. TCPClient classname: LengthPrefixedBinaryTCPClientImpl (my protocol is implemented this standard way)
2. Re-use connection ON.
3. Close connection OFF.
4. Set NoDelay OFF.
5. SO_Linger: nothing
6. Text to send: my hex code for the protocol (this is correct)
I get the response from the first TCP request and then I want to start interacting, however in the session, the server sends a keep alive mid-stream, so occassionally when I send a request, I get an unexpected keep alive response instead (it's an open stream of data).
This is what I would like to solve.
I attempted to use a recursive test fragment, so that on KeepAlive response, it would send the request again however one cannot recurse the test fragments (it throws a Java error on Run attempt).
I hope this gives more context! Thank you for your patience (I'm a newbie SO user!)
Please check the below options if it helps with you sceario:-
If "Re-use connection" is selected, connections are shared between
Samplers in the same thread, provided that the exact same host name
string and port are used. Different hosts/port combinations will use
different connections, as will different threads. If both of "Re-use
connection" and "Close connection" are selected, the socket will be
closed after running the sampler. On the next sampler, another socket
will be created. You may want to close a socket at the end of each
thread loop.
If an error is detected - or "Re-use connection" is not selected - the
socket is closed. Another socket will be reopened on the next sample.
The following properties can be used to control its operation:
tcp.status.prefix text that precedes a status numbertcp.status.suffix
text that follows a status numbertcp.status.properties name of
property file to convert status codes to messagestcp.handler Name of
TCP Handler class (default TCPClientImpl) - only used if not specified
on the GUI
For more details:-https://jmeter.apache.org/usermanual/component_reference.html#TCP_Sampler
When I open the haproxy statistics report page of my http proxy server, I saw something like this:
Cum. connections: 280073
Cum. sessions : 3802
Cum. HTTP requests: 24245
I'm not using 'appsession' and any other cookie related command in the configuration. So what's 'session' means here?
I guess haproxy identify http session by this order:
Use cookie or query string if it's exists in the configuration.
Use SSL/TLS session.
Use ip address and TCP connection status.
Am I Right?
I was asking myself the very same question this morning.
Searching through http://www.haproxy.org/download/1.5/doc/configuration.txt I came accross this very short definition (hidden in a parameter description) :
A session is a connection that was accepted by the layer 4 rules.
In your case, you're obviously using Haproxy as a layer7/HTTP loadbalancer. If a session is a TCP connection, due to client-side / frontend Keep-Alive, it's normal to have more HTTP reqs than sessions.
Then I guess the high connection number shows that a lot of incoming connections were rejected even before being considered by the HTTP layer. For instance via IP-based ACLs.
As a far as I understand, the 'session' word was introduced to make sure two different concepts were not mixed :
a (TCP) connection : it's a discrete event
a (TCP) session : it's a state which tracks various metadata and has some duration; most importantly Haproxy workload (CPU and memory) should be mostly related to the number of sessions (both arrival rate and concurrent number)
In fact sessions were not introduced after but before connections. An end-to-end connection was called a "session". With the introduction of SSL, proxy protocol and layer4 ACLs, it was needed to cut the end-to-end sessions in smaller parts, hence the introduction of "connections". Zerodeux has perfectly explained what you're observing.
I`m working on a project about Man In The Middle Attack by ARP poisoning method.
In this project I need to work like as a router. For example suppose In My Lan there is two other device (a modem & a laptop). I says to laptop that I`m the modem to fraud it. whenever the laptop wants to send a packet to outside of the LAN, sends the packet to me!
All thing I need is I want to send the received packet to the modem & sends the response to victim laptop.
How can I do it programmatically?
Thanks a lot.
Ya Ali.
Well the first thing you need to do is perform the ARP poisoning attack. You can review how to do this in detail here.
One thing of note is that your middle-man PC must how be able to perform like a switch and forward out packets it receives in - It will be passing packets between the modem and the laptop in both directions.
I can't wrap my head around how packet-sniffers can be used by anyone on the network.
I know very little about how networks work, but let me put it this way: suppose the mailman comes around delivering a package to my doorstep. Why is is that I'm able to rifle though all his other packages and look around? Shouldn't the mailman only hand me packages that are mine?
To quote William Pursell's comment, which he should have made an answer and should have expanded:
The mailman does not deliver the letter your doorstep. Instead, he opens your mail and shouts out: "this letter is for <name>. No-one else should listen" and then proceeds to read the letter out loud. –
In the original Ethernet network, there was a shared cable to which all hosts were attached; if a host wanted to send a message to another host, it would transmit the packet on the shared cable, with an Ethernet header with the destination Ethernet address of the other host. All hosts on the cable could, in theory, see the packet. (This was in an era where security was less of a concern; for cases where security was a concern, the packets were encrypted in a fashion that the other host could fairly easily decrypt but that other hosts would have to decrypt in some other more difficult fashion.)
In addition, a packet can be sent to the "broadcast" Ethernet address (all 1's) or a "multicast" Ethernet address (which several hosts are configured to handle); broadcast packets are intended for all hosts on the Ethernet to see, and multicast packets are intended for all hosts in the address's "multicast group" to see.
Normally, an Ethernet adapter would ignore packets that aren't sent to its Ethernet address, to the broadcast Ethernet address, or to a multicast address for which it's configured to receive packets. Most can, however, be put into "promiscuous" mode, where they pass all packets to the host; that mode is used for packet sniffers.
Most current Ethernets are "switched"; instead of a shared cable, there's an Ethernet switch, and hosts plug into the switch with a cable. Packets sent to a particular host's Ethernet address will only be sent out the switch port for that host (unless somebody's configured the hosts to have a "mirror port" on which all traffic is sent, or unless the switch hasn't yet determined which port is the port for that Ethernet address). Broadcast packets are sent to all ports, and multicast packets may be sent to all ports or, if the switch can determine that, to those ports that have adapters configured for the multicast address in question.
Wi-Fi networks are similar, but they're usually protected with encryption, as it's easier for somebody to bring in a laptop and put it into "monitor mode" to sniff on a given channel than it is for somebody to bring in a laptop, configure a switch to have a mirror port (or use some other mechanism to get access to the traffic), and plug the laptop into the appropriate port on the switch.
Generally speaking, with switches you are correct. However the person who owns the switch can intercept your traffic at will (in your example that would be the mail service). Also, sometimes the switch can be fooled into rerouting traffic (someone accepts the package on your behalf and then goes through it).
Furthermore, certain kinds of packets need to be broadcast. For instance ARP packets (where one computer is asking for the ethernet address of another computer specified by IP) get broadcast to all ethernet addresses and therefore can get sniffed.
Generally speaking man-in-the-middle requires someone in the connection chain to be compromised. For instance, your ISP or the company they buy transit from could create a man in the middle attack. (This is also why security in countries oppressive regimes is so difficult, they control the internet and therefore can sniff/man-in-the-middle attack whatever they please). This can also be done by compromising the DNS server you use to point you to a different site that can grab your data and forward your data (or a modified version thereof) on to the true site.
In the good 'ol days hubs were quite common (or even older, everyone shared a piece of coax). In this case it's more like the package gets dropped on the first door, the occupant looks to see if it's theirs, if not, passes it on, if so, copies what's inside and passes the package along. In other words, packet sniffing is actually quite easy.
Yes or more simple way packet sniffing not is good, while you login on the web page you normal use a secret password for verify this is you.
But in case we has a packet sniffer she/he can also see and read what you password is.
And laiter login in the web page as you.
Or in she/he can also modify you data on the road to do something other.
And in the case of internet, the normal way is more the one computer is use to
send a message from in this case Alice to Alice bank.
And in each of this computer ( right side of image ) is this possible
for the use to edit the message if the use want as in this image.
Eva is use for deliver the message to Alice Bank, but she can
can read the message/order and in some case edit this to get the bank
to think Alice want to transfer money to Eva instead of Bob.
In short for protect us against eva to modify the message we can use
hash-algorithm or cryptographer algorithm.