Re: SCTP : problems in sending ASCONF chunks
Hello Gaurav, Le Jeu 17 décembre 2009 08:17, Gaurav Bhateja a écrit : > Hi Vlad, > > > I would really appreciate if you could help me out on this issue. > > > I came to know about this email ID from the link > http://lists.freebsd.org/pipermail/freebsd-net/2009-January/020683.html > > > I am getting error, "Operation not permitted" when setting peer primary > address from server. I am using linux version 2.6-15(client) --- > 2.6.21(server) > > > Would there be a problem in dynamically configuring primary address using > sctp options, SCTP_PRIMARY_ADDR and SCTP_SET_PEER_PRIMARY_ADDR for these > linux versions? > I was working on performing hard handovers with SCTP using a FreeBSD client (7.0 at that time) and a Linux base-station (2.6.21 if memory serves), but the SCTP module for this version didn't support the dynamic configuration of the address for the ASCONF chunk very well, eventually I just switched both machines to FreeBSD to continue working on this subject. > > You have suggested that its better to use linux version - 2.6-25. (It is > difficult for us to switch to these versions due to license issues) > > Could you provide is any other way to solve this issue. > You could manually build and install a newer version of the lk-SCTP module from the source code. But I haven't worked with lk-sctp since then (January I mean), so I don't know if it is wiser to upgrade all your kernel sources, and not just the sctp source code. Vlad is much better suited to answer that one. > > > Regrds, > Gaurav > > > > > > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or > used for any purpose other than for what it is intended. If you have > received this message in error, please notify the originator immediately. > If you are not the intended recipient, you are notified that you are > strictly prohibited from using, copying, altering, or disclosing the > contents of this message. Aricent accepts no responsibility for loss or > damage arising from the use of the information transmitted by this email > including damage from virus." > ___ > 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" > > Aman Jassal Wisdom comes from experience. Experience comes from a lack of wisdom. ___ 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: trouble with Realtek NIC RTL8101E/RTL8102E under FreeBSD 7.2
Dear FreeBSD-net Community, I have trouble with FreeBSD 7.2 as well as PCBSD 7.1.1 detecting my NIC properly. Please see below for some technical details related to the problem. output of less /var/run/dmesg.boot | grep re0 re0: port 0x2000-0x20ff mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x2480 re0: MAC rev. 0x0040 re0: Unknown H/W revision: 0x24c0 device_attach: re0 attach returned 6 re0: port 0x2000-0x20ff mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x2480 re0: MAC rev. 0x0040 re0: Unknown H/W revision: 0x24c0 device_attach: re0 attach returned 6 re0: port 0x2000-0x20ff mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x2480 re0: MAC rev. 0x0040 re0: Unknown H/W revision: 0x24c0 device_attach: re0 attach returned 6 re0: port 0x2000-0x20ff mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x2480 re0: MAC rev. 0x0040 re0: Unknown H/W revision: 0x24c0 device_attach: re0 attach returned 6 output of pciconf -l | grep re0 r...@pci0:3:0:0:class=0x02 card=0x306a103c chip=0x813610ec rev=0x02 hdr=0x00 output of ifconfig ath0: flags=8802 metric 0 mtu 1500 ether 00:24:2c:5e:06:f2 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 Mhz 11b) authmode OPEN privacy OFF txpower 50 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11b 7 roam:rate11b 1 burst bintval 0 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 pflog0: flags=0<> metric 0 mtu 33204 pfsync0: flags=0<> metric 0 mtu 1460 syncpeer: 224.0.0.240 maxupd: 128 Please let me know if you require further details that might be of help. Look forward to hearing from anyone who would care to help at your convenience. Regards, Alexander Kapshuk. ___ 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 openbgpd + 8.0
Hi, thanks for help. Li, Qing píše v st 16. 12. 2009 v 15:39 -0800: > Hi, > > You have reported issues regarding openbgp/bgpd exiting > abnormally. Please apply patch: > > http://people.freebsd.org/~qingli/bgpd-patch-121615.diff > > and let me know if it fixes your issue. I performed limited > unit testing. > - bgpd don't terminate, it's OK but there appeared some new problems: TEST: bgpd is running, vlan3 not exists -- # netstat -rnf inet Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default10.8.20.1 UGS 5 135040 bge0 10.8.20.0/24 link#1 U 00 bge0 10.8.20.20 link#1 UHS 00lo0 127.0.0.1 link#4 UH 0 35lo0 $ bgpctl show fib flags: * = valid, B = BGP, C = Connected, S = Static N = BGP Nexthop reachable via this route r = reject route, b = blackhole route flags prio destination gateway *S 48 0.0.0.0/010.8.20.1 *C 48 10.8.20.0/24 link#1 *C 48 10.8.20.20/32link#4 *C 0 127.0.0.1/8 link#0 *C 48 127.0.0.1/32 link#4 # ifconfig vlan3 create # ifconfig vlan3 172.16.1.1/24 # netstat -rnfinet Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default10.8.20.1 UGS 2 136107 bge0 10.8.20.0/24 link#1 U 00 bge0 10.8.20.20 link#1 UHS 00lo0 127.0.0.1 link#4 UH 0 35lo0 172.16.1.0/24 link#6 U 00 vlan3 172.16.1.1 link#6 UHS 00lo0 $ bgpctl show fib *C 48 10.8.20.0/24 link#1 *C 48 10.8.20.20/32link#4 *C 0 127.0.0.1/8 link#0 *C 48 127.0.0.1/32 link#4 C 48 172.16.1.0/24link#6 /* there is 172.16.1.1/32 link#4 missing and 172.16.1.0/24 is not marked as valid */ # ifconfig vlan3 alias 172.16.1.2/32 $ bgpctl show fib *C 48 10.8.20.0/24 link#1 *C 48 10.8.20.20/32link#4 *C 0 127.0.0.1/8 link#0 *C 48 127.0.0.1/32 link#4 C 48 172.16.1.0/24link#6 C 48 172.16.1.2/32link#6 new alias /32 is added correctly after restart bgpd, it prints this: # netstat -rnfinet Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default10.8.20.1 UGS 6 141282 bge0 10.8.20.0/24 link#1 U 00 bge0 10.8.20.20 link#1 UHS 00lo0 127.0.0.1 link#4 UH 0 35lo0 172.16.1.0/24 link#6 U 00 vlan3 172.16.1.1 link#6 UHS 00lo0 172.16.1.2 link#6 UHS 00lo0 => 172.16.1.2/32 link#6 U 00 vlan3 $ bgpctl show fib flags: * = valid, B = BGP, C = Connected, S = Static N = BGP Nexthop reachable via this route r = reject route, b = blackhole route flags prio destination gateway *S 48 0.0.0.0/010.8.20.1 *C 48 10.8.20.0/24 link#1 *C 48 10.8.20.20/32link#4 *C 0 127.0.0.1/8 link#0 *C 48 127.0.0.1/32 link#4 *C 48 172.16.1.0/24link#6 *C 48 172.16.1.1/32link#4 *C 48 172.16.1.2/32link#4 *C 48 172.16.1.2/32link#6 /* So, after bgpd restart, it registered new interface and all routes correctly and routes are valid. When I start bgpd >after< creating vlan3 (without ip adresses), it's behavior is same, but routes in "bgpctl show fib" output are displayed as valid (with *) */ ___ 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/141696: [rum] [panic] rum(4)+ vimage = kernel panic
The following reply was made to PR kern/141696; it has been noted by GNATS. From: Venture37 To: bug-follo...@freebsd.org, ventur...@geeklan.co.uk Cc: Subject: Re: kern/141696: [rum] [panic] rum(4)+ vimage = kernel panic Date: Thu, 17 Dec 2009 15:25:28 + Photo of the trace output http://img64.imageshack.us/i/img1517.jpg/ ___ 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"
close: Socket is not connected
Hi,
We have an application that consists of two processes communicating via unix
socket (client connects, sends requests, reads response and close the
connection). Sometimes the error 'Socket is not connected' is observed when
client closes the socket.
We observed this problem on FreeBSD6.X and now have been observing it on 7.1.
To model the behaviour of the application I have written a simple test program
(see below) based on relevant parts from the application code. Using this test
program it requires from an a half of hour to several hours to reproduce the
error. It might fail on close() both in the parent (server) and the children
(client).
$ date; ./unixsocket ; date
Thu Dec 17 09:38:35 UTC 2009
unixsocket: parent: close error: 57
Thu Dec 17 14:13:07 UTC 2009
unixsocket: child: connect error 61
$ ./unixsocket
unixsocket: child: close error: 57
I can reproduce the error running the test on 8.0 too.
Does this indicate some bug in FreeBSD or may be just something is wrong with
our code?
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define UNIXSTR_PATH "/tmp/mytest.socket"
#define BUFSIZE 557
#define USLEEP 1
#define timeout 10
int waitData(int handle, int reading, int writing) {
struct timeval tv;
intresult;
fd_set rset;
fd_set wset;
fd_set eset;
FD_ZERO(&rset);
FD_SET(handle, &rset);
FD_ZERO(&wset);
FD_SET(handle, &wset);
FD_ZERO(&eset);
FD_SET(handle, &eset);
tv.tv_sec = timeout;
tv.tv_usec = 0;
for (;;)
{
if (reading && !writing)
result = select(handle + 1, &rset, 0, &eset, &tv);
else
if (!reading && writing)
result = select(handle + 1, 0, &wset, &eset,
&tv);
else
result = select(handle + 1, &rset, &wset,
&eset, &tv);
if (result == 0) /* timeout */
return 0;
if (result < 0)
{
if (errno == EINTR)
{
continue;
}
errx(1, "select: %d", errno);
}
if (FD_ISSET(handle, &rset) || FD_ISSET(handle, &wset))
{
int err = 0;
socklen_t err_size = sizeof(err);
if (getsockopt(handle, SOL_SOCKET, SO_ERROR,
(char*)&err, &err_size) != 0)
{
errx(1, "getsockopts: %d", errno);
}
if (err != 0)
{
errx(1, "getsockopts: err: %d", err);
}
}
else
{
errx(1, "select problems");
}
return 1; /* OK */
}
}
void Write(int handle, const char* buf, size_t size) {
size_t left = size;
while (left > 0)
{
while (1)
{
int sent = send(handle, buf, size, 0);
if (sent <= 0)
{
if (errno == EAGAIN)
{
if (!waitData(handle, 0, 1))
errx(1, "Write: timeout");
continue;
}
errx(1, "Write: error: %d", errno);
}
left -= sent;
buf += sent;
break;
}
}
}
void Read(int handle, char* buf, size_t size)
{
while (size > 0)
{
int blockSize;
if (!waitData(handle, 1, 0))
errx(1, "Read: timeout");
blockSize = recv(handle, buf, size, 0);
if (blockSize <= 0)
{
errx(1, "Read: error: blockSize: %d", blockSize);
}
buf += blockSize;
size -= blockSize;
}
}
int main(int argc, char **argv)
{
int listenfd, connfd, pid;
struct sockaddr_un servaddr;
charbuf[BUFSIZE];
memset(buf, 'X', sizeof(buf));
pid = fork();
if (-1 == pid)
errx(1, "fork(): %d", errno);
if (0 != pid) {
Re: kern/141696: [rum] [panic] rum(4)+ vimage = kernel panic
The following reply was made to PR kern/141696; it has been noted by GNATS. From: Sevan / Venture37 To: bug-follo...@freebsd.org, ventur...@geeklan.co.uk Cc: Subject: Re: kern/141696: [rum] [panic] rum(4)+ vimage = kernel panic Date: Thu, 17 Dec 2009 15:27:18 + Photo of the trace output http://img64.imageshack.us/i/img1517.jpg/ ___ 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: Racoon site-to site
At 02:50 AM 12/15/2009, Jon Otterholm wrote: On 2009-12-11 20.23, "Mike Tancsa" wrote: > > > You might also want to turn on DPD (dead peer > detection) in ipsectools if you dont already have > it on both sides. Are you really using des for > the crypto ? Also, when the session is > negotiated, take a look at the output of > setkey -D > and see what was actually negotiated and post it > here (just make sure you get rid of the info on the E and A lines. > > e.g. > 1.1.1.2 2.2.2.2 > esp mode=tunnel spi=125444787(0x077a22b3) reqid=16416(0x4020) > E: 3des-cbc 770cdd7b 770cdd7b 770cdd7b 770cdd7b 770cdd7b 770cdd7b > A: hmac-sha1 5cfdbabb 5cfdbabb 5cfdbabb 5cfdbabb 5cfdbabb > > ie. mask out the 5cfdbabb and 770cdd7b values > before posting as thats your crypto :) > > Here is output from setkey -D when we lost connection: localip remoteip esp mode=tunnel spi=989823717(0x3aff82e5) reqid=0(0x) E: des-cbc x x A: hmac-md5 x x x x seq=0x09ac replay=4 flags=0x state=mature created: Dec 15 07:57:41 2009 current: Dec 15 08:26:04 2009 diff: 1703(s) hard: 3600(s) soft: 2880(s) last: Dec 15 08:26:03 2009 hard: 0(s) soft: 0(s) current: 400400(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 2476 hard: 0 soft: 0 sadb_seq=1 pid=23175 refcnt=2 remoteip remoteip esp mode=tunnel spi=117094840(0x06fab9b8) reqid=0(0x) E: des-cbc x x A: hmac-md5 x x x x seq=0x0b73 replay=4 flags=0x state=mature created: Dec 15 07:57:41 2009 current: Dec 15 08:26:04 2009 diff: 1703(s) hard: 3600(s) soft: 2880(s) last: Dec 15 08:25:37 2009 hard: 0(s) soft: 0(s) current: 2960978(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 2931 hard: 0 soft: 0 sadb_seq=0 pid=23175 refcnt=1 The state looks good (mature). It would be useful to see what the other side thinks is going on. 3 different things to try when its down. racoonctl vpn-disconnect remoteip ... where remoteip is the public IP of the endpoint and then generate some traffic and see if things are re-established. setkey -F to flush the associations on this side... and again, generate some traffic. Another thing to try is sysctl -w net.key.preferred_oldsa=0 setkey -F restart racoon and then see if the hangs still happen. But you should try and get some debugging info from the other side to see what state things are in when the tunnel fails. In general, I have found setting net.key.preferred_oldsa=0 important when inter-operating with other platforms. Also, check and make sure you have dpd compiled into ipsectools and make sure enabled. ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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: Racoon site-to site
Hi all. On Thu, Dec 17, 2009 at 11:01:00AM -0500, Mike Tancsa wrote: [...] > Another thing to try is > sysctl -w net.key.preferred_oldsa=0 Yep, this is how most IPsec devices works and expects peers to work. > Also, check and make sure you have dpd compiled into > ipsectools and make sure enabled. Yes or no: misconfigured, or used in situations with important loss, DPD can be worst than nothing The best would be to first understand the issue, then fix it, and only after that consider finding useful DPD configuration regarding the setup Yvan. ___ 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: SCTP : problems in sending ASCONF chunks
Hi Gaurav, you might want to discuss this on the Linux SCTP mailing list, not on the FreeBSD net mailing list. You find Linux experts there... Best regards Michael On Dec 17, 2009, at 8:17 AM, Gaurav Bhateja wrote: > Hi Vlad, > > I would really appreciate if you could help me out on this issue. > > I came to know about this email ID from the link > http://lists.freebsd.org/pipermail/freebsd-net/2009-January/020683.html > > I am getting error, "Operation not permitted" when setting peer primary > address from server. > I am using linux version 2.6-15(client) --- 2.6.21(server) > > Would there be a problem in dynamically configuring primary address using > sctp options, SCTP_PRIMARY_ADDR and SCTP_SET_PEER_PRIMARY_ADDR for these > linux versions? > > You have suggested that its better to use linux version - 2.6-25. (It is > difficult for us to switch to these versions due to license issues) > > Could you provide is any other way to solve this issue. > > > Regrds, > Gaurav > > > > > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received this > message in error, please notify the originator immediately. If you are not > the intended recipient, you are notified that you are strictly prohibited > from using, copying, altering, or disclosing the contents of this message. > Aricent accepts no responsibility for loss or damage arising from the use of > the information transmitted by this email including damage from virus." > ___ > 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: issue with openbgpd + 8.0
Hi Qing, This indeed fixes the issue for me! Thanks very much, I hope to see the patch committed :) -Adam Adam Jacob Muller a...@adam.gs 201-616-0620 On Dec 16, 2009, at 6:39 PM, Li, Qing wrote: > Hi, > > You have reported issues regarding openbgp/bgpd exiting > abnormally. Please apply patch: > >http://people.freebsd.org/~qingli/bgpd-patch-121615.diff > > and let me know if it fixes your issue. I performed limited > unit testing. > > Thanks, > > -- Qing > > > > ___ 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"
Bug discussion:Tcp snd_nxt will not be increased.
Hello All: There's a problem i am facing. Is it a bug ? It's tcp connect socket, SYN will be send, but if before SYN ACK was received, the SYN will be retransmited, there'll be some problem. the restransmit is like this: move the snd_nxt to snd_una, and begin to sendout by tcp_output. after send the snd_nxt will return to normal just like below. before tcp_output after tcp output |--Seq--|--Seq+1--| |--Seq--|--Seq+1--| snd_una snd_una snd_nxt snd_nxt If the tcp_output just have some error, for example: when alloc mbuf, it returns NULL, and then the snd_nxt number will not be return to normal. If just in this time, SYN Ack arrives, freeBSD can't handle this situdition. Thanks! ___ 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/141720: [sctp] [lor] [hang] sctp-create vs. sctp-it causes system hang
Synopsis: [sctp] [lor] [hang] sctp-create vs. sctp-it causes system hang Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Thu Dec 17 18:51:08 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141720 ___ 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: trouble with Realtek NIC RTL8101E/RTL8102E under FreeBSD 7.2
On Thu, Dec 17, 2009 at 12:00:17PM +0200, Alexander Kapshuk wrote: > Dear FreeBSD-net Community, > > I have trouble with FreeBSD 7.2 as well as PCBSD 7.1.1 detecting my > NIC properly. > > Please see below for some technical details related to the problem. > > output of less /var/run/dmesg.boot | grep re0 > > re0: port 0x2000-0x20ff > mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 > on pci3 > re0: Using 1 MSI messages > re0: Chip rev. 0x2480 > re0: MAC rev. 0x0040 > re0: Unknown H/W revision: 0x24c0 > device_attach: re0 attach returned 6 > re0: port 0x2000-0x20ff > mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 > on pci3 > re0: Using 1 MSI messages > re0: Chip rev. 0x2480 > re0: MAC rev. 0x0040 > re0: Unknown H/W revision: 0x24c0 > device_attach: re0 attach returned 6 > re0: port 0x2000-0x20ff > mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 > on pci3 > re0: Using 1 MSI messages > re0: Chip rev. 0x2480 > re0: MAC rev. 0x0040 > re0: Unknown H/W revision: 0x24c0 > device_attach: re0 attach returned 6 > re0: port 0x2000-0x20ff > mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 > on pci3 > re0: Using 1 MSI messages > re0: Chip rev. 0x2480 > re0: MAC rev. 0x0040 > re0: Unknown H/W revision: 0x24c0 > device_attach: re0 attach returned 6 > Support for the controller was made in r195675 and the change was already MFCed to stable/8 and stable7. Try recent CURRENT or 8/stable and 7/stable. I guess you can download the following files from latest stable/7 via web interface and rebuilding both re(4) and rl(4) on your 7.2-RELEASE should make your controller recognized. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h > output of pciconf -l | grep re0 > > r...@pci0:3:0:0: class=0x02 card=0x306a103c chip=0x813610ec rev=0x02 > hdr=0x00 > > output of ifconfig > > ath0: flags=8802 metric 0 mtu 1500 > ether 00:24:2c:5e:06:f2 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > ssid "" channel 1 (2412 Mhz 11b) > authmode OPEN privacy OFF txpower 50 bmiss 7 scanvalid 60 bgscan > bgscanintvl 300 bgscanidle 250 roam:rssi11b 7 roam:rate11b 1 burst > bintval 0 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff00 > pflog0: flags=0<> metric 0 mtu 33204 > pfsync0: flags=0<> metric 0 mtu 1460 > syncpeer: 224.0.0.240 maxupd: 128 > > > Please let me know if you require further details that might be of help. > > Look forward to hearing from anyone who would care to help at your > convenience. > > Regards, > > Alexander Kapshuk. ___ 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 openbgpd + 8.0
Thanks for reporting back and the detailed description. > > - bgpd don't terminate, it's OK > Okay, making progress. > > but there appeared some new problems: > Interestingly enough, my patch is to resolve the issue where adding and removing address aliases are not reported. This issue appears to be solved but the regular address manipulation seems problematic as you describe in your environment. Let me investigate further with my bgp setup. Please note I am going on vacation for a couple of weeks so there may be some delay for a patch. -- Qing > TEST: bgpd is running, vlan3 not exists > -- > # netstat -rnf inet > Routing tables > > Internet: > DestinationGatewayFlagsRefs Use Netif > Expire > default10.8.20.1 UGS 5 135040 bge0 > 10.8.20.0/24 link#1 U 00 bge0 > 10.8.20.20 link#1 UHS 00lo0 > 127.0.0.1 link#4 UH 0 35lo0 > > $ bgpctl show fib > flags: * = valid, B = BGP, C = Connected, S = Static >N = BGP Nexthop reachable via this route >r = reject route, b = blackhole route > > flags prio destination gateway > *S 48 0.0.0.0/010.8.20.1 > *C 48 10.8.20.0/24 link#1 > *C 48 10.8.20.20/32link#4 > *C 0 127.0.0.1/8 link#0 > *C 48 127.0.0.1/32 link#4 > > # ifconfig vlan3 create > # ifconfig vlan3 172.16.1.1/24 > # netstat -rnfinet > Routing tables > > Internet: > DestinationGatewayFlagsRefs Use Netif > Expire > default10.8.20.1 UGS 2 136107 bge0 > 10.8.20.0/24 link#1 U 00 bge0 > 10.8.20.20 link#1 UHS 00lo0 > 127.0.0.1 link#4 UH 0 35lo0 > 172.16.1.0/24 link#6 U 00 vlan3 > 172.16.1.1 link#6 UHS 00lo0 > > $ bgpctl show fib > *C 48 10.8.20.0/24 link#1 > *C 48 10.8.20.20/32link#4 > *C 0 127.0.0.1/8 link#0 > *C 48 127.0.0.1/32 link#4 > C 48 172.16.1.0/24link#6 > > /* there is 172.16.1.1/32 link#4 missing > and 172.16.1.0/24 is not marked as valid */ > > # ifconfig vlan3 alias 172.16.1.2/32 > $ bgpctl show fib > *C 48 10.8.20.0/24 link#1 > *C 48 10.8.20.20/32link#4 > *C 0 127.0.0.1/8 link#0 > *C 48 127.0.0.1/32 link#4 > C 48 172.16.1.0/24link#6 > C 48 172.16.1.2/32link#6 > > new alias /32 is added correctly > > after restart bgpd, it prints this: > > # netstat -rnfinet > Routing tables > > Internet: > DestinationGatewayFlagsRefs Use Netif > Expire > default10.8.20.1 UGS 6 141282 bge0 > 10.8.20.0/24 link#1 U 00 bge0 > 10.8.20.20 link#1 UHS 00lo0 > 127.0.0.1 link#4 UH 0 35lo0 > 172.16.1.0/24 link#6 U 00 vlan3 > 172.16.1.1 link#6 UHS 00lo0 > 172.16.1.2 link#6 UHS 00lo0 => > 172.16.1.2/32 link#6 U 00 vlan3 > > $ bgpctl show fib > flags: * = valid, B = BGP, C = Connected, S = Static >N = BGP Nexthop reachable via this route >r = reject route, b = blackhole route > > flags prio destination gateway > *S 48 0.0.0.0/010.8.20.1 > *C 48 10.8.20.0/24 link#1 > *C 48 10.8.20.20/32link#4 > *C 0 127.0.0.1/8 link#0 > *C 48 127.0.0.1/32 link#4 > *C 48 172.16.1.0/24link#6 > *C 48 172.16.1.1/32link#4 > *C 48 172.16.1.2/32link#4 > *C 48 172.16.1.2/32link#6 > > /* So, after bgpd restart, it registered new interface and all routes > correctly and routes are valid. > > When I start bgpd >after< creating vlan3 (without ip adresses), it's > behavior is same, but routes in "bgpctl show fib" output are displayed > as valid (with *) > > */ ___ 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: trouble with Realtek NIC RTL8101E/RTL8102E under FreeBSD 7.2
Pyun YongHyeon wrote: On Thu, Dec 17, 2009 at 12:00:17PM +0200, Alexander Kapshuk wrote: Dear FreeBSD-net Community, I have trouble with FreeBSD 7.2 as well as PCBSD 7.1.1 detecting my NIC properly. Please see below for some technical details related to the problem. output of less /var/run/dmesg.boot | grep re0 re0: port 0x2000-0x20ff mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x2480 re0: MAC rev. 0x0040 re0: Unknown H/W revision: 0x24c0 device_attach: re0 attach returned 6 re0: port 0x2000-0x20ff mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x2480 re0: MAC rev. 0x0040 re0: Unknown H/W revision: 0x24c0 device_attach: re0 attach returned 6 re0: port 0x2000-0x20ff mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x2480 re0: MAC rev. 0x0040 re0: Unknown H/W revision: 0x24c0 device_attach: re0 attach returned 6 re0: port 0x2000-0x20ff mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x2480 re0: MAC rev. 0x0040 re0: Unknown H/W revision: 0x24c0 device_attach: re0 attach returned 6 Support for the controller was made in r195675 and the change was already MFCed to stable/8 and stable7. Try recent CURRENT or 8/stable and 7/stable. I guess you can download the following files from latest stable/7 via web interface and rebuilding both re(4) and rl(4) on your 7.2-RELEASE should make your controller recognized. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h output of pciconf -l | grep re0 r...@pci0:3:0:0:class=0x02 card=0x306a103c chip=0x813610ec rev=0x02 hdr=0x00 output of ifconfig ath0: flags=8802 metric 0 mtu 1500 ether 00:24:2c:5e:06:f2 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 Mhz 11b) authmode OPEN privacy OFF txpower 50 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11b 7 roam:rate11b 1 burst bintval 0 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 pflog0: flags=0<> metric 0 mtu 33204 pfsync0: flags=0<> metric 0 mtu 1460 syncpeer: 224.0.0.240 maxupd: 128 Please let me know if you require further details that might be of help. Look forward to hearing from anyone who would care to help at your convenience. Regards, Alexander Kapshuk. Thanks a lot! I'll give it a go. I've never rebuilt a driver before. So I'll have to look into it. Can the info on how to do it be found in the Handbook, or should I look elsewhere? Thanks. ___ 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 openbgpd + 8.0
Hi Adam, Thanks for the update. I think I will postpone the commit until I get a better handle on the addition behavior reported by Michal, hopefully soon. -- Qing > -Original Message- > From: Adam Jacob Muller [mailto:a...@adam.gs] > Sent: Thursday, December 17, 2009 10:24 AM > To: Li, Qing > Cc: Adam Jacob Muller; Michal Buchtik; freebsd-net@freebsd.org; Qing Li > Subject: Re: issue with openbgpd + 8.0 > > Hi Qing, > This indeed fixes the issue for me! > > Thanks very much, I hope to see the patch committed :) > > -Adam > > > > Adam Jacob Muller > a...@adam.gs > 201-616-0620 > > On Dec 16, 2009, at 6:39 PM, Li, Qing wrote: > > > Hi, > > > > You have reported issues regarding openbgp/bgpd exiting > > abnormally. Please apply patch: > > > >http://people.freebsd.org/~qingli/bgpd-patch-121615.diff > > > > and let me know if it fixes your issue. I performed limited > > unit testing. > > > > Thanks, > > > > -- Qing > > > > > > > > ___ 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: trouble with Realtek NIC RTL8101E/RTL8102E under FreeBSD 7.2
On Thu, Dec 17, 2009 at 09:16:23PM +0200, Alexander Kaphuk wrote: > Pyun YongHyeon wrote: > >On Thu, Dec 17, 2009 at 12:00:17PM +0200, Alexander Kapshuk wrote: > > > >>Dear FreeBSD-net Community, > >> > >>I have trouble with FreeBSD 7.2 as well as PCBSD 7.1.1 detecting my > >>NIC properly. > >> > >>Please see below for some technical details related to the problem. > >> > >>output of less /var/run/dmesg.boot | grep re0 > >> > >>re0: port 0x2000-0x20ff > >>mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 > >>on pci3 > >>re0: Using 1 MSI messages > >>re0: Chip rev. 0x2480 > >>re0: MAC rev. 0x0040 > >>re0: Unknown H/W revision: 0x24c0 > >>device_attach: re0 attach returned 6 > >>re0: port 0x2000-0x20ff > >>mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 > >>on pci3 > >>re0: Using 1 MSI messages > >>re0: Chip rev. 0x2480 > >>re0: MAC rev. 0x0040 > >>re0: Unknown H/W revision: 0x24c0 > >>device_attach: re0 attach returned 6 > >>re0: port 0x2000-0x20ff > >>mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 > >>on pci3 > >>re0: Using 1 MSI messages > >>re0: Chip rev. 0x2480 > >>re0: MAC rev. 0x0040 > >>re0: Unknown H/W revision: 0x24c0 > >>device_attach: re0 attach returned 6 > >>re0: port 0x2000-0x20ff > >>mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 > >>on pci3 > >>re0: Using 1 MSI messages > >>re0: Chip rev. 0x2480 > >>re0: MAC rev. 0x0040 > >>re0: Unknown H/W revision: 0x24c0 > >>device_attach: re0 attach returned 6 > >> > >> > > > >Support for the controller was made in r195675 and the change was > >already MFCed to stable/8 and stable7. Try recent CURRENT or > >8/stable and 7/stable. I guess you can download the following files > >from latest stable/7 via web interface and rebuilding both re(4) > >and rl(4) on your 7.2-RELEASE should make your controller > >recognized. > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h > > > > > >>output of pciconf -l | grep re0 > >> > >>r...@pci0:3:0:0:class=0x02 card=0x306a103c chip=0x813610ec > >>rev=0x02 hdr=0x00 > >> > >>output of ifconfig > >> > >>ath0: flags=8802 metric 0 mtu 1500 > >>ether 00:24:2c:5e:06:f2 > >>media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > >>status: no carrier > >>ssid "" channel 1 (2412 Mhz 11b) > >>authmode OPEN privacy OFF txpower 50 bmiss 7 scanvalid 60 bgscan > >>bgscanintvl 300 bgscanidle 250 roam:rssi11b 7 roam:rate11b 1 burst > >>bintval 0 > >>lo0: flags=8049 metric 0 mtu 16384 > >>inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > >>inet6 ::1 prefixlen 128 > >>inet 127.0.0.1 netmask 0xff00 > >>pflog0: flags=0<> metric 0 mtu 33204 > >>pfsync0: flags=0<> metric 0 mtu 1460 > >>syncpeer: 224.0.0.240 maxupd: 128 > >> > >> > >>Please let me know if you require further details that might be of help. > >> > >>Look forward to hearing from anyone who would care to help at your > >>convenience. > >> > >>Regards, > >> > >>Alexander Kapshuk. > >> > > > > > Thanks a lot! I'll give it a go. > > I've never rebuilt a driver before. So I'll have to look into it. Can > the info on how to do it be found in the Handbook, or should I look > elsewhere? > Basically you may have to save your old driver sources to safe place. And download the three files above and copy them to appropriate source directory and rebuild kernel/reboot. For instance, after downloading, Copy if_re.c to /usr/src/sys/dev/re/ Copy if_rl.c to /usr/src/sys/pci/ Copy if_rlreg.h to /usr/src/sys/pci/ And rebuild kernel. Handbook may have instructions how to rebuild kernel. Good luck. > Thanks. > > ___ 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: Bug discussion:Tcp snd_nxt will not be increased.
Hi, Could you please tell us what version you are running? > > If the tcp_output just have some error, for example: when alloc mbuf, > it returns NULL, and then the snd_nxt number will not be return to > normal. > If just in this time, SYN Ack arrives, freeBSD can't handle this > situdition. > I have seen a related issue in older versions that I fixed, but it's from the SYN+ACK perspective. If my memory serves me right, local listener receives a SYN packet, transmits the SYN+ACK, but memory allocation fails, so the SYN+ACK packet was never transmitted onto the wire, however, the SEQ advanced by 1. As a result of SEQ update, the retransmitted SYN packet from the other end were discard as duplicates, eventually the connection times out. -- Qing ___ 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: trouble with Realtek NIC RTL8101E/RTL8102E under FreeBSD 7.2
Pyun YongHyeon wrote: On Thu, Dec 17, 2009 at 09:16:23PM +0200, Alexander Kaphuk wrote: Pyun YongHyeon wrote: On Thu, Dec 17, 2009 at 12:00:17PM +0200, Alexander Kapshuk wrote: Dear FreeBSD-net Community, I have trouble with FreeBSD 7.2 as well as PCBSD 7.1.1 detecting my NIC properly. Please see below for some technical details related to the problem. output of less /var/run/dmesg.boot | grep re0 re0: port 0x2000-0x20ff mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x2480 re0: MAC rev. 0x0040 re0: Unknown H/W revision: 0x24c0 device_attach: re0 attach returned 6 re0: port 0x2000-0x20ff mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x2480 re0: MAC rev. 0x0040 re0: Unknown H/W revision: 0x24c0 device_attach: re0 attach returned 6 re0: port 0x2000-0x20ff mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x2480 re0: MAC rev. 0x0040 re0: Unknown H/W revision: 0x24c0 device_attach: re0 attach returned 6 re0: port 0x2000-0x20ff mem 0xd401-0xd4010fff,0xd400-0xd400 irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x2480 re0: MAC rev. 0x0040 re0: Unknown H/W revision: 0x24c0 device_attach: re0 attach returned 6 Support for the controller was made in r195675 and the change was already MFCed to stable/8 and stable7. Try recent CURRENT or 8/stable and 7/stable. I guess you can download the following files >from latest stable/7 via web interface and rebuilding both re(4) and rl(4) on your 7.2-RELEASE should make your controller recognized. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h output of pciconf -l | grep re0 r...@pci0:3:0:0: class=0x02 card=0x306a103c chip=0x813610ec rev=0x02 hdr=0x00 output of ifconfig ath0: flags=8802 metric 0 mtu 1500 ether 00:24:2c:5e:06:f2 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 Mhz 11b) authmode OPEN privacy OFF txpower 50 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11b 7 roam:rate11b 1 burst bintval 0 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 pflog0: flags=0<> metric 0 mtu 33204 pfsync0: flags=0<> metric 0 mtu 1460 syncpeer: 224.0.0.240 maxupd: 128 Please let me know if you require further details that might be of help. Look forward to hearing from anyone who would care to help at your convenience. Regards, Alexander Kapshuk. Thanks a lot! I'll give it a go. I've never rebuilt a driver before. So I'll have to look into it. Can the info on how to do it be found in the Handbook, or should I look elsewhere? Basically you may have to save your old driver sources to safe place. And download the three files above and copy them to appropriate source directory and rebuild kernel/reboot. For instance, after downloading, Copy if_re.c to /usr/src/sys/dev/re/ Copy if_rl.c to /usr/src/sys/pci/ Copy if_rlreg.h to /usr/src/sys/pci/ And rebuild kernel. Handbook may have instructions how to rebuild kernel. Good luck. Thanks. No worries. Thanks a lot for your help once again! ___ 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"
