Packets are not sending to wireless iface [Windows]

[lazna]

Using following command, packets are not going into wireless interface. Partialy confirmed by wireshark. Could someone else confirm this, please? Using actual version of program.

packetsender -uw 5000 255.255.255.255 10001 "01 00 00 00"

Windows 7/ 64bit

[lazna]

After years, today same thing happens (now on windows 10). Run command

packetsender.com -quw 1500 -B 192.168.1.236 255.255.255.255 10001 "01 00 00 00"

over wifi adapter Ralink RT3070 but PS do not print any output. Two replies come according to wireshark (see attached capture). When perfom same command via ethernet adapter Intel(R) PRO/1000 GT (just changed IP address) same two devices reply, and replies are correctly outputted by PS.

What am I doing wrong?

discovery_packed.zip

[dannagle]

Routers will sometimes filter out broadcast packets.

If the devices are connected to the Ethernet, the WiFi router may be filtering broadcasts and not letting those packets on to the Ethernet. Do you get responses if you unicast directly to the devices?

[lazna]

if you check the attached .pcap file, you will see there is a received response, but is not displayed by packetsender.com for some reason

[dannagle]

Your Wireshark capture looks OK to me. If it worked on Ethernet, it should work on WiFi. Packet Sender behaves the same on each. I see a packet going out port 60121 via broadcast and a response coming in to 60121.

The incoming with source address "0.0.0.0" is strange to me. It could mean some device is not configured. The one with the proper source address looks OK.

Couple things to try...

• Disable the Ethernet adapter before trying the WiFi test. This will force only 1 route and prevent any binding oddities.
• See if unicast directly to the device works properly before trying broadcast.

[lazna]

Finaly have time to perform more testing, and this issue is definitelly NOT binded only to wireless adapters.

Today I am tried several PCI and USB ethernet adapters with exact same command as used in previous posts, and it dow work only onone [Intel(R) PRO/1000 GT Desktop Adapter], on rest PCI and USB ethernet adapters I have tested it dows not work, but on ALL of them both wireshark and windump see received packets. So my result is, this packets are no properly "routed" to packetsender OR packetsender not "see" them for some reason, OR packetsender see packets but do not send it to STDOUT for some reason

Testing configuration of both testing machines:

desktop PC - Windows 10 / 64bit

1.\Device\NPF_{E0CBD3A5-CD3F-411A-A5E0-865A577960CA} (Realtek PCIe GBE Family Controller) 2.\Device\NPF_{1DC7EF94-0F1D-47B2-ABB7-6859539DF5B0} (Realtek USB NIC) 3.\Device\NPF_{D1BBB1AD-02D7-4243-B04B-E8EAC9F7C607} (Intel(R) PRO/1000 GT Desktop Adapter) 4.\Device\NPF_{8B5BFD9D-AEE3-4E39-BA4C-4832A59D77E8} (MS NDIS 6.0 LoopBack Driver) 5.\Device\NPF_{9EAD5B24-45C8-43DD-B4F4-929698F007DD} (TAP-Windows Adapter V9) 6.\Device\NPF_{33D2D49A-5D02-44A8-872B-AC37057B4ADE} (Oracle) 7.\Device\NPF_{E144A15D-DF70-48E4-9AA0-9EEC42B0CFF4} (Qualcomm Atheros Ar81xx series PCI-E Ethernet Controller)

tested USB adapters:

Corechip SR9900 Realtek RTL8153 AXIS AX88179 MosChip MCS7830

laptop Windows 10 - 64 bit

1.\Device\NPF_{203C263C-5461-48AD-8C07-F48722910CC4} (Microsoft) 2.\Device\NPF_{CAD330E0-E8E4-4AF7-A16C-478D9E41A724} (Intel(R) Ethernet Connection (3) I218-LM)

this "Microsoft" device is RTL8192EE wifi adapter

what can I do test more?

[dannagle]

This is really strange. Packet Sender has no code that is specific to adapters. It simply requests a socket from the OS to bind and the OS forwards incoming packet data to the app.

For the adapters that failed, did you disable all other adapters except the one you are testing with?

[lazna]

Juste tested on laptop: all other interfaces disabled, only Intel(R) Ethernet Connection (3) I218-LM enabled. No response, but windump.exe started in another cmd window see incomming packets..

[dannagle]

I tested wifi on my local set up, and it worked. (Yes, I know that does not help you). I used another Packet Sender GUI to send automatic {{DATE}} {{TIME}} replies on UDP.

My adapter: Realtek RTL8852AE WiFi 6 802.11ax PCIe Adapter

Another idea:

• There is a fairly recent Intel driver pack that mentions that card: https://www.intel.com/content/www/us/en/download/15084/intel-ethernet-adapter-complete-driver-pack.html

• Try force-binding to "AnyIPv4". That would be -B 0.0.0.0.

Here is my exact command that gave replies:

PS C:\Program Files\PacketSender> ./packetsender.com -quw 1500 -B 0.0.0.0 macwifi 56259 "01 00 00 00"


32 30 32 34 2D 30 39 2D 32 39 20 30 36 3A 32 35 3A 33 34 20 70 6D
PS C:\Program Files\PacketSender>

• What is the exact make and model of the adapter causing problems? I will order a one for myself to test. This is a strange issue.

[lazna]

UPDATE: its look like it depend on libraries present. When 'packetsender.com' started from directory where all libraries reside, than work fine. When started from direcory where only commandline necessary libraries reside, than failed (on some interfaces).

UPDATE2: Just download last version, unpacked WHOLE zip file into a new location, start command, but same situation. On Intel works, but not on others... So I am out of ideas now...

It depend on PS version !! tested on: Intel, Realtek and Qualcomm PCI adapters

Packet Sender Version 8.6.5 / SSL:OpenSSL 1.1.1m 14 Dec 2021 / Commit: de4f214 works on all adapters

Packet Sender Version 8.6.5 / Commit: de4f214 work on Intel only

Interesting thing is, that FileCompare program judge both .exe files as identical:

FC: no differences encountered

[lazna]

I think I found it !!

Its looke like firewall issue. Seems packetsender.com ask for permission and create two firewall inbound rules: one for UDP and second for TCP. If this rules was (accidentally) manually removed, packetsender do not ask for rules re-create, but incomming packets are filtered.

When user on firewall rule-creation prompt (accidetally) click on "cancel", Deny rule ic created instead "allow" one and packetsender no more ask for rule create which cause incomming packets are filtered.

This is by my observation now. So I have to check in my script allow rule existence PRIOR to run packetsender now.

UPDATE:

Now I have both allow rules created, but when dynamic source port used (no -b option specified) reply was not displayed in PS. When source port is specified, reply is displayed correctly. (reply received in both cases, as wireshark show me)

[dannagle]

Amazing. I just habitually create a firewall rule and never change the ports.

Thank you so much for diving into this. I hope others having trouble find this thread. I should of thought firewall earlier.

[lazna]

you are welcome. This script print all FW rules that are related to executable its 'path\name' contain string 'packetsender'. It outputed each rule per line hash separated values:

RuleName#Protocol#LocalPort#RemotePort#PathToExecutable#Direction#Action

hope it help someone who hounting such troubles. It need admin rights

powershell.exe "Get-NetFirewallApplicationFilter | Where-Object { $_.AppPath -like '*packetsender*' } | ForEach-Object { $appFilter = $_; Get-NetFirewallRule -AssociatedNetFirewallApplicationFilter $appFilter | ForEach-Object { $rule = $_; Get-NetFirewallPortFilter -AssociatedNetFirewallRule $rule | Select-Object @{Name='Output';Expression={\"$($rule.DisplayName)#$(if ($_.Protocol) { $_.Protocol } else { 'N/A' })#$(if ($_.LocalPort) { $_.LocalPort } else { 'N/A' })#$(if ($_.RemotePort) { $_.RemotePort } else { 'N/A' })#$(if ($appFilter.AppPath) { $appFilter.AppPath } else { 'N/A' })#$(if ($rule.Direction -eq 'Inbound') { 'Inbound' } else { 'Outbound' })#$(if ($rule.Action -eq 'Allow') { 'Allow' } else { 'Deny' })\"}} } } | ft -HideTableHeaders |out-string -width 999"

[lazna]

I tested wifi on my local set up, and it worked. (Yes, I know that does not help you). I used another Packet Sender GUI to send automatic {{DATE}} {{TIME}} replies on UDP.

My adapter: Realtek RTL8852AE WiFi 6 802.11ax PCIe Adapter

Another idea:

• There is a fairly recent Intel driver pack that mentions that card: https://www.intel.com/content/www/us/en/download/15084/intel-ethernet-adapter-complete-driver-pack.html
• Try force-binding to "AnyIPv4". That would be -B 0.0.0.0.

Here is my exact command that gave replies:

PS C:\Program Files\PacketSender> ./packetsender.com -quw 1500 -B 0.0.0.0 macwifi 56259 "01 00 00 00"


32 30 32 34 2D 30 39 2D 32 39 20 30 36 3A 32 35 3A 33 34 20 70 6D
PS C:\Program Files\PacketSender>

• What is the exact make and model of the adapter causing problems? I will order a one for myself to test. This is a strange issue.

What exactly means word 'macwifi' in your post?

And what exactly means '-b 0.0.0.0' or '-4' in cas ethere is multiple network adapters in the system? Should it send (in my case broadcast) packet to all adapters? Just trying it, andaccording wireshark packets was sent only to one adapter in both cases. This should be a bit more documented..

[lazna]

Back to the beginning :-/

Juste removed ALL firewall exceptions related to packetsender and test again. With my broadcast packet packetsender.com -quw 1500 -B 10.0.0.1 255.255.255.255 10001 "01 00 00 00" it do not open GUI box for asking FW permission, receive response packet (verified by wireshark) an every single interface I tested, but DISPLAY response only by Intel interface. I am check FW than, but not any rule was not added in background.

Thinking about it, we could cut out FW from our troubleshooting, because in this case wireshark will not see respond packet too, but it see it. So we are back on "routing" response to PS.

To be honest, I am out of ideas now....

[dannagle]

You questoin: "What exactly means word 'macwifi' in your post?"

I have a manual hosts entry for my macbook's WiFi address.

PS C:\Users\danie> ping macwifi

Pinging macwifi [192.168.1.240] with 32 bytes of data:
Reply from 192.168.1.240: bytes=32 time=287ms TTL=32
Reply from 192.168.1.240: bytes=32 time=100ms TTL=32
Reply from 192.168.1.240: bytes=32 time=99ms TTL=32
Reply from 192.168.1.240: bytes=32 time=100ms TTL=32

[dannagle]

• If you have another Packet Sender on the network with with automatic replies enabled listening on UDP port 10001, do those make it over?

• Does the destination address on the capture replies match your bind IP (10.0.0.1)?

• Broadcast packet behavior can be very unpredictable. Does everything work correctly if you use unicast?

[lazna]

You questoin: "What exactly means word 'macwifi' in your post?"

I have a manual hosts entry for my macbook's WiFi address.

Its better to avoid such things on troubleshooting conversations, becaus it could confuse people. 'mac' string could refer to MAC address and so on... Thanks for understanding.

[lazna]

hopefully got it now, and YES is it somehow related to FW:

if there is a two rules created by "packetsender.com -l" command in FW, it work on all my network interfaces including WiFi one.

If there IS NOT rules related to "packetsender.com" executable in FW, it only work on Intel interface. The only idea which comming to my mind is, that there is another (generic) rule in FW related to this interface, regardless to executable (but I am unable to found it now) or its caused by other unknown reason...

Addendum: By my opinion there is inconsistent behaviour when PS FW rules missing. If packetsender started in listening only mode (by '-l' option), than GUI prompt ask for rule creation. If packetsender start in "send packet than listen for answer" mode (my example from this conversation), it DOES NOT ask for rule creation thus packets not received by PS (but received by wireshark because thre are rules for wireshark). Omitting my intel adapter "specific behaviour" for now.