Solved

ARP Packets Dropped all of the sudden

Posted on 2013-12-19
20
636 Views
Last Modified: 2014-12-26
I have a branch building connected by a wireless bridge.  All of the sudden, the IP phones in the building will stop working, and I receive dropped ARP packets.  I have attached a screenshot of the Sonicwall packet capture window.

192.168.1.121 / 123 = ip phones
192.168.1.153 = the ip phone card in the main NEC box

Any idea what is going on??
trace.png
0
Comment
Question by:BullfrogSoftware
  • 11
  • 7
  • 2
20 Comments
 
LVL 1

Author Comment

by:BullfrogSoftware
ID: 39730268
Here is a detailed view of one of the entries:

ARP TYPE: ARP Request
 Sender MAC Address: 00:60:b9:05:f9:bc
 Sender IP Address: 192.168.1.153
 Target MAC Address: 00:00:00:00:00:00
 Target IP Address: 192.168.1.121
Value:[0]
DROPPED, Drop Code: 20, Module Id: 46, (Ref.Id: _705_jcpfngKpeqokpiCtrTgswguv) 1:0)

Open in new window

0
 
LVL 20

Expert Comment

by:carlmd
ID: 39731457
0
 
LVL 1

Author Comment

by:BullfrogSoftware
ID: 39731965
I applied the recommended policy, and now I have received a drop with a different drop code:

Ethernet Header
 Ether Type: ARP(0x806), Src=[00:60:b9:5c:fd:cb], Dst=[ff:ff:ff:ff:ff:ff]
ARP Packet:
 ARP TYPE: ARP Request
 Sender MAC Address: 00:60:b9:5c:fd:cb
 Sender IP Address: 192.168.1.123
 Target MAC Address: 00:00:00:00:00:00
 Target IP Address: 192.168.1.153
Value:[0]
DROPPED, Drop Code: 18, Module Id: 46, (Ref.Id: _594_jcpfngKpeqokpiCtrTgswguv) 1:0)

Open in new window

0
 
LVL 20

Expert Comment

by:carlmd
ID: 39732008
The following (depending on version of SonicOS)...

https://www.fuzeqna.com/sonicwallkb/ext/kbdetail.aspx?kbid=10505
or
https://www.fuzeqna.com/sonicwallkb/ext/kbdetail.aspx?kbid=10720

indicates it is in zones with "NULL source IP address"

Looking at this and the prior error, it seems that the address portion of the return packets are not not correct or missing entirely,

Have you changed or checked your zone entries?

Anything change on the wireless bridge?
0
 
LVL 1

Author Comment

by:BullfrogSoftware
ID: 39732731
I am now focusing more on the wireless bridge.  These are Engenius units.  The only thing that I can see that might be affecting packet traffic is Aggregation being enabled.  Anyone have any experience with Frame Aggregation and VOIP?
0
 
LVL 20

Expert Comment

by:carlmd
ID: 39732765
If it was just turned on, then I would turn if off and see what happens.

In fact I would just turn it off to see if it makes a difference.
0
 
LVL 1

Author Comment

by:BullfrogSoftware
ID: 39740010
I have chosen to leave this question open and delete the redundant questions.

The wireless access points are Engenius ENH500 units.

The phone system is an old NEC Aspire system.

I have also attached the dropped packet that was linked to the other question.  In this packet capture, 192.168.1.123 is the phone, and 192.168.1.153 is the VOIP card in the NEC box.

No. Time Source Destination Protocol Length Info
4 1819.050000 NecInfro_5c:fd:cb Broadcast ARP 64 Who has 192.168.1
.153? Tell 192.168.1.123 [ETHERNET FRAME CHECK SEQUENCE INCORRECT]
Frame 4: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Dec 23, 2013 14:32:03.100000000 Central Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1387830723.100000000 seconds
[Time delta from previous captured frame: 678.783334000 seconds]
[Time delta from previous displayed frame: 678.783334000 seconds]
[Time since reference or first frame: 1819.050000000 seconds]
Frame Number: 4
Frame Length: 64 bytes (512 bits)
Capture Length: 64 bytes (512 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:arp]
[Number of per-protocol-data: 1]
[Address Resolution Protocol, key 0]
[Coloring Rule Name: ARP]
[Coloring Rule String: arp]
Ethernet II, Src: NecInfro_5c:fd:cb (00:60:b9:5c:fd:cb), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: NecInfro_5c:fd:cb (00:60:b9:5c:fd:cb)
Type: ARP (0x0806)
Padding: 000000000000000000000000000000000000
Frame check sequence: 0x00000000 [incorrect, should be 0x99567da1]
Address Resolution Protocol (request)
Hardware type: Ethernet (1)
Protocol type: IP (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: request (1)
Sender MAC address: NecInfro_5c:fd:cb (00:60:b9:5c:fd:cb)
Sender IP address: 192.168.1.123 (192.168.1.123)
Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
Target IP address: 192.168.1.153 (192.168.1.153)
0000 ff ff ff ff ff ff 00 60 b9 5c fd cb 08 06 00 01 .......`.\......
0010 08 00 06 04 00 01 00 60 b9 5c fd cb c0 a8 01 7b .......`.\.....{
0020 00 00 00 00 00 00 c0 a8 01 99 00 00 00 00 00 00 ................
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Open in new window

0
 
LVL 24

Expert Comment

by:diverseit
ID: 39740759
As @carlmd suggested disable Aggregation and let us know if that makes a difference or not.

How was the L2 WLAN bridge configured? Are both Security Types now set to Trusted? Make sure both Zones have Allow Interface Trust checked (Network > Zones).

You can only bridge interfaces which belong to “Trusted” and “Public” Zone Types.

The interface bridge doesn’t change its Zone. Only an Allow Rule between bridge pair will be auto-added. Check other Rules, you may need to add them manually.

If the SonicWALL is the DHCP server, the WLAN clients can get an IP from the LAN DHCP lease scope on the SonicWALL. If there is a DHCP server you don’t need to create an IP Helper policy since the WLAN and LAN fall under bridge pair. No relay IP is needed. Double check you don't have them in place.

Waiting for your answers. Thanks!
0
 
LVL 1

Author Comment

by:BullfrogSoftware
ID: 39740778
I disabled Aggregation, and received the same problem when the phones behind the wireless bridge try to talk to the 192.168.1.153 talk card.

The real hard part here is that they will work, and phone calls can be made, then randomly, the user will pick up the phone and dial, and nothing will happen, dead air.  That is when this packet drop appears in the capture.  Every device in question here is in a trusted zone under the same local subnet 192.168.1.0.  The wireless bridge devices hold 160 and 161, the phones in question hold 121 and 123, and the NEC box holds 152, with the VOIP talk card at 153 ... and communication DOES happen sometimes, so no rules are in place that should block anything.  I am about to boil it down to an old phone system that needs to be replaced.
0
 
LVL 20

Expert Comment

by:carlmd
ID: 39741541
Do you have a backup wireless bridge that you could swap in?

How about obvious things like loose or bad cables or switch port? Have you tried swapping things around?
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 1

Author Comment

by:BullfrogSoftware
ID: 39741644
First instinct was to swap the switch behind AP 2 in the satellite building. No difference. I spoke with the telecom company. Seeing that they have several systems working with VoIP and these wireless units, they note that this is the only client using this particular, old NEC phone system in conjunction with the wireless units. They are planning to switch it out to see if it makes a difference.
0
 
LVL 20

Expert Comment

by:carlmd
ID: 39741650
The only problem with blaming the "old" phone systems is that you indicated that is was working fine, and then all of a sudden stopped. If nothing at all changed, its hard to blame the phones.
0
 
LVL 1

Author Comment

by:BullfrogSoftware
ID: 39741730
The only logic here is that communication ONLY breaks down between:

the IP of a phone behind the wireless bridge -> the 192.168.1.153 IP of the VoIP card

All other network communication stays solid (web browsing, applications, etc.).  

Because the phone company has other working systems using the same wireless hardware (proof of concept), this leads us to believe/hope that it is is just a matter of an outdated phone system over newer network tech (the phone guy says the system is at least 8 years old).

Thoughts?
0
 
LVL 20

Expert Comment

by:carlmd
ID: 39741743
I assumed that your initial comment "All of a sudden..."  meant that at one time, or for a while, everything worked ok, no problems. If that was true, then all phones behind the wireless bridge don't get "so old" all at once and stop working. Logic dictates that something common to "all phones" would be the culprit. Perhaps a software update, if not a piece of hardware or cabling.
0
 
LVL 1

Author Comment

by:BullfrogSoftware
ID: 39741748
Sorry about that, let me clarify ... 'all of the sudden' refers to 'any given day, at any point' ... not 'after years of wonderful service' :)

I think that my part of the investigation was to determine whether the SonicWALL settings were responsible for the interruption, which I believe I can say that is not the issue?

J
0
 
LVL 20

Accepted Solution

by:
carlmd earned 500 total points
ID: 39741761
So you are saying that this never worked reliably, correct?

If so, then I tend to agree that the phones could be the issue.
0
 
LVL 1

Author Comment

by:BullfrogSoftware
ID: 39741769
I believe that the phones in the satellite building have always dropped out since the installation of the wireless bridge, yes.  I will keep the post open and await the telecom company's results.
0
 
LVL 24

Expert Comment

by:diverseit
ID: 39770947
Any update on this?
0
 
LVL 1

Author Comment

by:BullfrogSoftware
ID: 39771108
We are still waiting for the phone company to switch out the system for a comparison test.
0
 
LVL 1

Author Comment

by:BullfrogSoftware
ID: 40519340
Replacing old phone system solved the issue.
0

Featured Post

Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

Join & Write a Comment

Join Greg Farro and Ethan Banks from Packet Pushers (http://packetpushers.net/podcast/podcasts/pq-show-93-smart-network-monitoring-paessler-sponsored/) and Greg Ross from Paessler (https://www.paessler.com/prtg) for a discussion about smart network …
This paper addresses the security of Sennheiser DECT Contact Center and Office (CC&O) headsets. It describes the DECT security chain comprised of “Pairing”, “Per Call Authentication” and “Encryption”, which are all part of the standard DECT protocol.
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…

760 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now