Removal of deprecated implied connect for TCP
When T/TCP RFC1644 support was introduced in r6283 by wollman 15 years
ago the semantics of sendto(2) with regard to TCP sockets were changed.
It became possible directly do a sendto(2) call with the target address in
the *to argument instead of doing a connect(2) first and subsequent write(2)
or send(2) calls as the standard TCP API specifies. Optionally MSG_EOR
could be specified to close the connection again right again after the
data has been sent out.
This is totally non-portable and no other OS (Linux, NetBSD, OpenBSD,
Solaris, HP-UX) ever supported this functionality for TCP sockets.
FreeBSD was the only OS to ever ship this.
T/TCP was ill-defined and had major security issues and never gained
any support. It has been defunct in FreeBSD and most code has been
removed about 6 years ago. The sendto(2) extended functionality is one
of the last parts that persisted and remained around living a zombie life.
I want to remove it now because it is totally non-portable, has no
known users and complicates the TCP send path. The patch is attached.
If you have any objections speak up now.
--
Andre
Index: netinet/tcp_usrreq.c
===
--- netinet/tcp_usrreq.c(revision 211874)
+++ netinet/tcp_usrreq.c(working copy)
@@ -740,86 +740,34 @@
int error = 0;
struct inpcb *inp;
struct tcpcb *tp = NULL;
- int headlocked = 0;
-#ifdef INET6
- int isipv6;
-#endif
+
TCPDEBUG0;
- /*
-* We require the pcbinfo lock in two cases:
-*
-* (1) An implied connect is taking place, which can result in
-* binding IPs and ports and hence modification of the pcb hash
-* chains.
-*
-* (2) PRUS_EOF is set, resulting in explicit close on the send.
-*/
- if ((nam != NULL) || (flags & PRUS_EOF)) {
- INP_INFO_WLOCK(&V_tcbinfo);
- headlocked = 1;
+ /* TCP doesn't do control messages (rights, creds, etc.) */
+ if (control != NULL && control->m_len) {
+ error = EINVAL;
+ goto out;
}
+
inp = sotoinpcb(so);
- KASSERT(inp != NULL, ("tcp_usr_send: inp == NULL"));
+ KASSERT(inp != NULL, ("%s: inp == NULL", __func__));
INP_WLOCK(inp);
- if (inp->inp_flags & (INP_TIMEWAIT | INP_DROPPED)) {
- if (control)
- m_freem(control);
- if (m)
- m_freem(m);
+ if (inp->inp_flags & (INP_DROPPED | INP_TIMEWAIT)) {
error = ECONNRESET;
- goto out;
+ goto done;
}
-#ifdef INET6
- isipv6 = nam && nam->sa_family == AF_INET6;
-#endif /* INET6 */
tp = intotcpcb(inp);
+
TCPDEBUG1();
- if (control) {
- /* TCP doesn't do control messages (rights, creds, etc) */
- if (control->m_len) {
- m_freem(control);
- if (m)
- m_freem(m);
- error = EINVAL;
- goto out;
- }
- m_freem(control); /* empty control, just free it */
- }
+
+ /*
+* Append the new data to the send socket buffer and
+* try to send it (may be limited by CWND).
+*/
if (!(flags & PRUS_OOB)) {
sbappendstream(&so->so_snd, m);
- if (nam && tp->t_state < TCPS_SYN_SENT) {
- /*
-* Do implied connect if not yet connected,
-* initialize window to default value, and
-* initialize maxseg/maxopd using peer's cached
-* MSS.
-*/
- INP_INFO_WLOCK_ASSERT(&V_tcbinfo);
-#ifdef INET6
- if (isipv6)
- error = tcp6_connect(tp, nam, td);
- else
-#endif /* INET6 */
- error = tcp_connect(tp, nam, td);
- if (error)
- goto out;
- tp->snd_wnd = TTCP_CLIENT_SND_WND;
- tcp_mss(tp, -1);
- }
- if (flags & PRUS_EOF) {
- /*
-* Close the send side of the connection after
-* the data is sent.
-*/
- INP_INFO_WLOCK_ASSERT(&V_tcbinfo);
- socantsendmore(so);
- tcp_usrclosed(tp);
- }
- if (headlocked) {
- INP_INFO_WUNLOCK(&V_tcbinfo);
- headlocked = 0;
- }
+ m = NULL;
+
if (!(inp->inp_flags & INP_DROPPED)) {
if (flags & PRUS_MORETOCOME)
Default router changes unexpectedly
Hi, I am using FreeBSD 7.3 STABLE-201004. IPFW + In kernel NAT and if_vlan used mostly. System has 3 em interfaces. Scenario is classical, LAN DMZ WAN. Sometimes default router changes unexpectedly. I inspected logs if someone logged in or changed route. I found nothing. This problem repeats at least 1 times per day. I wrote a shell script which monitors the default router. I saw that sometimes netstat -rn shows that default router is changed as 10.3.1.64 or 10.5.3.189 etc. which are client IP addresses but routing still routes to right router 212.X.Y.Z . After a while, routing really fails. I use em nics for all. At the weekends (when most clients are now working) i dont have any problems. I think some network packets affects the defaultrouter. I tried to block packets belongs to the IP addresses which shown as default router (10.3.1.64, 10.5.3.189 etc.. ). Then the problem is solved. I wonder how the default router can be changed with packets that came from network? How can i prevent this without writing firewall rules? Or which packets should I drop? Any ideas? Regards, Ozkan KIRIK Mersin University @ Turkey ___ 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"
Default router changes unexpectedly
Hi, I am using FreeBSD 7.3 STABLE-201004. IPFW + In kernel NAT and if_vlan used mostly. System has 3 em interfaces. Scenario is classical, LAN DMZ WAN. Sometimes default router changes unexpectedly. I inspected logs if someone logged in or changed route. I found nothing. This problem repeats at least 1 times per day. I wrote a shell script which monitors the default router. I saw that sometimes netstat -rn shows that default router is changed as 10.3.1.64 or 10.5.3.189 etc. which are client IP addresses but routing still routes to right router 212.X.Y.Z . After a while, routing really fails. I use em nics for all. At the weekends (when most clients are now working) i dont have any problems. I think some network packets affects the defaultrouter. I tried to block packets belongs to the IP addresses which shown as default router (10.3.1.64, 10.5.3.189 etc.. ). Then the problem is solved. I wonder how the default router can be changed with packets that came from network? How can i prevent this without writing firewall rules? Or which packets should I drop? Any ideas? Regards, Ozkan KIRIK Mersin University @ Turkey ___ 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"
How to configure specific router address to advertise with rtadvd?
I have a machine I want to do IPv6 routing. The interface out which its sending router advertisements has multiple static IPv6 addresses assigned from the same prefix. The problem is rtadvd is selecting the "wrong" address for the router. The man page for rtadvd.conf doesn't indicate how to do this. How do I tell rtadvd which address to advertise as the router? ___ 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"
How to configure non-EUI64 IPv6 addresses with solicited prefixes?
I have two machines where I need them to: 1. Solicit a prefix; 2. Apply the solicitation to a non-EUI64 address; 3. Use the non-EUI64 address as the default source address. Retaining the EUI64 address is not necessary. Static configuration prevents 1 and I have not been able to get 2 or 3 to work at all. The original KAME documentation implies this is/was possible, but current documentation says nothing about it (not that I can find, anyway). A grep of /etc/* indicates interface_ipv6_ifid_* variables (mentioned in the KAME documentation) are not supported. One is running 8.1, the other 6.4 (I can upgrade it if necessary). ___ 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: Default router changes unexpectedly
On 08/29/10 19:50, Özkan KIRIK wrote: Hi, I am using FreeBSD 7.3 STABLE-201004. IPFW + In kernel NAT and if_vlan used mostly. System has 3 em interfaces. Scenario is classical, LAN DMZ WAN. Sometimes default router changes unexpectedly. I inspected logs if someone logged in or changed route. I found nothing. This problem repeats at least 1 times per day. I wrote a shell script which monitors the default router. I saw that sometimes netstat -rn shows that default router is changed as 10.3.1.64 or 10.5.3.189 etc. which are client IP addresses but routing still routes to right router 212.X.Y.Z . After a while, routing really fails. I use em nics for all. At the weekends (when most clients are now working) i dont have any problems. I think some network packets affects the defaultrouter. I tried to block packets belongs to the IP addresses which shown as default router (10.3.1.64, 10.5.3.189 etc.. ). Then the problem is solved. I wonder how the default router can be changed with packets that came from network? How can i prevent this without writing firewall rules? Or which packets should I drop? Any ideas? Özkan, just one: Do you see RIP (521/tcp, 521/udp) traffic? Volker ___ 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: Default router changes unexpectedly
Hi Volker, There is no routing deamon working on this gateway. But I started a tcpdump that listening to port 521. I'll inform you about captured packets. Regards, Ozkan KIRIK Mersin University @ Turkey On Sun, Aug 29, 2010 at 10:09 PM, wrote: > On 08/29/10 19:50, Özkan KIRIK wrote: >> >> Hi, >> >> I am using FreeBSD 7.3 STABLE-201004. IPFW + In kernel NAT and if_vlan >> used mostly. >> System has 3 em interfaces. Scenario is classical, LAN DMZ WAN. >> >> Sometimes default router changes unexpectedly. I inspected logs if >> someone logged in or changed route. I found nothing. >> This problem repeats at least 1 times per day. I wrote a shell script >> which monitors the default router. >> I saw that sometimes netstat -rn shows that default router is changed >> as 10.3.1.64 or 10.5.3.189 etc. which are client IP addresses but >> routing still routes to right router 212.X.Y.Z . >> After a while, routing really fails. >> I use em nics for all. >> At the weekends (when most clients are now working) i dont have any >> problems. I'll correct the type above: At the weekends (when most clients are noT working) i dont have any problems. >> I think some network packets affects the defaultrouter. >> I tried to block packets belongs to the IP addresses which shown as >> default router (10.3.1.64, 10.5.3.189 etc.. ). Then the problem is >> solved. >> >> I wonder how the default router can be changed with packets that came >> from network? >> How can i prevent this without writing firewall rules? >> Or which packets should I drop? >> >> Any ideas? > > Özkan, > > just one: Do you see RIP (521/tcp, 521/udp) traffic? > > Volker > ___ 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/149969: [wlan] [ral] ralink rt2661 fails to maintain connection
Synopsis: [wlan] [ral] ralink rt2661 fails to maintain connection State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Sun Aug 29 20:27:52 UTC 2010 State-Changed-Why: David, does the device work for your if you disable powersave operation? Please note: For your IRQ question, the asterisk in the output indicates more devices being assigned to that IRQ but vmstat -i is unable to display all. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sun Aug 29 20:27:52 UTC 2010 Responsible-Changed-Why: over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=149969 ___ 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: How to configure non-EUI64 IPv6 addresses with solicited prefixes?
On Sun, Aug 29, 2010 at 2:47 PM, Darren Pilgrim wrote:
> I have two machines where I need them to:
>
> 1. Solicit a prefix;
> 2. Apply the solicitation to a non-EUI64 address;
> 3. Use the non-EUI64 address as the default source address.
>
> Retaining the EUI64 address is not necessary. Static configuration prevents
> 1 and I have not been able to get 2 or 3 to work at all. The original KAME
> documentation implies this is/was possible, but current documentation says
> nothing about it (not that I can find, anyway). A grep of /etc/* indicates
> interface_ipv6_ifid_* variables (mentioned in the KAME documentation) are
> not supported.
>
Your choices are:
1) Static IPv6 address using rc.conf variables
or
2) RA IPv6 address using EUI64
or
3) RA IPv6 address using EUI64 + IPv6 address with Random IID EUI64
(only in head right now via rc.conf, otherwise needs sysctl entries
for older code)
{net.inet6.ip6.use_tempaddr/net.inet6.ip6.prefer_tempaddr} RFC3041
Doug B, how about an MFC to RELENG_8 of the relevant bits for privacy
addresses in rc.conf. ? It is fairly self-contained.
or a bit more work
4) Install a DHCPv6 client and roll your own configuration via dhcpv6
server config.
or even more work
5) Submit a patch for review that does what you want.
I'm certain that someone will come up with other options as well.
Probably best to read the rc.conf man page, and /etc/defaults/rc.conf
as well, although I can not seem to find any documentation on the
use_tempaddr/prefer_tempaddr sysctls at the moment.
Can you be specific on what you want to use instead of EUI64, or is
this just a case of I want a dynamic prefix, and a static last 64 bits
that are NOT EUI64 derived ? For example, are you wanting to use
PREFIX::42 or something where PREFIX would be 2001:db8:: or the like
which would result in 2001:db8::42/64 ?
EUI64 without privacy extensions gives a fairly reliable static
address (barring DAD issues with another mis-configured host).
RFC3041 privacy extensions gives you both the normal (mac based IID)
EUI64 address AND the random Interface Identifier (IID) EUI64 address.
Are you just worried about EUI64 on the global address, or are you
wanting it for link-local (fe80::) as well ?
> One is running 8.1, the other 6.4 (I can upgrade it if necessary).
6.4 (and RELENG 6) are due to be EOL at the end of November, so
probably best to consider your upgrade strategy.
http://www.freebsd.org/security/#sup
Good Luck.
--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: kern/149969: [wlan] [ral] ralink rt2661 fails to maintain connection
The following reply was made to PR kern/149969; it has been noted by GNATS. From: David Gurvich To: bug-follo...@freebsd.org, davidgurv...@gmail.com Cc: Subject: Re: kern/149969: [wlan] [ral] ralink rt2661 fails to maintain connection Date: Sun, 29 Aug 2010 21:30:09 -0400 --001636284f88b99398048f006758 Content-Type: text/plain; charset=ISO-8859-1 Perhaps I am disabling powersave incorrectly? In rc.conf the ifconfig_wlan0="WPA DHCP -powersave". I've also tried on the command line "ifconfig wlan0 -powersave". If I do the same thing with ral0 I get an error that the argument is not valid. --001636284f88b99398048f006758 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps I am disabling powersave incorrectly?=A0 In rc.conf the ifconfig_wl= an0=3D"WPA DHCP -powersave".=A0 I've also tried on the comman= d line "ifconfig wlan0 -powersave".=A0 If I do the same thing wit= h ral0 I get an error that the argument is not valid. --001636284f88b99398048f006758-- ___ 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: Sending packets at Kernel level
On 8/28/10 10:16 PM, Sadish Kulasekere wrote: Hi, I need to know how to send packet from the kernel level. Can someone please point me to any documentation? look how nfs does it... or the netgraph ksocket code does it too. maybe just use netgraph ksocket directly.. You don't say what you want to do. Cheers, Sadish. ___ 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"
