Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/142197 net[ndis] [patch] ndis is missing media status reporting o kern/142066 net[patch] [sctp] Missing parenthesis in sys/netinet/sctp o kern/142052 net[panic] MROUTED option causes kernel panic o kern/142019 net[em] em needs "ifconfig em0 down up" when link was gon o kern/142018 net[iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net[wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141843 net[em] [vlan] Intel txcsum and assigned vlan invoke wron o kern/141777 net[rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 netEtherlink III NIC won't work after upgrade to FBSD 8, o kern/141720 net[sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net[sctp] [panic] Own lock on stcb at return from input o kern/141697 net[sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net[rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net[sctp] [panic] kernel page fault with non-sleepable lo o kern/141646 net[em] em(4) + lagg(4) + vlan(4) generates ISL-tagged fr o kern/141314 netNetwork Performance has decreased by 30% [regression] o kern/141285 net[em] hangs down/up intel nic during creating vlan o kern/141256 net[iwn] iwn(4) causes page fault on interface up o kern/141023 net[carp] CARP arp replays with wrong src mac o kern/140970 net[bce] The two NetXtreme II BCM5709S NICs on our HP Bl4 o kern/140796 net[ath] [panic] privileged instruction fault o kern/140778 net[em] randomly panic in vlan/em o kern/140742 netrum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net[em] [patch] Fast irq registration in em driver o kern/140684 net[bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail o kern/140647 net[em] [patch] e1000 driver does not correctly handle mu o kern/140634 net[vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net[ifnet] [patch] refine obsolete if_var.h comments desc s kern/140597 net[request] implement Lost Retransmission Detection o kern/140567 net[ath] [patch] ath is not worked on my notebook PC o kern/140564 net[wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net[wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net[em] em0: watchdog timeout when communicating to windo o kern/140245 net[ath] [panic] Kernel panic during network activity on o kern/140142 net[ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net[bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net[bce] [arp] ARP not sent through Bridge Firewall with o kern/140036 net[iwn] [lor] lock order reversal with iwn0_com_lock and o kern/139761 net[bce] bce driver on IBM HS22 [No PHY found on Child MI o kern/139565 net[ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net[ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net[patch] arp(8) add option to remove static entries lis o kern/139268 net[if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net[arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net[fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net[lagg] + wlan boot timing (EBUSY) o kern/139079 net[wpi] Failure to attach wpi(4) o kern/139058 net[ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138999 net[libc] lighttpd/php-cgi with freebsd sendfile(2) enabl o kern/138850 net[dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net[panic] sbflush_internal: cc 0 || mb 0xff004127b00 o kern/138739 net[wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net[bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net[rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net[lo] FreeBSD does not assign linklocal address to loop f kern/138666 net[multicast] [panic] not working multicast through igmp o kern/138660 net[igb] igb driver troubles in 8.0-BETA4 o kern/138652 net[tcp] TCP window scaling value calculated incorrectly? o kern/138620 net[lagg] [patch] lagg port bpf-writes blocked o kern/138427 net[wpi] [pani
Re: TDMA link cannot pass data
On 3 Jan 2010, at 12:23, Kim Culhan wrote: > Have setup a TDMA link with Atheros hardware but cannot pass any data > over the link. > > The hardware is: > > ath0: mem 0xfeb9-0xfeb9 irq 17 at device 1.0 on pci5 > ath0: [ITHREAD] > ath0: AR2413 mac 7.9 RF2413 phy 4.5 > > The setup on either end: > > ifconfig wlan create wlandev ath0 wlanmode tdma ssid freebsd-tdma > tdmaslotcnt 2 tdmaslotlen 2500 tdmaslot 0 up > ifconfig bridge create > ifconfig bridge0 addm wlan0 addm em1 192.168.1.17 netmask 255.255.255.0 up > ifconfig em1 up > > ifconfig wlan create wlandev ath0 wlanmode tdma ssid freebsd-tdma > tdmaslotcnt 2 tdmaslotlen 2500 tdmaslot 1 up > ifconfig bridge create > ifconfig bridge0 addm wlan0 addm em1 192.168.1.18 netmask 255.255.255.0 up > ifconfig em1 up > >> From machines connected to the bridged em interfaces on either end of > the link it is not possible to > ping the opposite end or the bridge0 address on the opposite end. > > Monitoring the traffic on bridge0 it is possible to see arp packets > from the opposite ends, this is > the only evidence of the link passing any traffic. > > The radio interfaces: > > wlan0: flags=8943 > metric 0 mtu 1500 >ether 00:22:3f:fd:d6:57 >media: IEEE 802.11 Wireless Ethernet OFDM/24Mbps mode 11g >status: running >ssid freebsd-tdma channel 10 (2457 Mhz 11g) bssid 00:22:3f:fd:d6:57 >country US ecm authmode OPEN privacy OFF txpower 22.5 ucastrate 24 >mcastrate 24 scanvalid 60 protmode CTS wme burst tdmaslot 0 >tdmaslotcnt 2 tdmaslotlen 2500 tdmabintval 5 > > wlan0: flags=8943 > metric 0 mtu 1500 >ether 00:22:3f:fd:70:ca >media: IEEE 802.11 Wireless Ethernet OFDM/24Mbps mode 11g >status: running >ssid freebsd-tdma channel 10 (2457 Mhz 11g) bssid 00:22:3f:fd:d6:57 >country US ecm authmode OPEN privacy OFF txpower 22 ucastrate 24 >mcastrate 24 scanvalid 60 protmode CTS wme burst tdmaslot 1 >tdmaslotcnt 2 tdmaslotlen 2500 tdmabintval 5 > > Any help on this is very greatly appreciated. > > Some background on the FreeBSD TDMA work can be found here: > > http://people.freebsd.org/~sam/FreeBSD_TDMA-20090921.pdf > This is odd. What happens without the bridge? -- Rui Paulo ___ 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: igb interrupt moderation
--- On Sun, 1/3/10, Michael Tüxen wrote: > From: Michael Tüxen > Subject: Re: igb interrupt moderation > To: "Barney Cordoba" > Cc: freebsd-net@freebsd.org, "Mike Tancsa" > Date: Sunday, January 3, 2010, 1:33 PM > On Jan 3, 2010, at 6:35 PM, Barney > Cordoba wrote: > > > --- On Sun, 1/3/10, Michael Tüxen > wrote: > > > >> From: Michael Tüxen > >> Subject: Re: igb interrupt moderation > >> To: "Barney Cordoba" > >> Cc: freebsd-net@freebsd.org, > "Mike Tancsa" > >> Date: Sunday, January 3, 2010, 12:14 PM > >> On Jan 3, 2010, at 6:00 PM, Barney > >> Cordoba wrote: > >> > >>> > >>> > >>> --- On Sun, 1/3/10, Michael Tüxen > >> wrote: > >>> > From: Michael Tüxen > Subject: Re: igb interrupt moderation > To: "Mike Tancsa" > Cc: "Barney Cordoba" , > >> jfvo...@gmail.com, > >> freebsd-net@freebsd.org > Date: Sunday, January 3, 2010, 11:38 AM > On Jan 3, 2010, at 5:23 PM, Mike > Tancsa wrote: > > > At 11:13 AM 1/3/2010, Michael Tüxen > wrote: > >>> > >>> Just a separate datapoint > about this > >> driver, > unless I apply > >>> > >>> http://people.freebsd.org/~yongari/igb/igb.buf.patch6 > >>> > >>> the driver is not really > usable for me > >> in > RELENG_8 on the dual port version of the > card > >> Could you elaborate on what you > mean by > >> "not > really usable"? > > > > > > Hi, > > > Some > >> link state issues > (getting confused about what port is up), > problems > >> at high > packet rates. I dont have this card > in > >> production, but > in my test environment it was much more > stable on > >> RELENG_8 > with the above patch in that I was not > able to > >> wedge the > box. pps rates were pretty ok on a > low end > >> i7 as > well. > Thanks for the information. I'll give it a > try. I > >> have a > problem when I flood > a system with SCTP INITs. The system under > attack > >> becomes > completely unresponsive > on the console. However, it continues to > send > >> INIT-ACKs > back. After the last > commit from Jack it recovers after the > attack. Not > >> yet sure > what is going on. > Using the em driver does not have the > problem. > >> However, > when using the em > driver only one core is fully used, when > using the > >> igb > driver both cores are fully > used. Unfortunately I do not have a more > than dual > >> core > machine available for > this testing... > >>> > >>> Try em and lower the interrupt moderation to > something > >> like 500 (about > >>> 100 packets per int is good). The latency > isn't going > >> to be noticable and > >>> you'll see your cpu burden reduced quite a > bit. > >> I'll try. Thanks. > >>> > >>> Are you using a single NIC on a server, or do > you have > >> a firewall or > >>> bridge? > >> The system is a sender/receiver for SCTP. I'm > interested in > >> the 82576 > >> since it provides checksum offloading for it. I > use one or > >> two ports > >> for simultaneous data transfer. The cards using > the em > >> driver do > >> not support this feature. So I'm trying to verify > that the > >> performance > >> goes up when using hardware checksum. But under > attack, > >> this is currently > >> not the case... > >>> > >>> Barney > > > > I usually try to find something that actually works > before I worry > > about special features. But we all work differently. > ... I want to make sure that the SCTP stuff works. So > others > can "just use it". SCTP checksum offloading is one > important > feature... > > > > Barney > > It just seems a bit silly to worry about saving a few cpu cycles on checksum offload when the general driver design is wholly inefficient and unsuitable for production. Barney ___ 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/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets
Thanks Pyun YongHyeon! I apply patch em.csum_tso.20091230.patch and rebuild/reinstall kernel and have received successful result for tcp and udp connections (test by iperf). But the hangs down/up nic bug do not disappear (kern/141285 without connection problems after your patch). Please pay attention to this problem. ___ 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/142052: commit references a PR
The following reply was made to PR kern/142052; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: kern/142052: commit references a PR Date: Mon, 4 Jan 2010 15:58:51 + (UTC) Author: syrinx Date: Mon Jan 4 15:58:36 2010 New Revision: 201515 URL: http://svn.freebsd.org/changeset/base/201515 Log: MFC r201254: Make sure the multicast forwarding cache entry's stall queue is properly initialized before trying to insert an entry into it. PR: kern/142052 Reviewed by: bms Modified: stable/8/sys/netinet/ip_mroute.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) stable/8/sys/dev/xen/xenpci/ (props changed) Modified: stable/8/sys/netinet/ip_mroute.c == --- stable/8/sys/netinet/ip_mroute.c Mon Jan 4 15:50:41 2010 (r201514) +++ stable/8/sys/netinet/ip_mroute.c Mon Jan 4 15:58:36 2010 (r201515) @@ -1384,6 +1384,15 @@ fail: rt->mfc_rp.s_addr = INADDR_ANY; rt->mfc_bw_meter = NULL; + /* initialize pkt counters per src-grp */ + rt->mfc_pkt_cnt = 0; + rt->mfc_byte_cnt = 0; + rt->mfc_wrong_if = 0; + timevalclear(&rt->mfc_last_assert); + + TAILQ_INIT(&rt->mfc_stall); + rt->mfc_nstall = 0; + /* link into table */ LIST_INSERT_HEAD(&mfchashtbl[hash], rt, mfc_hash); TAILQ_INSERT_HEAD(&rt->mfc_stall, rte, rte_link); ___ svn-src-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-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: igb interrupt moderation
--- On Sun, 1/3/10, Michael Tüxen wrote:
> From: Michael Tüxen
> Subject: Re: igb interrupt moderation
> To: "Michael Tüxen"
> Cc: "Barney Cordoba" , freebsd-net@freebsd.org,
> jfvo...@gmail.com
> Date: Sunday, January 3, 2010, 9:54 AM
> Dear all,
>
> I just figured out that there is a newer version of the
> spec
> available: 2.45. Some of the issues as indicated inline
> are already resolved.
>
> Best regards
> Michael
>
> On Jan 3, 2010, at 2:55 PM, Michael Tüxen wrote:
>
> > Hi Barney, Hi Jack,
> >
> > some comments and some more questions inside...
> >
> > Best regards
> > Michael
> >
> > On Jan 2, 2010, at 8:42 PM, Barney Cordoba wrote:
> >
> >> Jack,
> >>
> >> I'm trying to get some clarification on
> differences I'm finding between
> >> the 82575 and 82576 parts with respect to
> interrupt moderation. The spec
> >> I have for the 82576 (82576_Datasheet_v2p1.pdf)
> indicates that the
> > I'm only commenting 82576. You can get rev 2.41 from
> intels website...
> It is really 2.45 now
> >>
> >> ITR algorithm is different than the one used (I
> don't have one of the
> >> secret copies of the 82575 spec). The algorithm
> shown is
> >>
> >> interrupts/sec = 1/(2 * 10-6sec x interval) (page
> 295, Section 7.3.4)
> >>
> >> which is clearly wrong from practice. I have an
> 82576 (device id 10C9)
> > If you look at section 8.8.12, you find other
> formulas...
> > Jack: Which ones are correct?
> The formulas is 8.8.12 are gone. Issue resolved.
> >> if I use the 125d setting in the example get just
> under 32000 interrupts
> >> per second. Clearly your code doesnt implement
> this, nor do you have
> >> different settings for the 82575 and 82576 parts.
> So I assume that the
> >> same formula for the em parts hold for the igb
> parts, and that the
> >> datasheet is wrong?
> >>
> >> There does seem to be a slight difference. The
> setting that gets 1000
> >> ints/second on the 82575 generates about 1020 on
> the 82576. Not a big
> >> deal but I wonder why there's a difference? Is the
> reference clock for
> >> these something that may not be fixed and could
> vary from board to
> >> board? Note that both devices are on the same MB.
> >>
> >> Also, it seems that settings to EITR over 32767
> wrap on the 82576 (for
> >> example writing 32768 to EITR is the same as
> writing a 1). So the minimum setting on the 82576 is
> around 125 ints/second. The 82575 can accept
> >> values up the 65535 before wrapping.
> > Hmm, looking at the table in 8.8.12 would suggest:
> > Setting it to one sets a reserved bit, but does not
> change the interval.
> > Setting it to 2^15 should set the LLI_EN bit, but does
> not change in interval.
> >
> > Jack is setting the register to
> > igb_low_latency: 128
> > igb_ave_latency: 450
> > igb_bulk_latency: 1200
> >
> > This would result in intervals of:
> > igb_low_latency: 32
> > igb_ave_latency: 112
> > igb_bulk_latency: 300
> > Jack: What are the corresponding interrupt rates? The
> spec provides different
> > formulas and talks about a 1us,
> 2us or 8us counter. Not sure what is right...
> The interrupt rates are according to the formula in the
> spec
> igb_low_latency: 31250
> igb_ave_latency: 8929
> igb_bulk_latency:
> Jack: Is this right?
> > Jack: Why are you setting bit1 (which is reserved) in
> the case igb_ave_latency?
> Still valid.
> >
> > And another question for Jack:
> > In igb_update_aim() you do
> > if (olditr != newitr) {
> > /* Change
> interrupt rate */
> >
> rxr->eitr_setting = newitr;
> >
> E1000_WRITE_REG(&adapter->hw,
> E1000_EITR(rxr->me),
> >
> newitr | (newitr << 16));
> > }
> > So why are setting the higher bits of the EITR? You
> are setting
> > igb_low_latency: the LL Counter becomes 0, the
> moderation counter becomes 16
> > igb_ave_latency: the LL Counter becomes 2, the
> moderation counter becomes 56
> > igb_bulk_latency: the LL Counter becomes 16, the
> moderation counter becomes 148
> Still valid.
> >
> > I really do not understand these settings. Maybe the
> spec is wrong? Or you do mean
> > if (olditr != newitr) {
> > /* Change
> interrupt rate */
> >
> rxr->eitr_setting = newitr;
> >
> E1000_WRITE_REG(&adapter->hw, E1000_EITR(rxr->me),
> newitr);
> > }
> > Or do you want to preserve the counters, set the
> CNT_INGR bit and mean
> > if (olditr != newitr) {
> > /* Change
> interrupt rate */
> >
> rxr->eitr_setting = newitr;
> >
> E1000_WRITE_REG(&adapter->hw, E1000_EITR(rxr->me),
> 0x8000 | newitr);
> > }
> >
> > Could you clarify that?
> Still valid.
> >>
> >> The 82576 document doesn't have a map of the
> register that I can find, so
> >> Im curious as to whether these observations are
> something I can assume is
> >> true across all parts and motherboards/cards, or
> is there some
> >> implementation variance that will cause these to
> only apply to the ones
> >> I happen to be testing?
> >>
> >>
pppoe controlling simultaneous use with freeradius
Hi guys, i have trouble in simultaneous use to work with Freeradius 2 and FreeBSD5.2 pppoe server. My Freebsd box as working as PPPOE server and on same box freeradius is working. But i don't know how freebsd interact with radius as nas. Also could not kill stale pppoe sessions. I also tried MAC-based authentication but without luck. Please help if some one has solution for this problem i guess i am just missing nas type for freebsd as box is unable to answer radius querries due to wrong nas type. Thanks, Best regards, Fazal Ahmed Malik ___ 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/142066: commit references a PR
The following reply was made to PR kern/142066; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/142066: commit references a PR
Date: Mon, 4 Jan 2010 18:25:52 + (UTC)
Author: tuexen
Date: Mon Jan 4 18:25:38 2010
New Revision: 201523
URL: http://svn.freebsd.org/changeset/base/201523
Log:
Correct usage of parenthesis.
PR: kern/142066
Approved by: rrs (mentor)
Obtained from: Henning Petersen, Bruce Cran.
MFC after: 2 weeks
Modified:
head/sys/netinet/sctp_pcb.c
Modified: head/sys/netinet/sctp_pcb.c
==
--- head/sys/netinet/sctp_pcb.cMon Jan 4 18:21:27 2010
(r201522)
+++ head/sys/netinet/sctp_pcb.cMon Jan 4 18:25:38 2010
(r201523)
@@ -5528,7 +5528,7 @@ sctp_pcb_init()
/* Init the TIMEWAIT list */
for (i = 0; i < SCTP_STACK_VTAG_HASH_SIZE; i++) {
- LIST_INIT(&SCTP_BASE_INFO(vtag_timewait[i]));
+ LIST_INIT(&SCTP_BASE_INFO(vtag_timewait)[i]);
}
#if defined(SCTP_USE_THREAD_BASED_ITERATOR)
@@ -6385,7 +6385,7 @@ sctp_is_vtag_good(struct sctp_inpcb *inp
}
skip_vtag_check:
- chain = &SCTP_BASE_INFO(vtag_timewait[(tag %
SCTP_STACK_VTAG_HASH_SIZE))];
+ chain = &SCTP_BASE_INFO(vtag_timewait)[(tag %
SCTP_STACK_VTAG_HASH_SIZE)];
/* Now what about timed wait ? */
if (!LIST_EMPTY(chain)) {
/*
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-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"
CARP IPv6 support ?
Hi, Anyone who knows if perhaps CARP already works for IPv6, in a recent FreeBSD version ? (http://www.freebsd.org/cgi/query-pr.cgi?pr=127050) Thanks & regards, Wouter ___ 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/142066: [patch] [sctp] Missing parenthesis in sys/netinet/sctp_pcb.c .
Synopsis: [patch] [sctp] Missing parenthesis in sys/netinet/sctp_pcb.c . State-Changed-From-To: open->patched State-Changed-By: brucec State-Changed-When: Mon Jan 4 19:13:06 UTC 2010 State-Changed-Why: Fixed in r201523. Responsible-Changed-From-To: freebsd-net->brucec Responsible-Changed-By: brucec Responsible-Changed-When: Mon Jan 4 19:13:06 UTC 2010 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=142066 ___ 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: bin/136661: [patch] ndp(8) ignores -f option
Synopsis: [patch] ndp(8) ignores -f option Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Mon Jan 4 20:00:59 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). Patch looks good (and fits the style of the rest of the file), but I'm not in any position to test it. http://www.freebsd.org/cgi/query-pr.cgi?pr=136661 ___ 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: uath under FreeBSD 8.0-STABLE
On Sat, Dec 26, 2009 at 09:42:48AM -0500, Steven Friedrich wrote: > On Friday 25 December 2009 11:42:43 pm Weongyo Jeong wrote: > > On Fri, Dec 25, 2009 at 11:44:12AM -0800, Sam Leffler wrote: > > > Steven Friedrich wrote: > > > >On Thursday 24 December 2009 05:09:42 pm Weongyo Jeong wrote: > > > >>OK. It looks weird idProduct didn't be decreased 1 after loading the > > > >>firmware. > > > >> > > > >>And what I'd like to see is the *full* result of the following steps: > > > >> > > > >> 1. plugs in your USB device. > > > >> 2. run commands as follows: > > > >> > > > >> # kldload if_uath > > > >> # dmesg | tail > > > >> # uathload -v -d /dev/ugen4.3 > > > >> # dmesg | tail > > > >> > > > >>In a theory, after loading the firmware normally the device which at > > > >> the moment idProduct is 0x4251 is detached and reseted then it should > > > >> be reattached with idProduct(0x4250). > > > >> > > > >>regards, > > > >>Weongyo Jeong > > > > > > > >Opps, I'm sorry, the reply I just sent ws wrong because once you've used > > > >uathload, you have to unplugplug the device before you can run it again. > > > >So here it is: > > > >Load firmware ar5523.bin (builtin) to /dev/ugen4.3 > > > >send block 0: 147368 bytes remaining > > > > > > > > : data... > > > > : wait for ack...flags=0x14 total=149416 > > > > > > <...snip...> > > > > > > The device should detach and be re-enumerated w/ a different device id > > > that the driver attaches to. Hard to say why it does not. > > > > > > uathload should be automatically run by devd but it appears the devd > > > rules file I did got lost (don't see it in the tree). > > > > I agree with sam@ that it's hard to understand why it's not detached > > after downloading the firmware. > > > > Yesterday I ordered `Netgear Wireless USB Adapter WG111T' which probably > > is same one with you so I could reproduce your problem and debug it. > > Thanks for your effort. I appreciate it. Could you please test with attached patch? Today the device I ordered is delivered and I tried to test with it. One thing, it looks weird, I noticed is that after uploading the firmware, idProduct is increased not decreased. After patching, you should rebuild the module. regards, Weongyo Jeong ___ 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: uath under FreeBSD 8.0-STABLE
On Sat, Dec 26, 2009 at 09:42:48AM -0500, Steven Friedrich wrote: > On Friday 25 December 2009 11:42:43 pm Weongyo Jeong wrote: > > On Fri, Dec 25, 2009 at 11:44:12AM -0800, Sam Leffler wrote: > > > Steven Friedrich wrote: > > > >On Thursday 24 December 2009 05:09:42 pm Weongyo Jeong wrote: > > > >>OK. It looks weird idProduct didn't be decreased 1 after loading the > > > >>firmware. > > > >> > > > >>And what I'd like to see is the *full* result of the following steps: > > > >> > > > >> 1. plugs in your USB device. > > > >> 2. run commands as follows: > > > >> > > > >> # kldload if_uath > > > >> # dmesg | tail > > > >> # uathload -v -d /dev/ugen4.3 > > > >> # dmesg | tail > > > >> > > > >>In a theory, after loading the firmware normally the device which at > > > >> the moment idProduct is 0x4251 is detached and reseted then it should > > > >> be reattached with idProduct(0x4250). > > > >> > > > >>regards, > > > >>Weongyo Jeong > > > > > > > >Opps, I'm sorry, the reply I just sent ws wrong because once you've used > > > >uathload, you have to unplugplug the device before you can run it again. > > > >So here it is: > > > >Load firmware ar5523.bin (builtin) to /dev/ugen4.3 > > > >send block 0: 147368 bytes remaining > > > > > > > > : data... > > > > : wait for ack...flags=0x14 total=149416 > > > > > > <...snip...> > > > > > > The device should detach and be re-enumerated w/ a different device id > > > that the driver attaches to. Hard to say why it does not. > > > > > > uathload should be automatically run by devd but it appears the devd > > > rules file I did got lost (don't see it in the tree). > > > > I agree with sam@ that it's hard to understand why it's not detached > > after downloading the firmware. > > > > Yesterday I ordered `Netgear Wireless USB Adapter WG111T' which probably > > is same one with you so I could reproduce your problem and debug it. > > Thanks for your effort. I appreciate it. Oops I forgot to attach the file. regards, Weongyo Jeong Index: usbdevs === --- usbdevs (revision 201529) +++ usbdevs (working copy) @@ -2003,8 +2003,8 @@ product NETGEAR WG111V2 0x6a00 WG111V2 product NETGEAR2 MA101 0x4100 MA101 product NETGEAR2 MA101B 0x4102 MA101 Rev B -product NETGEAR3 WG111T 0x4250 WG111T product NETGEAR3 WG111T_NF 0x4251 WG111T (no firmware) +product NETGEAR3 WG111T 0x4252 WG111T product NETGEAR3 WPN111 0x5f00 WPN111 product NETGEAR3 WPN111_NF 0x5f01 WPN111 (no firmware) ___ 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: CARP IPv6 support ?
Wouter de Jong wrote: Hi, Anyone who knows if perhaps CARP already works for IPv6, in a recent FreeBSD version ? (http://www.freebsd.org/cgi/query-pr.cgi?pr=127050) Thanks & regards, Wouter ___ 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" Hello, I have CARP running on a couple of 8-boxes, dualstack with both v4 and v6 addresses on the inside and outside. Everything works as expected. Let me know if you need any of my configs! By the way, my v6 uplink on said firewalls is 6to4, not naitive v6 like you seem to have access to (lucky you!) :) Best regards, Thomas Rasmussen ___ 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: pppoe controlling simultaneous use with freeradius
Fazal Ahmed Malik wrote: > i have trouble in simultaneous use to work with Freeradius 2 and FreeBSD5.2 > pppoe server. My Freebsd box as working as PPPOE server and on same box > freeradius is working. But i don't know how freebsd interact with radius as > nas. Also could not kill stale pppoe sessions. I also tried MAC-based > authentication but without luck. > Please help if some one has solution for this problem i guess i am just > missing nas type for freebsd as box is unable to answer radius querries due > to wrong nas type. Have you looked on net/mpd5 port? It is one of the most featured PPPoE servers and it works fine with FreeRADIUS. You can find mpd manual here: http://mpd.sourceforge.net/doc5/mpd.html Also consider updating your system, as FreeBSD 5.2 is very old now. -- Alexander Motin ___ 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/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets
On Mon, Jan 04, 2010 at 05:30:25PM +0200, Prokofiev S.P. wrote: > Thanks Pyun YongHyeon! > I apply patch em.csum_tso.20091230.patch and rebuild/reinstall kernel > and have received successful result for tcp and udp connections (test by > iperf). Thanks for testing. > But the hangs down/up nic bug do not disappear (kern/141285 without > connection problems after your patch). Please pay attention to this problem. > The patch was not intended to fix kern/141285. Sorry I'm somewhat busy to address other driver issues. Maybe Jack can look into that as well as fixing checksum offload issues. ___ 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"
What's the proper way to traverse a getifaddrs() interface list?
I have an application where I want to collect information on the network
interfaces. I've researched this and the function getifaddrs(struct ifaddrs
*ifap) appears to be the way to go, but I'm having some trouble understanding
exactly how to process the information returned by this call. It's basically a
linked list, but there are two entries for each interface. I initially thought
I could just skip one of the entries but that doesn't appear to be the case,
not entirely anyway. What I want to do is write a function that returns a list
of dynamically allocated structures, one for each interface. My structure looks
like this:
typedef struct
{
string *ifcId;
string *ipAddr;
bytearray *hwAddr;
string *subnetMask;
string *bcastAddr;
} net_attributes;
and the function I am implementing has the following prototype:
int getAllNetAttributes(net_attributes **result, int **count)
where count is the number of elements in the net_attributes result array. This
means I need to first count the number of interfaces and allocate my result
array, and then collect the information for each interface. This means two
traversals of the linked list, once just to count the entries (the length of
the list divided by 2) and then traversing it again to collect the data. I've
got this mostly working but I'm having trouble with how to deal with the
duplicate entries in the linked list of ifaddrs structures returned by
getifaddrs. I've looked at ifconfig.c and I can't tell exactly what the code is
doing as far as how it handles these duplicate entries. Can someone explain the
proper way to traverse this linked list?
___
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/138782: [panic] sbflush_internal: cc 0 || mb 0xffffff004127b000 || mbcnt 2304
The following reply was made to PR kern/138782; it has been noted by GNATS. From: "C. C. Tang" To: bug-follo...@freebsd.org, univers...@ukr.net Cc: Subject: Re: kern/138782: [panic] sbflush_internal: cc 0 || mb 0xff004127b000 || mbcnt 2304 Date: Tue, 05 Jan 2010 12:56:56 +0800 This is a multi-part message in MIME format. --020806030508080609020103 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, My 8.0-RELEASE server encountered similar problem recently. FreeBSD minori 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 The difference of my situation is that / partition is not overflowed. I want to know if there is any solution for this problem? I can provide core dump if necessary. Thanks, C.C. --020806030508080609020103 Content-Type: application/gzip; name="core.txt.0.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="core.txt.0.gz" H4sICP+zNUsAA2NvcmUudHh0LjAA7L1rc+M4sjb4ufUrGDPRcarnlG0CJEFSMT3vW+1yddd2 3abs6j6XfcNLUZTNKd1alOzyxPnxm4kLCZLgRYInYj+sZtolkcCDRGYi8eBCcJWvN7vcmR9W 22zupJtd5pw5RZY5Fw/J7iLdJcX9xcMKr5+7k8l1sndeZ6lDmUP8aRBOg9j55dcbh7puPJm8 2WXZT9evnZXAjM7ds89X765eXV856pZ+7c/u1EHAD5sHhxKHBFM/mpLQ+XJzyQEd/Ow2m/3/ TparLJ8n52mRnc8Oi0Wy3Jxn88P04lDsLjazf/B/i116UTwVFz9ffbj6/PbScXIvYpPJNlnn 6dQpZovlobi/zdf7bLdOllMnTR3X+Z//cVYzx/2WhizLUldeSNd7h3quP5n8/OGLczefOeyc nBPnv2U1/s/kcrN92uV393uU1OfVc643i/1jAgp8szms58k+36xfOm/X6fnk59c/OXnhLDBV IVO9BGU/ZDtQ+uzJ2d9nDhb1c7bOdsnS+XSYLfPUeZen2bqApMl67jxtDg7kmzxmy3Szypz9 xknvk/Vd5uR7THCx2TnzvNjv8tlhnwH6Ns8KZ7PA2yBPtnPSbLdP8jXcWs9zFK84n9w8bTPn T8X95hFzPOXruz8hMnoAClVLeg/iYj2SWbFZQhnLJ2e9caAyu2S9f3IWIADU9NxxNFB190/8 9jwDAZYcC3BQLY9JgYUs8rsD6gJ+/QntdrZKdmm2PEOVzYr5n87PzyeTL+tdlsyd7WaHEmHV UMSvYM9s6ayyokhAGegf2W5qZ/d0e8jnzo+OO/my3eerbOqwOSX3XrgibjH5dP9U5GmCZa42 u6cp+AANnPc/TV5DKwINQvMg8BOu+wzxwLt9h8SRQyLqEAZtJ3Ad4sE1Atdc6kTMCV0n8B0v cih1wGs/Q0URqXhazTZLdJ3NyrmYQWO4EPW9SNJ0cXu/32/Pv25AO0dmkMkg43yzzs4n4u+7 TTIHI5QYYLFOiBEiYtTYZ6vREurpTxNQQxgh33YxVjKR8jSZeN4R0uSL230yWldV6tOkKvNP /uw6zhxSg+86L35wICBvwf3P76fgvRP47zv5E+K0UxzSe2eRLzOHB5tdlu6hAZxPvoOoIpJN XnyFePmD04v6Z+Jg23OjMF2w0IHMKJrzAgLGfvMjZS7PUIvqKDb/c1vcH/bzzeP6PJ36BLCo wppT6I1QEGz5zovFav/jb8kuT2Yg7p/g158wdq2hnOQBghBePp+MLCgI48mfPVnQPMzCDAtq xhbnRTH7EZKwwA2CWfrDBDswI/4h36a3xSb9CtEK4CPqT/7sl/CLgAj4XbbMkiLrKuAldCbq pz/3x5fneVCdoCpvFony5hl0H5unZyuGhZM/M1VMHMdCaxveD76ogw4AZnvAYx6d/DkUePEi Secu4u3T7e3+sdgnO/Cg/RZBZyRZuK5rlnSd7XP474Lng9j+mOQITmN38udIgmfz1E8U+Hxz W2R3qww6hxcrhA/mjMxd9yV0P/DTb+jnpcOLrUny0pnvNtvb+/luma1/9DErfoF/8+1+U/zo Ov/2f7v/Blfz2yXWdv6jNyx8vt4euOSMgV5iJfrC80u98CRNqTeLhfsjHaEdVQB0UaAb4ooC IppQrpvciN8Pm1eoYRgAKBGgNGMpb7yYsNjdApHZJvv0/hYAnBfb3QbiAkFFH4AWoN5GFXkh 0KCwmIArEqoKi5lrKEwr6Eh4AiQQ8D2Jz1LKW3AG/ATgs9Xhm/MiX3CPCEJKU3d0DSBOc5Ti MMOCohiV5styQhJ6VTnSGM9SThhgfQJeTghNY8bL2WW3u28Z8K4XRSrK8Ofcu3ffbtfbr/sC S+4oZJ49XOwyLAeGEqCxOEKLMFlCkoSqBAh20DUVX50Xye6uVsp6m62xW/yRjCqCUpdAEaGI P7OALChvF4D9xyE7QF0Oa+cF/8qLYQvgYx3S82iEurkts2MJGEeBw8kCPM+rF7BIir0oBfrB 1VO3cszwPsWuMhbwgb9IZrzZrfe72+wBwtFt9i1LgYffwjBgvgTbgQPzmgQ+CxcRBBdRsZCk YW/FeHeHuGgYwsDFqCtLZYEvSt3fI/mG8LTZVpYJ/IAm45HDCJCJRKbpgjcSoCZfoSYwSnkB nHq5Oex/lEX7mev8VS/4bzK21ot/CfQoWWFVsyAMw7kX9fXqWBw2JN8DWURAmMVkRt1Slj2g bTdLiFeSudSQcHQi/mTf0myLI5HzYkpDVzGfyeTsmT6TbeGcJd+WE6j0l7evoeKf8O8n/Hv5 6Yvz6fNb58NbuPzb9X/B38/X18773y9/efXBub55dQPDsBtHfG7evr9yLj++f//qw2uuQNep /8X/oublM5H59bsC/v6v/+U4nk9DFscwSGfnMGT6b0El/4+GSHTEkPF/aAxxV1zGrraGSELi BZHvTgnliPk63+t4VMc765bQkXhnNHIhtnvh9MwLzoPA+e870VR0UO9I0IiAL1J36vpcxrvb w1aH84+WMQbH9SiZnvmelBFppo4ZaJhnhDUx03R2W6QaJlycui4X79sWwuf9bq7DsX44NAs4 fwXn+ZE39SOOV6R76LOBfyYaYKjX2febgNtimWXbul1iPwrBdc68mNd5C2P1eQLj57UGG/XL 2YKl1FOe87ASaHq1Y13KsA13989st9HgCPWiiDHgrRwSRcQUGiTRm4xBwuQwz/e3ZsPwezqW 3ligIXQ4zueqtsRljLl06gtHzCHm63h6YzkDgmPG+73CCyMS+l6g6othWsfT24mhri3HhoYX uixUcE/Jbrd51AH1lnLGWl7TbikwTvG8MIjBawj3mkMx0wH1ZjLKDUnIXN/3aQkIA5WW3xDW D1s8rdNspzcXiGGBTykMEzmoSKAj6u3FoMqH5e7wuK8hxjB4iqJpICLEwxpS6IDRgIhzHJnq rh0y4keBNw2EcXAWcp5tIZUGGveDLpabx3RZAw084Af+1BceLhJkyTorQYn0IuLojZBAPmWj 5FBkYPRCgVI3jP2yzcz/gZ3M/p9V3X1G+sXcLvaruhvhFC1jvld2CtvF9rC70xoPi0NdzCDk /3g0Ui5bwEg83WtiAqlyMfzIKDm/T5e56mcY+mVYr7mUsw/SA/ISxGRK/TYklzL0jMqMoqgT 0nchoEUlZPag9QtRGJkk9PxOCc9AQtfzIIqTWHp6sdzcCcwAhYti0sb0Is9V1vn6B5/DrTDD MEIeN/VEHF8Dk6tkJK4Upi5j7EVul4xBHLiUeVNXGGa9mtXgDFUmvss6NUhBODdwPeWRRR0v 8krUXjynbDMUGBRTBqmjETc0VNaPmDKI6hIqgzCfBXHsgkGEZ6/3Wx2QmLSnWbgFSCPqQzij ZR+4ecx2OqJnROzxaqA7YRyHYdX6dvtkzv0QRs0UMUODz/RjekAqIRvQvEA4IjQWveLU6DZA axRkyw3PGPMCFtKSoKxg7CaCOKEB/0NK4F7I0tRnEQQIP6qM88fqTvQKjHJAajROTLtk9MCx g7h0RQh022//Z8KCAI1ClL7qeAy8s0uNnk/8IHLdKRWd4QbG1w9b0RViTCG0HhZlwPEYVZCK 0Jd1jiI/9EnZWO4rLJ9UiKV4sRcHqrpFfgdwelOBhoSMZ0pFU149FX8sNSP7QWCocOiX0q2T dbHcaogBi1wI9SrWbLPdUoNjhoBN/LC0xwEXw/SuCmrDKAwMZB8wS9LDMjlb6CJGBteG8Ynf Gb7OIF77DHr+s0AYBZdbaoisxK0qHURx2aHmUC3dDWnEIug0lZS7zT7ZZxC1Cw0zPBITqERI Q8W9jZDRkZA
