Ludovit Koren wrote:
>
> Hi,
>
> is there any possibility to set the routing statically on a multi-homed
> host so, that the packet is sent back via the same interface, as it has
> came from? Something like more default routes (it is not good name for
> it, I hope you can understand what I mean),
Ludovit Koren:
>is there any possibility to set the routing statically on a multi-homed
>host so, that the packet is sent back via the same interface, as it has
>came from?
ipfw(4) is your friend, for example on a box with addresses
192.168.20.31 and 172.16.164.54 with respective gateways 192.168.
Ludovit Koren wrote:
>
> Hi,
>
> is there any possibility to set the routing statically on a multi-homed
> host so, that the packet is sent back via the same interface, as it has
> came from? Something like more default routes (it is not good name for
> it, I hope you can understand what I mean),
Hi,
is there any possibility to set the routing statically on a multi-homed
host so, that the packet is sent back via the same interface, as it has
came from? Something like more default routes (it is not good name for
it, I hope you can understand what I mean), depending on particular
interface
This should be the full patch , but I'm not so sure :)
I add ifconfig and net/rtsock.c fixes. I hope I don't miss something this
time :)
--- sys/net/if.cSun Apr 28 08:40:25 2002
+++ sys/net/if.my.c Sat Jun 8 20:52:12 2002
@@ -952,6 +952,7 @@
struct ifstat *ifs;
Oooo...ppzzZ. I think I didn't sleep enough last night :P. But I found
what I was looking for :).
This is it line 950 of net/rtsock.c :
ifm->ifm_flags = (u_short)ifp->if_flags | ifp->if_ipending;
And I even try it - it works. But Im not sure if it will work in all
cases...
On Sat, 8 J
On Sat, 8 Jun 2002 21:53:59 +0300 (EEST), Iasen Kostov <[EMAIL PROTECTED]> wrote:
> Here is the patch. I'm now looking in the code to see where kernel
> replays to the interface table requests. I hope there are not a lot
> of places where it sets ifm_flags.
[.]
I think you forgot to add the
Here is the patch. I'm now looking in the code to see where kernel
replays to the interface table requests. I hope there are not a lot
of places where it sets ifm_flags.
> This certainly seems to make sense. Could you generate a patch and send
> it to me ? I can test & commit it, and then may
This certainly seems to make sense. Could you generate a patch and send
it to me ? I can test & commit it, and then maybe look at removing that
horrible BOOTP hack :)
I haven't looked at it yet, but it'll be worth testing that ifm_flags is
populated correctly in routing socket messages...
Than
On Sat, 8 Jun 2002, Brian Somers wrote:
> On Fri, 7 Jun 2002 17:27:46 +0300 (EEST), Iasen Kostov <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Fri, 7 Jun 2002, Iasen Kostov wrote:
> >
> > >
> > > I think it's possible to use SIOCSIFCAP to tell the kernel not to set
> > > host route via IFCAP_NORO
On Fri, 7 Jun 2002 17:27:46 +0300 (EEST), Iasen Kostov <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 7 Jun 2002, Iasen Kostov wrote:
>
> >
> > I think it's possible to use SIOCSIFCAP to tell the kernel not to set
> > host route via IFCAP_NOROUTE or something similar which will set
> > IFCAP_NOROUT
On Fri, 7 Jun 2002, Iasen Kostov wrote:
>
> I think it's possible to use SIOCSIFCAP to tell the kernel not to set
> host route via IFCAP_NOROUTE or something similar which will set
> IFCAP_NOROUTE in uif_capenable. This flag will be checked in in_ifinit()
> and if it is set no host route will
I think it's possible to use SIOCSIFCAP to tell the kernel not to set
host route via IFCAP_NOROUTE or something similar which will set
IFCAP_NOROUTE in uif_capenable. This flag will be checked in in_ifinit()
and if it is set no host route will be added. And ofcourse there should be
a way to set
in reachable via
> an alternative path/interface. To accomplish this goal you need to run a routing
> protocol - in my setup the plain old RIP 1 / routed combination worked just fine,
> although this was just an example...
>
> Marko
>
That means that VIPA does not work in my case.
Iasen Kostov wrote:
> > You might want to take a look at Marko Zec's VIPA patches that he posted to
> > -net a few days ago. You should be able to find it in the mailing list
> > archives under the subject "Patch for review: source VIPA".
> >
> It will work only if I can arpresolv VIPA and o
> You might want to take a look at Marko Zec's VIPA patches that he posted to
> -net a few days ago. You should be able to find it in the mailing list
> archives under the subject "Patch for review: source VIPA".
> If you have the time to review/test his patches, then perhaps we can get
> i
On Wed, 5 Jun 2002, Iasen Kostov wrote:
> It works fine (just a warrning) with 4.4 kernel and before, but in 4.5
> there is a check for host route addition and if it fail to add a route
> it also fails to set iface address (ofcourse I've patch it for myself).
> I need this not just for saving I
Hi,
Some times I don't need addition of host route when I'm setting iface's
address like in this case :
xl0: flags=8943 mtu 1500
options=3
inet 212.36.9.113 netmask 0xfe00 broadcast 212.36.9.255
ether 00:04:76:1b:cb:72
media: Ethernet autoselect (100baseTX
18 matches
Mail list logo
