Re: dummynet and vr(4)/egress broken in 4.11 ?

2005-01-30 Thread Jeremie Le Hen
> I didn't changed my kernel configuration file so much since my last
> kernel upgrade, I juste added gif(4), IPSEC_FILTERGIF and vr(4).
> I tested using this rule on ingress and egress of both my internal (sis0)
> and external interface (vr0) - inverting IPs where needed :-) - here are
> the results :
> 
>| ingress | egress  |
> ---+-+-+
> vr0 (ext)  |   OK|-|
> ---+-+-+
> sis0 (int) |   OK|   OK|
> ---+-+-+
> 
> I think that it is now very important to tell you that while upgrading
> my box to FreeBSD 4.11, I also changed my external interface from a 10
> MBits ep(4) to a 100 MBits vr(4).
> 
> I cannot switch back to ep(4) for the moment since it is not an option
> to have downtime, but according to the privous results, I'm pretty
> convinced there is a problem with the vr(4) driver (although I don't
> know how it can impact DUMMYNET).  Maybe the last commit on this
> driver in RELENG_4 (sys/pci/if_vr.c, rev 1.26.2.14) is the culprit.

Well, in fact I made further investigation :

- Only TCP seems to be affected.  UDP and ICMP appear to work
  without packet drop.

- Switching back from my vr(4) to my ep(4) did not resolve the
  problem.

Thus, it seems this problem is independant from the network driver
(which makes more sense because AFAIK the latters are not involved in
DUMMYNET, as they are in ALTQ for example).

I can still use pipes on interface ingress, internal interface egress,
but it fails when I use a pipe on egress on my external interface _for
packet being forwarded and NATed only_.  Weirdly I am still able to
use a TCP stream from the router itself.

I'll give a try to a 4.10 kernel ASAP.

Regards,
-- 
Jeremie Le Hen
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


if_stf and rfc1918

2005-01-30 Thread Lukasz Stelmach
Greetings All.

Once I've discussed this matter with Hajimu UMEMOTO and he posted a patch
that made it possible to run 6to4 router behind a nat (FreeBSD 4.x). Soon
I will probably be upgrading my old system to 5.x release so I checked
if newer stf code allows such operation and to my disapointment I've
found out that it doesn't (or at least it seems so). The comment in the
code says that it is a requirement of RFC3056. I've check it and in fact
it says that RFC1918 addresses MUST NOT be used as NLAs in 6to4 addresses.
But IMHO it does not mean that I can't run my 6to4 router behind a NAT
at all. In such a situation the IPv6 address contains valid public IPv4
address and the private one in the IPv4 header is substitutet by NAT. So
after the packets leave my site they are completly valid 6to4 packets.
Also when 6to4 packets come to me they are handeled properly.

My question now is why FreeBSD is so restrictive about it.

Best regards,
Łukasz Stelmach.

PS. Please cc: the answer, thank you.
-- 
|/   |_,  _   .-  --,  Już z każdej strony pełzną, potworne żądze
|__ |_|. | \ |_|. ._' /_. Będę uprawiał nierząd, za pieniądze


pgpuvRsIO7IAW.pgp
Description: PGP signature