Bug/Missing implementation of udp proxying in libalias.
Hi all.
When looking thru the code (and manpage) in libalias i could see that
proxy_rules support udp packets. This is nice.. The only problem is that in
the udpPacketIn/out functions proxy rules is not checked. I wrote a small
patch that implements this and I've done some basic testing..
Patch is attached to this mail.
I couldn't see any maintainer for libalias and decided to write to -net. I
hope this is the right list :)
Comments ?
---
Nicolai Petri
catpipe Systems ApS
Copenhagen / Denmark
Ps. A volunteering commiter would be nice if the patch looks sane.
--- alias.c.orig Fri Nov 8 14:45:08 2002
+++ alias.c Mon Nov 11 11:38:46 2002
@@ -257,7 +257,7 @@
static int ProtoAliasIn(struct ip *);
static int ProtoAliasOut(struct ip *);
-static int UdpAliasOut(struct ip *);
+static int UdpAliasOut(struct ip *, int);
static int UdpAliasIn (struct ip *);
static int TcpAliasOut(struct ip *, int);
@@ -744,28 +744,28 @@
struct udphdr *ud;
struct alias_link *link;
-/* Return if proxy-only mode is enabled */
-if (packetAliasMode & PKT_ALIAS_PROXY_ONLY)
-return PKT_ALIAS_OK;
-
ud = (struct udphdr *) ((char *) pip + (pip->ip_hl << 2));
link = FindUdpTcpIn(pip->ip_src, pip->ip_dst,
ud->uh_sport, ud->uh_dport,
-IPPROTO_UDP, 1);
+IPPROTO_UDP, !(packetAliasMode & PKT_ALIAS_PROXY_ONLY));
if (link != NULL)
{
struct in_addr alias_address;
struct in_addr original_address;
+struct in_addr proxy_address;
u_short alias_port;
+u_short proxy_port;
int accumulate;
u_short *sptr;
- int r = 0;
+int r = 0;
alias_address = GetAliasAddress(link);
original_address = GetOriginalAddress(link);
+proxy_address = GetProxyAddress(link);
alias_port = ud->uh_dport;
ud->uh_dport = GetOriginalPort(link);
+proxy_port = GetProxyPort(link);
/* Special processing for IP encoding protocols */
if (ntohs(ud->uh_dport) == CUSEEME_PORT_NUMBER)
@@ -791,14 +791,48 @@
sptr = (u_short *) &original_address;
accumulate -= *sptr++;
accumulate -= *sptr;
+
+/* If this is a proxy packet, modify checksum because of source change.*/
+if (proxy_port != 0)
+{
+accumulate += ud->uh_sport;
+accumulate -= proxy_port;
+}
+
+ if (proxy_address.s_addr != 0)
+{
+ sptr = (u_short *) &pip->ip_src;
+accumulate += *sptr++;
+accumulate += *sptr;
+sptr = (u_short *) &proxy_address;
+accumulate -= *sptr++;
+accumulate -= *sptr;
+}
+
ADJUST_CHECKSUM(accumulate, ud->uh_sum);
+
}
+/* XXX: Could the two if's below be concatenated to one ? */
+/* Restore source port and/or address in case of proxying*/
+
+ if (proxy_port != 0)
+ud->uh_sport = proxy_port;
+
+ if (proxy_address.s_addr != 0)
+ {
+ DifferentialChecksum(&pip->ip_sum,
+ (u_short *) &proxy_address,
+ (u_short *) &pip->ip_src,
+ 2);
+pip->ip_src = proxy_address;
+ }
+
/* Restore original IP address */
DifferentialChecksum(&pip->ip_sum,
- (u_short *) &original_address,
- (u_short *) &pip->ip_dst,
- 2);
+ (u_short *) &original_address,
+ (u_short *) &pip->ip_dst,
+ 2);
pip->ip_dst = original_address;
/*
@@ -813,16 +847,57 @@
}
static int
-UdpAliasOut(struct ip *pip)
+UdpAliasOut(struct ip *pip, int maxpacketsize)
{
struct udphdr *ud;
struct alias_link *link;
+int proxy_type;
+u_short dest_port;
+u_short proxy_server_port;
+struct in_addr dest_address;
+struct in_addr proxy_server_address;
-/* Return if proxy-only mode is enabled */
-if (packetAliasMode & PKT_ALIAS_PROXY_ONLY)
+/* Return if proxy-only mode is enabled and not proxyrule found.*/
+ ud = (struct udphdr *) ((char *) pip + (pip->ip_hl << 2));
+
+ proxy_type = ProxyCheck(pip, &proxy_server_address, &proxy_server_port);
+
+ if (proxy_type == 0 && (packetAliasMode & PKT_ALIAS_PROXY_ONLY))
return PKT_ALIAS_OK;
-ud = (struct udphdr *) ((char *) pip + (pip->ip_hl << 2));
+/* If this is a transparent proxy, save original destination,
+ then alter the destination and adjust checksums */
+dest_port = ud->uh_dport;
+dest_address = pip->ip_dst;
+
+if (proxy_type != 0)
+{
+int accumulate;
+u_short *sptr;
+
+accumulate = ud->uh_dport;
+ud->uh_dport = proxy_server_port;
+accumulate -= ud->uh_dport;
+
+sptr = (u_short *) &(pip->ip_dst);
+accumulate += *sptr++;
+accumulate += *sptr;
Bug in pppd with CallBack
Hi!
I think i found bug in CBCP support in pppd 2.3.5.
When used AdminDefined Call Back I take:
rcvd [CBCP Request id=0x63 < AdminDefined delay = 0>]
length: 3
user admin defined allowed
cbcp_resp cb_type=8
cbcp_resp CONF_ADMIN
sent [CBCP Response id=0x63 < AdminDefined delay = 5 number = >]
rcvd [CBCP Request id=0x64 < AdminDefined delay = 0>]
length: 3
user admin defined allowed
cbcp_resp cb_type=8
cbcp_resp CONF_ADMIN
sent [CBCP Response id=0x64 < AdminDefined delay = 5 number = >]
rcvd [CBCP Request id=0x65 < AdminDefined delay = 0>]
Looks like pppd sends one byte more then required.
After applying patch i got normal connection:
rcvd [CBCP Request id=0x3d < AdminDefined delay = 0>]
length: 3
user admin defined allowed
cbcp_resp cb_type=8
cbcp_resp CONF_ADMIN
sent [CBCP Response id=0x3d < AdminDefined delay = 5>]
rcvd [CBCP Ack id=0x3e < AdminDefined delay = 5>]
id doesn't match: expected 61 recv 62
sent [LCP TermReq id=0x2 "Call me back, please"]
rcvd [LCP TermAck id=0x2]
May be this patch need to be commited into FreeBSD STABLE?
*** cbcp.c.orig Sat Aug 28 04:19:00 1999
--- cbcp.c Mon Nov 11 14:15:41 2002
***
*** 343,352
if (cb_type & ( 1 << CB_CONF_ADMIN ) ) {
syslog(LOG_DEBUG, "cbcp_resp CONF_ADMIN");
PUTCHAR(CB_CONF_ADMIN, bufp);
! len = 3 + 1;
PUTCHAR(len , bufp);
PUTCHAR(5, bufp); /* delay */
- PUTCHAR(0, bufp);
cbcp_send(us, CBCP_RESP, buf, len);
return;
}
--- 343,351
if (cb_type & ( 1 << CB_CONF_ADMIN ) ) {
syslog(LOG_DEBUG, "cbcp_resp CONF_ADMIN");
PUTCHAR(CB_CONF_ADMIN, bufp);
! len = 3;
PUTCHAR(len , bufp);
PUTCHAR(5, bufp); /* delay */
cbcp_send(us, CBCP_RESP, buf, len);
return;
}
--
Alexander Motin [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Problem in High Speed and Long Delay with FreeBSD
> sockbuf datalen snd_time rcv_time > - > 16384 15000 0.0000.617 > 15 14 0.0034.021 > 50 495000 0.01514.083 > 100 995000 0.04228.577 > 150 149 0.07947.986 > 160 159 0.08844.055 > 180 179 0.10850.810 > 190 189 0.11755.010 > 200 199 1.01157.666 > 210 209 3.84560.233 > 300 299 39.594 122.308 Folks- Thanks for all the suggestions. This is what I get for comparing apples and oranges. The results from above were hacked out late one night on my home machine (4.7) which is certainly not tuned as well as the lab machines Cindy and Fran have been using. It looks like I was limited by the number of mbuf clusters. The 4.1 machines at the lab are not. The kernel easily swallows any of the above amount of data. However... I will say that I think it is bogus that freebsd blocked my (asyncronous) write() call when it was out of mbuf clusters. I think it would be nice if that were fixed. Back to the drawing board... (Joe is digging through the TCP code and chasing a couple of things.) Thanks again! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
mpd & mrtg
Hi, I've built a PPTP server using mpd. Now I'd like to keep track of "total VPN utilization" -- total bits moved by all VPN users -- using SNMP or MRTG. I'm just not sure which interface or netgraph node I should try to measure. Does anyone have any suggestions that might help me get started? Thanks -- JD --- John David Duncan Systems Administrator GreatSchools, Inc. (415) 977-0700 x115 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: mpd & mrtg
Various of the netgraph modules wil report back statisitics. Netstat gan give you stats on the ng interfaces, and standard snmpd can give you stats on a per-interface basis which is probably all you need. Also, mpd can give you stasts via the console interface. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Strange Problems with NIS and DNS/BIND on same system.
Hi I am wondering if anyone could shed some light on this problem, I have been scouring google and the FreeBSD newsgroups and found nothing in regards to an answer to his problem. It appears that several people have had this problem, but I never found any follow up messages or replies. I hope this is going to the appropriate news groups, apologies to the freebsd-net subscribers if everyone feels this is 'off topic' but then again I'm running a FreeBSD 4.7 server on a dual processor PIII 500 with 1GB of ram. It's configured as a DNS server and an NIS/YP master server. I am running bind 8.3.3-RELEASE and was compiled localy with gcc-3.2. I am receiving numerous messages in my system log (/var/log/messages) from ypserv Nov 10 16:35:16 samba1 ypserv[79]: DNS query failed Nov 10 16:35:16 samba1 ypserv[79]: res_mkquery failed Nov 10 16:35:47 samba1 last message repeated 43 times Nov 10 16:37:48 samba1 last message repeated 171 times Nov 10 16:47:49 samba1 last message repeated 840 times I also ran a 'truss' on named and I see the following messages: recvfrom(0x14,0xbfbfea40,0x1001,0x0,0xbfbffa50,0xbfbfea3c) ERR#35 'Resource temporarily unavailable' Any clues to what might be happening? I don't have any problems, accessing various domains and can do dns queries and lookups without any problems. Nothing seems to be amiss when doing an 'nslookup' and setting debug mode on... Funny thing is is that I have only seen these kinds of messages when running FreeBSD and Linux as an NIS master server, never when running Solaris, AIX or IRIX as an NIS master server. Thank you very much for any help! Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: forwarded message on Source Quench Packets.
(redirected to -net so others can review this) I can see how these source quench messages would cause problems if a DoS is being routed through a FreeBSD router, and I think that your patch makes sense. Are there any objections to me committing this in a few days? Mike "Silby" Silbersack On Mon, 11 Nov 2002, David Gilbert wrote: > I normally wouldn't forward something to such a big list, but this has > real implications (and was part of a nast DOS against dsl.ca last > week). The patch for FreeBSD (netbsd code is quoted) is trivial: > > --- /sys/netinet/ip_input.c Thu Oct 17 08:29:53 2002 > +++ ip_input.c Mon Nov 11 15:15:31 2002 > @@ -1822,9 +1822,7 @@ > break; > > case ENOBUFS: > - type = ICMP_SOURCEQUENCH; > - code = 0; > - break; > + return; > > case EACCES:/* ipfw denied packet */ > m_freem(mcopy); > > I'm submitting a PR now. > > For discussion: source quenches probably shouldn't be generated > anyways, but this patch also doesn't generate the source quench if > we're the target machine. It's probably good to go straight ahead > with this. IIRC, tcp_input.c also can generate a source quench > ... > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
