Re: Having problems with limited broadcast

[Bruce Walker]

Peter Steele wrote:

When our boxes are initially deployed, they have no IP addresses
assigned to them. Their ifconfig entry looks like this:

ifconfig_lagg0="laggproto failover laggport nfe0 laggport nfe1"

With this config, no IP is assigned to the lagg0 device, so the only way
to access the boxes is via a serial console.


Peter, leaving aside the issue of FreeBSD limited broadcast, have you 
considered ZeroConf, and in particular the IPv4 Link-Level Addressing 
portion of it to meet your basic "get the boxes addressed" requirement?


http://www.zeroconf.org/
http://files.zeroconf.org/rfc3927.txt

I don't have any experience with the lagg device yet, so I don't know if 
that presents specific issues wrt ipv4ll code.


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

Re: Having problems with limited broadcast

[Bruce Walker]

Bruce M. Simpson wrote:


The folk who point out that link-local addresses could be used, have 
an interesting suggestion which might work for you.


Peter, I understand your issue with the (apparent) restriction of the 
169.254/16 range, though I'd point out that the IPv4-LL addressing 
scheme is considered a fall-back plan by most systems implementors.  
Your systems could look  for DHCP first then failing that, drop back to 
IPv4-LL and get an address.  The picky customers would simply be 
required to supply a DHCP server.  Everyone else presumably doesn't care 
as long as the boxes can communicate.



But there's another useful point to pickup from the ZeroConf stuff.  I 
implemented a small standalone IPv4-LLA daemon using libevent, libnet 
and libpcap.  IPv4-LLA needs to muck around with a completely 
unaddressed interface (like you are doing with your DHCP-lite), sending 
and listening-for broadcast and directed ARP packets, per RFC 3927.  It 
was trivial to do this in a completely portable way using libpcap and 
libnet.  I'd highly recommend to you that you link those libraries into 
your Python DHCP-lite app and you will be able to deploy relatively 
painlessly on any platform that those libraries are ported to.


http://sourceforge.net/projects/pylibpcap/
http://pylibnet.sourceforge.net/

Cheers!

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

Re: Having problems with limited broadcast

[Bruce Walker]

Bruce Walker wrote:
It was trivial to do this in a completely portable way using libpcap 
and libnet.


Sorry, typo: I actually meant to say libdnet -- a different but similar 
package.  Also with Python bindings.


http://libdnet.sourceforge.net/

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

Re: SLIP slipping away

[Bruce Walker]

Sin wrote:


I wasn't going to ask before, but I guess curiosity got the best of 
me. I've been working for an ISP for the past 8 years, so PPP and SLIP 
talk comes up alot. I don't usually post, just read, however I am 
curious about what kind of application could possibly be using slip as 
opposed to ppp now-a-days ??


One legitimate use-case is talking to single-chip embedded CPUs, eg an 
Atmel AVR or Mega, or a PIC controller.  Very limited code space means 
that the networking implementation may be limited to just UDP/IP, and 
PPP is way too big, but SLIP is trivially doable.


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

Re: if_bridge FreeBSD 6.0 on a Broadcom interface not working

[Bruce Walker]

David Leimbach wrote:


x86 machine with FreeBSD 6 and using
if_bridge to connect the tap0 interface with xl0 with great success.

I tried to duplicate this configuration on a dual opteron machine that has
Broadcom adapters and when I add the bge0 or bge1 interfaces to the bridge0
iface that I create I lose all connectivity.  The moment I destroy the
bridge0 interface, bge0 or bge1 as it may be begins responding again.

 



Hmmm.  I'm getting this *exact* behaviour but with two Intel Ether 
Express Pro/1000 interfaces.  Previously, I was fiddling with if_bridge 
bridging in a box (HP VLi8) with the built-in 3Com i/f (xl0) and an 
add-in PRO/1000 card (em0).  That worked great.  So I have now 
duplicated that config in a Supermicro board (X6DHP-8G2; single 3.2 GHz 
Xeon) with three PRO/1000 interfaces, using em0 and em1.


As soon as I boot up with em0 and em1 added to the bridge0 interface, I 
lose IP connectivity.  Interestingly, I can ping hosts by IP address.  
But all attempts to do anything else, eg NTP, DNS or ssh are futile.


So it would seem to me that bridging with two identical (ie hardware) 
interfaces breaks if_bridge.


David: have you learned anything new?

If anyone wants me to run some tests, please let me know.

Cheers!

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

Re: if_bridge FreeBSD 6.0 on a Broadcom interface not working

[Bruce Walker]

Bruce Walker wrote:

[if_bridge trouble with] two Intel Ether Express Pro/1000 interfaces.  
Previously, I was fiddling with if_bridge bridging in a box (HP VLi8) 
with the built-in 3Com i/f (xl0) and an add-in PRO/1000 card (em0).  
That worked great.  So I have now duplicated that config in a 
Supermicro board (X6DHP-8G2; single 3.2 GHz Xeon) with three PRO/1000 
interfaces, using em0 and em1.


As soon as I boot up with em0 and em1 added to the bridge0 interface, 
I lose IP connectivity.  Interestingly, I can ping hosts by IP 
address.  But all attempts to do anything else, eg NTP, DNS or ssh are 
futile.



I have some more specific info now, and a workaround! :-)

This box actually has three working PRO/1000 interfaces.  So I tried 
avoiding adding em0 (my inet "ssh interface") to the bridge, and voila! 
... it works.  If I create a bridge from em1 and em2 only, then 
everything is jim-dandy.


Looks like:

ne# ifconfig -a
em0: flags=8943 mtu 1500
   options=b
   inet6 fe80::230:48ff:fe2e:998c%em0 prefixlen 64 scopeid 0x1
   inet 10.1.11.205 netmask 0x broadcast 10.1.255.255
   ether 00:30:48:2e:99:8c
   media: Ethernet autoselect (1000baseTX )
   status: active
em1: flags=8943 mtu 1500
   options=b
   inet6 fe80::230:48ff:fe2e:998d%em1 prefixlen 64 scopeid 0x2
   ether 00:30:48:2e:99:8d
   media: Ethernet autoselect (100baseTX )
   status: active
em2: flags=8943 mtu 1500
   options=b
   inet6 fe80::230:48ff:fe42:d992%em2 prefixlen 64 scopeid 0x3
   ether 00:30:48:42:d9:92
   media: Ethernet autoselect (1000baseTX )
   status: active
lo0: flags=8049 mtu 16384
   inet6 ::1 prefixlen 128
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
   inet 127.0.0.1 netmask 0xff00
bridge0: flags=8041 mtu 1500
   ether ac:de:48:47:be:24
   priority 32768 hellotime 2 fwddelay 15 maxage 20
   member: em2 flags=3
   member: em1 flags=3
ne#

The reason that em0 is in promiscuous mode here is because I'm running 
tcpdump on it to see if the act of putting it in promiscuous mode nukes 
it.  It does not harm it at all, so that aspect of bridging it is not at 
fault.


So my workaround is to connect em0 and em1 in parallel to the same 
switch, and use em2 to bridge over to my test net.  As long as I don't 
add my inet IP-numbered interface (em0) to the bridge, I'm good to go.  
Pretty strange.


Cheers!

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

Re: if_bridge FreeBSD 6.0 on a Broadcom interface not working

[Bruce Walker]

Andrew Thompson wrote:

On Wed, Jan 11, 2006 at 12:19:05PM -0500, Bruce Walker wrote:
  
As soon as I boot up with em0 and em1 added to the bridge0 interface, I 
lose IP connectivity.  Interestingly, I can ping hosts by IP address.  
But all attempts to do anything else, eg NTP, DNS or ssh are futile.

 
if_bridge doesnt handle interfaces with TXCSUM at the moment, you can

work around this by clearing this with 'ifconfig xxx -txcsum', where xxx
is your em or bge card.

Im testing a patch to fix this.
  



W00t!  :-)  That's it; perfect. No checksum errors, and bridging works 
great.


I'll watch for your patch and test it asap.

Thanks, Andrew!

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

Re: Zeroconfig and Multicast DNS

[Bruce Walker]

Fredrik Lindberg wrote:

mDNSResponder-108 appears to still be under APSL 2, I don't
know if that license is acceptable for base utilities, if it is, it
might be a viable alternative.


It should be under the Apache 2.0 license now.

Here's the announcement from the bonjour-dev list ...


 Original Message 
Subject:Fwd: Apple Opens Up: Bonjour now under Apache license
Date:   Mon, 7 Aug 2006 16:43:16 -0700
From:   Ernest Prabhakar <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>



Hi all,

As most of you know, Apple believes in the power of Open Source as a  
great way to enable adoption of standards-based technologies.  To  
make Bonjour even more attractive to various solution providers, we  
are pleased to announce that those portions of Bonjour previously  
under the Apple Public Source License** are now available under the  
widely-used Apache License, Version 2.0*.  The relicensed sources are  
currently available in the Bonjour CVS; additional information is  
available in the new Mac OS Forge community hosting site:




We hope this inspires you to use Bonjour as part of even more  
innovative products.


Sincerely,
Ernest Prabhakar
Open Source Product Manager, Apple

Begin forwarded message:
Subject: Apple Opens Up: Kernel, Mac OS Forge, iCal Server,  
Bonjour, Launchd


Hi all,

In conjunction with this week's Developer Conference, we have four  
great pieces of news for Open Source developers:


A. Intel Kernel Sources

As of today, we are posting buildable kernel sources for Intel- 
based Macs alongside the usual PowerPC (and other Intel) sources,  
starting with Mac OS X 10.4.7. We regret the delay in readying the  
new kernel for release, and thank you for your patience.


http://www.opensource.apple.com/darwinsource/tarballs/apsl/ 
xnu-792.10.96.tar.gz


B. New "Mac OS Forge" for Community Projects

Mac OS Forge, a new community site hosted by Apple, is being  
created to support WebKit and other open source projects focused on  
Mac OS X, especially those looking to transition from OpenDarwin.org.




C. New Open Source Calendaring Server

In order to encourage community participation, source code to the  
new iCal Server in Leopard Server is now available on Mac OS Forge  
under the Apache License.*




D. Apache-Licensed Bonjour and Launchd sources

To further enable and encourage cross-platform adoption, the APSL**  
sources for Bonjour service discovery and Launchd process  
management are being re-released under the Apache License and  
hosted on Mac OS Forge:





Apple is more excited than ever about the power of Open Source  
development to create value for our (and your) products and  
customers. I'll be offline much of this week due to WWDC, but I  
look forward to working with all of you as we move forward to Leopard.


Sincerely,
Ernest Prabhakar
Open Source Product Manager, Apple
WWDC 2006, Aug 7-11, San Francisco


* Apache License, Version 2.0


** Apple Public Source License 2.0




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

[Fwd: New Bonjour Internet Drafts posted]

[Bruce Walker]

Re the ZeroConf/Bonjour/IPv4LL chat: this just in ...


 Original Message 
Subject:New Bonjour Internet Drafts posted
Date:   Thu, 24 Aug 2006 17:20:23 -0700
From:   Marc Krochmal <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]



Hello,

Today we submitted the latest versions of the Bonjour draft specs to  
the IETF.  They're also available from here...









The majority of the changes were in the mDNS and DNS-SD drafts.


The following new sections were added to the mDNS draft.

6.7 Direct Unicast Queries to port 5353
16. Considerations for Multiple Responders on the Same Machine
16.1 Receiving Unicast Responses
16.2 Multi-Packet Known-Answer lists
16.3 Efficiency
16.4 Recommendation
28. Deployment History

Most of the technical changes were related to probing and probe tie- 
breaking but these changes shouldn't affect backward compatibility  
with any existing products.



The following new sections were added to the DNS-SD draft.

16. User Interface Considerations
16.1 Service Advertising User-Interface Considerations
16.2 Client Browsing User-Interface Considerations
21. Deployment History

The mDNS and DNS-SD drafts are very mature now and are close to being  
ready to publish, most likely as Informational RFCs.


If you haven't read them in a while, now would be a good time to skim  
them over and provide any remaining feedback.


Thanks.
-Marc

___
Do not post admin requests to the list. They will be ignored.
Bonjour-dev mailing list  ([EMAIL PROTECTED])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/bonjour-dev/bmw%40borderware.com

This email sent to [EMAIL PROTECTED]

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