Re: cxgbe's native netmap support broken since r307394

2016-12-19 Thread Vincenzo Maffione
Hi Navdeep, Indeed, we have reviewed the code, and we think it is ok to implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using IFNET_WLOCK(). Since IFNET_RLOCK() results into sx_slock(), this should fix the issue. On FreeBSD, this locking is needed to protect a flag read by nm_iszomb

Avoid using RFC3927 outside of the link

2016-12-19 Thread Alarig Le Lay
Hi, I have a router that is mutli-homed with BGP. One of my peers is using an RFC3927 address for the connection. If I traceroute to host behind that route where we use a route via this peer to reply, the ICMP reply display that link-local IP: 1. AS12876 195-154-86-1.rev.poneytelecom.eu (195.15

Re: Avoid using RFC3927 outside of the link

2016-12-19 Thread Eugene Grosbein
20.12.2016 1:46, Alarig Le Lay пишет: Is it possible to avoid this behaviour and reply with the public IP (89.234.186.1) instead? try: sysctl net.inet.icmp.reply_from_interface=1 ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mai

Re: Avoid using RFC3927 outside of the link

2016-12-19 Thread Alarig Le Lay
On Tue Dec 20 01:51:17 2016, Eugene Grosbein wrote: > 20.12.2016 1:46, Alarig Le Lay пишет: > > > Is it possible to avoid this behaviour and reply with the public IP > > (89.234.186.1) instead? > > try: sysctl net.inet.icmp.reply_from_interface=1 If an AS choose to go to us thought this peer, pa

Re: cxgbe's native netmap support broken since r307394

2016-12-19 Thread Navdeep Parhar
IFNET_RLOCK will work, thanks. Navdeep On Mon, Dec 19, 2016 at 3:21 AM, Vincenzo Maffione wrote: > Hi Navdeep, > > Indeed, we have reviewed the code, and we think it is ok to > implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using > IFNET_WLOCK(). > Since IFNET_RLOCK() results into

Re: Avoid using RFC3927 outside of the link

2016-12-19 Thread Eugene Grosbein
20.12.2016 2:05, Alarig Le Lay пишет: On Tue Dec 20 01:51:17 2016, Eugene Grosbein wrote: 20.12.2016 1:46, Alarig Le Lay пишет: Is it possible to avoid this behaviour and reply with the public IP (89.234.186.1) instead? try: sysctl net.inet.icmp.reply_from_interface=1 If an AS choose to go

Re: sonewconn: pcb [...]: Listen queue overflow to human-readable form

2016-12-19 Thread hiren panchasara
On 12/16/16 at 11:20P, Andrey V. Elsukov wrote: > On 15.12.2016 20:51, hiren panchasara wrote: > > On 12/15/16 at 05:23P, Eugene M. Zheganin wrote: > >> Hi. > >> > >> Sometimes on one of my servers I got dmesg full of > >> > >> sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in

Re: Avoid using RFC3927 outside of the link

2016-12-19 Thread Alarig Le Lay
On Tue Dec 20 02:34:29 2016, Eugene Grosbein wrote: > Well, you can always use brute force instead: > > ipfw nat 169 config reset ip 89.234.186.1 && \ > ipfw add 60 nat 169 ip from 169.254.0.0/16 to any out xmit igb0 > > That's ugly but works. I will work just by side effect: by doing this, I wi

Re: Avoid using RFC3927 outside of the link

2016-12-19 Thread Joe Holden
On 19/12/2016 21:01, Alarig Le Lay wrote: On Tue Dec 20 02:34:29 2016, Eugene Grosbein wrote: Well, you can always use brute force instead: ipfw nat 169 config reset ip 89.234.186.1 && \ ipfw add 60 nat 169 ip from 169.254.0.0/16 to any out xmit igb0 That's ugly but works. I will work just b

Re: Avoid using RFC3927 outside of the link

2016-12-19 Thread Eugene Grosbein
20.12.2016 4:01, Alarig Le Lay пишет: On Tue Dec 20 02:34:29 2016, Eugene Grosbein wrote: Well, you can always use brute force instead: ipfw nat 169 config reset ip 89.234.186.1 && \ ipfw add 60 nat 169 ip from 169.254.0.0/16 to any out xmit igb0 That's ugly but works. I will work just by si