UDP socket disconnect problem
Hello, In Linux, I can disconnect the socket using: sa.sin_family = AF_UNSPEC; val = connect(sockfd, (struct sockaddr *)&sa, sizeof(sa)); the return value of val is 0; on freebsd, the return value of connect() is -1. According to Linux's connect(2) man page: Connectionless sockets may dissolve the association by connecting to an address with the sa_family member of sockaddr set to AF_UNSPEC but FreeBSD's connect says: Datagram sockets may dissolve the association by connecting to an invalid address, such as a null address. I try to convert above code to memset(&sa, 0, sizeof(sa)); sa.sin_addr.s_addr = htonl(INADDR_ANY); val = connect(sockfd, (struct sockaddr *)&sa, sizeof(sa)); the return value of val still -1. Any idea? Thanks. Regards, Dave. ___ 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: Re: VIMAGE + NDIS
On 9/27/10, Julian Elischer wrote:
> anyone here have NDIS experience?
>
> On 9/27/10 10:51 AM, Nikos Vassiliadis wrote:
>> Julian Elischer wrote:
#10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0) at
/usr/src/sys/net/rtsock.c:1374
1374if (V_loif)
(kgdb) list
1369}
1370*(unsigned short *)(tag + 1) = sa->sa_family;
1371m_tag_prepend(m, tag);
1372}
1373#ifdef VIMAGE
1374if (V_loif)
1375m->m_pkthdr.rcvif = V_loif;
1376else {
1377m_freem(m);
1378return;
(kgdb)
>>>
>>> ok so probably there is a code-path to this point that does not first
>>> set up the current-vnet pointer before doing this.
>>> what you need to do is to produce a stack-trace so we can see how
>>> it got here,
>>> and then we can figure out where on that path we should set the
>>> pointer.
>>
>> Here it is:
>> (kgdb) #0 doadump () at pcpu.h:231
>> #1 0xc04d48b9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1058443808,
>> dummy4=0xeef1d720 "") at /usr/src/sys/ddb/db_command.c:548
>> #2 0xc04d4cb1 in db_command (last_cmdp=0xc0df4bdc, cmd_table=0x0,
>> dopager=1)
>> at /usr/src/sys/ddb/db_command.c:445
>> #3 0xc04d4e0a in db_command_loop () at
>> /usr/src/sys/ddb/db_command.c:498
>> #4 0xc04d6d0d in db_trap (type=12, code=0) at
>> /usr/src/sys/ddb/db_main.c:229
>> #5 0xc08e17ce in kdb_trap (type=12, code=0, tf=0xeef1d948)
>> at /usr/src/sys/kern/subr_kdb.c:535
>> #6 0xc0c0ae7f in trap_fatal (frame=0xeef1d948, eva=24)
>> at /usr/src/sys/i386/i386/trap.c:929
>> #7 0xc0c0b140 in trap_pfault (frame=0xeef1d948, usermode=0, eva=24)
>> at /usr/src/sys/i386/i386/trap.c:851
>> #8 0xc0c0bad5 in trap (frame=0xeef1d948) at
>> /usr/src/sys/i386/i386/trap.c:533
>> #9 0xc0bec9ac in calltrap () at /usr/src/sys/i386/i386/exception.s:166
>> #10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0)
>> at /usr/src/sys/net/rtsock.c:1374
>> #11 0xc0978864 in rt_ifmsg (ifp=0xc6c3d400) at
>> /usr/src/sys/net/rtsock.c:1168
>> #12 0xc76704a1 in ?? ()
>> #13 0xc6c3d400 in ?? ()
>> #14 0xeef1daa8 in ?? ()
>> #15 0xeef1daf4 in ?? ()
>> #16 0xc769ecb3 in NdisMIndicateStatusComplete (adapter=0xc76b9200)
>> at /usr/src/sys/modules/ndis/../../compat/ndis/subr_ndis.c:3105
>> #17 0xc766d8a1 in ?? ()
>> #18 0xc76b9200 in ?? ()
>> #19 0xc76c in ?? ()
>> #20 0xc76f1000 in ?? ()
>> #21 0xeef1dacc in ?? ()
>> #22 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start ()
>> from /boot/modules/bcmwl5_sys.ko
>> #23 0x006c in ?? ()
>> #24 0xeef1dbb4 in ?? ()
>> #25 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start ()
>> from /boot/modules/bcmwl5_sys.ko
>> #26 0xc76c in ?? ()
>> #27 0xc76c in ?? ()
>> #28 0xc7340800 in ?? ()
>> #29 0xc086adcc in hardclock_cpu (usermode=7077888)
>> at /usr/src/sys/kern/kern_clock.c:447
>
>
> whoa!
> hardclock interrupted itself?
>
>> #30 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start ()
>> from /boot/modules/bcmwl5_sys.ko
>> #31 0x006c in ?? ()
>> #32 0xeef1dbb4 in ?? ()
>> #33 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start ()
>> from /boot/modules/bcmwl5_sys.ko
>> #34 0xc76c in ?? ()
>> #35 0xc76c in ?? ()
>> #36 0xc7340800 in ?? ()
>
> hmmm maybe we need to get ndis to put in a wrapper at this point that
> is called form hardclock and sets the value before going further
>
> I'd have to look at the code to see what happens here..
>
> *wonders who has their fingers in this code*..
>
>> #37 0xc086adcc in hardclock_cpu (usermode=-949223424)
>> at /usr/src/sys/kern/kern_clock.c:447
>> Previous frame inner to this frame (corrupt stack?)
>> (kgdb)
>>
>>
>> and the panic, in case it helps:
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 1; apic id = 01
>> fault virtual address = 0x18
>> fault code = supervisor read, page not present
>> instruction pointer = 0x20:0xc0978200
>> stack pointer = 0x28:0xeef1d988
>> frame pointer = 0x28:0xeef1d9a0
>> code segment= base 0x0, limit 0xf, type 0x1b
>> = DPL 0, pres 1, def32 1, gran 1
>> processor eflags= interrupt enabled, resume, IOPL = 0
>> current process = 1404 (Windows Workitem 3)
>> panic: from debugger
>> cpuid = 1
>> KDB: stack backtrace:
>> Physical memory: 2916 MB
>> Dumping 113 MB: 98 82 66 50 34 18 2
>>
>> Thanks, Nikos
>>
Please give more background information of this case.
Personally I never tested VIMAGE.
Note that, for unknown reason (must be bug from old days) if_ndis.c calls
rt_ifmsg() on its own via NdisMIndicateStatusComplete(), and I see no
point to do that.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
Re: bge watchdog timeout errors FreeBSD 7.3
Quoting Pyun YongHyeon : Oops, sorry. I forgot one more chunk. You need to apply this one in addition to two patches. http://svn.freebsd.org/viewvc/base/stable/7/sys/dev/bge/if_bgereg.h?r1=202861&r2=208995&view=patch Hi, Ok I have installed the patches, and rebuilt the kernel. Unfortunately the errors persist, Sep 28 12:27:58 vcomm kernel: bge0: watchdog timeout -- resetting Sep 28 12:27:58 vcomm kernel: bge0: link state changed to DOWN Sep 28 12:28:00 vcomm kernel: bge0: link state changed to UP Although prior to the installation of the patch I tried to copy some backup files off the server via scp. Copying a large file ~2GB caused the network connection to drop and the copy to fail. Testing after applying the patch shows that this is now improved, I have ran a few copies without any problems... Where does that leave things? thanks Andy. ___ 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"
[PATCH] Netdump for review and testing -- preliminary version
In the last weeks I worked for porting the netdump infrastructure to FreeBSD-CURRENT on the behalf of Sandvine Incorporated. Netdump is a framework that aims for handling kernel coredumps over the TCP/IP suite in order to dump to a separate machine than the running one. That may be used on an interesting number of cases involving disk-less workstations, disk driver debugging or embedded devices. GENERAL FRAMEWORK ARCHITECTURE Netdump is composed, right now, by an userland "server" and a kernel "client". The former is run on the target machine (where the dump will phisically happen) and it is responsible for receiving the packets containing coredumps frame and for correctly writing them on-disk. The latter is part of the kernel installed on the source machine (where the dump is initiated) and is responsible for building correctly UDP packets containing the coredump frames, pushing through the network interface and routing them appropriately. While the server may appear as, pretty much, a simple userland deamon dealing with UDP packets, the client imposes interesting problems as long as its activity is linked to handling kernel core dumping. More precisely, as long as the client is part of the dumping mechanism and the kernel may be in general panic conditions, netdump must ensure "robustness" of operations. That is partially achieved by reworking (and someway replicating) locally some UDP, ARP and IP operations, hardsetting some values (like the default gateway, the destination and the client address) and reducing further interactions with the kernel just to the network interface acitivities. More specifically, it implements a very basic UDP / IPv4 / ARP stack separate from the standard stack (since that may not be in a consistent state). It can dump to a server on the same LAN or via a router (correctly specifying the connection gateway). In order to receive packet on critical conditions, netdump polls the interface. Every network driver can implement hooks to be used by netdump independently by DEVICE_POLLING option, even if it is probabilly a good idea to share some code among them. The reference set of hooks is contained into "struct netdump_methods". And if_lem/if_em driver modifies may be set as reference for netdump hooks implementation. In order to work into an "up and running" system (meant as with all the devices in place) the netdump handler hooks as a pre-sync handler (differently from other dumping routines). It however suffers some problems typical of other dumping mechanism. For example, on DDB entering unlocked version of polling handler is used, in order to reduce the risk of deadlocks during inspections*. That reflects, among the netdump methods, the existence of 2 versions of polling hooks, where the "unlocked" is meant as reducing locking as much as possible. PATCH AND FURTHER WORK The patch is not totally complete and it is not intended to be committed in SVN yet. What I'm looking for now is more testing and review (in particular in terms of architecture) coverage by community. The server should be in realtively "committable" state, though, but I encourage its stress-testing. A manpage is provided along that should be very easy to understand how to use it. Things that can be further improved, as it is now, in the client, are: - Deciding if hardcoding of the kernel parameter is done properly. I personally don't like the sysctl usage and I would prefer an userland small utility used to testing and maybe add some tunables for enabling netdump early in the boot. You may have several opinions on this though. - VIMAGE and IPv6 support. - More drivers support. Right now only if_em (and if_lem) are converted to use netdump and can be used as a draft for other device drivers. if_ixgb should came along in the final, committing, version too. In general I think that all drivers supporting device polling could easilly support also netdump - Ideally dumpsys() in FreeBSD is too much disk-activity oriented. It should be made, instead, more neutral and more flexible to cope better with different interfaces. It is a quite a bit of work, however, and beyond the scope of netdump introduction (even if it could be beneficial for it) Netdump has been developed on a FreeBSD project branch located here: svn://svn.freebsd.org/base/projects/sv/ which could also forsee further informations about every single change. However, for your convenience, also a patch has been made public which is located here (against freebsd-curr...@213246): http://www.freebsd.org/~attilio/Sandvine/STABLE_8/netdump/netdump_alpha_0.diff In order to enable the client it is enough to add at your kernel config: optionsNETDUMP_CLIENT NETDUMP_CLIENT_DEBUG can be specified too in order to have further debuggin traces but I'd encourage to use them just for developing Netdump itself. TYPICAL USAGE This is a set of the available sysctls for netdump: # sysctl -d net.dump net.dump: netdump net.dump.enable: enable network dump n
Re: Default gateway on different net
Sorry for the late reply, On 24. Sep 2010, at 12:56 , Lars Eggert wrote: > This seems very complex. Have you simply tried: > > ipv6_defaultrouter="2a01:::3180::1" > ipv6_ifconfig_re0="2a01:::3183::1 prefixlen 64" Yes - but you can't add a defaultroute to an ip not on the same subnet. If I had ie. 2a01:::3180::2 on my interface re0, it would work (I tried) - but the hosting provided wasn't very happy with me just picking a $random ip from their subnet ;) Best regards, Lasse Brandt___ 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: bge watchdog timeout errors FreeBSD 7.3
On Tue, Sep 28, 2010 at 01:24:45PM +0100, a.sm...@ukgrid.net wrote: > Quoting Pyun YongHyeon : > > >Oops, sorry. I forgot one more chunk. You need to apply this one in > >addition to two patches. > >http://svn.freebsd.org/viewvc/base/stable/7/sys/dev/bge/if_bgereg.h?r1=202861&r2=208995&view=patch > > > > Hi, > > Ok I have installed the patches, and rebuilt the kernel. > Unfortunately the errors persist, > > > Sep 28 12:27:58 vcomm kernel: bge0: watchdog timeout -- resetting > Sep 28 12:27:58 vcomm kernel: bge0: link state changed to DOWN > Sep 28 12:28:00 vcomm kernel: bge0: link state changed to UP > > Although prior to the installation of the patch I tried to copy some > backup files off the server via scp. Copying a large file ~2GB caused > the network connection to drop and the copy to fail. Testing after > applying the patch shows that this is now improved, I have ran a few > copies without any problems... > > Where does that leave things? > Ok thanks for testing. It seems you have another issue which is not correctly handled in bge(4). I'm not sure you're actually seeing an errata of controller but could you try patch at the following URL? http://freefall.freebsd.org/~yongari/bge/bge.7.3R.post.diff The patch includes all patches I suggested so please back out previous patches before applying it. The patch was written to get better RX performance under high network load and it also includes a fix for a known hardware errata. But it's highly experimental and it's not for non-MSI bge(4) controllers because the patch may trigger other locking issues due to highly increased RX BD updates ratio in firmware for controllers that use shared interrupt. It seems your controller uses MSI so you don't have to worry about the issue. However don't apply the patch to production box. ___ 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: bge watchdog timeout errors FreeBSD 7.3
Quoting Pyun YongHyeon : However don't apply the patch to production box. Hi, actually the only server of this type is a production box, it was originally running FreeBSD 7.2 without issue but was upgraded when 7.2 went EOL. What would you recommend? I guess I can wait for this to be tested by someone else as it doesnt seem to be causing and severe issues. The server in question is running wordpress-mu and I havent had any complaints from end users about this, thanks Andy. ___ 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: bge watchdog timeout errors FreeBSD 7.3
On Tue, Sep 28, 2010 at 11:08:24PM +0100, a.sm...@ukgrid.net wrote: > Quoting Pyun YongHyeon : > > > However don't apply the patch to production box. > > > > Hi, > > actually the only server of this type is a production box, it was > originally running FreeBSD 7.2 without issue but was upgraded when 7.2 > went EOL. > What would you recommend? I guess I can wait for this to be tested by I don't think it would cause severe problem with the patch but it was not heavily tested under various network load so this is the main reason why I took precaution against applying it on production box. If you're prepared to go back to old working kernel and it's tolerable for small down time you may go that route. > someone else as it doesnt seem to be causing and severe issues. The As I said, the patch requires another patch that handles shared interrupt with tagged status. I also have initial patch for that but it needs more polishing and cleanups. Lack of controller that has this issue also makes it hard to write patch. Your controller has no such issue so I wanted to know whether you're seeing known hardware errata or not. > server in question is running wordpress-mu and I havent had any > complaints from end users about this, > > thanks Andy. > > > > ___ 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: Call for testers: RFC 5569 (6rd) support in stf(4)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 9/22/2010 1:32 PM, Hiroki Sato wrote: | Hello, | | Can anyone try a patch for adding 6rd (RFC 5569) support to stf(4)? Well I don't want to be "Mr. Negativity," but I'd like to suggest that adding this support is the wrong way to go. STF and teredo are transition mechanisms, and we're currently knee-deep (well maybe ankle-deep) in the deployment of IPv6. This is only going to pick up steam in the next few years given the impending run-out of the free /8s in the IANA pool. In my opinion we'd be much better off focusing on making our native IPv6 stack more robust rather than adding more transition protocols that will (with any kind of luck) be obsolete within the useful life of the 9.x branch. For example I seem to recall you identifying a performance penalty with the IPv6 loopback device vs. the IPv4 version. Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBCAAGBQJMomu3AAoJEFzGhvEaGryE1hsH/iWx2smE8VC3akxNM8K8aCo5 ikGeSdpxRUVeu7Uz+fZ8RAIDkSPiD7qIIpGDFNJfur7KjojLJWS4twLCsXqmAQ62 kY4FsyWzogfYv+CnX1X7dmmYt7g1fNS3tzwq8cGS7HaQ74lP42W5dZBuqU8o9V2C 9Oq77LsmDNNnGYvpa9v/NgGxen6sm/ENC6Xb6cQ/5APd9inZqlJFjPwVQLvEFhf5 oI6GrP/jCprmhx7hDrnJ/OKvKp8+hxkzjRczRJ93ZYWWHvTSIhjkOaeCnTSwGmEa aFmdOVX+h3Y2rziNvrBhhzaDproGZXiyGUiZ/Lak/lypgbdpB7N3FO05p3hSaT8= =UjVm -END PGP SIGNATURE- ___ 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/149804: [icmp] [panic] ICMP redirect on causes "panic: rtqkill route really not free"
Synopsis: [icmp] [panic] ICMP redirect on causes "panic: rtqkill route really not free" State-Changed-From-To: open->patched State-Changed-By: delphij State-Changed-When: Wed Sep 29 05:55:38 UTC 2010 State-Changed-Why: A bandaid have been committed against -HEAD. Responsible-Changed-From-To: freebsd-net->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Wed Sep 29 05:55:38 UTC 2010 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=149804 ___ 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"
