ip_conntrack: table full, dropping packet

ip_conntrack: table full, dropping packet

[www.piratehosting.net]

can i get a url for the patch.
i have the latest kernal

Re: ip_conntrack: table full, dropping packet

[Jose Maria Lopez]

El vie, 24 de 09 de 2004 a las 17:55, www.piratehosting.net escribió:
> can i get a url for the patch.
> i have the latest kernal

Have you tried to change the /proc/sys/net/ipv4/ip_conntrack_max?
It should solve your problem if the table is full.

-- 
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
                -- Jack Kerouac, "On the Road"

ip_conntrack: table full, dropping packet

[www.piratehosting.net]

512mb ram
about 150,000 connections
its a ircd server with 15 clients at 1024 users each.
i have to keep moving it up as the conntrack doesnt empty

Re: ip_conntrack: table full, dropping packet

[Stephen J Smoogen]

www.piratehosting.net wrote:
> 512mb ram
> about 150,000 connections
> its a ircd server with 15 clients at 1024 users each.
> i have to keep moving it up as the conntrack doesnt empty
> 


Depending on the linux kernel you are using.. this is a 'known' bug. Red 
Hat Linux for the 7,8,9 series has a patch from netfilter experimental 
that does not let go connections. There is also another kernel version 
that seems to have this issue (2.4.18?) but I cant remember which one it 
was. Putting on the latest 2.4.x kernel with a clean netfilter patch 
fixed the problem on our boxes.

-- 
Stephen John Smoogen	        | CCN-5 Security Team
LANL SIRT Team Leader           | SMTP:  smoogen@lanl.gov
Los Alamos National Laboratory  | Voice: 505.664.0645
Ta-03 SM-1498 MS: B255 DP 10S   | FAX:   505.665.7793
Los Alamos, NM 87545            |

ip_conntrack: table full, dropping packet.

[www.piratehosting.net]

ip_conntrack: table full, dropping packet.

i have been using
echo "4008192" > /proc/sys/fs/file-max
echo 4008192 > /proc/sys/net/ipv4/ip_conntrack_max
to increase the limits to avoid this dropping of packets.
can i just clear the list from
/proc/net/ip_conntrack
or something

some info
ip_conntrack_ftp       70576  0
ip_conntrack_irc       70064  0
ip_conntrack           24968  4
iptable_nat,ip_conntrack_ftp,ip_conntrack_irc,ipt_state

Re: ip_conntrack: table full, dropping packet.

[Jason Opperisano]

On Fri, 2004-09-24 at 00:01, www.piratehosting.net wrote:
> ip_conntrack: table full, dropping packet.
> 
> i have been using
> echo "4008192" > /proc/sys/fs/file-max
> echo 4008192 > /proc/sys/net/ipv4/ip_conntrack_max
> to increase the limits to avoid this dropping of packets.
> can i just clear the list from
> /proc/net/ip_conntrack
> or something
> 
> some info
> ip_conntrack_ftp       70576  0
> ip_conntrack_irc       70064  0
> ip_conntrack           24968  4
> iptable_nat,ip_conntrack_ftp,ip_conntrack_irc,ipt_state

how much physical RAM is in this machine and how many simultaneous
connections are you trying to support?

-j

-- 
Jason Opperisano <opie@817west.com>

Re: ip_conntrack: table full, dropping packet.

[Jose Maria Lopez]

El vie, 24 de 09 de 2004 a las 06:01, www.piratehosting.net escribió:
> ip_conntrack: table full, dropping packet.
> 
> i have been using
> echo "4008192" > /proc/sys/fs/file-max
> echo 4008192 > /proc/sys/net/ipv4/ip_conntrack_max
> to increase the limits to avoid this dropping of packets.
> can i just clear the list from
> /proc/net/ip_conntrack
> or something
> 
> some info
> ip_conntrack_ftp       70576  0
> ip_conntrack_irc       70064  0
> ip_conntrack           24968  4
> iptable_nat,ip_conntrack_ftp,ip_conntrack_irc,ipt_state

Yes, you can clear the list using hping2 and sending RST to
both parts of the connection, but it will close the connections
if you do it that way.

The command would be something like this:

hping2 $DSTIP -R -s $SRCPORT -p $DSTPORT -a $SRCIP -k -c 1 -n
hping2 $SRCIP -R -s $DSTPORT -p $SRCPORT -a $DSTIP -k -c 1 -n

I have a script that does just that in my bastion-firewall
program. I can mail it to you if you want it.

-- 
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
                -- Jack Kerouac, "On the Road"

Strange setup

[Evan Borgstrom]

I've got sort of a strange setup that I'm looking to accomplish some
strange async routing. I know how I want to accomplish it and am pretty
sure that I can do it with netfilter but just can't seem to find the
proper way.

Here's the rundown on the network setup:

[ LAN ] --
[ DMZ ] -- [ Firewall/Router ] -- [ WAN ]
                    |
                    |
                 [ WLAN ]


The WLAN is between myself and a couple of other people in my building to
provide redundant paths out of each of our networks and is working
beautifully. We all advertise (via BGP) blocks close to us to each to
provide the shortest path as well.

Comming from the WAN I have a /29 routed to the DMZ which services a
number of machines that provide different services.

The firewall/router is a linux box that is running iptables.


Now the problem:
Because of the advertisments comming over the WLAN I now have about 40
routes in the kernel routing table. Most of them are not very specific
since we advertise our ISP's blocks to each other, so I have routes for
/16's, /21's, etc... What happens is when someone that resides in one of
these blocks that I'm getting advertisements for tries to access an
address in my /29 their return path follows the advertisment over the
WLAN.

Using the iproute2 package I've created a second routing table with a
single default route out my WAN default route. I'm hopping that there's a
way to tag the connection in the conntrack table and then -j MARK it when
a related,established packet comes back so that I use the iproute2 package
to specify that the second routing table will be used.

Anyone know of a way that I can accomplish this?

Thanks in advance,
Evan

-- 
Evan Borgstrom <evan@unixpimps.org>
http://www.unixpimps.org - SIG:ILL

Re: Strange setup

[Peter Johnson]

If this traffic isn't LAN related then just do

ip rule add from $WAN_IP table $TABLE_NAME

ip route add default via $WAN_PEER_IP dev $WAN_IF table $TABLE_NAME

This will add a source based route so that traffic entering on the
$WAN_IF has its resonses exit on the $WAN_IF.

See the Advanced Routing HOWTO for more info.

Regards,

PJ

On Mon, 2003-01-20 at 08:35, Evan Borgstrom wrote:
> I've got sort of a strange setup that I'm looking to accomplish some
> strange async routing. I know how I want to accomplish it and am pretty
> sure that I can do it with netfilter but just can't seem to find the
> proper way.
> 
> Here's the rundown on the network setup:
> 
> [ LAN ] --
> [ DMZ ] -- [ Firewall/Router ] -- [ WAN ]
>                     |
>                     |
>                  [ WLAN ]
> 
> 
> The WLAN is between myself and a couple of other people in my building to
> provide redundant paths out of each of our networks and is working
> beautifully. We all advertise (via BGP) blocks close to us to each to
> provide the shortest path as well.
> 
> Comming from the WAN I have a /29 routed to the DMZ which services a
> number of machines that provide different services.
> 
> The firewall/router is a linux box that is running iptables.
> 
> 
> Now the problem:
> Because of the advertisments comming over the WLAN I now have about 40
> routes in the kernel routing table. Most of them are not very specific
> since we advertise our ISP's blocks to each other, so I have routes for
> /16's, /21's, etc... What happens is when someone that resides in one of
> these blocks that I'm getting advertisements for tries to access an
> address in my /29 their return path follows the advertisment over the
> WLAN.
> 
> Using the iproute2 package I've created a second routing table with a
> single default route out my WAN default route. I'm hopping that there's a
> way to tag the connection in the conntrack table and then -j MARK it when
> a related,established packet comes back so that I use the iproute2 package
> to specify that the second routing table will be used.
> 
> Anyone know of a way that I can accomplish this?
> 
> Thanks in advance,
> Evan
> 
> -- 
> Evan Borgstrom <evan@unixpimps.org>
> http://www.unixpimps.org - SIG:ILL
> 
> 
> 
-- 

'Conformity is the jailer of freedom and the enemy of growth.' - John F.
Kennedy

Re: Strange setup

[Evan Borgstrom]

That's not gonna work in my sitation. I guess I need to further explain
how I'm looking for traffic to flow.


If traffic is from the WAN bound for the DMZ then the return path needs to
leave the WAN.

If traffic is from the WLAN bound for the DMZ then the return path needs
to leave the WLAN.

So, I need to be able to mark the connection somehow as the inbound
traffic from the WAN is bound for the DMZ so that I can specify a
different routing table for the return path so that it will leave the WAN
as well, otherwise it might end up with a more specific route through the
WLAN which will cause problems.

Does that make more sense?

-Evan

> If this traffic isn't LAN related then just do
>
> ip rule add from $WAN_IP table $TABLE_NAME
>
> ip route add default via $WAN_PEER_IP dev $WAN_IF table $TABLE_NAME
>
> This will add a source based route so that traffic entering on the
> $WAN_IF has its resonses exit on the $WAN_IF.
>
> See the Advanced Routing HOWTO for more info.
>
> Regards,
>
> PJ
>
> On Mon, 2003-01-20 at 08:35, Evan Borgstrom wrote:
>> I've got sort of a strange setup that I'm looking to accomplish some
>> strange async routing. I know how I want to accomplish it and am
>> pretty sure that I can do it with netfilter but just can't seem to
>> find the proper way.
>>
>> Here's the rundown on the network setup:
>>
>> [ LAN ] --
>> [ DMZ ] -- [ Firewall/Router ] -- [ WAN ]
>>                     |
>>                     |
>>                  [ WLAN ]
>>
>>
>> The WLAN is between myself and a couple of other people in my building
>> to provide redundant paths out of each of our networks and is working
>> beautifully. We all advertise (via BGP) blocks close to us to each to
>> provide the shortest path as well.
>>
>> Comming from the WAN I have a /29 routed to the DMZ which services a
>> number of machines that provide different services.
>>
>> The firewall/router is a linux box that is running iptables.
>>
>>
>> Now the problem:
>> Because of the advertisments comming over the WLAN I now have about 40
>> routes in the kernel routing table. Most of them are not very specific
>> since we advertise our ISP's blocks to each other, so I have routes
>> for /16's, /21's, etc... What happens is when someone that resides in
>> one of these blocks that I'm getting advertisements for tries to
>> access an address in my /29 their return path follows the advertisment
>> over the WLAN.
>>
>> Using the iproute2 package I've created a second routing table with a
>> single default route out my WAN default route. I'm hopping that
>> there's a way to tag the connection in the conntrack table and then -j
>> MARK it when a related,established packet comes back so that I use the
>> iproute2 package to specify that the second routing table will be
>> used.
>>
>> Anyone know of a way that I can accomplish this?
>>
>> Thanks in advance,
>> Evan
>>
>> --
>> Evan Borgstrom <evan@unixpimps.org>
>> http://www.unixpimps.org - SIG:ILL
>>
>>
>>
> --
>
> 'Conformity is the jailer of freedom and the enemy of growth.' - John F.
> Kennedy


-- 
Evan Borgstrom <evan@unixpimps.org>
http://www.unixpimps.org - SIG:ILL

Re: Strange setup

[Peter Johnson]

Ok, gotcha now...

Still do 
ip rule add from $WAN_IP table $WAN_TABLE
ip rule add from $WLAN_IP table $WLAN_TABLE
and 
ip route add default via $WAN_PEER_IP dev $WAN_IF table $WAN_TABLE
ip route add default via $WLAN_PEER_IP dev $WAN_IF table $WLAN_TABLE

Add iptables rules approximately as follows:

$IPTABLES -t nat -A PREROUTING -i $WAN_IF -j DNAT $DMZ_IP_0-16
$IPTABLES -t nat -A PREROUTING -i $WLAN_IF -j DNAT $DMZ_IP_17-32

$IPTABLES -t nat -A POSTROUTING -o $WAN_IF -j SNAT $WAN_IP
$IPTABLES -t nat -A POSTROUTING -o $WLAN_IF -j SNAT $WLAN_IP

$IPTABLES -t filter -A FORWARD -i $WAN_IF -o $DMZ_IF -j ACCEPT
$IPTABLES -t filter -A FORWARD -i $WLAN_IF -o $DMZ_IF -j ACCEPT

That takes care of the initial connection i.e. SYN packets. The IPTables
nat table is only used on the initial packet on each connection.

For the actual routing, the only thing that I can think of is assigning
two IPs (aliases) to each server in the DMZ say .0-16 for WAN and 17-32
for WLAN then using

$IPTABLES -t mangle -A PREROUTING -s $DMZ_IP_0-16 -j MARK --set-mark 1
and
$IPTABLES -t mangle -A PREROUTING -s $DMZ_IP_17-32 -j MARK --set-mark 2

then add

ip rule add fwmark 1 table $WAN_TABLE
and
ip rule add fwmark 2 table $WLAN_TABLE


Sorry but that is all I can come up with at the moment.

PJ

-- 

Quitters never win, and winners never quit, but those who never quit AND
never win are idiots.

Re: Strange setup

[Evan Borgstrom]

Thanks for the reply Peter,

That's the sortta setup I was playing with yesterday. Kindda kludgey but
it would work.

What would be nice is if connection tracking would log the source
interface of the last packet. That way in the PREROUTING table I could
check that and change the mark on the packet so that it would pick a
different routing table. Perhaps I should look at implementing that on
my setup to see how it works...

The only other way I thought of doing it was using TOS bits inside the
network (say give an 8 to anything coming over the WAN and a 16 to
anything coming over the WLAN), but I can't find a way to make my sun
boxes set the same TOS for related pakets...

If anyone else has ideas, comments, etc... on this I'm always up to
listen.

-Evan

On Mon, 2003-01-20 at 02:50, Peter Johnson wrote:
> Ok, gotcha now...
> 
> Still do 
> ip rule add from $WAN_IP table $WAN_TABLE
> ip rule add from $WLAN_IP table $WLAN_TABLE
> and 
> ip route add default via $WAN_PEER_IP dev $WAN_IF table $WAN_TABLE
> ip route add default via $WLAN_PEER_IP dev $WAN_IF table $WLAN_TABLE
> 
> Add iptables rules approximately as follows:
> 
> $IPTABLES -t nat -A PREROUTING -i $WAN_IF -j DNAT $DMZ_IP_0-16
> $IPTABLES -t nat -A PREROUTING -i $WLAN_IF -j DNAT $DMZ_IP_17-32
> 
> $IPTABLES -t nat -A POSTROUTING -o $WAN_IF -j SNAT $WAN_IP
> $IPTABLES -t nat -A POSTROUTING -o $WLAN_IF -j SNAT $WLAN_IP
> 
> $IPTABLES -t filter -A FORWARD -i $WAN_IF -o $DMZ_IF -j ACCEPT
> $IPTABLES -t filter -A FORWARD -i $WLAN_IF -o $DMZ_IF -j ACCEPT
> 
> That takes care of the initial connection i.e. SYN packets. The IPTables
> nat table is only used on the initial packet on each connection.
> 
> For the actual routing, the only thing that I can think of is assigning
> two IPs (aliases) to each server in the DMZ say .0-16 for WAN and 17-32
> for WLAN then using
> 
> $IPTABLES -t mangle -A PREROUTING -s $DMZ_IP_0-16 -j MARK --set-mark 1
> and
> $IPTABLES -t mangle -A PREROUTING -s $DMZ_IP_17-32 -j MARK --set-mark 2
> 
> then add
> 
> ip rule add fwmark 1 table $WAN_TABLE
> and
> ip rule add fwmark 2 table $WLAN_TABLE
> 
> 
> Sorry but that is all I can come up with at the moment.
> 
> PJ
-- 
Evan Borgstrom <evan@unixpimps.org>
http://www.unixpimps.org
http://www.ragga-jungle.com

ip_conntrack: table full, dropping packet.

[hare ram]

Hi

iam getting this error
what is the problem

when i do dmesg in redhat

ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
NET: 1 messages suppressed.
ip_conntrack: table full, dropping packet.
NET: 3 messages suppressed.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
NET: 10 messages suppressed.
ip_conntrack: table full, dropping packet.
NET: 7 messages suppressed.
ip_conntrack: table full, dropping packet.
NET: 5 messages suppressed.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
NET: 2 messages suppressed.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
NET: 2 messages suppressed.
ip_conntrack: table full, dropping packet.
NET: 5 messages suppressed.
ip_conntrack: table full, dropping packet.
NET: 3 messages suppressed.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.

Re: ip_conntrack: table full, dropping packet.

[Maciej Soltysiak]

> iam getting this error
> what is the problem
The conntrack table is full and your machine can not store
more connection tracking information, as each tracked connection
takes up some memory.

Increase your
/proc/sys/net/ipv4/ip_conntrack_max

as described in the FAQ. The FAQ shows how to calculate the value
for your system.

Regards,
Maciej Soltysiak

ip_conntrack: table full, dropping packet.

[Vicky Shrestha]

I have built a firewall on 2.4.8-17 kernel which has 2 Mb of traffic going in 
an out of it. 

I recently added a line :
iptables -A FORWARD -m state --state ESTABLISED,RELATED -J ACCEPT

Now I can see the lines "ip_conntrack : table full, dropping packet" in my 
kern.log.

Does dropping packets means that it is actually dropping the packets or just 
truncating the file /proc/net/ip_conntrack , does this affect my client's  
connections???

-- 
Best regards,


Vicky Shrestha
System Administrator
WorldLink Communications Pvt.Ltd
Jawalakhel, Kathmandu, Nepal.

Re: ip_conntrack: table full, dropping packet.

[Antony Stone]

On Wednesday 30 October 2002 1:43 pm, Vicky Shrestha wrote:

> I have built a firewall on 2.4.8-17 kernel which has 2 Mb of traffic going
> in an out of it.
>
> I recently added a line :
> iptables -A FORWARD -m state --state ESTABLISED,RELATED -J ACCEPT
>
> Now I can see the lines "ip_conntrack : table full, dropping packet" in my
> kern.log.
>
> Does dropping packets means that it is actually dropping the packets or
> just truncating the file /proc/net/ip_conntrack , does this affect my
> client's connections???

It means it really is dropping packets.   You should find out why the 
conntrack table is too small and do something about it.

The two possible reasons are:

1. You have a reasonable sized conntrack table but something is creating 
large numbers of entries (maybe SYN floods or something similar).

2. You have a reasonable number of connections being created through the 
machine, but insufficient memory has been allocated to the conntrack table.

Questions:

1. How much memory do you have in your firewall machine ?

2. What are the results of:
wc -l /proc/net/ip_conntrack
cat /proc/sys/net/ipv4/ip_conntrack_max

Antony.

-- 

Your email has been returned due to insufficient voltage.

Re: ip_conntrack: table full, dropping packet.

[Maciej Soltysiak]

> Now I can see the lines "ip_conntrack : table full, dropping packet" in my
> kern.log.
Yes, but have you read the FAQ ? :) Guess not.
You need to increase the /proc/net/ip_conntrack_max value, according to
the FAQ, it gives some reasonable values depending on the RAM you have.

> Does dropping packets means that it is actually dropping the packets or just
> truncating the file /proc/net/ip_conntrack , does this affect my client's
> connections???
Well, it means that the state mechanism has no space to insert a
conntrack entry, meaning, that the --state ESTABLISHED,RELATED works only
to a limited number of currently tracked connections.

Depending on your setup, it may do different things, but most probably it
does whatever your POLICY instructs them to do. DROP ? Most certainly.

In other words, it means that the --state rule will not match on the
packet. It will not get accepted by this rule.

Regards,
Maciej Soltysiak

Re: ip_conntrack: table full, dropping packet.

[Vicky Shrestha]

Yes I have read the FAQ .

I have 512 Mb of Ram and Hence the Maximum value of 
/proc/sys/net/ipv4/ip_conntrack_max must be 32768, which is what I have set 
already.

But Even this value is not enough for the connection passing through the 
firewall. It gets maxed out with minutes

If I increase the value what negative effect does it have??? Can I increase it 
to say 3276800 ???? Hope It doesnot crash my machine.


On Wednesday 30 October 2002 22:44, Maciej Soltysiak wrote:
> > Now I can see the lines "ip_conntrack : table full, dropping packet" in
> > my kern.log.
>
> Yes, but have you read the FAQ ? :) Guess not.
> You need to increase the /proc/net/ip_conntrack_max value, according to
> the FAQ, it gives some reasonable values depending on the RAM you have.
>
> > Does dropping packets means that it is actually dropping the packets or
> > just truncating the file /proc/net/ip_conntrack , does this affect my
> > client's connections???
>
> Well, it means that the state mechanism has no space to insert a
> conntrack entry, meaning, that the --state ESTABLISHED,RELATED works only
> to a limited number of currently tracked connections.
>
> Depending on your setup, it may do different things, but most probably it
> does whatever your POLICY instructs them to do. DROP ? Most certainly.
>
> In other words, it means that the --state rule will not match on the
> packet. It will not get accepted by this rule.
>
> Regards,
> Maciej Soltysiak

-- 
Best regards,


Vicky Shrestha
System Administrator
WorldLink Communications Pvt.Ltd
Jawalakhel, Kathmandu, Nepal.

Re: ip_conntrack: table full, dropping packet.

[Jet]

No I guess the maximum value is 64K.

Yes. It did crash my machine.
Just FYI, I tried this before on my 64M RAM linux box.
The default is 4K connection max.
But I tried to increase it to 64K.
End up when the number of connections grow to 13K (based on
/proc/net/ip_conntrack),
it first starts killing my other processes including klogd, syslog-ng,
snort.
At this time, you can see the kernel start killing the process from your
syslog (before syslog died)
After a while my linux box hang. And wait for reboot
I guess this is related to OOM (out-of-memory) bug in the kernel (I'm using
2.4.18-xfs).

.//Jet

>
> If I increase the value what negative effect does it have??? Can I
increase it
> to say 3276800 ???? Hope It doesnot crash my machine.
>
>