Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Smart Response never received by clients #164

Open
wieb18 opened this issue Oct 28, 2019 · 6 comments
Open

Smart Response never received by clients #164

wieb18 opened this issue Oct 28, 2019 · 6 comments
Assignees
Labels

Comments

@wieb18
Copy link

@wieb18 wieb18 commented Oct 28, 2019

OS Windows 10 64 bit & Packet Sender v6.2.3

Hello,

I am trying UDP Smart Response but doesn't work as expected.

The UDP Smart Response packets never received by clients.

Here is the detail:

1. UDP Smart Response setting

image

image

2. UDP packet test

image

I am using 2 UDP clients for this test: 192.168.0.242 & 192.168.0.243.

When client received UDP packets then it will reply with message "RECEIVED xxx BYTES FROM xxx, PORT xxx"

3. Smart Response on 192.168.0.243

image

As could see on the above image, there is no received messages when Smart Response send UDP packet.

But when I copy and paste the Smart Response ASCII and then manually send it. The 192.168.0.243 successfully received it.

4. Another test, Smart Response on 192.168.0.242

image

Same as 192.168.0.243 above, this issue also happen on 192.168.0.242. Not received anything when Smart Response send UDP packet.

image

But when manually send it, the UDP packet successfully received by client.

Is this a bug or am I wrong on using Packet Sender?
Thanks for the answer.

@dannagle

This comment has been minimized.

Copy link
Owner

@dannagle dannagle commented Oct 28, 2019

Thank you for the detailed report. Smart Responses work by exact string matches. Have you tried sending just UNIXTIME by itself? Then you should (hopefully) get your UNIX:{{UNIXTIME}} response.

If you want Packet Sender to reply to everything, regardless of data, you can use the "basic response with macro support" feature.

Smart Responses is overdue for some upgrades, such as making it search/replace any text or perhaps support even regex, but this has not been high priority.

Hope that helps.

@dannagle dannagle self-assigned this Oct 28, 2019
@wieb18

This comment has been minimized.

Copy link
Author

@wieb18 wieb18 commented Oct 29, 2019

Hi,

Thank you for the response.

I am very sorry for my poor English. Maybe because my poor English, you misunderstood the main problem.

Smart Response works perfectly, always reply every time when the 2 clients send specific string (UNIXTIME string) into it.

But this issue is not about Smart Response reply capability. Packet Sender Smart Response works perfectly, NEVER miss to reply.

The main problem is: although Smart Response always reply, but the reply packet (UDP) frequently received on clients side.

After few days looking at Packet Sender traffic log, here is the comparison:

  • Manually send: 100% received on clients side
  • Smart Response reply: maybe only 5% - 10% received on clients side

My guess:

  • On manual send, beside 100% displaying the traffic in Traffic Log, also actually 100% send the packet.
  • On Smart Response reply, 100% displaying the traffic in Traffic Log, but NOT 100% actually send the packet.

Here is the recent Traffic Log:

image

As you could see, Smart Response always send reply ("UNIXTIME;xxxxx") after receiving specific string ("UNIXTIME"), NEVER miss to reply. But the reply packet SOMETIME received by clients (client answering with "RECEIVED xxx BYTES), but MOSTLY not (clients not answer).

Maybe this problem is because:

  1. Smart Response use different routine/function/class than Manual Send on Sending Packet
  2. Because use different Sending routine/function/class:
  • On Manual Send, packet actually send and also displaying it in Traffic Log
  • On Smart Response, always displaying in Traffic Log but NOT actually send the packet (that is why the clients SOMETIME received the reply packet but MOSTLY not received anything)

Please help.

@dannagle

This comment has been minimized.

Copy link
Owner

@dannagle dannagle commented Oct 29, 2019

OK, I didn't realize you were detailing an intermittent problem. These can be very hard to track down. I'll need to wait until I get back to my lab to set up a proper test and troubleshoot. Probably this weekend. I'll flag this ticket as a bug.

@dannagle dannagle added the bug label Oct 29, 2019
@wieb18

This comment has been minimized.

Copy link
Author

@wieb18 wieb18 commented Oct 29, 2019

I know it will be very hard to track down this bug.

But please focus on Smart Response (specifically UDP) Sending Packet routine/function/class. I think this bug is in there.

Although Traffic Log displaying Smart Response already send the reply but its actually NOT 100% sending the packet. Just use 2 or 3 UDP clients and you will know sometime UDP packet received by clients, but most of the time the clients never received UDP packet from Smart Response reply.

Finally, thank you for all your help. Hope Packet Sender update version which free of this bug will be release soon.

@dannagle

This comment has been minimized.

Copy link
Owner

@dannagle dannagle commented Nov 3, 2019

@wieb18
I finally got a chance to look at this. I've been running tests, and so far it seems OK. Maybe I am missing a setting that helps trigger it.

Will you email me your packets.ini and ps_settings.ini ?
You can email it to hello@packetsender.com

In Windows, these files are found in your local %AppData%.

For example, assuming your windows name is wieb18:
"C:\Users\wieb18\AppData\Local\PacketSender\packets.ini"

@wieb18

This comment has been minimized.

Copy link
Author

@wieb18 wieb18 commented Nov 4, 2019

Found only ps_settings.ini and didn't find packets.ini in that folder.

Here is my ps_settings.ini file:

[General] checkforUpdatesAsked=true packetIPEditSession=192.168.0.241 persistentTCPCheck=true udpPort=4210 udpServerEnable=true checkforUpdates=true packetHexEditSession="54 45 53 54 49 4e 47 46 41 4c 53 45 " tcpPort=3000 sslPort=0 udptcpComboBoxSession=UDP packetPortEditSession=4210 sendReponse=false resendEditSession= responseName=<Load..> responseHex= tcpServerEnable=true sslServerEnable=true serverSnakeOilCheck=true attemptReceiveCheck=false delayAfterConnectCheck=false resolveDNSOnInputCheck=false ignoreSSLCheck=true sslCaPath= sslLocalCertificatePath= sslPrivateKeyPath= restoreSessionCheck=true copyUnformattedCheck=true rolling500entryCheck=false asciiEditTranslateEBCDICCheck=false cancelResendNum=0 multiSendDelay=@Variant(\0\0\0\x87\0\0\0\0) ipMode=4 packetSavedTableHeaders=Send, Name, Resend (sec), To Address, To Port, Method, ASCII, Hex packetTableHeaders=Time, From IP, From Port, To IP, To Port, Method, Error, ASCII, Hex smartResponseEnableCheck=true responseIfEdit1=UNIXTIME responseIfEdit2=UTIME responseIfEdit3= responseIfEdit4= responseIfEdit5= responseReplyEdit1="UNIXTIME;{{UNIXTIME}}" responseReplyEdit2="UTIME;{{UNIXTIME}}" responseReplyEdit3= responseReplyEdit4= responseReplyEdit5= responseEnableCheck1=true responseEnableCheck2=true responseEnableCheck3=false responseEnableCheck4=false responseEnableCheck5=false responseEncodingBox1=Mixed ASCII responseEncodingBox2=Mixed ASCII responseEncodingBox3=Mixed ASCII responseEncodingBox4=Mixed ASCII responseEncodingBox5=Mixed ASCII cloudPassword= updateLastChecked=2019-11-04 07:43:02

I am also send ps_settings.ini to hello@packetsender.com
Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.