Bruce M. Simpson wrote:
Peter Steele wrote:
...
I personally like this idea, but I'm not sure I can sell it to the
others. Are there any restrictions to these 169.254.x.y addresses?
169.254.0.0/16 must never appear outside a link -- it is strictly scoped
to that link.
Currently the IPv4
Bruce M. Simpson wrote:
Peter Steele wrote:
...
I personally like this idea, but I'm not sure I can sell it to the
others. Are there any restrictions to these 169.254.x.y addresses?
169.254.0.0/16 must never appear outside a link -- it is strictly
scoped to that link.
P.S. I checked in a
Peter Steele wrote:
...
I personally like this idea, but I'm not sure I can sell it to the
others. Are there any restrictions to these 169.254.x.y addresses?
169.254.0.0/16 must never appear outside a link -- it is strictly scoped
to that link.
Currently the IPv4 BSD stack has no concept
> BTW: If you guys are already looking at scapy, you may also wish to
give
> pcs.sourceforge.net a look as an alternative.
I didn't come across that in my research. I'll have to check it out.
Thanks.
Peter
___
freebsd-net@freebsd.org mailing list
http
>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
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
Peter Steele wrote:
The folk who point out that link-local addresses could be used, have
an
interesting suggestion which might work for you.
It's definitely interesting, but it is very likely that some of our
customers will want to be able to set their own IP ranges and not be
li
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
> The folk who point out that link-local addresses could be used, have
an
> interesting suggestion which might work for you.
It's definitely interesting, but it is very likely that some of our
customers will want to be able to set their own IP ranges and not be
limited to 169.254/16. So we need a
Peter Steele wrote:
...
It's really a matter of time. We didn't anticipate limited broadcast
being broken in FreeBSD and we're scrambling to come up with a solution.
To be quite frank I haven't done anything with IPv6 before so it would
be more research to get up to speed on this option. It seems
>If this is all going over an L2 LAN, why not do the initial discovery
>and general configuration exchange over IPv6? :P Link layer
>network-scope addresses to the rescue.
>
>(think: just like apple wireless base stations and MacOSX hosts doing
>configuration do..)
It's really a matter of time. We
If this is all going over an L2 LAN, why not do the initial discovery
and general configuration exchange over IPv6? :P Link layer
network-scope addresses to the rescue.
(think: just like apple wireless base stations and MacOSX hosts doing
configuration do..)
Adrian
2009/1/8 Peter Steele :
>> T
> Thanks for the suggestion though. I'm not familiar with ZeroConf; I'll
> check it out.
ZeroConf is an interesting concept. Unfortunately it restricts IPs to
the 169.254/16 range and it is very likely some of our customers will
want to be able to configure our boxes to an IP range of their own
ch
>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
> You will need to go to the pcap layer to send limited broadcasts w/o
any
> IPv4 addresses configured in a BSD stack for now. If you have an IP on
> the interface, you can just use IP_ONESBCAST.
Yes, I can send broadcasts if my box has an IP. Since we are writing our
own DHCP-like service thoug
Peter Steele wrote:
..
Based on the discussion in the link above, it doesn't seem like the
problem was entirely resolved by the patches mentioned in this thread.
Has anything been done since this discussion took place. Surely there
must be a way to get limited broadcast to work under FreeBSD.
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 box
>We ARE talking about "just a LAN" here, right? Also, these computers
>are "not on the internet?" They have absolutely no connectivity?
>(Unlikely).
When our boxes are initially deployed, they have no IP addresses
assigned to them. Their ifconfig entry looks like this:
ifconfig_lagg0="laggproto
On Tue, Jan 6, 2009 at 8:45 AM, Peter Steele wrote:
> We have a Python app that implements a DHCP-like protocol using limited
> broadcast using address 255.255.255.255. Our code works fine on Linux
> and FreeBSD but we cannot seem to get broadcast to work on FreeBSD.
> We've tried both Python and
We have a Python app that implements a DHCP-like protocol using limited
broadcast using address 255.255.255.255. Our code works fine on Linux
and FreeBSD but we cannot seem to get broadcast to work on FreeBSD.
We've tried both Python and C under FreeBSD 7.0.
I've found a lengthy discussion of t
We have a Python app that implements a DHCP-like protocol using limited
broadcast using address 255.255.255.255. Our code works fine on Linux
and FreeBSD but we cannot seem to get broadcast to work on FreeBSD.
We've tried both Python and C under FreeBSD 7.0.
I've found a lengthy discussion of t
21 matches
Mail list logo
