Re: 5.1r Bridge with one ip - no access from non-ip side - WORKS

From: Ian Smith (smithi_at_nimnet.asn.au)
Date: 01/07/04

  • Next message: jeremie le-hen: "Re: Driver for D-Link DWL-G520+ ??"
    Date: Wed, 7 Jan 2004 23:23:12 +1100 (EST)
    To: Maxim Konovalov <maxim@macomnet.ru>
    
    

    On Tue, 6 Jan 2004, Maxim Konovalov wrote:

    > On Tue, 6 Jan 2004, 06:33+0100, Bjorn Eikeland wrote:
    >
    > > P? Tue, 6 Jan 2004 07:41:26 +0300 (MSK), skrev Maxim Konovalov
    > > <maxim@macomnet.ru>:
    > >
    > > > Try sysctl net.inet.ip.check_interface=0.
    > > >
    > >
    > > Well that did the trick!
    > > Thank you very much!
    >
    > We really have to document that knob somewhere in bridge.4.

    I thought this might affect my problem with a very similar setup that I
    reported in some detail the other day, re the bridge not seeing (or not
    taking notice of, at least) rwho UDP 113 packets to the subnet broadcast
    address on the non-IP interface from hosts 'outside', but on checking,
    that knob was already set to 0 by default (4.8-RELEASE + BRIDGE kernel).

    Setting this to 1 did indeed kill connectivity (ping) on the unnumbered
    interface. I wonder why your system would default to 1 on that knob?

    In chasing this I've tried fiddling with several knobs, most recently
    net.link.ether.inet.proxyall=1 (guesswork!), and have tried creating an
    extra arp entry for the MAC address of the non-IP outside interface (pub
    and pub only) but these always get stored with the MAC of the inside
    interface, ie that with the IP assigned, despite specifying the other.

    I'm not sure if our problem is to do with arp at all, or with processing
    broadcast packets received on the non-IP interface, or what. I can live
    with rwho/ruptime only half-working on this box (ie for 'inside' boxes),
    but I do wonder whether protocols other than rwho using UDP broadcasts
    (such as ..?) might have the same problem? Anyway, the consequence is
    that the bridge box is the only one that won't report on rwho/ruptime
    for the (single) box on the unnumbered (outside) interface.

    Guess I could bring it up to -STABLE if anyone knows of bridge changes?

    Chees, Ian

    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"


  • Next message: jeremie le-hen: "Re: Driver for D-Link DWL-G520+ ??"

    Relevant Pages

    • Re: bridge issues with pf rules on OpenBSD/Sparc
      ... confused as to which physical interface traffic goes in and out on ... for the bridge, I was hoping to have the bridge tell it. ... >> router always appears to match rules for le2 outbound traffic from ... I want to be functional between the LAN and AP. ...
      (comp.unix.bsd.openbsd.misc)
    • Re: Paketfiler als Bridge (was: Stealth Gateway)
      ... >>der Hauptnachteil eines solchen Paketfilters. ... Eine Ethernet Bridge nimmt alle Ethernetpakete auf einem Interface ...
      (de.comp.security.firewall)
    • Re: Multiple pvcs on Cisco 878
      ... full bridge. ... interface BRI0 ... ip route 0.0.0.0 0.0.0.0 Dialer0 ... The gateway of last resort disappears, and the routing table is shut ...
      (comp.dcom.sys.cisco)
    • Re: BC30518: Overload resolution failed because no accessible ToString can be called with these argu
      ... assign the cached report to the AccessKey property instead of the ... > 'Public Shared Function ToString(value As String) As String': ... the implemented interface 'CrystalDecisions.ReportSource.ICachedReport'. ... > 'Public Shared Function ToStringAs String': ...
      (microsoft.public.vb.crystal)
    • Re: If_bridge behaving as HUB
      ... I have a bridge setup with a number of vlan IF's as members. ... After a while traffic destined for one member IF are sent to all member IF's. ... A bridge works like a hub, forwarding traffic from one interface to ... Multicast and broadcast packets are always forwarded to all ...
      (freebsd-net)