Avaya Embedded Configuration Protocol

[Bob]

Using WireShark to try to discover what is bringing down a small business
network I maintain. Security system with 14 cameras was recently installed
with a GenIV NVR running on the same 1Gb network. Max bandwidth for the
security video is around 20Mb, so that’s not the problem

Finally got some data that shows an av-emb-config protocol from each camera
(the source) using port 2050 and broadcasting to port 5050 as the
destination and WireShark shows malformed packets at the same time that the
firewall log shows its rebooting.

Not asking for troubleshooting advice but has anyone any knowledge of what
the av-emb-config protocol is used for? The cameras do have an option for
Bonjour, no audio options. WireShark shows thousands of entries of the
av-emb-config protocol using the port combination of 2050 / 63297 and no
errors. Firewall reboots only when the port combination of 2050 /5050
(mmcc) is used.

Here's the kicker. All 14 cameras start kicking out malformed packets in the
av-emb-config protocol at the same time. The firewall - from what I've
found, will consider it an attack and obviously reboots and knocks down the
network for a few minutes, then restores operation.

I've set up some new rules to block ports 2050 / 5050 to see if that is a
temporary fix. Would like to know why this protocol uses ports 2050 / 63297
all day long and then at some point switches and uses ports 2050 / 5050 and
produces malformed packets.

What is this protocol doing and why? Goggled till the cows came and
went.....

Thanks,

BobS

[Jorgen Grahn]

On Mon, 2013-05-06, Bob wrote:
...

> Here's the kicker. All 14 cameras start kicking out malformed packets in the
> av-emb-config protocol at the same time. The firewall - from what I've
> found, will consider it an attack and obviously reboots and knocks down the
> network for a few minutes, then restores operation.

I don't administer firewalls, but I find it unlikely that a firewall's
correct response to a perceived attack is to reboot. Not only does it
hurt valid traffic: it makes it forget about the "attack", so that it
reboots again when it persists. IMHO this is what you should look
into rather than those broadcast packets.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Rick Jones]

Jorgen Grahn <grahn...@snipabacken.se> wrote:
> I don't administer firewalls, but I find it unlikely that a firewall's
> correct response to a perceived attack is to reboot.

Agreed.

rick jones
--
Don't anthropomorphize computers. They hate that. - Anonymous
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

[Bob]

"Rick Jones" wrote in message news:km8oak$vvj$3...@usenet01.boi.hp.com...

Jorgen Grahn <grahn...@snipabacken.se> wrote:
> I don't administer firewalls, but I find it unlikely that a firewall's
> correct response to a perceived attack is to reboot.

Agreed.

rick jones

But.... unfortunately that is the nature of the beast for *some types of
attacks* according to tech support. It varies but ~20 hits in one second
and the house of cards comes down. Without the video system - this network
stays up for months with no reboots. I have logs showing many DoS, and SYN
Flood attacks over time and the firewall stays up. This is an internal UDP
Flood attack and it only takes 20 hits and it reboots. If I enable "Block
UDP Flood", it then blocks the internal addresses forever. A bug obviously
but NetGear doesn't have a fix yet.

So anyone know anything about the av-emb-config protocol? I am working with
the manf rep and tech support - no answers yet (amazing right...) so that’s
why I came here.

Thanks,

BobS