Re: Cjc's Ipfilter/Bridge patch

2002-12-06 Thread Eric Masson
 Crist == Crist J Clark [EMAIL PROTECTED] writes:

 Crist No, it's not there. I've just been way to busy with my day-job
 Crist to do much FreeBSD work for the last few months.

Welcome to the real world :)

 Crist But I'll try to add this code today.

Thanks a lot.

Eric Masson

-- 
 Bref, me dire que j'ai peut-être contribué, ne serait-ce que d'un
 epsilon, à la propagation de serveurs compatibles avec FrontPage me
 flanque des remontées gastriques peu reluisantes.
 -+- FM in Guide du Macounet Pervers : Bien préparer sa digestion -+-

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message



Squid and NATD with Redirect of ports

2002-12-06 Thread Joao Carlos
I'm having the following problem.

FreeBSD 4.7-STABLE (but with any version it does not work either)

I've a FreeBSD connected to a cable network, with only one IP Address.
My FreeBSD has three network cards. One is connected to my internal network,
other is connected to the cable, and the other is connected to a server that
has some serves something to the Internet.

I'm using IPFIREWALL and NATD, and without squid everything works fine. But
I have to use SQUID + SQUIDGUARD to block some content and urls.
The problem is:
When the client is using squid, it requests www.somesite.com that is hosted
at the server conected to this FreeBSD and has a non valid IP address.
External access works because NATD redirects the port 80 to the internal
address, but SQUID, that is located at the firewall, resolves the
www.somesite.com to the local ip address and tries to connect to the
localhost port 80. It does not pass the packets to the natd to redirect
because it is a local ip address. Then i get Connection Refused because
there is no web server at the firewall.

Any ideas how i can solve this problem? I really need the clients using the
squid at the IE configuration.


Thanks.
---
Joao Carlos
[EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message



FreeBSD 4.7 and shapeing bridge

2002-12-06 Thread Bartlomiej Butyn
Hi.
I'm trying to configure shapeing bridge on FreeBSD and I have problems
with putting packets to pipe with ipfw. My configuration is:

%uname -a
FreeBSD bridge1.milc.com.pl 4.7-RELEASE-p2 FreeBSD 4.7-RELEASE-p2 #0:
Fri Dec  6 13:31:37 CET 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL  i386

cvsuped about 2 hours ago. I'm configuring test pipes with:

bridge1# ipfw pipe 1 config bw 64Kbit/s
bridge1# ipfw pipe 2 config bw 64Kbit/s
bridge1# ipfw add pipe 1 ip from any to any out recv rl0 xmit vr0
bridge1# ipfw add pipe 2 ip from any to any out recv vr0 xmit rl0

then, I make some nettwork traffic going throught that bridge, and:

bridge1# ipfw show
001000  0 pipe 1 ip from any to any out recv rl0 xmit vr0
002000  0 pipe 2 ip from any to any out recv vr0 xmit rl0
65535 2626 283073 allow ip from any to any

Can you explain me why didn't any packet match rules 100 and 200?
Measured network traffic is about 7Mbit/s. (that's because there is
HUB between vr0 and test host), but why this bridge does not shapeing
any traffic?

Because I'm new on this list I don't know that I gave you all
informations needed to answer to me. If not, tell me and I'll give you more
with plaesure.
TIA.

-- 
Bart³omiej Butyn aka Yoss
Nie ma tego z³ego co by na gorsze nie wysz³o.
 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message



Re: FreeBSD 4.7 and shapeing bridge

2002-12-06 Thread Kevin Day
At 09:45 AM 12/6/2002, Bartlomiej Butyn wrote:

Hi.
I'm trying to configure shapeing bridge on FreeBSD and I have problems
with putting packets to pipe with ipfw. My configuration is:

%uname -a
FreeBSD bridge1.milc.com.pl 4.7-RELEASE-p2 FreeBSD 4.7-RELEASE-p2 #0:
Fri Dec  6 13:31:37 CET 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL  i386

cvsuped about 2 hours ago. I'm configuring test pipes with:

bridge1# ipfw pipe 1 config bw 64Kbit/s
bridge1# ipfw pipe 2 config bw 64Kbit/s
bridge1# ipfw add pipe 1 ip from any to any out recv rl0 xmit vr0
bridge1# ipfw add pipe 2 ip from any to any out recv vr0 xmit rl0

then, I make some nettwork traffic going throught that bridge, and:

bridge1# ipfw show
001000  0 pipe 1 ip from any to any out recv rl0 xmit vr0
002000  0 pipe 2 ip from any to any out recv vr0 xmit rl0
65535 2626 283073 allow ip from any to any

Can you explain me why didn't any packet match rules 100 and 200?
Measured network traffic is about 7Mbit/s. (that's because there is
HUB between vr0 and test host), but why this bridge does not shapeing
any traffic?

Because I'm new on this list I don't know that I gave you all
informations needed to answer to me. If not, tell me and I'll give you more
with plaesure.
TIA.


Have you turned on ipfw for bridging? Try this:

sysctl -w net.link.ether.bridge_ipfw=1





To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message



Re: FreeBSD 4.7 and shapeing bridge

2002-12-06 Thread Joost Bekkers
On Fri, Dec 06, 2002 at 04:45:24PM +0100, Bartlomiej Butyn wrote:
 bridge1# ipfw pipe 1 config bw 64Kbit/s
 bridge1# ipfw pipe 2 config bw 64Kbit/s
 bridge1# ipfw add pipe 1 ip from any to any out recv rl0 xmit vr0
 bridge1# ipfw add pipe 2 ip from any to any out recv vr0 xmit rl0




/usr/src/sys/net/bridge.c says:
/*
* The third parameter to the firewall code is the dst. interface.  
* Since we apply checks only on input pkts we use NULL.  
* The firewall knows this is a bridged packet as the cookie ptr
   
* is NULL.
*/

so if you use

ipfw add pipe 1 ip from any to any in recv rl0 bridged
ipfw add pipe 2 ip from any to any in recv vr0 bridged

things should be fine.

-- 
greetz Joost
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message



Re: FreeBSD 4.7 and shapeing bridge

2002-12-06 Thread Yoss
On Fri, Dec 06, 2002 at 06:31:55PM +0100, Joost Bekkers wrote:

 so if you use
 ipfw add pipe 1 ip from any to any in recv rl0 bridged
 ipfw add pipe 2 ip from any to any in recv vr0 bridged
 things should be fine.

Yes, now packets are going through pipes.
But it doesn't help me in the matter of fact. I have four xDSL links 
concentrated in one point and connected to the router. I have to cut down 
speed via these links to 1Mbit to be sure that every link will have 2Mbit 
bandwidth from router. Now I can shape bandwidth incoming from every link, 
but there is possibility that hosts on 2 of them will send data to 
host on third link, and then third one will be full. 
Is there any possibility do shape outgoing bandwidth on bridge in depend of 
interface it is going out?
TIA

-- 
Bartomiej Butyn aka Yoss
Nie ma tego zego co by na gorsze nie wyszo




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message



Re: broadcast over loopback

2002-12-06 Thread Joshua Graessley

Thank you for the reply Dan!

I am aware of the issues with broadcast, and I strongly urge people to 
use multicast instead of broadcast for a variety of reasons. All the 
same, I've been asked to address this issue and I wanted to understand 
why FreeBSD doesn't allow broadcast on the loopback interface. 
Conceptually, it sort of makes sense to allow it. Using a broadcast 
should result in everyone on some link receiving your packet. If 
loopback is your only interface that's up, then why not use that? In 
the case of loopback, you are the only one on your link, so you should 
still receive your broadcast.

Is there a technical reason this was done (i.e. if I set the broadcast 
flag on loopback I'll be chasing down other bugs until my hair turns 
grey or falls out) or is it a conceptual reason (i.e. broadcast, on 
loopback, are you out of your mind?).

Other platforms out there will handle broadcast on the loopback 
interface. Is it desirable to make changes to the FreeBSD stack to get 
this behavior?

Thanks,
-josh

On Thursday, December 5, 2002, at 04:50 PM, Dan Lukes wrote:

[EMAIL PROTECTED] wrote, On 12/05/02 20:41:


Is there a reason that the broadcast flag is not set on the loopback
interface? It seems like it might be useful to allow applications that
use broadcast to continue to work even when loopback is the only
interface.


	Your application shouldn't use broadcast unless it knows it run in 
broadcast capable environment or it shouldn't refuse to run when it 
cannot send a packet - as it doesn't care where it's packets are sent 
to.


	BTW, the broadcast are handled in mad way in TCP/IP stack already - 
the destination of 255.255.255.255 is silently rewritten to network 
broadcast and sent over first interface (if it is broadcast capable) 
or it is routed (often to default route). You can't send the 
non-network broadcast to interface of your choice (unless you use  bpf).


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message



Re: broadcast over loopback

2002-12-06 Thread Jason Hunt
On Fri, 6 Dec 2002, Joshua Graessley wrote:

 I am aware of the issues with broadcast, and I strongly urge people to
 use multicast instead of broadcast for a variety of reasons. All the
 same, I've been asked to address this issue and I wanted to understand
 why FreeBSD doesn't allow broadcast on the loopback interface.
 Conceptually, it sort of makes sense to allow it. Using a broadcast
 should result in everyone on some link receiving your packet. If
 loopback is your only interface that's up, then why not use that? In
 the case of loopback, you are the only one on your link, so you should
 still receive your broadcast.

 Is there a technical reason this was done (i.e. if I set the broadcast
 flag on loopback I'll be chasing down other bugs until my hair turns
 grey or falls out) or is it a conceptual reason (i.e. broadcast, on
 loopback, are you out of your mind?).


With any kind of broadcast media, unless this is specific to Ethernet, or
there are some exceptions, a broadcast packet sent by a station is
received on every port other than the port that the packet came
from.  As far as I know, a station should never receive it's own broadcast
packets unless you have a loop somewhere in your Layer 2 infrastructure.
I believe that the above applies to IP broadcasts (or any other Layer 3
protocols) as well.


 Other platforms out there will handle broadcast on the loopback
 interface. Is it desirable to make changes to the FreeBSD stack to get
 this behavior?

Any examples?  I cannot think of a practical case where this would be
required.  I would think that an application will know if it sent a
broadcast or not, so it shouldn't have to receive that broadcast itself.
Anyone disagree?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message



Re: Sysctl and root privileges, how could I avoid them ?

2002-12-06 Thread JINMEI Tatuya / $B?@L@C#:H(B
 On Mon, 02 Dec 2002 10:14:54 +0100, 
 Juan Francisco Rodriguez Hervella [EMAIL PROTECTED] said:

 Are you talking about the flag CTLFLAG_RW ? I'm using req-oldptr ==
 NULL and
req- newptr != NULL to add a new element into a kernel table and I
 plan
 to use req-oldptr  req-newptr != NULL to show the elements of the
 table...

If you just want to show (get) the elements, you don't have to have a
non NULL newptr.  Then the root privilege won't be required.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message