[7.185] queue overflow due to ips - no packet going through [OPEN]

what other settings do you have enabled?

IPS, Transparent Proxy (HTTP & FTP), POP3 Proxy, AV (Dual Scan), Anti-Spam (POP3), Anti-Spyware, Site2Site VPN.

Very low load on the box, I was the only user active at that point in time.  Connections graph very clearly shows an exponential build.

I've been experiencing the same issues with even less functions enabled. The problem occurs 10 hours after the firewall has been started.

Here are the active functions on my ASG220:
IPS, POP3 Proxy, Remote Access PPTP

i have the same too. as far i know this is related to the IM /P2P filter. do you have that enabled?

Both IM and P2P control are disabled.

I killed the IPS and everything has been working spotlessly. Obviously, dropping IPS scares the dickens out of me.

I killed the IPS and everything has been working spotlessly. Obviously, dropping IPS scares the dickens out of me.

Hi guys, 

that is interresting. 

the ip_queue is the mechanism how we pass packets down from kernel to userspace. 
This is used for our ips engine snort as well as for our im/p2p engine afcd. 

2008:04:09-18:44:08 (none) kernel: ip_queue: full at 1024 entries, dropping packets(s). Dropped: 1
2008:04:09-18:44:08 (none) kernel: ip_queue: full at 1024 entries, dropping packets(s). Dropped: 2
2008:04:09-18:44:08 (none) kernel: ip_queue: full at 1024 entries, dropping packets(s). Dropped: 3

these loglines show that the queue inside the linux kernel has an overflow, means that the userspace process is no longer processing packets. 

This has happended in the two earlier beta versions for the afcd process, when it was in a futex() deadlock.

Based on your posting it seems that our updated snort process might have a similar issue. 

In order to track it down further two things are important if it happens the next time.

1) is IPS enabled, if yes, is the snort process running
2) is IM/P2P enabled, if yes, is the snort process running

If the queue is overflowing and the function is configured and the process is running, than we have indeed again a locking issue, in this case it is important to know in which state the process is in. 

Could you please attach strace to the running ips or im/p2p engine when it happens the next time using this command?

# for ips debugging
strace -p $(pidof snort_inline)

# for im/p2p debugging
strace -p $(pidof afcd)

wait up to 60 seconds until somthing gets logged and than please post the results here.

Looking forward to your valuable feedback, 
thanks
Gert

i tried to ssh to the box but it keeps telling me

loginuser@***.***.***.***'s password:
Permission denied, please try again.
loginuser@***.***.***.***'s password:
Permission denied, please try again.
loginuser@***.***.***.***'s password:
Permission denied (publickey,password,keyboard-interactive).

no matter what password i give it via webadmin.

a local login on the box it self with root is ok. but when i run your commands the output keeps scrolling and all internet traffic stops, box may be running out of air [;)]

i don't know why i can't login via ssh. i included lan as allowed network. changed the loginuser password many times but no joy.

Hi biton, 

wow, not that is strange, can you please check /var/log/sshd.log what it tell's us?

thx Gert

it's a big log file with many of the same lines in it. here just some of them.

2008:04:15-21:58:03 (none) sshd [10324] User loginuser not allowed because account is locked
2008:04:15-21:59:09 failed password for invalid user loginuser from ***.***.***.*** port 1953 ssh2
2008:04:15-22:01:02 (none) sshd [10336] error: Could not get shadow information for NOUSER

so it looks like user loginuser is being locked?

Setting passwords via webadmin is not working (7.190 here).

Edit: Setting only the loginuser password via webadmin does not work. Setting root itself works as well as setting both at the same time.

ok thanks for that will test this.

i can of cource also change the passwd of loginuser on the console it self. have a temp monitor / keyboard connected at the moment fot this beta testing.

ok, can confirm this shell access behavior [[:)]] 

@bitonw as you are the first who mentioned this problem, maybe you could make a new thread and i'll push this thread to the confirmed threads because the primary topic of this thread wasn't about shell passwords [[:)]]