Re: Removing support for FreeBSD 2.x in PPP

There are certainly no objections from me. On Jul 1, 2013, at 3:35 PM, Robert Millan wrote: > Hi, > > Is there any concern if the arcane FreeBSD 2.x build logic is removed from > PPP? > > These ifdefs are currently being hit when building on GNU/kFreeBSD > (because of __FreeBSD__ value being

Removing support for FreeBSD 2.x in PPP

Hi, Is there any concern if the arcane FreeBSD 2.x build logic is removed from PPP? These ifdefs are currently being hit when building on GNU/kFreeBSD (because of __FreeBSD__ value being undefined, i.e. 0). I guess one could add even more ifdef logic could be added to handle that, but it seems a

Re: kern/157410: [ip6] IPv6 Router Advertisements Cause Excessive CPU Use

On Mon, Jul 01, 2013 at 12:58:23PM -0700, Loganaden Velvindron wrote: > Hi I came across this old PR. It appears that it's not fixed in -current. > > I attempted to port the diff to our FreeBSD 9.1 release machines which > have IPv6 connectivity and are affected by RA flooding. > > I can report t

kern/157410: [ip6] IPv6 Router Advertisements Cause Excessive CPU Use

Hi I came across this old PR. It appears that it's not fixed in -current. I attempted to port the diff to our FreeBSD 9.1 release machines which have IPv6 connectivity and are affected by RA flooding. I can report that it mitigates RA_flooding. Feedback welcomed. I'd be happy to polish it so tha

Re: Problem with fwip(4) and limited size ll_addr in the struct llentry

On 01.07.2013 16:26, Vijay Singh wrote: > If you enable OFED, then the llentry size is expanded to store IB addresses > as well. Code should be in 9.x. Yes, but this isn't solution. -- WBR, Andrey V. Elsukov ___ freebsd-net@freebsd.org mailing list htt

Re: Problem with fwip(4) and limited size ll_addr in the struct llentry

If you enable OFED, then the llentry size is expanded to store IB addresses as well. Code should be in 9.x. -vijay On Mon, Jul 1, 2013 at 4:49 PM, Andrey V. Elsukov wrote: > Hi, > > In the kern/176596 described the easy repeatable panic. > I found that it occurs, because struct llentry by defa

IPv6 Multicast Routing problem

Hi! I need some help, I had working multicast IPv6 routing using freebsd 8.3  but when i try to test it I failed. my topology is like this with freebsd as router and xp as server and client : XP1<---2001:abcd:10::/64--->FBSD1<---2001:abcd:20::/64--->FBSD2<---2001:abcd:30::/64--->XP2 this is my

Multiqueue support for bpf

Hi all, I'd like to propose multiqueue support for bpf. It's result of GSoC'11, and proposed on freebsd-net at Aug.2011 but not yet merged: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/syuu1228/1 http://lists.freebsd.org/pipermail/freebsd-net/2011-August/029585.html The obje

Problem with fwip(4) and limited size ll_addr in the struct llentry

Hi, In the kern/176596 described the easy repeatable panic. I found that it occurs, because struct llentry by default has only 8 bytes to store hardware address, but fwip(4) has 16-bytes hw address. And it overwrites next field of struct llentry. Since fwip(4) can be loaded in runtime, we can't u

Re: DNAT in freebsd

Hi, I did ping 10.0.1.1 from 10.0.1.2, so packet is 10.0.1.2 ->10.0.1.1 > ipfw add 1000 nat 1 all from 10.0.1.2 to 10.0.1.1 if I have 10.0.1.1 in em1 no translation is done! if I delete it (and add a static arp entry in 10.0.1.2 for mac of 10.0.1.1) rule 1000 translates well and I get packet from 1

Current problem reports assigned to freebsd-net@FreeBSD.org

Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker

Re: DNAT in freebsd

On 01.07.2013 17:05, Sami Halabi wrote: > Hi, > forgot to mention that but this sysctl is already set to 0. > i see in the logs packets pass 1000 rule. Use rules like 'ipfw add 1500 count log ip from any to any' to check intermediate results of translation. ___

Re: DNAT in freebsd

Hi, forgot to mention that but this sysctl is already set to 0. i see in the logs packets pass 1000 rule. Sami On Mon, Jul 1, 2013 at 12:17 PM, Eugene Grosbein wrote: > On 01.07.2013 14:30, Sami Halabi wrote: > > Hi, > > > > I've tried the following: > > > > em1 - ip 10.0.1.1/24

Re: DNAT in freebsd

On 01.07.2013 14:30, Sami Halabi wrote: > Hi, > > I've tried the following: > > em1 - ip 10.0.1.1/24 > em2 - ip 11.0.3.1/24 > route add 11.0.4.0/24 11.0.3.2 > > ipfw flush > ipfw add 1000 nat 1 all from 10.0.1.2 to 10.0.1.1 > ipfw ad

Re: probable side effects of deleting interfaces ip addresses(loopback ones) from routing table !

Thanks Alan for your helpful reply. As in my test cable was always connected, I didn't have any problem pinging my own interface ip. I think it's better to keep interface loopback ip rather than deleting them to avoid the problem you mentioned besides performance reduction. On Thu, Jun 27, 2013 at

Re: cxgbetool & hw filtering issues

On 30.06.2013 23:41, Navdeep Parhar wrote: On 06/30/13 07:25, Alexander V. Chernikov wrote: Hello list! While experimenting with Chelsio T440-CR (cxgbe) internal firewall, I'm getting some kind of unexpected results: One bit of general advice to begin with: add "hitcnts 1" to all your filter r

Re: DNAT in freebsd

Hi, I've tried the following: em1 - ip 10.0.1.1/24 em2 - ip 11.0.3.1/24 route add 11.0.4.0/24 11.0.3.2 ipfw flush ipfw add 1000 nat 1 all from 10.0.1.2 to 10.0.1.1 ipfw add 2000 nat 2 all from 11.0.3.1 to 10.0.1.1 ipfw add 3000 nat 2 all from 11.0.4.2 to 11.0.3.1 ipfw add 4000 nat 1 all from 10