Hi,
Two oddities with wlan0:
From dmesg:
ath0: Atheros 9285 mem 0xfeaf-0xfeaf irq 18 at device 0.0 on pci3
[ath] AR9285 Main LNA config: LNA2
[ath] AR9285 Alt LNA config: LNA1
[ath] LNA diversity enabled, Diversity enabled
[ath] Enabling diversity for Kite
ath0: [HT] enabling HT modes
On 01/31/13 00:45, Eggert, Lars wrote:
Hi,
I have a small system running FreeBSD 8.2 that does NAT using ipfw and
natd to systems attached to two interfaces: em0 and wlan0. I have a
dhcpd daemon issuing leases on those interfaces. The system has an em1
interface plugged into a cable
Hi
I have a small system running FreeBSD 8.2 that does NAT using ipfw and
natd to systems attached to two interfaces: em0 and wlan0. I have a
dhcpd daemon issuing leases on those interfaces. The system has an em1
interface plugged into a cable modem where it obtains a DHCP lease from
an
Hi
I'd like to create a freebsd AP using my mini-itx board. I have a
mini-pcie expansion slot and am considering this wifi card
http://www.habeyusa.com/products_show.php?id=361
I currently run 8.2R but plan to upgrade to 9.0R.
The main concern I have is that it lists its host interface as
Hi Adrian,
The docs say Atheros AR9285(MAC/Baseband/RF) with AR3011 -- I tend to think
the AR3011 is an error in their docs as the card is not advertised as
supporting bluetooth, and because an AR9285 is apparently exposed over PCIe,
I tend to think the card will work fine as an hostap, but
I found measurement results on this website:
http://hide.dnsalias.net//worldipv6day.cgi
Some more results:
http://www.wand.net.nz/~mluckie/ipv6day/
and (semi-related) a PR with a patch for PMTUD problems that was filed
15 months ago
http://www.freebsd.org/cgi/query-pr.cgi?pr=145733
I found measurement results on this website:
http://hide.dnsalias.net//worldipv6day.cgi
Some more results:
http://www.wand.net.nz/~mluckie/ipv6day/
Interesting. Did you post on the v6 lists as well?
Just on ipv6-tech...@listserv.internetnz.net.nz
Feel free to forward on to other lists
Does anybody have an idea of whether the patch in kern/145733 will be
incorporated into ip_fw2.c any time soon?
That PR is mine. I've emailed people off list several times (last on
25 Jan) but have not made progress. To say I'm frustrated is an
understatement.
Is there any particular reason why reassembled packets were not
checked? If the answer is no, I'll send in a PR.
I think it was just a random decision -- either pass packets to
the firewall before reassembly as we do, or after reassembly, as
linux does. Both have pros and cons.
Going through
I think that a patch like the one you propose is very useful (for
ipv4 as well) but it requires a sysctl or other mechanism to make
sure that when it is enabled we don't pass fragments through the
firewall.
i've looked further into this and I now wonder if is a byproduct of my
use of
Hi
Reassembled packets are not passed to the packet filter interface for
both IPv4 and IPv6, so a firewall has no effect if the packets arrive
in fragments. Here is a patch to fix this for IPv6. The patch for
IPv4 is similarly trivial, but I have not written / tested it yet.
Is there any
When rtadvd is compiled on 7.0, the following warning is emitted:
/usr/src/usr.sbin/rtadvd/rrenum.c:179: warning: overflow in implicit
constant conversion
I have not determined if the code works correct or not, but I wonder
if it does. the line in question is this:
struct irr_raflagmask {
The existing intel BPF JIT compiler has one flaw. sys/net/bpf_filter.c
initialises the A and X registers to zero when called. The just in time
compiler does not. This means the JIT compiler will behave differently
to the interpreter on any filter that does not set the A or X registers
BIOCSETF and BIOCSETWF call reset_d which discards any packets
currently in the hold buffer and resets the packet rx count.
The patch below adds BIOCSETFNR, an ioctl that swaps the BPF filter
without resetting the hold buffer and without resetting the packet rx
counts, which is handy when the
BPF includes a divide instruction.
As best I can tell, libpcap does not ever output a BPF divide
instruction, which indicates that use of the BPF divide instruction is
probably going to be done with a BPF program created by hand.
Can anyone provide any examples of a BPF program where a
At the moment, freebsd checks a UDP checksum in place, overwriting
whatever is there. This has a side effect of the ICMP code sending back
the first eight bytes of the UDP payload with 2 bytes different to
what that system sent.
For example:
listening on lo0, link-type NULL (BSD loopback),
I'm not very familiar with the route code, but here is what i came up with.
[EMAIL PROTECTED] mjl]$ sudo route change 10.3.2.1 127.0.0.1
route: writing to routing socket: No such process
change host 10.3.2.1: gateway 127.0.0.1: not in table
the code checks that if changing a host or network
I'd suggest a name like DLT_PSEUDO might be better -- it may be helpful to
get review for the change from the NetBSD and OpenBSD guys too, as well as
the tcpdump.org guys.
I posted a patch to netbsd tech-kern and have had positive feedback:
is there a good reason why _all_ DLT_NULL bpf devices could not simply
have writes supported? the user space application would pass the
address family in the first 4 bytes of the packet; this is currently
done anyway for if_disc, if_loop, if_tun, if_faith, and ng_iface.
ip_carp could get bpf
I'd be wary of changing the definition of DLT_NULL however -- it literally
means 'there's nothing here apart from raw data', and changing this notion
would mean that we have to change it everywhere, including bpf clients,
because the change being proposed would make DLT_NULL mean 'there's a
this was the behaviour expected of most DLT_NULL bpf devices already
(passing a 32bit int when writing). It is important to note that the
behaviour of BPF writers does not change in these cases, and my patch
is merely a bug fix.
Agreed. When you use BPF or PCAP to capture packets, for
I can successfully write BPF packets up to 1500 bytes in size (1496 IP
bytes without the address family integer). Writes larger than this
return EMSGSIZE.
http://lists.freebsd.org/pipermail/freebsd-net/2005-May/007371.html
Just for the record, the patch below fixes this on 4.11; the same
If I was to pursue this, would someone on this list consider committing the
work to current?
...
+ case DLT_NULL:
+ sockp-sa_family = AF_UNSPEC;
+ if(strcmp(ifp-if_name, tun) == 0)
+ hlen = sizeof(int);
+ else
+
Hi
I would like to use the BPF device to write packets on a tun device,
which is bpf type DLT_NULL. I'm aware that the man page (for 4.X and
5.X) says that BPF writes are only supported on Ethernet and SLIP links.
I did notice, though, that the tunoutput function in sys/net/if_tun.c
has
This is probably a pointless optimization, as you probably relatively
rarely have multiple BPF devices bound to the same interface receiving
the bulk of the packets (as opposed to some daemon with a filter that
passes only the packets it's interested in), but would there be any
advantage to
I am under the impression that implementing this mechanism would
not be so trivial.
hmm, we looked at how other protocols handled the ENOBUFS case from
ip_output.
tcp_output calls tcp_quench on this error.
while the interface may not be able to send any more packets than it does
currently,
again?
Ideally, I would block until such time as i could send it via ip_output
(please CC: me on any responses)
Matthew Luckie
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
Is there a mechanism to tell when ip_output should be called again?
Ideally, I would block until such time as i could send it via ip_output
You probably get that because the outbound interface queue gets full, so
you want to block your caller until space becomes available there. There
28 matches
Mail list logo
