Re: PANIC in tcp_syncache.c sonewconn() line 562
Hi Thomas,
> s = splnet();
> + if (so->so_state & (SS_ISCONNECTED | SS_ISCONNECTING)) {
> + splx(s);
> + return (EINVAL);
> + }
> error = (*so->so_proto->pr_usrreqs->pru_listen)(so, td);
> if (error) {
> splx(s);
>
Can you commit this ? The fix looks appropriate, but the manpage should
also be changed to reflect the change.
ERRORS
Listen() will fail if:
[EBADF]The argument s is not a valid descriptor.
[ENOTSOCK] The argument s is not a socket.
[EOPNOTSUPP] The socket is not of a type that
supports the operation listen().
[EINVAL] Listen() has been already called on the socket.
Any objections from others ?
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: PANIC in tcp_syncache.c sonewconn() line 562
Martin Blapp wrote: > Can you commit this ? The fix looks appropriate, but the manpage should > also be changed to reflect the change. > > ERRORS > Listen() will fail if: > > [EBADF]The argument s is not a valid descriptor. > [ENOTSOCK] The argument s is not a socket. > [EOPNOTSUPP] The socket is not of a type that > supports the operation listen(). > [EINVAL] Listen() has been already called on the socket. > > Any objections from others ? It seems to me that calling listen() on a socket to change the listen queue depth is a reasonable thing to do; this is true before it's bound, after it's bound, before listen() has been called on it, and after listen() has been called on it once (or more). Am I missing something here? Is there a good technical reason to not permit an application to change the listen queue depth? Or is there some way that an application can do this, using a call other than listen()? That it causes a panic when the SYN cache is enabled isn't really a technical reason, it's a circumstantial reason. I can think of a lot of programs that might be based on FreeBSD, which would have a CLI that would let you change the wait queue (e.g. a Layer 7 load balancer, or an application proxy), where closing and reopening it -- and losing the pending connections which have performed the SYN/SYN-ACK/ACK, but have not had accept called on them yt), where it would not just be a legitimate use, it would be a required feature. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: PANIC in tcp_syncache.c sonewconn() line 562
On Tue, 2003/01/14 at 02:51:03 -0800, Terry Lambert wrote: > Martin Blapp wrote: > > Can you commit this ? The fix looks appropriate, but the manpage should > > also be changed to reflect the change. > > > > ERRORS > > Listen() will fail if: > > > > [EBADF]The argument s is not a valid descriptor. > > [ENOTSOCK] The argument s is not a socket. > > [EOPNOTSUPP] The socket is not of a type that > > supports the operation listen(). > > [EINVAL] Listen() has been already called on the socket. > > > > Any objections from others ? > > It seems to me that calling listen() on a socket to change the > listen queue depth is a reasonable thing to do; this is true > before it's bound, after it's bound, before listen() has been > called on it, and after listen() has been called on it once (or > more). > > Am I missing something here? Is there a good technical reason > to not permit an application to change the listen queue depth? > Or is there some way that an application can do this, using a > call other than listen()? > > That it causes a panic when the SYN cache is enabled isn't really > a technical reason, it's a circumstantial reason. The manpage change does not reflect the change in the patch :) It should be: [EINVAL]The socket is connected. - Thomas -- Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/ <[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: PANIC in tcp_syncache.c sonewconn() line 562
Thomas Moestl wrote: > > > [EINVAL] Listen() has been already called on the socket. > The manpage change does not reflect the change in the patch :) > It should be: > > [EINVAL]The socket is connected. Oh. That's very different. Never mind. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
ng_sppp version 1.1
Hi, I just release new version of ng_sppp. Have anybody try this driver? Changes: Fixed: It was wrong to stop sending packets if an interface is not !running or !up. Added: Manual page was added. Best regards, Roman Kurakin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
ng_sppp version 1.1
Hi, I just release new version of ng_sppp. Have anybody try this driver? Changes: Fixed: It was wrong to stop sending packets if an interface is not !running or !up. Added: Manual page was added. Best regards, Roman Kurakin ng_sppp-1.1.tgz Description: application/compressed
Re: PANIC in tcp_syncache.c sonewconn() line 562
On Tue, 14 Jan 2003, Martin Blapp wrote:
>
> Hi Thomas,
>
> > s = splnet();
> > + if (so->so_state & (SS_ISCONNECTED | SS_ISCONNECTING)) {
> > + splx(s);
> > + return (EINVAL);
> > + }
> > error = (*so->so_proto->pr_usrreqs->pru_listen)(so, td);
> > if (error) {
> > splx(s);
> >
>
> Can you commit this ? The fix looks appropriate, but the manpage should
> also be changed to reflect the change.
>
> ERRORS
> Listen() will fail if:
>
> [EBADF]The argument s is not a valid descriptor.
> [ENOTSOCK] The argument s is not a socket.
> [EOPNOTSUPP] The socket is not of a type that
> supports the operation listen().
> [EINVAL] Listen() has been already called on the socket.
>
> Any objections from others ?
EINVAL is a bogus errno for this, but is standard. POSIX has better
wording: "The socket is already connected". The patch also returns
EINVAL if the socket is being connected. Is this right? (Maybe we
should wait until we can tell if it is connected.)
POSIX also specifies the errors EDESTADDRREQ, EACCES, another EINVAL for
shut down sockets, and ENOBUFS. The last 3 "may" cause listen() to fail
and the others (including the first EINVAL) "shall" cause it to fail.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: PPTP tunneling over PPPoE link
| That bug has been fixed, in sys/netgraph/ng_pptpgre.c revisions | 1.26 and 1.2.2.13. | | http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_pptpgre.c Any plans to commit relevant patches to -stable branch? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
3COM 3C996-SX (bge) fibre support?
I see in the cvs comments that this card is supported (1.11 of if_bge.c). The relevant change seems to be: + /* +* Figure out what sort of media we have by checking the +* hardware config word in the EEPROM. Note: on some BCM5700 +* cards, this value appears to be unset. If that's the +* case, we have to rely on identifying the NIC by its PCI +* subsystem ID, as we do below for the SysKonnect SK-9D41. +*/ + bge_read_eeprom(sc, (caddr_t)&hwcfg, + BGE_EE_HWCFG_OFFSET, sizeof(hwcfg)); + if ((ntohl(hwcfg) & BGE_HWCFG_MEDIA) == BGE_MEDIA_FIBER) + sc->bge_tbi = 1; sadly, I have a phy-id of 0, so I think I have to use the hackish method the SK... uses, just below it: /* The SysKonnect SK-9D41 is a 1000baseSX card. */ if ((pci_read_config(dev, BGE_PCI_SUBSYS, 4) >> 16) == SK_SUBSYSID_9D41) sc->bge_tbi = 1; I have the subsystem etc (side-node: there's a bug in the above code, it should check the vendor id as well): PCI sub-devid 0x1004 PCI PCI sub-vid 0x10b7 So I added a line of the SK_... type above, to set the 'bge_tbi' to one for my 1000baseSX card. However, I see this interface 'flapping', I get snowed with messages to my console about 'link up' (but never link down). I tried forcing the media & mediaopts to 1000Mbps and full-duplex. The other end of the link sees nothing (no link). Anyone have a suggestion on where to start? I suspect this is related to the comment about "One thing that confuses me still is that the 'link state change' bit in the status block seems to change state an awful lot." (1.10). --don To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
PR/47044
Hi, We are facing similar issues mention in PR/47044. This is on a 4.6-stable box running sendmail 8.12.6 http://www.freebsd.org/cgi/query-pr.cgi?pr=47044 One more data point I would like to mention. When I do a telnet to a host:port where no service is running. Sometimes I get "Connection refused", sometimes I get "Can't assign requested address" so I am not certain if this is a sendmail issue # telnet 208.23.118.222 smtp Trying 208.23.118.222... telnet: connect to address 208.23.118.222: Connection refused telnet: Unable to connect to remote host # telnet 208.23.118.222 smtp Trying 208.23.118.222... telnet: connect to address 208.23.118.222: Can't assign requested address telnet: Unable to connect to remote host -- Yusuf Goolamabbas [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: PR/47044
On Wed, 15 Jan 2003, Yusuf Goolamabbas wrote: > http://www.freebsd.org/cgi/query-pr.cgi?pr=47044 > One more data point I would like to mention. When I do a telnet to a > host:port where no service is running. Sometimes I get "Connection > refused", sometimes I get "Can't assign requested address" so I am not > certain if this is a sendmail issue > > # telnet 208.23.118.222 smtp > Trying 208.23.118.222... > telnet: connect to address 208.23.118.222: Connection refused > telnet: Unable to connect to remote host > # telnet 208.23.118.222 smtp > Trying 208.23.118.222... > telnet: connect to address 208.23.118.222: Can't assign requested address > telnet: Unable to connect to remote host This is almost certaintly related to not having your network devices properly configured. Do a google groups search on "Can't assign requested address" and you will likely find what I am talking about. Long story short, if lo0 and/or the ethernet port is mangled and/or the dns is mangled, etc. You will have these problems. My PR is on a box which I fully believe is configured correctly (although I can't vouch for it). Drop me a copy of "ifconfig -a" and "netstat -rn" and also a copy of /etc/rc.conf and I will see If I can see anything. - Forrest W. Christian ([EMAIL PROTECTED]) AC7DE -- The Innovation Machine Ltd. P.O. Box 5749 http://www.imach.com/Helena, MT 59604 Home of PacketFlux Technologies and BackupDNS.com (406)-442-6648 -- Protect your personal freedoms - visit http://www.lp.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
ipfw: blocking syn floods - two proposed rules
My goal is to create an ipfw rule that stops normal syn floods by blocking ALL syn packets that have no MSS set. My understanding is that there is no legitimate packet that is a SYN and has no MSS, and further, most of the kiddie tools in existence for syn flooding do indeed send syn packets with no MSS. Here is what I came up with: ipfw add 1 deny tcp from any to any tcpoptions !mss setup the rationale here is that I am blocking all tcp connections with no MSS, provided that they are in the setup phase - and the man page for ipfw states: setup TCP packets only. Match packets that have the SYN bit set but no ACK bit. So therefore I would get all the no mss syn packets, and I wouldn't inadvertantly get a syn+ack packet ... I am mainly worried about this because I do not know for sure if a syn+ack packet with no MSS is legitimate...just in case there are some, I thought this would be a good rule. Next: ipfw add 1 deny tcp from any to any tcpoptions !mss tcpflags syn Same idea, but I explicitly define it to match _any_ packet that contains a syn and has no MSS - so theoretically there could be other flags besides syn set as well and I would still drop it. Again, I am worried because, although I know that there are no syn-only packets with no MSS, I am not sure if there are ever (in the wild) syn+(other flags) packets with no MSS. Comments ? Finally: ipfw add 1 deny tcp from any to any tcpoptions !mss tcpflags syn !ack I am fairly certain that this rule is _functionally identical_ to the first rule which used the setup keyword. --- So, any comments ? Which of these is best ? And given my original goal: "to create an ipfw rule that stops normal syn floods by blocking ALL syn packets that have no MSS set." will whatever rule above is the best one accomplish that goal ? Will there be unintended consequences like all sorts of lost traffic and customers complaining and me locked out of my firewall etc ? I specify 1 in all those rules above because I really do plan on putting it as my first (or so) rule... comments appreciated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
