https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277029
Mark Linimon changed:
What|Removed |Added
CC||ma...@freebsd.org
Assigne
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265089
--- Comment #2 from Frank Behrens ---
Hello Alexander, thanks for your fast reponse!
I confirm, that your patch fixed the problem on my system. From my side the bug
may be closed.
Kind regards, Frank
--
You are receiving this mail because
al traffic. First problem is that the logic
of passing source interface is not working correcly for TCP connections,
resulting in passing "origifp" on the first 2 connection attempts and
lo0 on the subsequent ones. Second problem is that source address
validation logic skip
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265089
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254997
--- Comment #2 from Ozkan KIRIK ---
As a workaround, when service ip6addrctl start, everything becomes working.
But I think, a jail shouldn't need start a service to properly select an source
address.
It's better to be fixed.
-
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254997
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
quot;tunnel "
ifconfig_gif0_ipv6="inet6 auto_linklocal"
ipv6_defaultrouter="-interface gif0"
Using this configuration, your source IPv6 address will be that on
igb1. And if you have two or more physical interfaces you can define
ip6addrctl.conf to control which addr
On 31.07.2019 15:50, Viktor Dukhovni wrote:
> After further manpage reading, it seems to work with:
>
> ifconfig_gif0_ipv6="inet6 ::2 ::1 prefixlen
> 128 no_prefer_iface"
> ifconfig_igb1_ipv6="inet6 ::1 prefixlen 64 prefer_source"
> ip6addrctl_policy="AUTO"
Yes, in general this shoul
On Wed, Jul 31, 2019 at 02:46:14PM +0200, Patrick M. Hausen wrote:
> > Is it possible to configure my system to use the internal /64 address
> > as the default source address of outgoing IPv6 packets?
>
> That is probably pretty easy depending on your preferred mail server
erse resolution for
> outgoing IPv6, which means that I need the outgoing sources address
> to be ::1, not ::2, even though the
> routing table lists "gif0" as the interface with the default route.
>
> Is it possible to configure my system to use the internal /64 address
&g
t the point-to-point "tunnel-prefix" (the /128).
Since a bunch of my traffic is SMTP, I need reverse resolution for
outgoing IPv6, which means that I need the outgoing sources address
to be ::1, not ::2, even though the
routing table lists "gif0" as the interface with the defau
1
> prefixlen 128"
> ipv6_defaultrouter="::1"
>
> 2. A /64 for my network:
>
> ipv6_network_interfaces="igb1"
> ifconfig_igb1_ipv6="inet6 ::1 prefixlen 64"
>
> Is it possible to configure my system to use the inter
nterface with the default route.
>
> Is it possible to configure my system to use the internal /64 address
> as the default source address of outgoing IPv6 packets?
That is probably pretty easy depending on your preferred mail server.
Make your mail server listen to ::1 only instead of ::
if0" as the interface with the default route.
Is it possible to configure my system to use the internal /64 address
as the default source address of outgoing IPv6 packets?
If it would help, I can assign the "::1" address to the
external physical network interface (same one tha
if0" as the interface with the default route.
Is it possible to configure my system to use the internal /64 address
as the default source address of outgoing IPv6 packets?
If it would help, I can assign the "::1" address to the
external physical network interface (same one tha
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=159103
Eitan Adler changed:
What|Removed |Added
Status|In Progress |Open
--- Comment #7 from Eitan Adler
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=159103
Hiren Panchasara changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org
--- Com
Summary|source address based|[request] source address
|routing without pf or ipfw |based routing without pf or
||ipfw
--
You are receiving this mail because:
You are the assignee for the bug
On 04/08/2015 19:59, John Howie wrote:
> Still at 35000’ (literally), trying to get to where I am going!
Oh, you are flying! I first didn't understand what 35000' meant.
Have a safe rest of the flight!
Yuri
___
freebsd-net@freebsd.org mailing list
http
Hi Yuri,
No need to apologize! Sometimes it takes a dispassionate person to review
the problem to help you find the solution. You found it, not me. I just
helped you get there…
Still at 35000’ (literally), trying to get to where I am going!
Regards,
John
On 4/8/15, 9:43 PM, "Yuri" wrote:
>O
On 04/08/2015 16:07, John Howie wrote:
Have you tried using a static IP address for the host and VM, and
disabling DHCP? The DHCP client will bind to and use 0.0.0.0 to get an IP
address. The SO_REUSEADDR rule is that every tuple (proto, src ip, src
port, dst ip, dst prt) must be unique. I am won
Hi Yuri,
Have you tried using a static IP address for the host and VM, and
disabling DHCP? The DHCP client will bind to and use 0.0.0.0 to get an IP
address. The SO_REUSEADDR rule is that every tuple (proto, src ip, src
port, dst ip, dst prt) must be unique. I am wondering if that is where
your pr
On 04/08/2015 15:31, John Howie wrote:
Is your machine a router or gateway, or have a firewall? Are you trying to
capture all broadcast packets, or just UDP targeted and broadcast packets
to a particular port?
No, it isn't a gateway or router, and no firewall. Trying to capture all
broadcast U
ps getting some other packets,
>sin_port doesn't seem to matter. Also, UDP is the practically important
>case.
>
>Unless there is some reasonable explanation why ip source address can
>influence reception, I believe this is a bug in kernel. And pretty
>important one, because it can hu
doesn't seem to matter. Also, UDP is the practically important
case.
Unless there is some reasonable explanation why ip source address can
influence reception, I believe this is a bug in kernel. And pretty
important one, because it can hurt DHCP servers.
Yuri
--- C program exhibitin
If nobody answers this question by the time I get home I'll try and
help; however, in the mean time I do have a couple of suggestions.
Have you tried writing the equivalent program in C using the sockets
API? IE is this a python specific problem or a sockets problem in
general?
The second thing
I noticed that the socket bound to '0.0.0.0' only receives UDP
broadcasts when they are sent from zero IP: 0.0.0.0->255.255.255.255.
When the source IP is not zeros, but some valid IP on that network,
socket never receives such broadcast.
I compared two packets in wireshark as they arrive, and
em won't answer to the request.
Maybe because it is not on the same LAN as the requesting address.
The jail host, which selects the wrong source address is running
9.1-STABLE r246590.
So maybe this is fixed already?
But since I've never heared about such a problem I guess it still exists.
On Tue, Oct 15, 2013 at 06:07:54AM +0900, Hiroki Sato wrote:
> pr> It's my understanding that by leaving ip6addrctl_policy as AUTO will
> pr> only prefer IPv6 if ipv6_enable_all_interfaces is set to YES, which it
> pr> is in my /etc/rc.conf. However, it appears that this never resulted in
> pr> ip
Mark Kamichoff wrote
in <20131014205824.gi25...@prolixium.com>:
pr> On Tue, Oct 15, 2013 at 05:45:15AM +0900, Hiroki Sato wrote:
pr> > Try ip6addrctl_policy="ipv6_prefer" in rc.conf.
pr>
pr> Excellent. Thank you. I glanced right over that in
pr> /etc/default/rc.conf. I just added the above l
On Tue, Oct 15, 2013 at 05:45:15AM +0900, Hiroki Sato wrote:
> Try ip6addrctl_policy="ipv6_prefer" in rc.conf.
Excellent. Thank you. I glanced right over that in
/etc/default/rc.conf. I just added the above line to /etc/rc.conf and
ran /etc/rc.d/ip6addrctl start prefer_ipv6. Now, it works as e
has not been seen
pr> on any prior version of FreeBSD that supports IPv6.
pr>
pr> I took a quick look through /etc/default/rc.conf to see if there were
pr> any new variables that might influence source address selection or name
pr> resolution, but did not see anything relevant.
Tr
UG1 em0
This behavior has been reproduced on 9.2, as well. It has not been seen
on any prior version of FreeBSD that supports IPv6.
I took a quick look through /etc/default/rc.conf to see if there were
any new variables that might influence source address selection or name
resolution, but did
Currently source address selection for raw packets under jails
uses prison_get_ip4 in the INADDR_ANY case.
This can cause an invalid source address to be used, including
using addresses which are unusable e.g. down interfaces
un-routable addresses etc.
I suspect this is a hang over from when
Old Synopsis: gre(4) when using a tunnel source address from carp(4) doesn't
honor the MASTER/BACKUP state
New Synopsis: [gre] gre(4) when using a tunnel source address from carp(4)
doesn't honor the MASTER/BACKUP state
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Respon
Gleb,
> A> I'm not an expert on networking, but is this condition of ignoring such an
> ARP packet really a noteworthy event? I.e. is this something that should not
> occur in "normal" operation according to the ARP specifications? If this is
> mostly for kernel developers, maybe it should only
Alexander,
On Thu, Nov 10, 2011 at 12:42:15PM -0500, Alexander Wittig wrote:
A> > Can you try attached patch. It reduces severity level of all ARP
A> > messages, that can be triggered by packet on network, with expection to
A> > "using my IP address".
A> >
A> > With default syslog.conf, now ARP
Alexander Wittig wrote:
>
> Nov 10 12:25:45 bt kernel: in_arp: 03:bf:23:09:44:e4 is multicast
> Nov 10 12:25:45 bt kernel: in_arp: 03:bf:23:09:44:87 is multicast
> [...]
>
> I'm not an expert on networking, but is this condition of ignoring
> such an ARP packet really a noteworthy event? I.e. is
Gleb,
Am 10.11.2011 um 01:51 schrieb Gleb Smirnoff:
> On Tue, Nov 08, 2011 at 05:14:45PM -0500, Alexander Wittig wrote:
> A> I upgraded one of my machines from FreeBSD 8 to 9.0-RC1 (FreeBSD
> bt.pa.msu.edu 9.0-RC1 FreeBSD 9.0-RC1 #3: Fri Oct 28 16:45:28 EDT 2011
> r...@bt.pa.msu.edu:/usr/ob
Alexander,
On Tue, Nov 08, 2011 at 05:14:45PM -0500, Alexander Wittig wrote:
A> I upgraded one of my machines from FreeBSD 8 to 9.0-RC1 (FreeBSD
bt.pa.msu.edu 9.0-RC1 FreeBSD 9.0-RC1 #3: Fri Oct 28 16:45:28 EDT 2011
r...@bt.pa.msu.edu:/usr/obj/usr/src/sys/ALEX i386), and ever since that
Hello
I upgraded one of my machines from FreeBSD 8 to 9.0-RC1 (FreeBSD bt.pa.msu.edu
9.0-RC1 FreeBSD 9.0-RC1 #3: Fri Oct 28 16:45:28 EDT 2011
r...@bt.pa.msu.edu:/usr/obj/usr/src/sys/ALEX i386), and ever since that
upgrade the kernel keeps flooding my log files with messages like these:
Nov
On 03/03/11 15:03, Bjoern A. Zeeb wrote:
Not sure what you expect. Your jail has an address out of
192.168.82.2/24 and
192.168.75.2/24
You are trying to connect to neither of those networks but 192.168.72.3.
Now it was a typo. Either I've lost my mind or I can't reproduce a
problem. Will ch
inet 192.168.82.2 netmask 0xff00 broadcast 192.168.82.255
..
In other words, source address is selected as primary IP, and packet runs out
on 100% improper interface.
No specific routing, no firewall.
Not sure what you expect. Your jail has an address out of
192.168.82.2/24 and
192.16
parent interface: bce1
vlan82: flags=8843 metric 0 mtu 1500
options=103
ether 00:14:5e:1a:a6:29
inet 192.168.82.2 netmask 0xff00 broadcast 192.168.82.255
media: Ethernet autoselect (100baseTX )
status: active
vlan: 82 parent interface: bce1
In other words, source address is selected as pri
On Mon, 7 Feb 2011, Alex Povolotsky wrote:
Hello!
On a multihomed FreeBSD 8.1-RELEASE, in a multihomed jail, source IP
selection suddenly refused to work.
ifconfig on a box:
...
Seems reasonable, yes?
Pinging from the box
# ping 192.168.75.59
PING 192.168.75.59 (192.168.75.59): 56 data b
Hello!
On a multihomed FreeBSD 8.1-RELEASE, in a multihomed jail, source IP
selection suddenly refused to work.
ifconfig on a box:
bce0: flags=8943 metric
0 mtu 1500
options=c01bb
ether 00:1a:64:c5:d0:c8
inet 192.168.80.40 netmask 0xff00 broadcast 192.168.80.255
media:
# sysctl security.jail.param.ip4.saddrsel=0
->
# echo $?
0
# sysctl security.jail.param.ip4.saddrsel
#
# sysctl -d security.jail.param.ip4.saddrsel
security.jail.param.ip4.saddrsel: Do (not) use IPv4 source address selection
rather than the primary jail IPv4 address.
Is this tunable only available when VIM
$?
0
# sysctl security.jail.param.ip4.saddrsel
#
# sysctl -d security.jail.param.ip4.saddrsel
security.jail.param.ip4.saddrsel: Do (not) use IPv4 source address
selection rather than the primary jail IPv4 address.
Is this tunable only available when VIMAGE jails are built? The
8.1-RELEASE
The following reply was made to PR kern/146534; it has been noted by GNATS.
From: jhell
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/146534: [icmp6] wrong source address in echo reply
Date: Sat, 18 Sep 2010 18:59:20 -0400
This is a multi-part message in MIME format
The following reply was made to PR kern/146534; it has been noted by GNATS.
From: jhell
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/146534: [icmp6] wrong source address in echo reply
Date: Sat, 18 Sep 2010 16:52:21 -0400
This is a multi-part message in MIME format
The following reply was made to PR kern/146534; it has been noted by GNATS.
From: Earl Lapus
To: bug-follo...@freebsd.org, earl.la...@gmail.com
Cc:
Subject: Re: kern/146534: [icmp6] wrong source address in echo reply
Date: Sat, 22 May 2010 14:06:45 +0800
--001636b14d02cd6f320487289c7c
Old Synopsis: [icmpv6] wrong source address in echo reply
New Synopsis: [icmp6] wrong source address in echo reply
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri May 14 08:54:45 UTC 2010
Responsible-Changed-Why:
Over
The following reply was made to PR kern/146394; it has been noted by GNATS.
From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?=
To: bug-follo...@freebsd.org, kes-...@yandex.ru
Cc:
Subject: Re: kern/146394: [vlan] IP source address for outgoing connections
Date: Tue, 11 May 2010 20:05:36 +0300
jFo
Здравствуйте, Julian.
Вы писали 8 мая 2010 г., 20:05:02:
jFo> Synopsis: [vlan] IP source address for outgoing connections
jFo> State-Changed-From-To: open->feedback
jFo> State-Changed-By: julian
jFo> State-Changed-When: Sat May 8 09:47:30 PDT 2010
jFo> State-Changed-Why:
jFo&
Synopsis: [vlan] IP source address for outgoing connections
State-Changed-From-To: open->feedback
State-Changed-By: julian
State-Changed-When: Sat May 8 09:47:30 PDT 2010
State-Changed-Why:
The behaviour you quote as a bug is expected and useful and I don't think it is
a bug.
Any n
Old Synopsis: IP source address for outgoing connections
New Synopsis: [vlan] IP source address for outgoing connections
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat May 8 14:38:10 UTC 2010
Responsible-Changed-Why:
Over
cal addresses or/and interfaces ?
Such way that kernel will decide what fib to use examining local IP
address of package ?
--
Vladimir B. Grebenschikov
v...@fbsd.ru
The actual routing code doesn't receive any information about the source
address (the route is found using exclusively
> >> you could set up 2 routing tables and assign different apps to use
> >> different tables
> >
> > Is it possible to select routing table by ipfw setfib X ?
> >
> > someting like:
> >
> > ipfw add setfib 1 ip from a.b.c.d to any out xmit em0
> > setfib 1 route add default 10.10.10.1
>
> n
Vladimir Grebenschikov wrote:
Hi
you could set up 2 routing tables and assign different apps to use
different tables
Is it possible to select routing table by ipfw setfib X ?
someting like:
ipfw add setfib 1 ip from a.b.c.d to any out xmit em0
setfib 1 route add default 10.10.10.1
no t
Vladimir Grebenschikov wrote:
Hi
you could set up 2 routing tables and assign different apps to use
different tables
Is it possible to select routing table by ipfw setfib X ?
someting like:
ipfw add setfib 1 ip from a.b.c.d to any out xmit em0
setfib 1 route add default 10.10.10.1
PS:
Hi
> you could set up 2 routing tables and assign different apps to use
> different tables
Is it possible to select routing table by ipfw setfib X ?
someting like:
ipfw add setfib 1 ip from a.b.c.d to any out xmit em0
setfib 1 route add default 10.10.10.1
PS:
you may need to compile kern
Jamie Ostrowski wrote:
On Thu, Jul 23, 2009 at 9:57 AM, luc...@lastdot.org wrote:
Hi guys,
I need to change the default source address on a freebsd server.
My situation is somehow similar to this
(http://marc.info/?l=freebsd-questions&m=122535960804508&w=2).
In linux i can easily do
On Thu, Jul 23, 2009 at 9:57 AM, luc...@lastdot.org wrote:
> Hi guys,
>
> I need to change the default source address on a freebsd server.
> My situation is somehow similar to this
> (http://marc.info/?l=freebsd-questions&m=122535960804508&w=2).
> In linux i can ea
luc...@lastdot.org wrote:
Hi guys,
I need to change the default source address on a freebsd server.
My situation is somehow similar to this
(http://marc.info/?l=freebsd-questions&m=122535960804508&w=2).
In linux i can easily do it like:
ip ro replace default via 10.10.10.1 src a.b.c.
luc...@lastdot.org wrote:
Hi guys,
I need to change the default source address on a freebsd server.
My situation is somehow similar to this
(http://marc.info/?l=freebsd-questions&m=122535960804508&w=2).
In linux i can easily do it like:
ip ro replace default via 10.10.10.1 src a.b.c.
Hi guys,
I need to change the default source address on a freebsd server.
My situation is somehow similar to this
(http://marc.info/?l=freebsd-questions&m=122535960804508&w=2).
In linux i can easily do it like:
ip ro replace default via 10.10.10.1 src a.b.c.d (where a.b.c.d is em0 alia
t
help me with multihoming jails?
As it turns out, my issue is with source address selection mostly,
The routing table selects your source address so it has everything
to do with it. If youhave several addressesin your jail,
(with teh new code) then which is selected for a particular sessi
e any documentation on how source addresses are selected?
I thought I remembered that on unbound sockets the destination
route would be used to pick the first address of the outgoing
interface as the source address; the same address would be picked
on connecting a socket.
sys/netinet/in_pcb.c:in_pcb
ought I remembered that on unbound sockets the destination route
would be used to pick the first address of the outgoing interface as
the source address; the same address would be picked on connecting a
socket.
sys/netinet/in_pcb.c:in_pcbladdr() is your friend -
http://fxr.watson.org/fxr/s
at on unbound sockets the destination route
would be used to pick the first address of the outgoing interface
as the source address; the same address would be picked on
connecting a socket.
sys/netinet/in_pcb.c:in_pcbladdr() is your friend -
http://fxr.watson.org/fxr/source/netinet/in_pcb.c
enVPN instance
with a private /18 range.
I'd like my jails to be dual-homed, with a public and a VPN address each.
Processes in the jail should pick the appropriate source address depending on
the destination address, so that the source address for a connection going to
a VPN address will be
;d like my jails to be dual-homed, with a public and a VPN address
each. Processes in the jail should pick the appropriate source address
depending on the destination address, so that the source address for a
connection going to a VPN address will be the jails' VPN address, and
all ot
t programs which multicast sent a simple
> >>>text message and received the text message. I added some code to report
> >>>the source address, because none of the references that I looked at
> >>>specified the source IP address in the frame.
> >>>
report
the source address, because none of the references that I looked at
specified the source IP address in the frame.
I ran the sender on A -current system, AMD64 vintage last week. The
receiver was on a -current system I386 vintage last week. TCPDUMP shows
the source IP address in the
t message. I added some code to report
> >the source address, because none of the references that I looked at
> >specified the source IP address in the frame.
> >
> >I ran the sender on A -current system, AMD64 vintage last week. The
> >receiver was on a -current
On Sun, 1 Feb 2009, Derek Tattersall wrote:
In order to become familiar with multicast implementation using FreeBSD, I
found via Google a pair of test programs which multicast sent a simple text
message and received the text message. I added some code to report the
source address, because
In order to become familiar with multicast implementation using FreeBSD,
I found via Google a pair of test programs which multicast sent a simple
text message and received the text message. I added some code to report
the source address, because none of the references that I looked at
specified
On Sat, 13 Dec 2008, Frank Behrens wrote:
Bjoern A. Zeeb wrote on 8 Dec 2008 21:02:
Did you try the patch and did it work for you as expected? If so I'll
add it to my repo and the next jail patch.
Meanwhile I can confirm that your patch works well for me on an up-to-
date RELENG_7 kernel.
Bjoern A. Zeeb wrote on 8 Dec 2008 21:02:
> Did you try the patch and did it work for you as expected? If so I'll
> add it to my repo and the next jail patch.
Meanwhile I can confirm that your patch works well for me on an up-to-
date RELENG_7 kernel.
Thanks!
Frank
--
Frank Behrens, Osterw
the people directly
(with valid IPs). Instead of having policies to control the traffic
you are using simple IP filters on each side. So now in your network
topology, with your setup, with the destination not being on a
directly connected network, what would source address selection pick
as outgo
if you don't mind to go out with a source address of 192.168.90.1
instead of .254, what about this hack. What happens if you change the
route to
route change -net 192.168.200.0/24 192.168.90.2
(assuming the .2 is not on your local machine).
That works for the router, but for incoming pac
y, they are only an
optimization.
> > Does anybody have a better solution for source address selection? Am
> > I the only one with an IPSEC tunnel?
>
> The best solution actually is to teach your application to bind for
> this connection I guess instead of relying on any ha
go out with a source address of 192.168.90.1
instead of .254, what about this hack. What happens if you change the
route to
route change -net 192.168.200.0/24 192.168.90.2
(assuming the .2 is not on your local machine).
That works for the router, but for incoming packets on the interna
Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote on 27 Nov 2008 16:47:
> > Now I want to tunnel between my 192.168.90.0/24 and a foreign
> > 192.168.200.0/24. So I assigned 192.168.90.254/32 to lo2 and created
> > a static route.
>
> So if you don't mind to go out wi
Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote on 27 Nov 2008 16:47:
> I am running out the door but ... will check again tonight.
Thanks!
> So if you don't mind to go out with a source address of 192.168.90.1
> instead of .254, what about this hack. What happens if you c
192.168.90.1/24
and additional aliases for external addresses
...
Now I want to tunnel between my 192.168.90.0/24 and a foreign
192.168.200.0/24. So I assigned 192.168.90.254/32 to lo2 and created
a static route.
So if you don't mind to go out with a source address of 192.168.90.1
instea
Bjoern,
thanks for your fast answer.
Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote on 27 Nov 2008 14:53:
> Yes I know that hack though I never actually used it with a loopback
> as the loopback case is *uhm* gross. You know you are telling the
> kernel to actually send the packets to yourself which so
ifaddr *)sro.ro_rt->rt_ifa;
+// FB
if (ia == NULL) {
error = ENETUNREACH;
goto done;
Can you provide a patch to solve the connect problem?
Is there a better solution to setup source address selection for
IPSEC tunnels?
Let me answer t
"foreign"
subnet is 192.168.200.0/24. When I send packets via this tunnel I
must ensure the right source address, because the machine has several
interfaces. (BTW: this is so easy with openvpn and real routing, but
sometimes other people decide..) An easy solution was for me
ifconfig lo
On (06/10/2008 14:04), Julian Elischer wrote:
> Ryan French wrote:
> > Hi All,
> >
> > For my implementation of MPLS I have just about run out of time for my
> > dissertation so at the moment I am trying to create fake routing table
> > entries e.t.c. rather than doing this properly (I will be d
Ryan French wrote:
Hi All,
For my implementation of MPLS I have just about run out of time for my
dissertation so at the moment I am trying to create fake routing table
entries e.t.c. rather than doing this properly (I will be doing this once uni
is finished and I have more free time to work
Ryan, good day.
Mon, Oct 06, 2008 at 05:30:23PM +1300, Ryan French wrote:
> I now have receiving,
> decoding and sending of packets working, except for one small problem. When I
> send a packet back out the MAC address is wrong. I am looking for a way in
> the ether_output function in if_ethers
Hi All,
For my implementation of MPLS I have just about run out of time for my
dissertation so at the moment I am trying to create fake routing table
entries e.t.c. rather than doing this properly (I will be doing this once uni
is finished and I have more free time to work on it). I now have re
Bjoern A. Zeeb wrote:
On Sun, 24 Aug 2008, Bjoern A. Zeeb wrote:
Hi,
I have a patch, that was inspired by work from Y!, to do porper
IPv4 source address selection for unbound sockets (with multi-IP
jails).
You can temporary find it here:
http://people.freebsd.org/~bz/20080823-01
On Sun, 24 Aug 2008, Bjoern A. Zeeb wrote:
Hi,
I have a patch, that was inspired by work from Y!, to do porper
IPv4 source address selection for unbound sockets (with multi-IP
jails).
You can temporary find it here:
http://people.freebsd.org/~bz/20080823-01-in_pcbladdr.diff
People running my
Bjoern A. Zeeb wrote:
Hi,
I have a patch, that was inspired by work from Y!, to do porper
IPv4 source address selection for unbound sockets (with multi-IP
jails).
Hi,
This kinda overlaps with some other ideas I'd like to see go in. It
looks good and if it's already been tested,
Hi,
I have a patch, that was inspired by work from Y!, to do porper
IPv4 source address selection for unbound sockets (with multi-IP
jails).
You can temporary find it here:
http://people.freebsd.org/~bz/20080823-01-in_pcbladdr.diff
People running my latest jail patches have been ``testing
Don't forget the souls who find themselves using jails. In this case it
is common to want a name server on the parent host but not on any of the
jail IPs.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ne
es the connection as
having a source address of 0.0.0.0 instead of 127.0.0.1.
Can you capture source port as well (squid.conf says %>p will do this)?
Thanks, I am tcpdumping for this already but will change squid.conf.
Is there any correlation with the source port or package being fetch
e connection as
>having a source address of 0.0.0.0 instead of 127.0.0.1.
Can you capture source port as well (squid.conf says %>p will do this)?
Is there any correlation with the source port or package being fetched?
Is it consistent?
--
Peter Jeremy
pgplcBkHQKfdh.pgp
Description: PGP signature
1 - 100 of 139 matches
Mail list logo
