Re: BRIDGE breaks ARP?

* Masachika ISHIZUKA <[EMAIL PROTECTED]> [010205 00:09] wrote: > > May i suggest to try a recent (feb.2, 2001) version of the code ? > > there have been long-standing problems with bridging on 4.x and > > in particular some related to the handling of broadcast packets (ARP > > requests are among t

Re: VPN question

IRE Has a rather nice IPSec client for NT/2K/Win that (at least) operates rather nicely with Cisco and Altiga stuff. It's one of the most commonly used clients from an OEM point of view. I've never tested it against FreeBSD but I think it would be possible with Pre-Shared keys? (At least easy to

Re: BRIDGE breaks ARP?

> I cvsuped three hours ago and the same ARP troubles happened. can you repeat exactly what the problem was (bridge machine not responding to ARP requests ?) and what is your exact setup (i am interested in ipfw config, and the following sysctl vars: net.link.ether.bridge net.l

Re: BRIDGE breaks ARP?

>> I cvsuped three hours ago and the same ARP troubles happened. > > can you repeat exactly what the problem was (bridge machine not > responding to ARP requests ?) and what is your exact setup (i > am interested in ipfw config, and the following sysctl vars: > > net.link.ether.bridge >

Re: packet loss when 'ipfw pipe list' with dummynet and bridge

>>> A better approach would probably be to set a semaphore before >>> starting, and release it at the end, and keep interrupts enabled >> >> As I set "net.inet.ip.dummynet.expire=0", if it will affect >> only to ip addresses founded newly when a semaphore is introduced, >> I'll be happy. > > n

Re: VPN question

Julian Elischer wrote: > > Motonori Shindo wrote: > > > > Mark, > > > > There are two that I know of; one is PPTP implementation and another > > is L2TP implementation. > > > > There is a ports/packages for PPTP called 'pptpclient'. You many need > > to modify pppd a little bit, depending on how

Re: packet loss when 'ipfw pipe list' with dummynet and bridge

> >>> A better approach would probably be to set a semaphore before > >>> starting, and release it at the end, and keep interrupts enabled > >> > >> As I set "net.inet.ip.dummynet.expire=0", if it will affect > >> only to ip addresses founded newly when a semaphore is introduced, > >> I'll be h

Re: BRIDGE breaks ARP?

> > can you repeat exactly what the problem was (bridge machine not > > responding to ARP requests ?) and what is your exact setup (i ... > The problem is that the bridge machine can not communicate any > other machines unless net.link.ether.bridge=0. That is no response > from/to any other mach

diskless boot of a PXE-compatible machine : finally done !

Hello, this a simili victory report : the PC now boots via PXE (this is a Motorola rack-mount PC, with a no-thrills BX motherboard and an fxp NIC, with a strictly 4.2-Release installation) the rc.diskless2 must be wrong (I've not yet checked with -Stable), as it tries to chmod, chgrp and find

Re: netgraph router? (was Re: BRIDGE breaks ARP?)

Julian Elischer wrote: > > > try using netgraph bridging instead. and I replied: > > Can't do this until the netgraph code supports ipfirewall > > or ipfilter. to which Julian replied: > why can't you use routing? (ipfw only REALLY works with IP > packets anyhow..) OR yo

Re: netgraph router? (was Re: BRIDGE breaks ARP?)

Rich Wales wrote: > > Julian Elischer wrote: > > > > > try using netgraph bridging instead. > > and I replied: > > > > Can't do this until the netgraph code supports ipfirewall > > > or ipfilter. > > to which Julian replied: > > > why can't you use routing? (ipfw only REALLY

Re: BRIDGE breaks ARP? (more info)

Hi! "Rich Wales" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Robert Watson wrote: > > > There used to be a kludge that mapped the ether_header.ether_type > > field of non-IP packets into the UDP port number for the purposes > > of certain IPFW rules when bridg

Re: BRIDGE breaks ARP? (more info)

as a matter of fact -- i believe the recent commit by julian on netinet/if_ether.c (1.74 -> 1.75 and 1.64.2.5 -> 1.64.2.6, specifically the first part of the patch) is responsible for this bug. Essentially: before that patch, as the comment near to the code clearly says, if bridging was active, a

Re: netgraph router? (was Re: BRIDGE breaks ARP?)

Julian Elischer wrote: > some people run a bridge between two ethernet segments, > but give them different IP netranges, . . . I suppose I could do this, provided I could specify a more-or-less arbitrary range or set of IP addresses for each segment. I can't do conventional IP subnettin

Re: BRIDGE breaks ARP?

> was changed to return 0x4, which may somehow conflict with > 'normal' return values. In any case the 0x4 should be a > #define. It does not conflict with a normal value, those are in the range 0-65535 (0x). The 0x4 was supposed to be a #define in ip_fw.h (it is in -current, i

Re: BRIDGE breaks ARP? (more info)

Luigi Rizzo wrote: > > as a matter of fact -- i believe the recent commit by julian on > netinet/if_ether.c (1.74 -> 1.75 and 1.64.2.5 -> 1.64.2.6, specifically > the first part of the patch) is responsible for this bug. > > Essentially: before that patch, as the comment near to the code > clear

Re: BRIDGE breaks ARP? (more info)

Luigi Rizzo wrote: > > as a matter of fact -- i believe the recent commit by julian on > netinet/if_ether.c (1.74 -> 1.75 and 1.64.2.5 -> 1.64.2.6, specifically > the first part of the patch) is responsible for this bug. > > Essentially: before that patch, as the comment near to the code > clear

Re: BRIDGE breaks ARP? (more info)

Ok, mea culpa I figured it out.. Luigi.. does this fix it? (void)memcpy(&itaddr, ea->arp_tpa, sizeof (itaddr)); TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { #ifdef BRIDGE /* * For a bridge, we want to check the address irrespective

RE: BRIDGE breaks ARP? (more info)

Ah! Yep this seems to be fixing my problem here. I actually reimplemented Julian's patch on a test system here, but luckily did not get confused by the order of the test (the first test should be if(do_bridge || ...) rather than if (!do_bridge)). To Julian's defence, the use of a #ifdef BRIDGE

PCMCIA 10/100BaseT Cards That Support Promiscuous Mode

Any suggestions for a 4.2-RELEASE supported 10/100BaseT, PCMCIA card suitable for bridging? If this is not the correct list to ask, please direct me to an appropriate list. I found that the WaveLAN PCMCIA supports promiscuous mode, however, I need a wired card. And, as I also found out, the "Low

Re: BRIDGE breaks ARP? (more info)

Patrick Bihan-Faou wrote: > > Ah! > > Yep this seems to be fixing my problem here. I actually reimplemented > Julian's patch on a test system here, but luckily did not get confused by > the order of the test (the first test should be if(do_bridge || ...) rather > than if (!do_bridge)). > > To J

Re: PCMCIA 10/100BaseT Cards That Support Promiscuous Mode

At Mon, 5 Feb 2001, [EMAIL PROTECTED] wrote: >Any suggestions for a 4.2-RELEASE supported 10/100BaseT, PCMCIA card >suitable for bridging? If this is not the correct list to ask, please >direct me to an appropriate list. > >I found that the WaveLAN PCMCIA supports promiscuous mode, however, I >ne

Re: BRIDGE breaks ARP? (more info)

Patrick Bihan-Faou wrote: > > Ah! > > Yep this seems to be fixing my problem here. I actually reimplemented > Julian's patch on a test system here, but luckily did not get confused by > the order of the test (the first test should be if(do_bridge || ...) rather > than if (!do_bridge)). > > To J

Re: BRIDGE breaks ARP? (more info)

Patrick Bihan-Faou wrote: > > Ah! > > Yep this seems to be fixing my problem here. I actually reimplemented > Julian's patch on a test system here, but luckily did not get confused by > the order of the test (the first test should be if(do_bridge || ...) rather > than if (!do_bridge)). > > To J

RE: BRIDGE breaks ARP? (more info)

Hi Julian, > > Yep this seems to be fixing my problem here. I actually reimplemented > > Julian's patch on a test system here, but luckily did not get > confused by > > the order of the test (the first test should be if(do_bridge || > ...) rather > > than if (!do_bridge)). > > > > To Julian's def

Re: BRIDGE breaks ARP? (more info)

> [Charset iso-8859-15 unsupported, skipping...] > Luigi.. does this fix it? it looks like it essentially reverts to the old (1.75) behaviour, which means it does not fix bugs, it is only a workaround to let people run kernels with bridging compiled-in as if it was not compiled-in. I think the p

RE: BRIDGE breaks ARP? (more info)

Hi again, Maybe I am misunderstanding things, but since the arp-request we recieve are for our IP address, do we need to forward them to the other segments ? Here is my setup: [PC : 192.168.1.254][rl0]---[FreeBSD : 192.168.1.1]---[fxp0][] On the freebsd machine I have 2 tcpdumps

Re: BRIDGE breaks ARP? (more info)

Luigi Rizzo wrote: > it looks like it essentially reverts to the old (1.75) behaviour, > . . . when bridging is compiled in (and now, when bridging is > enabled), arp requests do not consider the interface from which > the request came from. . . . there are some cases where you

Re: BRIDGE breaks ARP? (more info)

btw sorry but i keep getting this msg from elm when i try to reply to you... [Charset iso-8859-15 unsupported, skipping...] and it prevents me from including the original msg in the reply, i need to do a cut&paste... > Maybe I am misunderstanding things, but since the arp-request we rec

Re: BRIDGE breaks ARP? (more info)

> Luigi Rizzo wrote: > > > it looks like it essentially reverts to the old (1.75) behaviour, > > . . . when bridging is compiled in (and now, when bridging is > > enabled), arp requests do not consider the interface from which > > the request came from. . . . there are some case

Re: BRIDGE breaks ARP? (Julian's patch)

Luigi Rizzo wrote: > the answer is in the first line... it will be the same as before. > There are surely situations where you can have misbehaviours, > though i cannot think of an easy and general example. OK, I'll try this patch (hopefully tonight, when I get home from work) and I'

Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch))

Good news and bad news. First the good news: The bridge is answering ARP requests for its own hardware address on the internal (rl0) interface now. I rebooted my bridge (from work, via the DSL line) just now, with a new kernel incorporating Julian's patch from earlier today.

Re: diskless boot of a PXE-compatible machine : finally done !

in your rc.conf or rc.conf.local, you should set early_nfs_mounts="YES" so that /usr and friends are mounted before rc.diskless2 is invoked. This has worked for me at least in 3.1-something (the scripts in the CVS repository derive from the setup i have prepared on that version). not su

Re: BRIDGE breaks ARP? (more info)

On Mon, Feb 05, 2001 at 01:53:12PM -0800, Luigi Rizzo wrote: > > If people wonders what is this "cluster-id" -- that code comes > from some unreleased code that i wrote in 2.2.x times > which makes FreeBSD work as a VLAN bridge. > So the cluster-id is essentially the VLAN-ID, and the > special ID

Re: Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch))

> Good news and bad news. > > First the good news: > > The bridge is answering ARP requests for its own hardware address > on the internal (rl0) interface now. expected :) > Now the bad news: > > ARP replies from the bridge to the DSL modem (via the external > i/f) are still g

Re: BRIDGE breaks ARP? (more info)

> > If people wonders what is this "cluster-id" -- that code comes > > from some unreleased code that i wrote in 2.2.x times > > which makes FreeBSD work as a VLAN bridge. ... > Talking about trunks and VLANs, I've got some code for implementing ISL, > but no ISL switches to hand anymore, if anyo

Re: BRIDGE breaks ARP? (more info)

On Mon, Feb 05, 2001 at 04:34:50PM -0800, Luigi Rizzo wrote: > > > If people wonders what is this "cluster-id" -- that code comes > > > from some unreleased code that i wrote in 2.2.x times > > > which makes FreeBSD work as a VLAN bridge. > .. > > Talking about trunks and VLANs, I've got some code

Re: Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch))

I wrote: > > ARP replies from the bridge to the DSL modem (via the > > external i/f) are still getting sent to the desktop > > (via the internal i/f), Luigi replied: > this is a bit less expected -- because the reply is unicast to > the MAC of the host requesting the packet,

Re: BRIDGE breaks ARP? (more info)

Not your culpa at all. It was my patch and I made a dumb mistake. *tries to hide face in shame* DocWilco At 12:07 5-2-01 -0800, you wrote: >Ok, mea culpa > >I figured it out.. >Luigi.. does this fix it? > > > (void)memcpy(&itaddr, ea->arp_tpa, sizeof (itaddr)); > TAILQ_

Re: Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch))

> > > external i/f) are still getting sent to the desktop > > > (via the internal i/f), > > Luigi replied: > > > this is a bit less expected -- because the reply is unicast to > > the MAC of the host requesting the packet, and ether_output() > > is called with the correct int

Re: Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch))

Luigi wrote: > OK, I have a half idea on why this happens, though it would > mean that you are being unlucky and the MAC dst-address of > the ARP packet collides with some address and prevents the > bridging code from locating the correct interface to use > for output. I'll a

Re: Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch))

I just noticed something else weird. I did "arp -a" on my bridge, and one of the entries was for the bridge itself. In other words, the bridge had an ARP entry telling it its own hardware address (on its external, "xl0" interface, in case it matters). The superfluous ARP entry was marked as per

Re: BRIDGE breaks ARP? (more info)

Luigi Rizzo wrote: > > > [Charset iso-8859-15 unsupported, skipping...] > > Luigi.. does this fix it? > > it looks like it essentially reverts to the old (1.75) behaviour, > which means it does not fix bugs, it is only a workaround to let > people run kernels with bridging compiled-in as if it w

Re: diskless boot of a PXE-compatible machine : finally done !

Luigi Rizzo wrote: > > in your rc.conf or rc.conf.local, you should set > > early_nfs_mounts="YES" Well : (I don't find this knob in a recent -Stable machine - it is indeed in the examples) multi# cd /etc multi# grep early rc* rc:# BOOTP diskless boot. We have to run the rc file early

Re: BRIDGE breaks ARP? (more info)

Patrick Bihan-Faou wrote: > > Hi again, > > Maybe I am misunderstanding things, but since the arp-request we recieve are > for our IP address, do we need to forward them to the other segments ? > > Here is my setup: > > [PC : 192.168.1.254][rl0]---[FreeBSD : 192.168.1.1]---[fxp0][]

Re: BRIDGE breaks ARP? (more info)

Rich Wales wrote: > > Luigi Rizzo wrote: > > > it looks like it essentially reverts to the old (1.75) behaviour, > > . . . when bridging is compiled in (and now, when bridging is > > enabled), arp requests do not consider the interface from which > > the request came from. . . .

Re: Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch))

Rich Wales wrote: > > I wrote: > > > > ARP replies from the bridge to the DSL modem (via the > > > external i/f) are still getting sent to the desktop > > > (via the internal i/f), > > Luigi replied: > > > this is a bit less expected -- because the reply is unicast to > > t

Re: BRIDGE breaks ARP? (more info)

> Instead of trying to fix the old bridging which was written when netgraph was > not publically available (It was as good as could be done at the time, > but it was like trying to fit a square peg into a round hole a hack at > best) the same effort should be put into making netgraph > bridgi

Re: diskless boot ...

> Luigi Rizzo wrote: > > > > in your rc.conf or rc.conf.local, you should set > > > > early_nfs_mounts="YES" > > Well : (I don't find this knob in a recent -Stable machine - it is > indeed in the examples) > multi# cd /etc > multi# grep early rc* > rc:# BOOTP diskless boot. We have to

Re: diskless boot of a PXE-compatible machine : finally done !

Hi, while looking into diskless operation it was noticed that: > early_nfs_mounts was removed with revision 1.209 of rc > >() do you remember why that was done ? It was used for diskless operation --