RE: kernel: arpresolve: can't allocate llinfo for 65.59.233.102
I have the same issue (default gateway unexpectedly changes on some random address) on FreeBSD 9.0 Box with lot of traffic going through it, I have a wild guess that it is related to libalias compilled into kernel (troubles start showing itself when I started to use ipfw nat functionality ). ___ 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: kern/171532: [ndis] ndis(4) driver includes 'pccard'-specific code, even if 'device pccard' absent from config
Old Synopsis: ndis(4) driver includes 'pccard'-specific code, even if 'device pccard' absent from config New Synopsis: [ndis] ndis(4) driver includes 'pccard'-specific code, even if 'device pccard' absent from config Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Sep 13 13:10:02 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=171532 ___ 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: kern/171524: [ipmi] ipmi driver crashes kernel by reboot or shutdown
On Tuesday, September 11, 2012 4:00:21 pm Sean Bruno wrote: > The following reply was made to PR kern/171524; it has been noted by GNATS. > > From: Sean Bruno > To: bug-follo...@freebsd.org, dhoj...@brainbits.net > Cc: > Subject: Re: kern/171524: [ipmi] ipmi driver crashes kernel by reboot or > shutdown > Date: Tue, 11 Sep 2012 12:56:16 -0700 > > It looks like the fix is not in releng_91 for release. > http://svnweb.freebsd.org/base/stable/9/sys/dev/ipmi/ipmi.c?revision=239920&view=markup > > You can either patch the system by hand by applying this change to your > local tree or update to stable/9 to fix this. > > http://www.wonkity.com/~wblock/docs/html/stable.html This has nothing to do with freebsd-net@ either, but it should probably be closed since it is fixed in HEAD. -- John Baldwin ___ 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: Why wpa_supplicant doesn't start with ndis0 interface?
On 09/12/2012 20:01, Glen Barber wrote: It would be helpful if you would at least try my cron(8) suggestion. So I tried adding the lines into crontab: @reboot root/sbin/kldload /boot/kernel/if_ndis.ko >/dev/null 2>&1 @reboot root/sbin/kldload /boot/modules/bcmwl5_sys.ko >/dev/null 2>&1 Firstly, for some reason, this method fails to load bcmwl5_sys.ko with the error message: KLD bcmwl5_sys.ko: depends on ndis - not available or version mismatch However, command 'kldload /boot/modules/bcmwl5_sys.ko' typed manually after boot succeeds without any messages. This is a mystery to me, why one way to run it produces this message and another one doesn't. And '/etc/rc.d/netif start' still doesn't start wifi even though all kernel modules were loaded after kernel boot. Yuri ___ 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: moving pfil consumers to sys/netpfil
On Wed, 12 Sep 2012, Luigi Rizzo wrote: On Wed, Sep 12, 2012 at 04:34:57PM +0400, Gleb Smirnoff wrote: Hi, we (me and Bjoern) would like to establish a single place for all kinds of pfil(9) consumers, for current ones and for future as well. The place chosen is sys/netpfil. On first round we'd like to move there our Tier-1 firewalls: ipfw and pf. This also includes moving pf out of contrib. The plan of movement is the following: sys/contrib/pf/net/*.c -> sys/netpfil/pf/ sys/contrib/pf/net/*.h -> sys/net/ [1] contrib/pf/pfctl/*.c-> sbin/pfctl contrib/pf/pfctl/*.h-> sbin/pfctl contrib/pf/pfctl/pfctl.8-> sbin/pfctl contrib/pf/pfctl/*.4-> share/man/man4 contrib/pf/pfctl/*.5-> share/man/man5 sys/netinet/ipfw-> sys/netpfil/ipfw I have two concerns against moving ipfw/ - what do we gain by moving ipfw/ further away from its user header files (whose location in netinet/ is pretty much part of the API so difficult to change) ? What do we gain by having 3 firewalls ... in three different places ... in the tree? The result is that ipfw unconditionally depends on a pf header file .. oops .. that actually is an ALTQ thing *bummer*. - pfil is just one of the APIs that the ipfw code uses to send/receive packets (pfil, netmap for FreeBSD, and then netfilter and ndispacket for the other OS). The other two really don't count for us. The pfil dependencies amount to probably 1% of the code. So if we really want to relocate ipfw/ i'd rather move to a more generic place (but as far as i know we do not have one for subsystems -- dev/ is used for drivers, other stuff has generally accumulated under sys/ ,see geom, ofed, netgraph). You may remember we talked about this in the FreeBSD 8.0-CURRENT(?) times when ipfw moved the last time. So suggestions as saying no and not coming up with anything better is not helpful otherwise I'll tell to glebius "sorry for holding you up for 3 days" go head with his initial proposal to also put pf into netinet/pf if you'd prefer that? /bz -- Bjoern A. Zeeb You have to have visions! Sometimes you wonder why people are so reluctant to cleaning things up and finding a good soultion for the next decade. It's no fun probably? ___ 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: Why wpa_supplicant doesn't start with ndis0 interface?
On Thu, Sep 13, 2012 at 08:34:40AM -0700, Yuri wrote: > On 09/12/2012 20:01, Glen Barber wrote: > > It would be helpful if you would at least try my cron(8) suggestion. > > So I tried adding the lines into crontab: > @reboot root/sbin/kldload /boot/kernel/if_ndis.ko >/dev/null 2>&1 > @reboot root/sbin/kldload /boot/modules/bcmwl5_sys.ko >/dev/null 2>&1 > > Firstly, for some reason, this method fails to load bcmwl5_sys.ko with > the error message: > KLD bcmwl5_sys.ko: depends on ndis - not available or version mismatch > Hmm. This should also be loading ndis.ko. If not, add that to the cron line as well. If that is the problem, sorry, that was my mistake. Also, are your kernel and userland in sync? And is this module built on the kernel you are currently running? Glen > However, command 'kldload /boot/modules/bcmwl5_sys.ko' typed manually > after boot succeeds without any messages. This is a mystery to me, why > one way to run it produces this message and another one doesn't. > > And '/etc/rc.d/netif start' still doesn't start wifi even though all > kernel modules were loaded after kernel boot. > pgp56pQiPtCDn.pgp Description: PGP signature
Re: kernel: arpresolve: can't allocate llinfo for 65.59.233.102
On 13 September 2012 03:04, Вадим Уразаев wrote: > I have the same issue (default gateway unexpectedly changes on some random > address) on FreeBSD 9.0 Box with lot of traffic going through it, I have a > wild guess that it is related to libalias compilled into kernel (troubles > start showing itself when I started to use ipfw nat functionality ). OOO. Wait. Is ipfw nat the common thread with all the people demonstrating this issue? Adrian ___ 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: kernel: arpresolve: can't allocate llinfo for 65.59.233.102
W dniu 2012-09-13 19:04, Adrian Chadd pisze: On 13 September 2012 03:04, Вадим Уразаев wrote: I have the same issue (default gateway unexpectedly changes on some random address) on FreeBSD 9.0 Box with lot of traffic going through it, I have a wild guess that it is related to libalias compilled into kernel (troubles start showing itself when I started to use ipfw nat functionality ). OOO. Wait. Is ipfw nat the common thread with all the people demonstrating this issue? Adrian Hi! I don't use ipfw nat, but I do use ipfw+dummynet and PF for nat/filtering - together. Krzysiek ___ 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: moving pfil consumers to sys/netpfil
On Thu, Sep 13, 2012 at 04:36:10PM +, Bjoern A. Zeeb wrote: > On Wed, 12 Sep 2012, Luigi Rizzo wrote: > > >On Wed, Sep 12, 2012 at 04:34:57PM +0400, Gleb Smirnoff wrote: > >> Hi, > >> > >> we (me and Bjoern) would like to establish a single place > >>for all kinds of pfil(9) consumers, for current ones and > >>for future as well. > >> > >> The place chosen is sys/netpfil. > >> > >> On first round we'd like to move there our Tier-1 firewalls: > >>ipfw and pf. This also includes moving pf out of contrib. > >> > >> The plan of movement is the following: > >> > >>sys/contrib/pf/net/*.c -> sys/netpfil/pf/ > >>sys/contrib/pf/net/*.h -> sys/net/ [1] > >>contrib/pf/pfctl/*.c-> sbin/pfctl > >>contrib/pf/pfctl/*.h-> sbin/pfctl > >>contrib/pf/pfctl/pfctl.8-> sbin/pfctl > >>contrib/pf/pfctl/*.4-> share/man/man4 > >>contrib/pf/pfctl/*.5-> share/man/man5 > >> > >>sys/netinet/ipfw-> sys/netpfil/ipfw > > > >I have two concerns against moving ipfw/ > > > >- what do we gain by moving ipfw/ further > > away from its user header files (whose location in netinet/ > > is pretty much part of the API so difficult to change) ? > > What do we gain by having 3 firewalls ... in three different places > ... in the tree? The point of my question was that if you do some work you expect some return, in the short or in the long term, otherwise you are wasting time. If you leave things as they are at least you break even. (i don't know what is the third firewall you mention, but it is irrelevent). Specifically, for ipfw i think the move is a mistake for the reason i am explaining below. > The result is that ipfw unconditionally depends on a pf header file > .. oops .. that actually is an ALTQ thing *bummer*. > > > >- pfil is just one of the APIs that the ipfw code > > uses to send/receive packets (pfil, netmap for FreeBSD, > > and then netfilter and ndispacket for the other OS). > > The other two really don't count for us. > > > > The pfil dependencies amount to probably 1% of the code. > >So if we really want to relocate ipfw/ i'd rather move to > > a more generic place (but as far as i know we do not have > > one for subsystems -- dev/ is used for drivers, other stuff > > has generally accumulated under sys/ ,see geom, ofed, netgraph). > > You may remember we talked about this in the FreeBSD 8.0-CURRENT(?) > times when ipfw moved the last time. > > So suggestions as saying no and not coming up with anything better > is not helpful otherwise I'll tell to glebius "sorry for holding you > up for 3 days" go head with his initial proposal to also put pf into > netinet/pf if you'd prefer that? First of all: the relocation of pf/ is unrelated to the relocation of other subsystems. If Gleb or you or both feel that pf goes under netpfil/pf/ i am perfectly fine with it and i never said anything that blocks this move. Second: What i contest is the fact that you classify ipfw as a "pfil client", when pfil is just a tiny adaptation layer to access ipfw. I mentioned the three alternative APIs (netmap, netfilter, ndis) to witness the fact that pfil is irrelevant to ipfw's operation. Third: any code relocation comes with some pain -- specifically, netinet/ is hardwired in many #include paths in the ipfw sources > grep netinet/ipfw sys/netinet/ipfw/* | grep include | wc 35 701791 so having it relocated (and in different places between HEAD and STABLE/9, and other platforms that may not count for you but do count for the maintainer, aka me) causes some extra maintainance work which I am willing to take if there are good reasons, but i do not see now. So for pf do whatever you see fit, i never objected. For ipfw, i think that netinet/ is more appropriate than netpfil/ (i'd be ok with something like net-subsystems/ but we do not have one such a thing and i do not have the time and energy to discuss and create one). > /bz > > -- > Bjoern A. Zeeb You have to have visions! > Sometimes you wonder why people are so reluctant to cleaning things up > and finding a good soultion for the next decade. It's no fun probably? Is this coming from a new targeted .sig service ? :) Cleaning up/refactoring is actually quite fun and gives you the feeling that you get things done even though it is mostly mechanical work. It is the "finding a good solution" part that is much harder. cheers luigi ___ 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: kernel: arpresolve: can't allocate llinfo for 65.59.233.102
Hi, Altough I'm using ipfw for traffic shaping, I'm not using it for NAT. I'm using PF for NAT. -- -Message d'origine- De : owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] De la part de Adrian Chadd Envoyé : 13 septembre 2012 13:04 À : Вадим Уразаев Cc : freebsd-net@freebsd.org Objet : Re: kernel: arpresolve: can't allocate llinfo for 65.59.233.102 On 13 September 2012 03:04, Вадим Уразаев wrote: > I have the same issue (default gateway unexpectedly changes on some > random > address) on FreeBSD 9.0 Box with lot of traffic going through it, I > have a wild guess that it is related to libalias compilled into > kernel (troubles start showing itself when I started to use ipfw nat > functionality ). OOO. Wait. Is ipfw nat the common thread with all the people demonstrating this issue? Adrian ___ 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" ___ 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: kernel: arpresolve: can't allocate llinfo for 65.59.233.102
Then my guess is wrong. I found the message, where similiar problem was described in ipfw mailling list http://lists.freebsd.org/pipermail/freebsd-ipfw/2011-March/004582.html, with no answer. Maybe it will be usefull for somebody. ___ 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: moving pfil consumers to sys/netpfil
On Thu, Sep 13, 2012 at 07:41:05PM +0200, Luigi Rizzo wrote: L> Second: L>What i contest is the fact that you classify ipfw as a "pfil client", L>when pfil is just a tiny adaptation layer to access ipfw. L>I mentioned the three alternative APIs (netmap, netfilter, ndis) L>to witness the fact that pfil is irrelevant to ipfw's operation. In FreeBSD ipfw is a pfil client. Dot. In Linux it is netfilter client, and if they want to they may or may not put it under netfilter/ipfw. We don't care. Same for Windows and ndis. ipfw isn't netinet specific, it also supports netinet6 and also supports layer2 pfil hooks. Putting all pfil clients into one place puts things in order. It simplifies kernel overview for newcomer, it makes things easier for those who want to hack on the pfil itself. L> Third: L>any code relocation comes with some pain -- specifically, netinet/ L>is hardwired in many #include paths in the ipfw sources L> L> > grep netinet/ipfw sys/netinet/ipfw/* | grep include | wc L>35 701791 Numbers from your grep are impressive, but they are absolutely irrelevant. Actual diff for movement isn't that big. For example: - sys/net has zero diff, no files modified - sys/netinet/* has zero diff, just ipfw directory removed, no files modified - sbin/ipfw has zero diff This is actual diff that is already universe-tested. L>so having it relocated (and in different places between HEAD and L>STABLE/9, and other platforms that may not count for you but do L>count for the maintainer, aka me) causes some extra maintainance L>work which I am willing to take if there are good reasons, L>but i do not see now. -- Totus tuus, Glebius. ___ 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: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)
On 09/12/2012 10:51 PM, Freddie Cash wrote: On Wed, Sep 12, 2012 at 1:48 PM, Jack Vogel wrote: On Wed, Sep 12, 2012 at 12:40 PM, Freddie Cash wrote: Thanks for checking. I've used lagg(4) with igb, just not on 9.x. You're right, it seems to be pointing to the igb(4) driver in 9.x compared to < 9.0. How do you determine that since it doesn't happen without lagg? I've no reports of igb hanging otherwise and its being used extensively. Well, I did say "seems to". :) igb+lagg worked for us on 8.3. Haven't tried it since moving to 9.0 and 9-STABLE on those three boxes. igb+lagg doesn't work for him on 9.0. Although, I don't recall if non-LACP options were tried earlier in this thread, or if it's just the LACP mode that's failing. If one mode works (say failover) and LACP mode doesn't, that "seems to" point to lagg. Sorry, forgot to mention it. I tried both failover and lacp: neither worked. The switch is a Dell powerconnect 6248 with ports configured for aggragation. I first tried on a 9.1 prerelease, then on a 9.0 release to have everything clean. In both ssh, both as server and as client, become unresponsive and unkillable. The problem might also lie within ssh/d, but I somehow doubt it. I haven't tried other network services. ___ 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: moving pfil consumers to sys/netpfil
On Thu, Sep 13, 2012 at 11:31:25PM +0400, Gleb Smirnoff wrote:
> On Thu, Sep 13, 2012 at 07:41:05PM +0200, Luigi Rizzo wrote:
> L> Second:
> L>What i contest is the fact that you classify ipfw as a "pfil client",
> L>when pfil is just a tiny adaptation layer to access ipfw.
> L>I mentioned the three alternative APIs (netmap, netfilter, ndis)
> L>to witness the fact that pfil is irrelevant to ipfw's operation.
>
> In FreeBSD ipfw is a pfil client. Dot.
>
> In Linux it is netfilter client, and if they want to they may or may not
> put it under netfilter/ipfw. We don't care. Same for Windows and ndis.
This is the second time a "we don't care" statement appears in
this discussion and I find them extremely non constructive.
I do not know who you consider as "we", but as one who maintains
the code under multiple platforms i do have an interest in avoiding
gratuitous changes that introduce differences between the various
versions.
> ipfw isn't netinet specific, it also supports netinet6 and also supports
> layer2 pfil hooks.
>
> Putting all pfil clients into one place puts things in order. It simplifies
> kernel overview for newcomer, it makes things easier for those who want
> to hack on the pfil itself.
>
> L> Third:
> L>any code relocation comes with some pain -- specifically, netinet/
> L>is hardwired in many #include paths in the ipfw sources
> L>
> L>> grep netinet/ipfw sys/netinet/ipfw/* | grep include | wc
> L> 35 701791
>
> Numbers from your grep are impressive, but they are absolutely irrelevant.
> Actual diff for movement isn't that big. For example:
>
> - sys/net has zero diff, no files modified
> - sys/netinet/* has zero diff, just ipfw directory removed, no files modified
> - sbin/ipfw has zero diff
please remain in context.
We were talking about the files in netinet/ipfw, which have
#include
in them, so when moved to the new location these 35 lines
need to be changed to
#include
Which is completely trivial, but introduces a difference between
the files in HEAD and those in stable/9 (and in the other versions
"we don't care" about) .
Now if your plan involves removing the netinet/ prefix and adding
... compile-with "${NORMAL_C} -I$S/netpfil"
to the lines in HEAD:sys/conf/files, and
... compile-with "${NORMAL_C} -I$S/netinet"
for those in stable/9, i can lift this objection.
I still think that a subsystem should not be classified by looking
at one of the APIs it uses, but rather based on overall functionality.
Hence in my opinion ipfw does not belong under netpfil/ more than
it belongs under netinet/ , and lacking a better place i consider
the relocation a gratuitous one.
> This is actual diff that is already universe-tested.
(attachment probably stripped by the mailing list ?)
cheers
luigi
___
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: Why wpa_supplicant doesn't start with ndis0 interface?
On Thu, 13 Sep 2012, Glen Barber wrote: On Thu, Sep 13, 2012 at 08:34:40AM -0700, Yuri wrote: On 09/12/2012 20:01, Glen Barber wrote: It would be helpful if you would at least try my cron(8) suggestion. So I tried adding the lines into crontab: @reboot root/sbin/kldload /boot/kernel/if_ndis.ko >/dev/null 2>&1 @reboot root/sbin/kldload /boot/modules/bcmwl5_sys.ko >/dev/null 2>&1 Firstly, for some reason, this method fails to load bcmwl5_sys.ko with the error message: KLD bcmwl5_sys.ko: depends on ndis - not available or version mismatch Hmm. This should also be loading ndis.ko. If not, add that to the cron line as well. If that is the problem, sorry, that was my mistake. On a fast machine, there could be a race there. Best to load them in order in a single command: @reboot root/sbin/kldload if_ndis.ko && /sbin/kldload bcmwl5_sys.ko ___ 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: kernel: arpresolve: can't allocate llinfo for 65.59.233.102
On Thu, 13 Sep 2012 21:53:23 +0300, ? ??? wrote: > Then my guess is wrong. I found the message, where similiar problem was > described in ipfw mailling list > http://lists.freebsd.org/pipermail/freebsd-ipfw/2011-March/004582.html, with > no answer. > Maybe it will be usefull for somebody. For that problem at least, and another that's just emerged in ipfw@ - also using ipfw kernel nat - all interfaces shown have TSO enabled. % man ipfw | tail | head -4 Due to the architecture of libalias(3), ipfw nat is not compatible with the TCP segmentation offloading (TSO). Thus, to reliably nat your net- work traffic, please disable TSO on your NICs using ifconfig(8). I couldn't find an ifconfig shown in this thread, so I'm left wondering whether TSO is configured on the OP's or any of the problem boxes here? cheers, Ian ___ 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: kern/167325: [netinet] [patch] sosend sometimes return EINVAL with TSO and VLAN on 82599 NIC
On Fri, Sep 07, 2012 at 05:44:48PM -0400, Jeremiah Lott wrote: > On Apr 27, 2012, at 2:07 AM, lini...@freebsd.org wrote: > > > Old Synopsis: sosend sometimes return EINVAL with TSO and VLAN on 82599 NIC > > New Synopsis: [netinet] [patch] sosend sometimes return EINVAL with TSO and > > VLAN on 82599 NIC > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=167325 > > I did an analysis of this pr a while back and I figured I'd share. > Definitely looks like a real problem here, but at least in 8.2 it is > difficult to hit it. First off, vlan tagging is not required to hit this. > The code is question does not account for any amount of link-local header, so > you can reproduce the bug even without vlans. > > In order to trigger it, the tcp stack must choose to send a tso "packet" with > a total size (including tcp+ip header and options, but not link-local header) > between 65522 and 65535 bytes (because adding 14 byte link-local header will > then exceed 64K limit). In 8.1, the tcp stack only chooses to send tso > bursts that will result in full mtu-size on-wire packets. To achieve this, > it will truncate the tso packet size to be a multiple of mss, not including > header and tcp options. The check has been relaxed a little in head, but the > same basic check is still there. None of the "normal" mtus have multiples > falling in this range. To reproduce it I used an mtu of 1445. When > timestamps are in use, every packet has a 40 bytes tcp/ip header + 10 bytes > for the timestamp option + 2 bytes pad. You can get a packet length 65523 as > follows: > > 65523 - (40 + 10 + 2) = 65471 (size of tso packet data) > 65471 / 47 = 1393 (size of data per on-wire packet) > 1393 + (40 + 10 + 2) = 1445 (mtu is data + header + options + pad) > > Once you set your mtu to 1445, you need a program that can get the stack to > send a maximum sized packet. With the congestion window that can be more > difficult than it seems. I used some python that sends enough data to open > the window, sleeps long enough to drain all outstanding data, but not long > enough for the congestion window to go stale and close again, then sends a > bunch more data. It also helps to turn off delayed acks on the receiver. > Sometimes you will not drain the entire send buffer because an ack for the > final chunk is still delayed when you start the second transmit. When the > problem described in the pr hits, the EINVAL from bus_dmamap_load_mbuf_sg > bubbles right up to userspace. > > At first I thought this was a driver bug rather than stack bug. The code in > question does what it is commented to do (limit the tso packet so that > ip->ip_len does not overflow). However, it also seems reasonable that the > driver limit its dma tag at 64K (do we really want it allocating another > whole page just for the 14 byte link-local header). Perhaps the tcp stack > should ensure that the tso packet + max_linkhdr is < 64K. Comments? Hmm, I think it's a driver bug. Upper stack may not know whether L2 includes VLAN. Almost all drivers in tree includes L2 header size in DMA tag. If ethernet hardwares can handle this oversized frames(64KB + L2 header) with TSOv4/TSOv6 I think there is no reason not to support it. > > As an aside, the patch attached to the pr is also slightly wrong. Taking the > max_linkhdr into account when rounding the packet to be a multiple of mss > does not make sense, it should only take it into account when calculating the > max tso length. > > Jeremiah Lott > Avere Systems ___ 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: kernel: arpresolve: can't allocate llinfo for 65.59.233.102
I am using two lagg interfaces : lagg0: flags=8843 metric 0 mtu 1500 options=400b8 ether 00:1b:21:55:a7:c4 nd6 options=9 media: Ethernet autoselect status: active laggproto lacp laggport: igb1 flags=1c laggport: igb0 flags=1c lagg1: flags=8843 metric 0 mtu 1500 options=400b8 ether 00:1b:21:63:59:c8 nd6 options=9 media: Ethernet autoselect status: active laggproto lacp laggport: igb3 flags=1c laggport: igb2 flags=1c I am not using ipfw nat for a while, and problem still occur. uname -a FreeBSD bras-2 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Tue Feb 28 10:50:04 EET 2012 root@bras:/usr/obj/usr/src/sys/BRAS amd64 Xeon X3440/RAM - 4G, two network cards Intel Pro 1000 ET Dual Port. It has 400 Mbit/s traffic at peak going through. my ipfw rules are: 00100 allow ip from any to any via lo0 00200 deny ip from 127.0.0.0/8 to any 00300 deny ip from any to 127.0.0.0/8 00400 netgraph 1 udp from 10.0.0.0/8 to any dst-port 53 in via vlan* // Filter MX recods requests from RFC Net 00500 deny ip from table(2) to not x.x.x.x dst-port 25 01000 allow udp from any 68 to any dst-port 67 in via vlan* 01100 deny log icmp from any to any icmptypes 5,9,10 07000 allow ip from any to table(80) dst-port 53 // DNS ALLOW 07100 allow ip from table(80) 53 to any // DNS Reverse Allow 07200 allow ip from any to x.x.x.x // Billing Allow 07300 allow ip from x.x.x.x to any // Billing Reverse Allow 08000 fwd 127.0.0.1,83 ip from table(3) to not x.x.x.x dst-port 80,443,8080 in recv vlan* // New-Computers 08100 fwd 127.0.0.1,82 ip from not table(20) to not x.x.x.x dst-port 80,443,8080 in recv vlan* // Debotors 09000 allow ip from any to 255.255.255.255 dst-port 67 in via vlan* 1 allow ip from table(20) to table(10) in recv vlan* // UA-IX Without shapers 10100 allow ip from table(10) to table(20) out xmit vlan* 10200 allow ip from table(20,0) to any in recv vlan* 10300 allow ip from any to table(20,0) out xmit vlan* 4 pipe tablearg ip from any to table(20) out xmit vlan* 40100 pipe tablearg ip from table(21) to any in recv vlan* 40800 allow ip from table(20) to any out xmit ext_if 40900 allow ip from any to table(20) in recv ext_if 5 allow ip from me to any 50005 allow tcp from any to me established 50010 allow tcp from any to me dst-port 125,53,83,84 setup 50020 allow udp from any to me dst-port 53,161 50030 allow icmp from any to me icmptypes 0,8 50040 allow tcp from x.x.x.x to me dst-port 72 setup 50050 deny tcp from any to me dst-port 72 setup 50100 allow ip from any to me 50300 allow ip from any to any out via vlan* 65500 deny log ip from any to any 65535 allow ip from any to any route monitor didn`t show event that changes default router. I use a script in crontab to restore proper gateway, for now. I am wandering: is it dummynet issue, because we all using it. My statistics of changing default gateway is follows August 5 August 14 August 18 September 2 September 6 I will appriciate any suggestion in debugging that problem. > > > I couldn't find an ifconfig shown in this thread, so I'm left wondering > whether TSO is configured on the OP's or any of the problem boxes here? > > cheers, Ian > ___ 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: kernel: arpresolve: can't allocate llinfo for 65.59.233.102
On Thu, Sep 13, 2012 at 11:29 PM, Вадим Уразаев wrote: > I am using two lagg interfaces : > lagg0: flags=8843 metric 0 mtu 1500 > options=400b8 > ether 00:1b:21:55:a7:c4 > nd6 options=9 > media: Ethernet autoselect > status: active > laggproto lacp > laggport: igb1 flags=1c > laggport: igb0 flags=1c > > lagg1: flags=8843 metric 0 mtu 1500 > options=400b8 > ether 00:1b:21:63:59:c8 > nd6 options=9 > media: Ethernet autoselect > status: active > laggproto lacp > laggport: igb3 flags=1c > laggport: igb2 flags=1c > > I am not using ipfw nat for a while, and problem still occur. > > uname -a > FreeBSD bras-2 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Tue Feb 28 10:50:04 EET > 2012 root@bras:/usr/obj/usr/src/sys/BRAS amd64 > Xeon X3440/RAM - 4G, two network cards Intel Pro 1000 ET Dual Port. > It has 400 Mbit/s traffic at peak going through. > > > my ipfw rules are: > > 00100 allow ip from any to any via lo0 > 00200 deny ip from 127.0.0.0/8 to any > 00300 deny ip from any to 127.0.0.0/8 > 00400 netgraph 1 udp from 10.0.0.0/8 to any dst-port 53 in via vlan* // > Filter MX recods requests from RFC Net > 00500 deny ip from table(2) to not x.x.x.x dst-port 25 > 01000 allow udp from any 68 to any dst-port 67 in via vlan* > 01100 deny log icmp from any to any icmptypes 5,9,10 > 07000 allow ip from any to table(80) dst-port 53 // DNS ALLOW > 07100 allow ip from table(80) 53 to any // DNS Reverse Allow > 07200 allow ip from any to x.x.x.x // Billing Allow > 07300 allow ip from x.x.x.x to any // Billing Reverse Allow > 08000 fwd 127.0.0.1,83 ip from table(3) to not x.x.x.x dst-port 80,443,8080 > in recv vlan* // New-Computers > 08100 fwd 127.0.0.1,82 ip from not table(20) to not x.x.x.x dst-port > 80,443,8080 in recv vlan* // Debotors > 09000 allow ip from any to 255.255.255.255 dst-port 67 in via vlan* > 1 allow ip from table(20) to table(10) in recv vlan* // UA-IX Without > shapers > 10100 allow ip from table(10) to table(20) out xmit vlan* > 10200 allow ip from table(20,0) to any in recv vlan* > 10300 allow ip from any to table(20,0) out xmit vlan* > 4 pipe tablearg ip from any to table(20) out xmit vlan* > 40100 pipe tablearg ip from table(21) to any in recv vlan* > 40800 allow ip from table(20) to any out xmit ext_if > 40900 allow ip from any to table(20) in recv ext_if > 5 allow ip from me to any > 50005 allow tcp from any to me established > 50010 allow tcp from any to me dst-port 125,53,83,84 setup > 50020 allow udp from any to me dst-port 53,161 > 50030 allow icmp from any to me icmptypes 0,8 > 50040 allow tcp from x.x.x.x to me dst-port 72 setup > 50050 deny tcp from any to me dst-port 72 setup > 50100 allow ip from any to me > 50300 allow ip from any to any out via vlan* > 65500 deny log ip from any to any > 65535 allow ip from any to any > > route monitor didn`t show event that changes default router. > I use a script in crontab to restore proper gateway, for now. > I am wandering: is it dummynet issue, because we all using it. > My statistics of changing default gateway is follows > August 5 > August 14 > August 18 > September 2 > September 6 > > I will appriciate any suggestion in debugging that problem. Try disabling tso at the global level in the kernel. Under some circumstances with some drives VLAN_HWTSO -> TSO. -Garrett ___ 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"
