blocking dhcp requests
Hey there, I have a problem concerning ipfw and dhcp. I am trying to block dhcp request which are sent to my host. but the dhcp server replys even though my firewall rule matches. the firewall rule in my script $cmd 02 deny log ip from any to any bootps keep-state in which will be translated into: deny log logamount 100 ip from any to any dst-port 67 keep-state the log entry in /etc/security Apr 22 14:41:54 lizard kernel: ipfw: 2 Deny UDP 0.0.0.0:68 255.255.255.255:67 in via fxp1 lizard# tcpdump -n -i fxp1 broadcast or host 192.168.1.2 and not arp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on fxp1, link-type EN10MB (Ethernet), capture size 96 bytes 14:41:54.026011 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:11:11:94:72:76, length: 548 14:41:54.026534 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length: 351 the dhcp server sends the client an answer, even though ipfw seems to reject the packet. Is there any way to block the dhcprequest from reaching the dhcp server ? tcpdump version 3.8.3 isc-dhcp3-server-3.0.2_7 FreeBSD lizard 5.4-RC2 FreeBSD 5.4-RC2 best regards Thomas Vogt ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/103454: [ipfw] [patch] add a facility to modify DF bit of the IP packet
Hello
Roman Bogorodskiy schrieb:
> Andrey V. Elsukov wrote:
>
>> Roman Bogorodskiy wrote:
>>> +.It Cm setdf Ar value
>>> +Changes
>>> +.Cm DF
>>> +bit of the IP packet.
>>> +Value may be 0 (May Fragment) or 1 (Don't Fragment).
>> May be, it would be more handy make this feature via modifier
>> (not an action).
>> Rule format:
>> [setdf|resetdf]
>>
>> Or more extensible, use not only DF modification:
>> [{modip [DF|TOS|DSCP|TTL]}]
>
> Yeah, that's nice idea. However, I have already working DF bit stuff and
> tos/dscp stuff as well (kern/102471) implemented in another way. And
> since committers don't seem to show intested in these
> patches/functionaliy, I'm not quite sure if I need to waste time on
> re-implementing it because it would be pretty useless if these patches
> would hang in GNATS forever.
I hope someone will commit it. DSCP/TOS feature in ipfw is pretty useful
if you're doing VOIP or QoS in generell.
The days where ISPs don't do QoS because they do erything with
"over-provesioning" are over. Most do MPLS QoS but thats more for the
backbone.
I would like to see this patch in the main tree. Of course the DF
modification would be nice too.
Cheers,
Thomas
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW+Dummynet Capability
Hello Am 20.07.2008 um 01:06 schrieb Kazi A. Sharif: Hello Guys, I was planning to install a heavy duty bandwidth manager for my ISP. I went through some documentation and installed IPFW and Dummynet in FreeBSD 7.0. Before I spent so much time on this I need to know the limitations that are already noticed: 1. If we compare IPFW+Dummynet with Allot or Emerging Technologies Bandwidth manager, how efficient is the IPFW+Dummynet? 2. Is it possible to control/throttle 800/900Mbps bandwidth using recommended hardware? We use something similiar to make sure that certain ip ranges always get the best performance. Simulating some kind of QoS and set a max bandwidth for everything. We figured out that the limit with this Xeon is somewhere between 200-300Mbps with a few IPFW+Dummynet rules. We also tested a slower quad cores but the performance was even worse. UP systems with fast CPU where the best choice so far for us. At the moment our system runs with 6.2 but to be honest i don't belive that the performance gets trippled with FreeBSD 7. Our hardware: Intel(R) Xeon(TM) CPU 3.20GHz (3199.10-MHz 686-class CPU) and intel em cards ( In the past Ian Freislich mentioned at performance@ that AMD Opterons are maybe faster because of the bigger L1 cache. You will get less cache misses with it. We could squeeze a bit more speed with ipfw table keyword. In gerneral, the less rule you have the better performance you will get. There is also an dummynet issue with FreeBSD 7.0. We just used dummynet to limit a ftp server to 500Mpbs and had a lot of kernel panics. Oleg Bulyzhin wrote a patch: http://www.freebsd.org/cgi/query-pr.cgi?prp=113548-3-diff As far as i know this patch is not included in 7.0-Release and i'm not sure if it was ever commited to -stable or -head. Regards, Thomas Vogt ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
