Re: devel/jenkins port not starting. Kernel panic in IPv6 multicast code

Hello, On 29/09/2013 20:42, Rui Paulo wrote: On 29 Aug 2013, at 13:47, Craig Rodrigues wrote: Thanks for the analysis. It looks like the mailing list is dropping my attachments, so I uploaded my log files here: http://people.freebsd.org/~rodrigc/jenkins-problem/ I don't understand where to

Re: Question about MLDv2 implemenation in Kernel

Hi, Regarding RFC 6636, I don't know anything about it. It wasn't published until last month, so MLDv2 in FreeBSD came 3 years before it. On 21/06/12 14:16, GuYong wrote: > > > My reading of it suggests that we are doing the right thing. We do > > > accept it and process it, but, like the text im

Re: Question about MLDv2 implemenation in Kernel

All, I'm working on something new just now,and am in a conference, but here is my 2p. On 20/06/12 22:20, Rui Paulo wrote: > On 20 Jun 2012, at 01:12, GuYong wrote: >> 1. RFC3810 clause 6.1 mentions there is a Source Retransmission Counter >> associated to each source, so that the merged report

Re: Deferring inp_freemoptions() to an asychronous task

rk, having started a FreeBSD-based project with no infrastructure. "Of course it runs ZFS." John Baldwin wrote: > On Monday, January 09, 2012 10:23:48 am Bruce Simpson wrote: >> You've also stumbled on the behaviour specific to how BSD has >> traditionally dealt with

Re: Deferring inp_freemoptions() to an asychronous task

John, Sorry it's taken me so long to reply. No objections in principle to your change, but this seems to point at a more general issue with modern network controllers. You've also stumbled on the behaviour specific to how BSD has traditionally dealt with broadcast/multicast sockets. The pcbinfo

Re: Intel 10Gb

On 05/09/10 14:43, Barney Cordoba wrote: Blah, Blah, Blah. Let's see some real numbers on real networks under real loads. Until then, you've got nothing. But that's also blah blah on your part, Barney. As long as the peak throughput under load in testing is above the median range for the

Re: Traverse Solos 4-port ADSL card

The way these things generally work is they have an ADSL2+ MAC in front, and a Realtek-like Ethernet chip on the PCI bus, with a little microcontroller and web interface. The multi-port ones don't; generally they use native encap. A Linux driver will certainly not work and need to be rewritten

Re: 3-Line MLPPP DSL on BSD - MTU/MRRU/MRU??

On 04/22/10 18:14, Carrick, David wrote: The config works - just don't think it is optimal. I structured it based on the mpd5.conf.sample and some other configurations stolen from dslreports.com. I am looking more for advised MRU/MTU, and MRRU values for the links and the bundle as a whole as

Re: kern/145905: [fxp] multicast packets aren't received when PROMISC mode on fxp.

Spooky http://en.wikipedia.org/wiki/Cisco_PIX Some Intel-based Ethernet cards for the PIX are identified at boot with the designation "mcwa". This designation denotes a multicast receive bug in the card's

Re: Poor situation with snmp support in FreeBSD

On 03/26/10 04:58, Alexander Bubnov wrote: Hello Harti and freebsd-net maillist! One more question please in scope of snmp topic. does bsnmp support master agentx mode? I totally agree that would be a good way to go, but it's a case of someone having time to sit down and finish things off

Re: why zero-copy sockets(9) are not popular?

On 03/20/10 10:06, Alexander Bubnov wrote: Hello, all! Anybody knows why zero copy is not popular although this technique allows to increase performance of servers? It is very hard to find any examples of zero-copy for FreeBSD. Transmit is easy. Receive is hard. The whole concept of zero-

Re: Tunneling in freeBSD

On 01/30/10 04:11, Nazeem نجم لدين wrote: hi, Can you suggest way of getting a multicast tunnel work. The assumption is that there is a unicast cloud in between two mbone networks. So we need to forward the multicast traffic over the unicast tunnel. Application is for video transmission. J

Re: MROUTED: Problem with vif installation

Tunnel support for MROUTING was removed several FreeBSD releases ago. We followed OpenBSD with this change because DVMRP's older, naive IP-in-IP encapsulation mechanism doesn't offer any benefit, and can't be administered. Also, PIM doesn't use it, and PIM is now the industry standard. thank

Re: Ralink 28xx series drivers?

On 01/28/10 06:08, Bruce Simpson wrote: ... moonlightakkiy maybe-at yahoo.ca is working on a port of Damien Bergamini's run(4) driver for OpenBSD right now. I should know better than to cut and paste email addresses in an environment where there may be spam clams. My apologies, Akinor

Re: Ralink 28xx series drivers?

On 01/28/10 01:26, Brett Glass wrote: I am trying to make FreeBSD 8.0 fully functional on an ASUS mini-workstation that seems to have a Ralink RT2860 card inside. The "ral" driver for FreeBSD doesn't recognize the card. Apparently, OpenBSD does have a driver for this chip. Is anyone porting it?

Re: MROUTED: Problem with vif installation

Did you remember to kldload ip_mroute or build your kernel with 'options MROUTING' ? ___ 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: What's the proper way to traverse a getifaddrs() interface list?

On 05/01/2010 02:05, Peter Steele wrote: 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

Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy

Andriy Syrovenko wrote: Perhaps Florian can shed some light on your IGMP issue? igmpproxy only understands IGMPv2, afaik. Yep, it is igmp v2 only indeed. The only other thing I can think of is: is this an igmpproxy issue, ie. is the IGMP traffic which is causing problems, coming from

Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy

Andriy Syrovenko wrote: I have switched to 8-STABLE. Kernel does not seem to crash anymore, however IGMP still does not work. tcpdump complains that outgoing IGMP report and leave packets have incorrect checksum- it is always 0. Though I'm not sure weather it is IGMP checksum or IP checksum that

Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy

Andriy Syrovenko wrote: Is it planned to be MFCed to STABLE? Or, could you possibly point me into the right revision in HEAD, so I could merge and test it locally? Actually I did already MFC most of my changes to stable/8, just not releng/8.0. There were a few things to do with IGMP packet

Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy

I believe this *may* have been fixed in HEAD, but was one of the things which couldn't be MFCed due to the RC freeze... ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "free

Re: generating routing message on LL address change

Harti Brandt wrote: Hi all, I would like to commit the following patch. It generates an RTM_IFINFO message when the link-layer address of an interface is changed. This should be no problem for routing daemons, because the same messages are also generated when other interface state changes. Ar

Re: [PATCH] CFR: use refcount(9) in mcast

After discussion with jhb@, no real need for it. The atomics add instructions which aren't needed as all accesses are covered by a mutex. cheers, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsu

Re: [PATCH] CFR: use refcount(9) in mcast

Bruce Simpson wrote: Look OK? All accesses are covered by a mutex, so the atomic ops aren't really needed -- but it makes for clearer source. Missed in mld6.c. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/lis

[PATCH] CFR: use refcount(9) in mcast

Look OK? All accesses are covered by a mutex, so the atomic ops aren't really needed -- but it makes for clearer source. Index: netinet/in_mcast.c === --- netinet/in_mcast.c (revision 199528) +++ netinet/in_mcast.c (working copy)

Re: Native support for AutoIP (aka LLA, RFC 3927).

Martin Garon wrote: I need to implement AutoIP in my embedded FW that uses a snapshot of FreeBSD 4.4 network stack. Fredrik Lindberg (shapeshifter.se) implemented some of this for FreeBSD as part of an earlier Google Summer of Code, but I haven't found any free time to integrate it. The

Re: kern/137164: [netinet] [patch] assert panic imo_match_source()

The following reply was made to PR kern/137164; it has been noted by GNATS. From: Bruce Simpson To: Stef Walter Cc: bug-follo...@freebsd.org, jha...@pangolin-systems.com Subject: Re: kern/137164: [netinet] [patch] assert panic imo_match_source() Date: Tue, 06 Oct 2009 17:56:54 +0100 Hi Stef

Re: kern/133786: [netinet] [patch] ip_input might cause kernel panic

The following reply was made to PR kern/133786; it has been noted by GNATS. From: Bruce Simpson To: freebsd-gnats-sub...@freebsd.org Cc: Subject: Re: kern/133786: [netinet] [patch] ip_input might cause kernel panic Date: Fri, 18 Sep 2009 16:40:20 +0100 Interesting... the input checks in

Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy

The following reply was made to PR kern/138666; it has been noted by GNATS. From: Bruce Simpson To: freebsd-gnats-sub...@freebsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy Date: Sun, 13 Sep 2009 02:04:52 +0100 I did a

Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy

I did a quick pass over ip_mroute.c to see if I could have introduced any obvious errors during refactoring; didn't see anything obvious. The backtrace which was posted points towards a trashed rte->m pointer, assuming it's accurate and the arguments didn't get trashed on-stack. The MFC lock s

Re: [patch] Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP

Stef Walter wrote: ... Patch is attached which fixes the problem. Is this the right approach? If not, I hope it helps highlight the problem area. Good catch; thanks for the fix. I used to depend on imf being initialized to NULL in this function, however, I opted to keep the old vector-styl

Re: Panic in imo_match_source (netinet/in_mcast.c)

Shteryana Shopova wrote: Hi, I actually managed to get the same kernel dump using the following sample code - http://people.freebsd.org/~syrinx/mcast/mcast_crash.c and the crash is 100% reproducable. A temporary fix is here - http://people.freebsd.org/~syrinx/mcast/in_mcast.c-20090908-01.diff bu

Re: Panic in imo_match_source (netinet/in_mcast.c)

[Brief reply as I'm meant to be doing a zillion other things...] Bruce Simpson wrote: Full OS version, dmesg, panic and backtrace please, when reporting this kind of issue... otherwise folk can't help. Are you using SSM multicast features? P.S. You might want to try demoting the

Re: Panic in imo_match_source (netinet/in_mcast.c)

Stef Walter wrote: Stef Walter wrote: On a new VPN server, running OSPF, I'm experiencing regular panics at: imo_match_source: !AF_INET BTW, src->sa_family is 0 Moved back to FreeBSD 7.1 i386 and the problem goes away. Full OS version, dmesg, panic and backtrace please, when rep

Re: kern/134931:[route] [fib] Route messages sent to all socket listeners regardless of setfib

Stef Walter wrote: I agree in principle with Mark that having future route messages might be able to let routing daemons differentiate between various fibs and manage them, and that this might be a feature However any implementation of that would likely break API and ABI, and very probabl

Re: native vlan

Graham Smith wrote: Networking folks Nothing to do with freebsd per say, but can someone tell real life scenario requiring creation of native vlan (vlan 0) and why native vlan are most suitable for this scene ? Assuming you're referring to what's in the 802.1q header: it's what 802.1p puts i

Re: net.inet.tcp.keepidle and friends

Brian A. Seklecki wrote: All: The description on this sysctl was just recently added in -CURRENT. It was missing during all of RELENG_6 and RELENG_7? Do we not trust it entirely, ergo the two hour initial threshold and lack of documentation? I believe this has just been down to a lack of

Re: mld_mtx lock order reversal

Michael Tuexen wrote: Dear all, when doing a ifconfig gif0 down ifconfig gif0 -tunnel ifconfig gif0 destroy I got a the following message on the last command. Is this a false positive? See comments in mld6.c. Some LOR warnings are unavoidable at the moment because of INET6 locking; the worst

Re: Wrong multicast destination IP

Hi, It sounds as though you are in fact running into a regression in the ARP cache code. Please see recent threads on current@, this is a known issue. Unfortunately I can't assist other than providing advice, I am very busy at the moment. ipre...@freebsd.org wrote: In recent current kerne

Re: How to change default source address?

luc...@lastdot.org wrote: Hi guys, I need to change the default source address on a freebsd server. My situation is somehow similar to this (http://marc.info/?l=freebsd-questions&m=122535960804508&w=2). In linux i can easily do it like: ip ro replace default via 10.10.10.1 src a.b.c.d (where a.

Re: em driver doesn't set multicast ethernet address

ipre...@freebsd.org wrote: I placed config in sysctl.conf and rebooted but mcastread still generates IGMPv3 membership report. Am I missing something? Only other thing I can think of right now: Are any multicast queriers/routers present on the virtual subnet? I'm tied up, so probably can't

Re: em driver doesn't set multicast ethernet address

Hi, Thanks for the feedback. ipre...@freebsd.org wrote: Well, now, something really interesting happened. I changed default IGMP version via sysctl # sysctl net.inet.igmp.default_version=2 but, then I tested it with mtest and generated packets were still IGMPv3 Membership reports, but first t

Re: em driver doesn't set multicast ethernet address

ipre...@freebsd.org wrote: While testing -CURRENT in VMWare environment, I discovered that em driver doesn't properly set destination address in Ethernet header. In the other words, when I start listening multicast session with mcastread (mcast-tools), kernel triggers IGMPv3 packet. Its destionat

Netconf / Yang model support?

Is anyone in the FreeBSD community working on NETCONF support? information here: http://en.wikipedia.org/wiki/Netconf Interesting that SSH is a mandatory transport. Note: This does NOT appear to be the same as Debian's netconf effort, but I could be wrong: http://netconf.alioth.debian.o

Anyone working on RNDIS support?

Hi, Is anyone out there working on RNDIS driver support for FreeBSD? For the uninitiated: RNDIS is a movement towards unifying device support, mostly instigated by Microsoft, where the hardware specifics of dealing with a device are pushed onto the device itself, perhaps using a microcontroll

Re: RFC: convert net.inet6.ip6.{accept_rtadv, auto_linklocal} to per-interface flags

Hiroki Sato wrote: The ip6.autolinklocal had been enabled but disabled since 6.2R by default because automatic configuration of L3 address is insecure. However, it makes IPv6 configuration complex because of no link-local address on an interface. Malformed address configuration can be happe

Re: TCP bug?

Andre Oppermann wrote: ... 2) in old T/TCP (RFC1644) which we supported in our TCP code the SYN/FIN combination was a valid one, though not directly intended for SYN/ACK/FIN. T/TCP has been superseded by SCTP, and should be completely deprecated in the stack, IMHO. I believe this has bee

Re: Bridging and stp question

Jedrzej Kalinowski wrote: pluknet pisze: 2009/5/28 Jedrzej Kalinowski : Is there any way to configure the bridge to add stp protocol to any added (via ifconfig bridgeX addm ifX) member interface - so to change the default behaviour? Or specifying it explicitly is unavoidable? L

Re: kern/134931: [route] [fib] Route messages sent to all socket listeners regardless of setfib

Julian Elischer wrote: Stanislav A Svirid wrote: So, how routing daemon can decide in what FIB route is changed? Or it can't now? I believe there is a field that has been used for this purpose in OpenBSD, but is otherwise deprecated. anyone woth ore knowledge of teh protocls is invited t

Dialer for UMTS/3G modems

Hi, Does anyone have a UMTS/3G dialer for FreeBSD which: a) works, and b) preferably has a GUI? Perhaps mpd has grown hooks for this sort of thing? thanks, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-

Re: kern/134931: [route] [fib] Route messages sent to all socket listeners regardless of setfib

lini...@freebsd.org wrote: Synopsis: [route] [fib] Route messages sent to all socket listeners regardless of setfib That might actually be a feature, however, the "API contract" with the multiple routing table support might not have covered this, so it might be "undefined behaviour". __

Re: Deleting a TAP interface

Asheesh Jadav wrote: Hi, I'm able to create the TAP interface, lets say with name 'test', and bring it up, but when I try deleting it using ioctl(fd, TUNSETPERSIST, 0) It sounds from your interface name as though you are using a Linux system, and I can't find this ioctl documented anywh

Re: Can pfsync be used over router or WAN?

Sam Wun wrote: Establish a IPSEC bewteen this 2 pfsync points is a way to go. Yup. The key observation about pfsync is that you can configure the peer(s) for synchronization in the 'syncdev' mode or the 'syncpeer' mode. Unlike CARP, pfsync(4) has no authentication built-in. With syncdev,

Re: IPv6 duplicate address detection

Bob Van Zant wrote: > Well that goes all the way back to my first email :-) > > "An alternative view on this is that I shouldn't be sending out any packets, > especially unsolicited NAs, using or referencing a tentative address." > > This makes sense. I'll stop doing bad things now :-) Thanks for y

Re: IPv6 duplicate address detection

Bob Van Zant wrote: I'm working on a piece of software that, among other things, allows an administrator to easily configure IPv6 interfaces on a FreeBSD host. I've run into a problem where whenever I reconfigure an interface with an IPv6 address FreeBSD marks the new address as being a duplicate

Re: Request feedback on IPv6 multicast listen on ::

JINMEI Tatuya / 神明達哉 wrote: I believe you can safely remove it. The KAME repository version of that code was already deprecated long time ago. Thanks for clearing this up. I couldn't find anything which referenced the code, and as you pointed out its implementation was not complete, so I wi

Re: CARP as a module; followup thoughts

Will Andrews wrote: Thank you very much for your feedback. I have implemented your suggestion as follows: http://firepipe.net/patches/carp-as-module-20090503-2.diff Great stuff. Overall this does make things that much cleaner. This version doesn't reinvent the wheel as far as registering

Request feedback on IPv6 multicast listen on ::

During the MLDv2 refactoring, I removed some old KAME code which supports the ability to listen to *all* multicast groups. It isn't clear to me whether this code was still in use, and I couldn't find information about it in the normative RFCs (2292, 3542) for IPv6 stack implementation. This ca

LOR in ip6_output() and MLDv2

Hi all, There is a Lock Order Reversal in ip6_output(), which is triggered by the MLDv2 code. What's the best way to resolve? IF_AFDATA_LOCK could be changed to an rwlock, that might help get rid of it -- ip6_output() will take an exclusive lock by way of in6_setscope(), which is needed as

Re: Network Card

Kaushal Shriyan wrote: ... so there is no such command line utility to get to know about that information on Free BSD ? There is no sure fire way to get that information anywhere, unless you're working with a system which has implemented PCI geographical addressing. Some of this is present

Re: CARP as a module; followup thoughts

Will Andrews wrote: I'm sure most of this sounds like rambling from a crazed lunatic or something, but I'm also sure most who understand my patch agree that it isn't the nicest of ways to make it possible to load carp (or any other protocol) as a module. Not at all. It is a mess to be sure.

Re: ae on freebsd7.1

Sergey Vavilov wrote: Hello guys! Somebody overcame the problem with Attansic L2 (http://www.attansic.com/english/products/index.html) fast ethernet interface on Freebsd-7.1-RELEASE? Thank you! I've seen this happen after a suspend/resume cycle on the ASUS EeePC 701. It looks pretty normal,

Re: OpenSSL DTLS bug fix patches

Michael Tüxen wrote: On Apr 16, 2009, at 2:19 AM, Bruce Simpson wrote: ... That's excellent news, and these fixes look good, but I was more wondering if this drop would be in FreeBSD 7.2-RELEASE :-) I know, but I wanted to make the state of the patches clear to make the decision for the

Re: OpenSSL DTLS bug fix patches

Michael Tüxen wrote: Hi Bruce, at least one member of the OpenSSL core team (Steven) has integrated our patches regarding bug fixes in the source code. So they will be included in the next release of OpenSSL. That's excellent news, and these fixes look good, but I was more wondering if this

Re: MD5 authentication in quagga

Алексей Блинков wrote: If modelling ideal situation, then: md5 password doesn`t match or empty, then peering must be closed... Now md5 working only for outgoing packets, not for input. And peering not closed if password miss or not match. because bsd not check incoming packets, i think...

OpenSSL DTLS bug fix patches

I know it's late in the 7.2 game, but does our OpenSSL maintainer know about this? http://sctp.fh-muenster.de/dtls-patches.html It would be nice to have in a release, although I'm tracking branches for anything I'm doing at the moment. JFYI, BMS ___

Re: Multicast routing

Upakul Barkakaty wrote: Hi all, I was trying to setup a multicast tunneling setup with freebsd, with the mrouted utility. However, my multicast router doesnt seem to be forwarding those multicast packets. It would really be helpful if someone could help me with the setup or the mrouted.conf fil

Re: if_ath

Bruce Simpson wrote: I believe Sam removed the HAL_ABI_VERSION define in the -CURRENT branch so you should not need it. Please see here for the relevant change (MFC was set to 1 week):- http://svn.freebsd.org/changeset/base/190096 thanks BMS

Re: if_ath

Hi, I have been doing repeated build runs of RELENG_7 using NanoBSD, and haven't seen this issue. How exactly are you building the kernel? Are you using 'make buildkernel KERNCONF=...' ? Do you have any old ath(4) build options present? I believe Sam removed the HAL_ABI_VERSION define in the -C

Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem

The following reply was made to PR kern/122839; it has been noted by GNATS. From: Bruce Simpson To: Eugene <4...@legis.krsn.ru>, freebsd-gnats-sub...@freebsd.org Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem Date: Thu, 19 Mar 2009 17:47:38 + Hi,

Re: 802.1x broken after SVN rev 189592

Hi, Based on the backtrace you've provided, this doesn't seem like a multicast related issue. I skimmed wpa_supplicant and I see that whilst it requests a link-layer multicast address, it does not use IPv4 multicast. Vany Serezhkin wrote: Hello. I do not really sure in this, but : after t

Re: ae(4) Wake-on-Lan MFC

Stanislav Sedov wrote: So, basically WOL works on 7.1 with ae and the PC resumes correctly? That's what I saw. Video is still broken for me on resume, though everything else on the EeePC 701 resumed OK. cheers, BMS ___ freebsd-net@freebsd.org mai

Re: ae(4) Wake-on-Lan MFC

Pyun YongHyeon wrote: Do you have ae(4) hardware? I'm not sure why stas@ removed WOL part in the MFC but it could be lack of testing(CCed to stas@). I've attached diff that includes WOL support from HEAD. Thanks. I tested this OK on the EeePC 701 so I've committed it! cheers BMS __

Re: IGMP+WiFi panic on recent kernel - in igmp_fasttimo()

A suitably kludgy fix for this issue has now been committed to HEAD. ___ 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: IGMP+WiFi panic on recent kernel - in igmp_fasttimo()

Coleman Kane wrote: If you are looking for a reliable test case, this might be it for you, but I think you need a wlan interface to test it with: * Install net/avahi from ports * Set avahi_daemon_enable="YES" in rc.conf * Configure VAP params for wlan0 card in rc.conf * Log in and run "dh

Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work

The following reply was made to PR kern/132722; it has been noted by GNATS. From: Bruce Simpson To: Matthias Apitz Cc: bug-follo...@freebsd.org, freebsd-net@FreeBSD.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 10:39

Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work

Matthias Apitz wrote: as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. I tested

Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work

Hi, One crucial piece of info missing is exactly which Atheros part you are using, can you please attach this to the PR? you can get this from pciconf -lv and look for the ath0, also please post your boot time dmesg / or when you insert the part. thanks. Matthias Apitz wrote: The following

Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work

The following reply was made to PR kern/132722; it has been noted by GNATS. From: Bruce Simpson To: freebsd-gnats-sub...@freebsd.org Cc: lini...@freebsd.org, freebsd-b...@freebsd.org, freebsd-net@FreeBSD.org, Matthias Apitz , Sam Leffler Subject: Re: kern/132722: [ath] Wifi ath0 associates

Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work

Hi, Can you please try cvsupping RELENG_7 sources to after this date: %%% Date: Thu Mar 12 03:09:11 2009 New Revision: 189720 URL: http://svn.freebsd.org/changeset/base/189720 %%% The Atheros open source HAL from HEAD was MFC'd and this may or may not fix your problem. thanks, BMS ___

Re: IGMP+WiFi panic on recent kernel - in igmp_fasttimo()

Sam Leffler wrote: It is the same issue but the root cause is unclear. There is much code that does assumes ifma_protospec might be NULL and checks for it. In my case (creating a wlan ifnet and then destroying it on eject) the patch below is sufficient. I don't care to dig right now to unde

ae(4) Wake-on-Lan MFC

Hi, I noticed that ae(4) got MFC'ed to RELENG_7 before Wake-on-Lan support did. However, WOL support is now there, and it looks like the change can just go in: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ae/if_ae.c.diff?r1=1.1.2%3ARELENG_7&tr1=1.1&r2=1.3%3AHEAD&tr2=1.3 I am tied up

Re: IGMP+WiFi panic on recent kernel - in igmp_fasttimo()

All I have in the kit box is what appears to be a Belkin branded Ralink cardbus card. I think it's a Ralikn 25xx. I have a PCI-Cardbus bridge, so I'm going to leave a NanoBSD image of SVN HEAD to cook in the background whilst I sort out my humanity... __

Re: tap(4) SIOCSIFMTU patch

Sean C. Farley wrote: ... Exhausting the jumbo cluster pool refers to kern.ipc.nmbjumbo[p|9|16], yes? em(4) has an upper limit of 16114 for MTU. I could limit the MTU to TAPMRU (16384) which is the limit for a write to the driver anyway. Just waiting for my VFS cache to spool up after a fres

Re: IGMP+WiFi panic on recent kernel - in igmp_fasttimo()

Thanks for this report. Sam has reported wihat I believe is the same issue. I haven't had a chance to look at this yet, I'm absolutely exhausted from working on some other stuff that had to happen right away. ___ freebsd-net@freebsd.org mailing list ht

Re: tap(4) SIOCSIFMTU patch

Sean C. Farley wrote: Yes, this fixes my issue with bridging a tap device to an interface with an MTU higher than 1500. I will probably commit this patch this weekend. I can't think of any reason why not, other than you might want to ensure that tap's MTU is bounded within reasonable limits

HEADS UP: multicast forwarding ipv4/ipv6 split and fine grained locking patch

Hi all, If you look at this URL: http://people.freebsd.org/~bms/stage/mrouting/ ...I have two patches which considerably clean up IPv4 multicast forwarding. Summary of changes: The ip_mroute.ko module is also split into two, and the dependencies between IPv4 and IPv6 are untangled. BSD con

HEADS UP: IGMPv3/SSM committed to IPv4 stack.

Hi all, Support for IGMPv3 and Source-Specific Multicast has now been committed to FreeBSD-CURRENT. At this point, the code is believed to be in a 'late beta' state suitable for more widespread testing. There may be some issues with recorded-source processing. Folk running multicast-enabled

Re: implementation of mDNS

Sailor Siraj wrote: Hello everyone, I , Sailor Siraj - a computer science student from India, am quite interested to implement mDNS in FreeBSD as my gsoc project. I have done quite study in this field. Before submiting my project idea I needed to confirm if there is any previous or ongoing wo

Re: HEADS UP: IGMPv3/SSM: alpha code drop.

Alexander Leidinger wrote: ... Is this supposed to make multicast work in a jail? In the past I tried some simple tests (e.g. mtest(8)), but I wasn't able to receive anything in a jail (this test was triggered by the fact, that some avahi-tools from the avahi port didn't showed an expected res

Re: HEADS UP: IGMPv3/SSM: alpha code drop.

Bruce Simpson wrote: From an architectural standpoint, the most important wide-ranging change that this makes to the IPv4 stack in FreeBSD, is the change which takes the IN_MULTI_LOCK() out of the ip_output() and ip_input() paths. Filtering of inbound multicast traffic is pushed up to the

HEADS UP: IGMPv3/SSM: alpha code drop.

Hi all, I am making patches available against 8-CURRENT to do IGMPv3 and Source Specific Multicast in the IP stack: http://people.freebsd.org/~bms/stage/igmpv3/ At the moment, the patches are extracted from Perforce, so may need some rejigging of patch's -p option. I would hope to post

Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed

Robert Watson wrote: .. Just a reminder that 1 March is gradually approaching. It looks like the new USB stack is settling nicely, so I currently have no plans to defer the above schedule. Just to say: this is good news for 8.x, particularly for VIMAGE. Losing the Giant lock from the netwo

Re: HEADSUP: arp-v2 has been committed

+1 for introducing RTF_LLINFO backwards compatibility. I had to sneak in a fix to XORP and pretty much broke release protocol to do so. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send

Re: ipv6 bugfix, need review.

Alfred Perlstein wrote: The traffic class byte is set to 0x in the header of some BGP packets sent between interfaces that have IPv6 addresses, instead of the correct setting 0xc0 (INTERNETCONTROL). Content free argument: Feels right. I had to commit a man page diff to docu

Re: NATM hardware available

Bruce Simpson wrote: Robert Watson wrote: ... Do we have any of the necessary software parts to do simulated ATM hardware similar to what if_tap does for Ethernet? Using the VIMAGE stuff and virtual ATM hardware might open up the door to a more accessible development and test environment

Re: NATM hardware available

Robert Watson wrote: ... Do we have any of the necessary software parts to do simulated ATM hardware similar to what if_tap does for Ethernet? Using the VIMAGE stuff and virtual ATM hardware might open up the door to a more accessible development and test environment. I did the NATM locking

Re: HEADSUP: arp-v2 has been committed

Hi Ian, Well, yuletide and new year is a good time to clean out the cupboards, so... without further ado... Ian FREISLICH wrote: ... Do you have applications which do not explicitly specify the interface address to use for multicast group joins? If they do not, that's a bug in the applica

Re: HEADSUP: arp-v2 has been committed

Ian FREISLICH wrote: You can add net/quagga to that list as well. net/xorp got bit too. XORP doesn't do anything with the RTF_LLINFO information, so I have checked in a 2 line fix to the XORP repo. The ability to turn off ARP, or redirect ARP processing to a userland daemon, would be in

NATM hardware available

Hartmut Brandt wrote: In any case there is still an Todo on my side: the routing information for NETNATM is currently lost somewhere between L2 and L3 :-) I guess I come back to you in the new year to fix this issue... Have to fetch my ATM equipment from the corner where it is collecting dust

  1   2   >