The following reply was made to PR kern/179901; it has been noted by GNATS.
From: Mikolaj Golub
To: bug-follo...@freebsd.org
Cc: Michael Gmelin
Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled
incorrectly
Date: Sun, 30 Jun 2013 10:17:05 +0300
--EeQfGwPcQSOJBaQU
Cont
On Sat, Jun 29, 2013 at 09:50:15AM +0300, Sami Halabi wrote:
> I think I was misunderstood...
> Here is the situation i want to handle:
> My box is a router that handles several /24 behind.
> One of my links (em0) is connected to a private network 192.168.0.1 is me,
> my neighbour is 192.168.0.2.
On 29.06.2013 13:50, Sami Halabi wrote:
> I think I was misunderstood...
> Here is the situation i want to handle:
> My box is a router that handles several /24 behind.
> One of my links (em0) is connected to a private network 192.168.0.1 is me,
> my neighbour is 192.168.0.2.
> I want to make that
Hi,
Thanks for your time.
What this configuration does is normal NAT configuration (SNAT).
what I'm seeking is combination of SNAT & DNAT to act as a transparent
proxy as:
192.168.0.2 connects to me (192.168.0.1) it'll talk actually with
193.xx.yy.1 whithout knowing it using my special public ip
Hi,
I don't understand how reverse mode works exactly, and didn't find a good
example.
can you try and help on the configuration?
Thanks in advance,
Sami
On Sun, Jun 30, 2013 at 1:22 PM, Eugene Grosbein wrote:
> On 29.06.2013 13:50, Sami Halabi wrote:
> > I think I was misunderstood...
> > H
Hello list!
While experimenting with Chelsio T440-CR (cxgbe) internal firewall, I'm
getting some kind of unexpected results:
filtering 'type ipv4 action drop' permits IPv4 TCP traffic with bad
checksum.
filtering 'type IPv6 action drop' permits IPv6 traffic to multicast
addresses (MLDv2, etc
On 30.06.2013 18:48, Sami Halabi wrote:
> Hi,
> I don't understand how reverse mode works exactly, and didn't find a good
> example.
>
>
> can you try and help on the configuration?
Well, that's pretty simple. Generally, NAT translates source IP address of the
packet
keeping destination IP int
One particular annoyance with Freebsd is that different NICs have different
dormant behavior.
For example em and igb both will show the link being active or not on boot
whether the interface
has been UPed or not, while ixgbe and bce do not.
I think it's a worthy goal to have NICs work the same
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 rules and then you can see how many inc
Hi Eugene,
It simply doesn't work for me, the reverse option doesn't work properly for
me it keeps translating the source instead of the destination...
On Sun, Jun 30, 2013 at 6:32 PM, Eugene Grosbein wrote:
> On 30.06.2013 18:48, Sami Halabi wrote:
> > Hi,
> > I don't understand how rever
I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the
"bridged" type of networking with VMWare. It gets it's IPv4 address from
DHCP (successfully) and then fails to initialize IPv6. The relevant
rc.conf is:
ipv6_activate_all_interfaces="YES"
ifconfig_em0_ipv6="inet6 accept_rtadv"
ip
Zaphod Beeblebrox wrote
in :
zb> I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the
zb> "bridged" type of networking with VMWare. It gets it's IPv4 address from
zb> DHCP (successfully) and then fails to initialize IPv6. The relevant
zb> rc.conf is:
zb>
zb> ipv6_activate_all_in
On Jun 30, 2013, at 6:48 PM, Zaphod Beeblebrox wrote:
> I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the
> "bridged" type of networking with VMWare. It gets it's IPv4 address from
> DHCP (successfully) and then fails to initialize IPv6. The relevant
> rc.conf is:
>
> ipv6_ac
13 matches
Mail list logo
