On Jan 17, 2007, at 11:00 AM, Kailas Ramasamy wrote:
Hi Mike,
Thanks a lot. This is what I was looking for.
-Kailas
On 1/17/07, Mike Meyer <[EMAIL PROTECTED]> wrote:
In <[EMAIL PROTECTED]>,
Kailas
Ramasamy <[EMAIL PROTECTED]> typed:
> Hi Mike,
> I read through fork() and exec() man pages
Hi Mike,
Thanks a lot. This is what I was looking for.
-Kailas
On 1/17/07, Mike Meyer <[EMAIL PROTECTED]> wrote:
In <[EMAIL PROTECTED]>, Kailas
Ramasamy <[EMAIL PROTECTED]> typed:
> Hi Mike,
> I read through fork() and exec() man pages but I couldn't find anything
> related to
> this. Basical
In <[EMAIL PROTECTED]>, Kailas Ramasamy <[EMAIL PROTECTED]> typed:
> Hi Mike,
> I read through fork() and exec() man pages but I couldn't find anything
> related to
> this. Basically, I want to launch a telnet session from a process and pass
> in
> /dev/console as stdin and stdout.
Well, you don't
Hi Mike,
I read through fork() and exec() man pages but I couldn't find anything
related to
this. Basically, I want to launch a telnet session from a process and pass
in
/dev/console as stdin and stdout.
Thanks
Kailas
On 1/16/07, Mike Meyer <[EMAIL PROTECTED]> wrote:
In <[EMAIL PROTECTED]>, Ka
In <[EMAIL PROTECTED]>, Kailas Ramasamy <[EMAIL PROTECTED]> typed:
> Hi Mike,
> Yes, that what I am planing but I want to do this dynamically. Do you know
> how to launch a
> telnet session from a process?. How do I pass stdin and stdout to the telnet
> from a process?.
See the fork() and exec() m
Hi Mike,
Yes, that what I am planing but I want to do this dynamically. Do you know
how to launch a
telnet session from a process?. How do I pass stdin and stdout to the telnet
from a process?.
Thanks
Kailas
On 1/16/07, Mike Meyer <[EMAIL PROTECTED]> wrote:
In <[EMAIL PROTECTED]>, Kailas
Ramas
On Tue, Jan 16, 2007 at 03:03:55PM -0800, Kailas Ramasamy wrote:
> Hi,
> Within a FreeBSD system, I want to telnet to another system and bridge that
> session to the
> console port so that when an user connects to the system via console port,
> it is automatically
> redirected to other system for I
In <[EMAIL PROTECTED]>, Kailas Ramasamy <[EMAIL PROTECTED]> typed:
> Hi,
> Within a FreeBSD system, I want to telnet to another system and bridge that
> session to the
> console port so that when an user connects to the system via console port,
> it is automatically
> redirected to other system for
Hi,
Within a FreeBSD system, I want to telnet to another system and bridge that
session to the
console port so that when an user connects to the system via console port,
it is automatically
redirected to other system for I have already established a telnet session.
Your help is greatly appreciate
l, you COULD pass it out to a netgraph
node that strips off the header
and stores the info in a tag, and then passes it back to ipfw, but
I don't know how the details would work. (I haven't been in ifpw since
it was rewritten). Alternatively you could use netgraph bridging and
tehnetgraph
lan interfaces on each of the physical ones, then define
N bridges between the corresponding vlans (and i think there is
a limit on how large N can be).
It's worse than that. The device has four bridged interfaces. One up,
three down to three switches. Each switch holds 24 vlans. Th
On Sat, Aug 13, 2005 at 12:49:56AM +0200, Jeremie Le Hen wrote:
> Hi,
>
> > I am afraid the existing code cannot help you.
> > The packets you see are encapsulated in 802.1q aka VLAN frames,
> > and since ipfw2 does not try to decapsulate the packets, you
> > don't get to see the IP headers.
> >
Hi,
> I am afraid the existing code cannot help you.
> The packets you see are encapsulated in 802.1q aka VLAN frames,
> and since ipfw2 does not try to decapsulate the packets, you
> don't get to see the IP headers.
>
> Your most reasonable option would be to write a new ipufw2 opcode,
> say som
@ earlier, but upon further investigation
> of the issue, I realize that I basically need a "hack".
>
> Warning, long.
>
> My original question:
>
> [begin]
>
> I'm setting up a bridging firewall where the packets are passing through
> on dot1q trunks.
Note: I posted this to questions@ earlier, but upon further investigation
of the issue, I realize that I basically need a "hack".
Warning, long.
My original question:
[begin]
I'm setting up a bridging firewall where the packets are passing through
on dot1q trunks. Figure si
today, hope for tomorrow." //
- Original Message -
From: "SharkTECH Maillists" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, September 11, 2004 5:22 AM
Subject: Interface Bonding & Bridging problem
Hello,
I have been running a FreeBSD 4.10-STABLE
side.
The problem is although bonding seems to work fine as I can assign IPs at
fec0/ngeth0 and send/receive packet with both cards using the virtual
interface, I cannot get bridging to work at all between ngeth0/fec0(virtual)
and em2(switch). There are no errors in logs, it just doesn't se
> Does the bridging code in FreeBSD 5.2-RELEASE have the hability
> to perform mac checking for a given IP?
Since you can filter bridged packets using ipfw(8) and the latter is able
to match against MAC address, I would say yes. Nevertheless, it may not
be suitable enough for your
> I couldn't find any help on the exact syntax. And the manpage says
> it's somewhat difficult.
>
> Have you seen any practical article on this scenario? I couldn't find any.
There is some documentation written on this topic by Alex Dupre:
http://www.freebsd.org/doc/en/articles/filtering-bridges/
PROTECTED]> wrote:
>
> > Does the bridging code in FreeBSD 5.2-RELEASE have the hability
> > to perform mac checking for a given IP?
>
> Since you can filter bridged packets using ipfw(8) and the latter is able
> to match against MAC address, I would say yes. Neve
On Tue, Jun 15, 2004 at 03:57:12PM -0300, Aldrin Leal wrote:
> Does the bridging code in FreeBSD 5.2-RELEASE have the hability
> to perform mac checking for a given IP?
You could use ipfw2, which can match both on IP address and MAC
address.
I'll check arpwatch, but i'm more interested in tuning the bridging
code, making it suitable to my needs.
Any pointers?
- Original Message -
From: Jose Hidalgo Herrera <[EMAIL PROTECTED]>
Date: Tue, 15 Jun 2004 13:17:14 -0600
Subject: Re: Bridging Code - MAC Filtering
Hello,
Does the bridging code in FreeBSD 5.2-RELEASE have the hability
to perform mac checking for a given IP?
If it doesn't, does any kernel hacker could point me to places
where i could do it myself? Maybe proper pointers on debugging the
bridging facilities, tips, general gui
Hello Maxim,
today I've tried your hack and it works, at least it seems so.
It was not exactly the same setup but nearly the same.
The bridge has two interfaces (fxp0, fxp1) and
one host is connected to each interface (using crosslink
cables, no other networking devices such as broken HP
ProCurve
I have two 3com 3c589 10BT pc cards. As vanilla as they come.
In a previous thread, I described how a bit of pccard.conf mumbo jumbo made
it possible for me to get both cards up and running in 4.3-RELEASE. It was
explained to me that pccard.conf is deprecated, and that two pcmcia nics
shoul
>I am wondering if anyone knows of any workarounds to
>get IPFilter to filter across an ethernet bridge.
this a FAQ, or at least a Recently AQ.
ipfilter bridging only works on OpenBSD
Len
http://MenAndMice.com/DNS-training
http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 &
Hello,
I am wondering if anyone knows of any workarounds to
get IPFilter to filter across an ethernet bridge. The
bridge is working fine, and so is ipf, but ipf has no
effect on any packets that go across the bridge.
Pings to localhost are monitored and filtered, but
that's about it.
Any combi
/etc/rc.conf looks like this:
pccard_enable="YES"
pccard_mem="DEFAULT"
pccardd_flags=" -i 10 -i 15"
removable_interfaces="ep0 ep1"
network_interfaces="lo0"
(I have tried with and without that last lo0 line)
and /etc/defaults/pccard.conf looks like this:
config auto "ep0" 10
config auto "ep1"
Ok, so I finally got two identical "ep" cards to come up at the same time
and both work. Thanks.
But when I run:
sysctl -w net.link.ether.bridge=1
Nothing happens. They don't get put in promiscuous mode, and bridging does
not get turned on, even though I have bridging in
thank you - this was helpful. One last question - when you say that
bridging cannot work with wi cards because they do not support promiscuous
transmission, this makes me wonder two things:
1. Do you mean the wi driver does not support this, or you mean the actual
physical card itself is
Julian Elischer wrote:
> bridging is not a function of it being a pc-card..
This is true, particularly with netgraph bridging.
> actually bridging may already work with wi cards
> also netgraph bridgiung may also work...
>
Bridging cannot work with wi cards, since they do
Joesh Juphland writes:
|
| Great.
|
| Can I already bridge with an* ? And does this mean that bridging in
| general with pc cards is a-ok ?
This has been reported to work with the "an" driver with netgraph
bridging.
Doug A.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with &q
bridging is not a function of it being a pc-card..
actually bridging may already work with wi cards
also netgraph bridgiung may also work...
On Tue, 26 Jun 2001, Joesh Juphland wrote:
>
> Great.
>
> Can I already bridge with an* ? And does this mean that bridging in
>
Great.
Can I already bridge with an* ? And does this mean that bridging in
general with pc cards is a-ok ?
thanks.
>you WILL be able to bridge with WI cards
>no time estimates though..
>
>
>On Tue, 26 Jun 2001, Joesh Juphland wrote:
>
> >
> > Recently on th
ly, if the answer to #2 was 'yes', can I bridge between ep0 and an0
> ?
>
> I am just trying to figure out if the difficulties with 'wi' bridging are an
> odd, isolated case, or if bridging on pcmcia cards is, in general,
> difficult.
>
> Any further comm
I bridge between ep0 and an0
> ?
>
> I am just trying to figure out if the difficulties with 'wi' bridging are an
> odd, isolated case, or if bridging on pcmcia cards is, in general,
> difficult.
Ethernet bridging should work, however we can't the wireless bridgi
'an' (cisco aironet cards) ?
3. can I bridge between two 'ep' cards (3com pcmcia) ?
4. Finally, if the answer to #2 was 'yes', can I bridge between ep0 and an0
?
I am just trying to figure out if the difficulties with 'wi' bridging are an
odd,
Duncan Barclay wrote:
> I use IBSS and routing at home (with DHCP on a short timeout)
> to create seperate wired and wireless IP subnets. The FreeBSD
> box routes between the two and the external Cable Modem seamlessly.
>
> What disadvantages does this setup have compared with using a
> true acce
- Original Message -
From: "list tracker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, June 25, 2001 3:27 AM
Subject: Re: trouble with 802.11 and kernel bridging (more)
>
> ok, thank you! This explains my in
list tracker wrote:
>
> ok, thank you! This explains my inability to perform bridging like I
> expected to
>
> >I've been told the "wi" driver can't do bridging. The Cisco/Aironet
> >"an" driver can. Patches were submitted so you ca
ok, thank you! This explains my inability to perform bridging like I
expected to
>I've been told the "wi" driver can't do bridging. The Cisco/Aironet
>"an" driver can. Patches were submitted so you can do this. They are
>in the tree.
If I want
I have compiled options BRIDGE into my kernel. (also options IPFIREWALL,
and IPSTEALTH, but probably not important).
So I booted up with ep0 and wi0 in their slots, everything is great. I set
up bridging with:
sysctl -w net.link.ether.bridge=1
then made sure everything was wide open
> Hello,
>
> I'm using 4.2 release and i need bridging.
> Luigi tells in the manpage that the option
> to select specific devices for bridging is
> still in development.
>
> Does anybody know how far this work is done
> in 4.3 stable ?
it works on 4.3-RELEASE
Hello,
I'm using 4.2 release and i need bridging.
Luigi tells in the manpage that the option
to select specific devices for bridging is
still in development.
Does anybody know how far this work is done
in 4.3 stable ?
I need this feature very urgently, and all
of my experiments
When doing bridging (Luigi's standard bridging code) using two Davicom
DM9102A NIC's, I am seeing some strange results.
If I do a 'ping -s 8000' between two PC's sitting on either side of the bridge,
I see a whole bunch of TX underrun errors on both NIC's of th
FWIW, we have seen similar problems (poor throughput, TX underrun, and
watchdog timeouts) with plain TCP (not bridging) on systems with built-in
Davicom DM9102 devices running FreeBSD 4.0 and 4.2. Reboot improves the
performance for a while. There seems to be a few problems with the Davicom
On Tue, Aug 08, 2000 at 02:36:02PM +0900, Akinori -Aki- MUSHA wrote:
> At a quick glance, "start_bridge" doesn't seem to have chance to be 1,
> does it?
It's depend. I'm pretty tired that discussian about bridging. So if people
want to use bridge let set start_
At a quick glance, "start_bridge" doesn't seem to have chance to be 1,
does it? And, what's the difference among those three values of
"bridge"?
> + bridge="_bridge_on"
> + bridge="_bridge"
> + bridge="_bridge_off"
--
/
Ok, guys.
See in the attachment fix, you should apply it to prevent current behavior.
On Sun, Aug 06, 2000 at 07:14:59PM -0400, Robert Watson wrote:
> On Thu, 3 Aug 2000, Vladimir N. Silyaev wrote:
>
> > >Bridging on by default may
> > >have nasty side effects for
On Sun, 6 Aug 2000, Robert Watson wrote:
> Un-announced, the vmware port enabled bridging between the ethernet
> interfaces on my notebook
This is bad - ethernet segments should not be bridged without explicit
user confirmation, because they are commonly separated precisely for
security r
On Thu, 3 Aug 2000, Vladimir N. Silyaev wrote:
> >Bridging on by default may
> >have nasty side effects for multi-interface machines (especially security
> >side effects).
> It's several ways to work around about that:
> - compile kernel without bridging support.
&g
in-- reading table
>...
>
>The vmware2 port now seems to enable bridging by default, and generate a
>kernel message for every ethernet packet sent.
FreeBSD bridge code doesn't have any vmware related modifications. Only
one modification what was impelmented, it's a special
On Thu, 3 Aug 2000, Reinier Bezuidenhout wrote:
> I'm using vmware2 in a different way ... I do not have bridging enabled
> in the kernel. I'm using the host method although I do not have
> a "legal" subnet on the other side.
That was the configuration I was us
I'm using vmware2 in a different way ... I do not have bridging enabled
in the kernel. I'm using the host method although I do not have
a "legal" subnet on the other side.
I've ment to contact the port maintainer so he can add this to the
Hints.FreeBSD file.
I'
bridge_in-- reading table
bridge_in-- reading table
bridge_in-- reading table
bridge_in-- reading table
bridge_in-- reading table
bridge_in-- reading table
bridge_in-- reading table
bridge_in-- reading table
bridge_in-- reading table
...
The vmware2 port now seems to enable bridging by default
unity
> > to act as a repeater (not that you'd want to anyway) to have a
> > single collision domain.
>
> You know, you are right...never thought it
> through completely before I sent my reply. Sorry
> everyone for the wasted bandwidth.
>
>
On Fri, 7 Jul 2000, Narvi wrote:
> > On Thu, 6 Jul 2000, Sean Lutner wrote:
> >
> > >
> > > Bridges create a broadcast zone. broadcast packets will cross the bridge
> > > unobstructed.
> >
> > OK. So do bridged interfaces fall within the same collision
> > domain?... or are they just
a
> single collision domain.
You know, you are right...never thought it
through completely before I sent my reply. Sorry
everyone for the wasted bandwidth.
Have 1 more question (has to do with this bridging deal):
Anyone working on load-sharing/load-bal
They can't be in the same collision domain -- the only way to do that
is to have an Ethernet repeater which repeats bit by bit fron one
segment to another, and propagating a collision on one segment as a
jam on another.
On a FreeBSD box, where you interfaces to ethernet segments are NIC
cards, y
On Thu, 6 Jul 2000, Nick Rogness wrote:
> On Thu, 6 Jul 2000, Sean Lutner wrote:
>
> >
> > Bridges create a broadcast zone. broadcast packets will cross the bridge
> > unobstructed.
>
> OK. So do bridged interfaces fall within the same collision
> domain?... or are they just mem
domain?... or are they just members of the same broadcast domain?
FreeBSD bridging support places nodes in the same broadcast domain, but
different collision domains. As such, you may see reordering of packets
between segments, and packets may be lost transitting between segments.
FreeBSD
On Thu, 6 Jul 2000, Sean Lutner wrote:
>
> Bridges create a broadcast zone. broadcast packets will cross the bridge
> unobstructed.
OK. So do bridged interfaces fall within the same collision
domain?... or are they just members of the same broadcast domain?
Nick Rogness
- Spe
Bridges create a broadcast zone. broadcast packets will cross the bridge
unobstructed.
On Thu, 6 Jul 2000, Nick Evans wrote:
> Correct me if I am wrong, but isn't bridging of two interfaces supposed to
> make a duplicate of the traffic from one onto another? Why is it then that
>
(* On Thu, Jul 06, 2000 at 12:13:07PM -0400, Nick Evans wrote:
(* > Correct me if I am wrong, but isn't bridging of two interfaces supposed to
(* > make a duplicate of the traffic from one onto another? Why is it then that
(* > on the second interface I bridge to I only see
At 12:13 PM 7/6/00 -0400, Nick Evans wrote:
>
> Correct me if I am wrong, but isn't bridging of two interfaces supposed to
> make a duplicate of the traffic from one onto another? Why is it then
that on
> the second interface I bridge to I only see broadcast and multicast packe
On Thu, Jul 06, 2000 at 12:13:07PM -0400, Nick Evans wrote:
> Correct me if I am wrong, but isn't bridging of two interfaces supposed to
> make a duplicate of the traffic from one onto another? Why is it then that
> on the second interface I bridge to I only see broadcast and multi
Title: bridging
Correct me if I am wrong, but isn't bridging of two interfaces supposed to make a duplicate of the traffic from one onto another? Why is it then that on the second interface I bridge to I only see broadcast and multicast packets? I have fxp0 and fxp1 acting as a bridge,
dress as the source. Apparrently,
> the card needs to be set up as an access point (or something)
> to do bridging.
You can make it run as an access point... if and only if you're prepared
to produce an 802.11 protocol suite to run in the FreeBSD kernel, because
you won't b
> On my end, I have a box with a wi0 and fxp0--I was hoping to set it
> up to do transparent bridging. So far however, I can't get anything
> on this side of the bridge box to talk to the outside world. I
> can see all the network traffic from my box, however I can't tal
something)
to do bridging.
Is there a way to do this in the current driver? If not,
are there plans?
Chris
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
I have been trying for over a week now to get bridging working, but
without success. I have tried both 4.0 and current, but with no
luck. Anyways, my setup is as follows..
On one end is a Lucent WavePoint attached to the outside world. (Some
sort of switch I believe. I really don't under
Nick,
are you sure the problem does not depend upon having bridge_ipfw=1 ?
I don't think there is anything else IPv4-specific in the bridging
code, if it was we would also have problems with IPv4/IPX
and other non-ip protocols.
cheers
luigi
> Alas,
> IPv6 does not app
both of the prefixes show up on all of the hosts.
I don't really care if I can bridge IPv6 or not, truth be told. With
IPv6 the
vast number of subnets makes it unnecessary to bridge. But I need to be
able to
either keep the two interfaces totally separate despite the bridging of
other
prot
We were unable to get a wi configured on 4.0 release yesterday but it may
be that we didn't have the time to check out the configuration fully.
Was never recognized on boot-up. We've got a few more to get configured
over the next week so we'll put your patch in and try again.
Jim Flowers <[E
I have had some wi cards for a while, and while I have managed to get
an Airport to work (a friend helped me out), I believe that adding wi
to the list of bridge compatible interfaces may be helpful.
According to the documentation, the IBSS mode of the driver doesn't
work. That's too bad, as in
75 matches
Mail list logo
