freebsd-hackers Digest, Vol 176, Issue 8
freebsd-hac...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
or, via email, send a message with subject or body 'help' to
freebsd-hac...@freebsd.org
You can reach the person managing the list at
freebsd-ha...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-hackers digest..."
Today's Topics:
1. Re: getting interface MAC addr from C (Robert Watson)
2. Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs
(Gleb Smirnoff)
3. RFC 919 compliance (broadcasts to 255.255.255.255) (Benjamin Lutz)
4. Re: RFC 919 compliance (broadcasts to 255.255.255.255)
(Andrey V. Elsukov)
5. Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs
(Joao Barros)
6. Re: getting interface MAC addr from C (Michal Mertl)
7. Re: RFC 919 compliance (broadcasts to 255.255.255.255)
(Andre Oppermann)
8. Re: RFC 919 compliance (broadcasts to 255.255.255.255)
(Andrey V. Elsukov)
9. Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs
(Gleb Smirnoff)
10. Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs
(Julian Elischer)
11. linux ioremap equivalent on freebsd (Niki Denev)
12. Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs
(Joao Barros)
13. Re: RFC 919 compliance (broadcasts to 255.255.255.255)
(Mohacsi Janos)
14. Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs
(Joao Barros)
15. pthreads memoty leak? (Igor A. Valcov)
16. Re: miibus + USB = problem ? (Hans Petter Selasky)
17. Re: RFC 919 compliance (broadcasts to 255.255.255.255)
(Benjamin Lutz)
----------------------------------------------------------------------
Message: 1
Date: Fri, 4 Aug 2006 13:43:56 +0100 (BST)
From: Robert Watson <rwa...@FreeBSD.org>
Subject: Re: getting interface MAC addr from C
To: Mario Lobo <mario...@ipad.com.br>
Cc: freebsd...@freebsd.org
Message-ID: <2006080413...@fledge.watson.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 4 Aug 2006, Mario Lobo wrote:
> Would anyone have a tip on how to get the MAC from a C program?
>
> I tried:
>
> struct ifreq ifreq;
> unsigned char *hw;
>
> strcpy(ifreq.ifr_name, "rl0");
> ioctl(fd, SIOCGIFMAC, &ifreq);
> hw = ifreq.ifr_ifru.ifru_data; ????
>
> but i don't know if this is right or, if it is, where to get the MAC from
> the structure. I doesn't issue any error compiling or running though.
Usually the general purpose interface recommended for inspecting interface
information is getifaddrs(), which will build a userspace list of interfaces
and their various addresses, including link-layer addresses. Something like
the above will work, but may not be preferred.
Robert N M Watson
Computer Laboratory
University of Cambridge
>
> In linux i used:
>
> struct ifreq ifreq;
> unsigned char *hw;
>
> strcpy(ifreq.ifr_name, "rl0");
> ioctl(fd, SIOCGIFHWADDR, &ifreq);
> hw = ifreq.ifr_hwaddr.sa_data;
>
> Thanks,
>
> Mario
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>
------------------------------
Message: 2
Date: Fri, 4 Aug 2006 19:03:02 +0400
From: Gleb Smirnoff <gle...@FreeBSD.org>
Subject: Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs
To: Joao Barros <joao....@gmail.com>
Cc: freebsd...@FreeBSD.org, Julian Elischer <jul...@FreeBSD.org>
Message-ID: <20060804150...@cell.sick.ru>
Content-Type: text/plain; charset="koi8-r"
On Thu, Aug 03, 2006 at 03:35:04PM +0100, Joao Barros wrote:
J> I recently switched ISPs which in turn led me from a cablemodem to an
J> ADSL modem.
J> After setting PPPoE up I started noticing this messages in the daily
J> run outputs that that nice guy Charlie root sends me at 3am:
J>
J> Aug 3 08:24:54 ultra5 kernel: session in wrong state
J>
J> I was a bit suspicious of anything PPPoE related and a little search
J> confirmed that, pointing directly at ng_pppoe.c
J> Being this a cryptic message to say the least and to probably save
J> someone some time when presented with this message I attach a patch
J> that adds the header "pppoe:" in every printf that didn't have it,
J> making it consistent with the rest of the file.
J> I also noticed this message appears right before the ISP closes the
J> connection due to time limit.
J>
J> I'm CCing those I see were the last ones to commit to this file and
J> will file a PR if asked to.
I've attached a patch that cleans a bit logging in ng_pppoe. It changes
all printf(9) to log(9). The latter is better since it spams console
less, if event occurs many times per second. Also I've made the messages
more clear - prepended node ID where possible, function name when it
starts with ng_pppoe, or just "ng_pppoe".
Can you please try out this patch and tell whether you like it. If you
do I will commit it soon.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
-------------- next part --------------
Index: ng_pppoe.c
===================================================================
RCS file: /home/ncvs/src/sys/netgraph/ng_pppoe.c,v
retrieving revision 1.78
diff -u -p -r1.78 ng_pppoe.c
--- ng_pppoe.c 27 Jan 2006 10:56:22 -0000 1.78
+++ ng_pppoe.c 4 Aug 2006 15:00:30 -0000
@@ -48,6 +48,7 @@
#include <sys/mbuf.h>
#include <sys/malloc.h>
#include <sys/errno.h>
+#include <sys/syslog.h>
#include <net/ethernet.h>
#include <netgraph/ng_message.h>
@@ -261,7 +262,7 @@ union uniq {
#define LEAVE(x) do { error = x; goto quit; } while(0)
static void pppoe_start(sessp sp);
-static void sendpacket(sessp sp);
+static void ng_pppoe_sendpacket(sessp sp);
static void pppoe_ticker(node_p node, hook_p hook, void *arg1, int arg2);
static const struct pppoe_tag *scan_tags(sessp sp,
const struct pppoe_hdr* ph);
@@ -383,7 +384,8 @@ insert_tag(sessp sp, const struct pppoe_
if ((i = neg->numtags++) < NUMTAGS) {
neg->tags[i] = tp;
} else {
- printf("pppoe: asked to add too many tags to packet\n");
+ log(LOG_NOTICE, "ng_pppoe: asked to add too many tags to "
+ "packet\n");
neg->numtags--;
}
}
@@ -406,7 +408,7 @@ make_packet(sessp sp) {
uint16_t length = 0;
KASSERT((sp->neg != NULL) && (sp->neg->m != NULL),
- ("%s: make_packet called from wrong state", __func__));
+ ("%s: called from wrong state", __func__));
CTR2(KTR_NET, "%20s: called %d", __func__, sp->Session_ID);
dp = (char *)wh->ph.tag;
@@ -415,7 +417,7 @@ make_packet(sessp sp) {
tag++, count++) {
tlen = ntohs((*tag)->tag_len) + sizeof(**tag);
if ((length + tlen) > (ETHER_MAX_LEN - 4 - sizeof(*wh))) {
- printf("pppoe: tags too long\n");
+ log(LOG_NOTICE, "ng_pppoe: tags too long\n");
sp->neg->numtags = count;
break; /* XXX chop off what's too long */
}
@@ -714,18 +716,21 @@ ng_pppoe_rcvmsg(node_p node, item_p item
case NGM_PPPOE_SERVICE:
ourmsg = (struct ngpppoe_init_data *)msg->data;
if (msg->header.arglen < sizeof(*ourmsg)) {
- printf("pppoe: init data too small\n");
+ log(LOG_ERR, "ng_pppoe[%x]: init data too "
+ "small\n", node->nd_ID);
LEAVE(EMSGSIZE);
}
if (msg->header.arglen - sizeof(*ourmsg) >
PPPOE_SERVICE_NAME_SIZE) {
- printf("pppoe_rcvmsg: service name too big");
+ log(LOG_ERR, "ng_pppoe[%x]: service name "
+ "too big\n", node->nd_ID);
LEAVE(EMSGSIZE);
}
if (msg->header.arglen - sizeof(*ourmsg) <
ourmsg->data_len) {
- printf("pppoe: init data has bad length,"
- " %d should be %zd\n", ourmsg->data_len,
+ log(LOG_ERR, "ng_pppoe[%x]: init data has bad "
+ "length, %d should be %zd\n", node->nd_ID,
+ ourmsg->data_len,
msg->header.arglen - sizeof (*ourmsg));
LEAVE(EMSGSIZE);
}
@@ -767,7 +772,8 @@ ng_pppoe_rcvmsg(node_p node, item_p item
break;
if (sp->state != PPPOE_SNONE) {
- printf("pppoe: Session already active\n");
+ log(LOG_NOTICE, "ng_pppoe[%x]: Session already "
+ "active\n", node->nd_ID);
LEAVE(EISCONN);
}
@@ -882,7 +888,8 @@ ng_pppoe_rcvmsg(node_p node, item_p item
* If you do it twice you just overwrite.
*/
if (sp->state != PPPOE_PRIMED) {
- printf("pppoe: Session not primed\n");
+ log(LOG_NOTICE, "ng_pppoe[%x]: session not "
+ "primed\n", node->nd_ID);
LEAVE(EISCONN);
}
neg = sp->neg;
@@ -1012,7 +1019,7 @@ pppoe_start(sessp sp)
insert_tag(sp, &uniqtag.hdr);
insert_tag(sp, &sp->neg->service.hdr);
make_packet(sp);
- sendpacket(sp);
+ ng_pppoe_sendpacket(sp);
}
static int
@@ -1105,7 +1112,8 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
if( m->m_len < sizeof(*wh)) {
m = m_pullup(m, sizeof(*wh)); /* Checks length */
if (m == NULL) {
- printf("couldn't m_pullup\n");
+ log(LOG_NOTICE, "ng_pppoe[%x]: couldn't "
+ "m_pullup(wh)\n", node->nd_ID);
LEAVE(ENOBUFS);
}
}
@@ -1124,7 +1132,10 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
if( m->m_len < m->m_pkthdr.len) {
m = m_pullup(m, m->m_pkthdr.len);
if (m == NULL) {
- printf("couldn't m_pullup\n");
+ log(LOG_NOTICE, "ng_pppoe[%x]: "
+ "couldn't "
+ "m_pullup(pkthdr)\n",
+ node->nd_ID);
LEAVE(ENOBUFS);
}
}
@@ -1147,7 +1158,8 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
}
}
if (m == NULL) {
- printf("packet fragmented\n");
+ log(LOG_NOTICE, "ng_pppoe[%x]: packet "
+ "fragmented\n", node->nd_ID);
LEAVE(EMSGSIZE);
}
}
@@ -1204,13 +1216,15 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
utag = get_tag(ph, PTT_HOST_UNIQ);
if ((utag == NULL)
|| (ntohs(utag->tag_len) != sizeof(sp))) {
- printf("no host unique field\n");
+ log(LOG_NOTICE, "ng_pppoe[%x]: no host "
+ "unique field\n", node->nd_ID);
LEAVE(ENETUNREACH);
}
sendhook = pppoe_finduniq(node, utag);
if (sendhook == NULL) {
- printf("no matching session\n");
+ log(LOG_NOTICE, "ng_pppoe[%x]: no "
+ "matching session\n", node->nd_ID);
LEAVE(ENETUNREACH);
}
@@ -1220,7 +1234,8 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
*/
sp = NG_HOOK_PRIVATE(sendhook);
if (sp->state != PPPOE_SINIT) {
- printf("session in wrong state\n");
+ log(LOG_NOTICE, "ng_pppoe[%x]: session "
+ "in wrong state\n", node->nd_ID);
LEAVE(ENETUNREACH);
}
neg = sp->neg;
@@ -1249,7 +1264,7 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
scan_tags(sp, ph);
make_packet(sp);
sp->state = PPPOE_SREQ;
- sendpacket(sp);
+ ng_pppoe_sendpacket(sp);
break;
case PADR_CODE:
@@ -1311,7 +1326,7 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
scan_tags(sp, ph);
make_packet(sp);
sp->state = PPPOE_NEWCONNECTED;
- sendpacket(sp);
+ ng_pppoe_sendpacket(sp);
/*
* Having sent the last Negotiation header,
* Set up the stored packet header to
@@ -1560,7 +1575,7 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
insert_tag(sp, &uniqtag.hdr);
scan_tags(sp, ph);
make_packet(sp);
- sendpacket(sp);
+ ng_pppoe_sendpacket(sp);
break;
/*
@@ -1655,8 +1670,9 @@ ng_pppoe_disconnect(hook_p hook)
/* Generate a packet of that type. */
MGETHDR(m, M_DONTWAIT, MT_DATA);
- if(m == NULL)
- printf("pppoe: Session out of mbufs\n");
+ if (m == NULL)
+ log(LOG_NOTICE, "ng_pppoe[%x]: session out of "
+ "mbufs\n", node->nd_ID);
else {
m->m_pkthdr.rcvif = NULL;
m->m_pkthdr.len = m->m_len = sizeof(*wh);
@@ -1749,13 +1765,14 @@ pppoe_ticker(node_p node, hook_p hook, v
break;
default:
/* Timeouts have no meaning in other states. */
- printf("pppoe: unexpected timeout\n");
+ log(LOG_NOTICE, "ng_pppoe[%x]: unexpected timeout\n",
+ node->nd_ID);
}
}
static void
-sendpacket(sessp sp)
+ng_pppoe_sendpacket(sessp sp)
{
struct mbuf *m0 = NULL;
hook_p hook = sp->hook;
@@ -1770,7 +1787,8 @@ sendpacket(sessp sp)
case PPPOE_DEAD:
case PPPOE_SNONE:
case PPPOE_CONNECTED:
- printf("pppoe: sendpacket: unexpected state\n");
+ log(LOG_NOTICE, "%s: unexpected state %d\n",
+ __func__, sp->state);
break;
case PPPOE_NEWCONNECTED:
@@ -1807,7 +1825,7 @@ sendpacket(sessp sp)
default:
error = EINVAL;
- printf("pppoe: timeout: bad state\n");
+ log(LOG_NOTICE, "%s: bad state %d\n", __func__, sp->state);
}
}
------------------------------
Message: 3
Date: Fri, 4 Aug 2006 17:12:11 +0200
From: Benjamin Lutz <ben...@datacomm.ch>
Subject: RFC 919 compliance (broadcasts to 255.255.255.255)
To: freebsd...@freebsd.org
Message-ID: <200608041712....@datacomm.ch>
Content-Type: text/plain; charset="us-ascii"
Hello,
I've noticed that FreeBSD does not by default comply to RFC 919, Chapter 7
(http://tools.ietf.org/html/rfc919). Specifically, it does not handle IP
packets with a destination address of 255.255.255.255 properly.
255.255.255.255 is a "limited broadcast address" (the term is not mentioned in
the RFC, but seems to be in use everywhere else). An IP packet send to that
address should be broadcast to the whole IP subnet of the broadcasting
device. However, in FreeBSD (4.11, 5.5, 6.1) this does not work, as is
evident by this tcpdump output:
17:00:59.125132 00:12:17:5a:b3:b6 > 00:40:63:d9:a9:28, ethertype IPv4
(0x0800), length 98: 10.0.0.1 > 255.255.255.255: ICMP echo request, id 33319,
seq 0, length 64
The destination MAC address is that of my gateway, but it should be
ff:ff:ff:ff:ff:ff. You can reproduce this by running "tcpdump -en ip proto 1"
and "ping 255.255.255.255".
I found a discussion from 2003 about this, but it seems to have trailed off
without coming to a conclusion:
http://lists.freebsd.org/pipermail/freebsd-net/2003-July/000921.html
I've noticed that the ip(7) manpage lists a SO_ONESBCAST option. The intention
seems to be to enable packets to 255.255.255.255. However a test with a small
program showed that this option seems to have no effect, outgoing packets
still carried the gateway's MAC address as destination.
Btw, Linux and NetBSD both handle packets to 255.255.255.255 as broadcasts.
Now, is this behaviour intentional? Is there a way to turn on RFC 919
compliance? If not, would someone be willing to add this to the kernel? Should
I submit a PR?
Cheers
Benjamin
------------------------------
Message: 4
Date: Fri, 4 Aug 2006 19:37:58 +0400 (MSD)
From: "Andrey V. Elsukov" <bu7...@yandex.ru>
Subject: Re: RFC 919 compliance (broadcasts to 255.255.255.255)
To: ben...@datacomm.ch
Cc: freebsd...@freebsd.org
Message-ID: <44D369D6.0...@mfront7.yandex.ru>
Content-Type: text/plain; charset="US-ASCII"
>I found a discussion from 2003 about this, but it seems to have trailed off
>without coming to a conclusion:
>http://lists.freebsd.org/pipermail/freebsd-net/2003-July/000921.html
I've opened a similar PR
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/99558
--
WBR, Andrey V. Elsukov
------------------------------
Message: 5
Date: Fri, 4 Aug 2006 16:48:49 +0100
From: "Joao Barros" <joao....@gmail.com>
Subject: Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs
To: "Gleb Smirnoff" <gle...@freebsd.org>
Cc: freebsd...@freebsd.org
Message-ID:
<70e8236f0608040848x304...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 8/4/06, Gleb Smirnoff <gle...@freebsd.org> wrote:
> On Thu, Aug 03, 2006 at 03:35:04PM +0100, Joao Barros wrote:
> J> Being this a cryptic message to say the least and to probably save
> J> someone some time when presented with this message I attach a patch
> J> that adds the header "pppoe:" in every printf that didn't have it,
> J> making it consistent with the rest of the file.
>
> I've attached a patch that cleans a bit logging in ng_pppoe. It changes
> all printf(9) to log(9). The latter is better since it spams console
> less, if event occurs many times per second. Also I've made the messages
> more clear - prepended node ID where possible, function name when it
> starts with ng_pppoe, or just "ng_pppoe".
>
> Can you please try out this patch and tell whether you like it. If you
> do I will commit it soon.
Hi,
I've looked at the patch and it looks ok.
It serves the purpose: make the messages more clear with the added
bonus of more info.
Thanks for taking the time to look into this :-)
--
Joao Barros
------------------------------
Message: 6
Date: Fri, 04 Aug 2006 18:15:47 +0200
From: Michal Mertl <mi...@traveller.cz>
Subject: Re: getting interface MAC addr from C
To: Mario Lobo <mario...@ipad.com.br>
Cc: freebsd...@freebsd.org
Message-ID: <1154708147.3...@genius.i.cz>
Content-Type: text/plain; charset="us-ascii"
Mario Lobo wrote:
> Hi;
>
> Would anyone have a tip on how to get the MAC from a C program?
>
> I tried:
>
> struct ifreq ifreq;
> unsigned char *hw;
>
> strcpy(ifreq.ifr_name, "rl0");
> ioctl(fd, SIOCGIFMAC, &ifreq);
> hw = ifreq.ifr_ifru.ifru_data; ????
This is probably very far from what you want. MAC stands here for MAC(4)
- e.g. security related stuff as opposed to something network (did you
read MAC as Media Access Control?).
I don't know it that is the easiest/right way to get this information
but you can use getifaddrs(3). Attached find a simple program which
prints out the interfaces and their MAC addresses using getifaddrs().
The code for getting the printable address is taken from function
fmt_sockaddr() from src/usr.bin/netstat/route.c.
You can also probably use SIOCGIFADDR with the right socket passed in as
fd or with sysctl(3) (int mib[] = { CTL_NET, AF_ROUTE, 0, AF_LINK,
NET_RT_IFLIST, 0}).
> but i don't know if this is right or, if it is, where to get the MAC from the
> structure. I doesn't issue any error compiling or running though.
>
> In linux i used:
>
> struct ifreq ifreq;
> unsigned char *hw;
>
> strcpy(ifreq.ifr_name, "rl0");
> ioctl(fd, SIOCGIFHWADDR, &ifreq);
> hw = ifreq.ifr_hwaddr.sa_data;
>
> Thanks,
>
> Mario
>
HTH
Michal
------------------------------
Message: 7
Date: Fri, 04 Aug 2006 20:04:11 +0200
From: Andre Oppermann <an...@freebsd.org>
Subject: Re: RFC 919 compliance (broadcasts to 255.255.255.255)
To: bu7...@yandex.ru
Cc: ben...@datacomm.ch, freebsd...@freebsd.org
Message-ID: <44D38C1B...@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Andrey V. Elsukov wrote:
>>I found a discussion from 2003 about this, but it seems to have trailed off
>>without coming to a conclusion:
>>http://lists.freebsd.org/pipermail/freebsd-net/2003-July/000921.html
>
>
> I've opened a similar PR
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/99558
This PR is in the works and I have produced a first (non-working unfortunately)
patch some time ago. I've just come back from two+half week vacation and have
to catch up to things again. It is not forgotten.
--
Andre
------------------------------
Message: 8
Date: Fri, 4 Aug 2006 22:19:19 +0400 (MSD)
From: "Andrey V. Elsukov" <bu7...@yandex.ru>
Subject: Re: RFC 919 compliance (broadcasts to 255.255.255.255)
To: an...@freebsd.org
Cc: freebsd...@freebsd.org
Message-ID: <44D38FA7.0...@soapbox.yandex.ru>
Content-Type: text/plain; charset="US-ASCII"
>This PR is in the works and I have produced a first (non-working unfortunately)
>patch some time ago. I've just come back from two+half week vacation and have
>to catch up to things again. It is not forgotten.
Ok :)
Thanks for your work!
--
WBR, Andrey V. Elsukov
------------------------------
Message: 9
Date: Fri, 4 Aug 2006 22:21:23 +0400
From: Gleb Smirnoff <gle...@FreeBSD.org>
Subject: Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs
To: Joao Barros <joao....@gmail.com>
Cc: freebsd...@FreeBSD.org, Julian Elischer <jul...@FreeBSD.org>
Message-ID: <20060804182...@cell.sick.ru>
Content-Type: text/plain; charset=koi8-r
On Fri, Aug 04, 2006 at 04:48:49PM +0100, Joao Barros wrote:
J> On 8/4/06, Gleb Smirnoff <gle...@freebsd.org> wrote:
J> >On Thu, Aug 03, 2006 at 03:35:04PM +0100, Joao Barros wrote:
J> >J> Being this a cryptic message to say the least and to probably save
J> >J> someone some time when presented with this message I attach a patch
J> >J> that adds the header "pppoe:" in every printf that didn't have it,
J> >J> making it consistent with the rest of the file.
J> >
J> >I've attached a patch that cleans a bit logging in ng_pppoe. It changes
J> >all printf(9) to log(9). The latter is better since it spams console
J> >less, if event occurs many times per second. Also I've made the messages
J> >more clear - prepended node ID where possible, function name when it
J> >starts with ng_pppoe, or just "ng_pppoe".
J> >
J> >Can you please try out this patch and tell whether you like it. If you
J> >do I will commit it soon.
J>
J> Hi,
J>
J> I've looked at the patch and it looks ok.
J> It serves the purpose: make the messages more clear with the added
J> bonus of more info.
J> Thanks for taking the time to look into this :-)
Since I don't use ng_pppoe now much, I'd appreciate if you
do at brief test of this patch, before I commit it.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
------------------------------
Message: 10
Date: Fri, 04 Aug 2006 13:22:21 -0700
From: Julian Elischer <jul...@elischer.org>
Subject: Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs
To: Gleb Smirnoff <gle...@FreeBSD.org>
Cc: freebsd...@FreeBSD.org, Joao Barros <joao....@gmail.com>,
Julian Elischer <jul...@FreeBSD.org>
Message-ID: <44D3AC7D...@elischer.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Gleb Smirnoff wrote:
>On Thu, Aug 03, 2006 at 03:35:04PM +0100, Joao Barros wrote:
>J> I recently switched ISPs which in turn led me from a cablemodem to an
>J> ADSL modem.
>J> After setting PPPoE up I started noticing this messages in the daily
>J> run outputs that that nice guy Charlie root sends me at 3am:
>J>
>J> Aug 3 08:24:54 ultra5 kernel: session in wrong state
>J>
>J> I was a bit suspicious of anything PPPoE related and a little search
>J> confirmed that, pointing directly at ng_pppoe.c
>J> Being this a cryptic message to say the least and to probably save
>J> someone some time when presented with this message I attach a patch
>J> that adds the header "pppoe:" in every printf that didn't have it,
>J> making it consistent with the rest of the file.
>J> I also noticed this message appears right before the ISP closes the
>J> connection due to time limit.
>J>
>J> I'm CCing those I see were the last ones to commit to this file and
>J> will file a PR if asked to.
>
>
>I've attached a patch that cleans a bit logging in ng_pppoe. It changes
>all printf(9) to log(9). The latter is better since it spams console
>less, if event occurs many times per second. Also I've made the messages
>more clear - prepended node ID where possible, function name when it
>starts with ng_pppoe, or just "ng_pppoe".
>
>Can you please try out this patch and tell whether you like it. If you
>do I will commit it soon.
>
>
>
I like the look of it..
much of my code should use log() instead of printf() in such cases I think.
>------------------------------------------------------------------------
>
>Index: ng_pppoe.c
>===================================================================
>RCS file: /home/ncvs/src/sys/netgraph/ng_pppoe.c,v
>retrieving revision 1.78
>diff -u -p -r1.78 ng_pppoe.c
>--- ng_pppoe.c 27 Jan 2006 10:56:22 -0000 1.78
>+++ ng_pppoe.c 4 Aug 2006 15:00:30 -0000
>@@ -48,6 +48,7 @@
> #include <sys/mbuf.h>
> #include <sys/malloc.h>
> #include <sys/errno.h>
>+#include <sys/syslog.h>
> #include <net/ethernet.h>
>
> #include <netgraph/ng_message.h>
>@@ -261,7 +262,7 @@ union uniq {
>
> #define LEAVE(x) do { error = x; goto quit; } while(0)
> static void pppoe_start(sessp sp);
>-static void sendpacket(sessp sp);
>+static void ng_pppoe_sendpacket(sessp sp);
> static void pppoe_ticker(node_p node, hook_p hook, void *arg1, int arg2);
> static const struct pppoe_tag *scan_tags(sessp sp,
> const struct pppoe_hdr* ph);
>@@ -383,7 +384,8 @@ insert_tag(sessp sp, const struct pppoe_
> if ((i = neg->numtags++) < NUMTAGS) {
> neg->tags[i] = tp;
> } else {
>- printf("pppoe: asked to add too many tags to packet\n");
>+ log(LOG_NOTICE, "ng_pppoe: asked to add too many tags to "
>+ "packet\n");
> neg->numtags--;
> }
> }
>@@ -406,7 +408,7 @@ make_packet(sessp sp) {
> uint16_t length = 0;
>
> KASSERT((sp->neg != NULL) && (sp->neg->m != NULL),
>- ("%s: make_packet called from wrong state", __func__));
>+ ("%s: called from wrong state", __func__));
> CTR2(KTR_NET, "%20s: called %d", __func__, sp->Session_ID);
>
> dp = (char *)wh->ph.tag;
>@@ -415,7 +417,7 @@ make_packet(sessp sp) {
> tag++, count++) {
> tlen = ntohs((*tag)->tag_len) + sizeof(**tag);
> if ((length + tlen) > (ETHER_MAX_LEN - 4 - sizeof(*wh))) {
>- printf("pppoe: tags too long\n");
>+ log(LOG_NOTICE, "ng_pppoe: tags too long\n");
> sp->neg->numtags = count;
> break; /* XXX chop off what's too long */
> }
>@@ -714,18 +716,21 @@ ng_pppoe_rcvmsg(node_p node, item_p item
> case NGM_PPPOE_SERVICE:
> ourmsg = (struct ngpppoe_init_data *)msg->data;
> if (msg->header.arglen < sizeof(*ourmsg)) {
>- printf("pppoe: init data too small\n");
>+ log(LOG_ERR, "ng_pppoe[%x]: init data too "
>+ "small\n", node->nd_ID);
> LEAVE(EMSGSIZE);
> }
> if (msg->header.arglen - sizeof(*ourmsg) >
> PPPOE_SERVICE_NAME_SIZE) {
>- printf("pppoe_rcvmsg: service name too big");
>+ log(LOG_ERR, "ng_pppoe[%x]: service name "
>+ "too big\n", node->nd_ID);
> LEAVE(EMSGSIZE);
> }
> if (msg->header.arglen - sizeof(*ourmsg) <
> ourmsg->data_len) {
>- printf("pppoe: init data has bad length,"
>- " %d should be %zd\n", ourmsg->data_len,
>+ log(LOG_ERR, "ng_pppoe[%x]: init data has bad "
>+ "length, %d should be %zd\n", node->nd_ID,
>+ ourmsg->data_len,
> msg->header.arglen - sizeof (*ourmsg));
> LEAVE(EMSGSIZE);
> }
>@@ -767,7 +772,8 @@ ng_pppoe_rcvmsg(node_p node, item_p item
> break;
>
> if (sp->state != PPPOE_SNONE) {
>- printf("pppoe: Session already active\n");
>+ log(LOG_NOTICE, "ng_pppoe[%x]: Session already "
>+ "active\n", node->nd_ID);
> LEAVE(EISCONN);
> }
>
>@@ -882,7 +888,8 @@ ng_pppoe_rcvmsg(node_p node, item_p item
> * If you do it twice you just overwrite.
> */
> if (sp->state != PPPOE_PRIMED) {
>- printf("pppoe: Session not primed\n");
>+ log(LOG_NOTICE, "ng_pppoe[%x]: session not "
>+ "primed\n", node->nd_ID);
> LEAVE(EISCONN);
> }
> neg = sp->neg;
>@@ -1012,7 +1019,7 @@ pppoe_start(sessp sp)
> insert_tag(sp, &uniqtag.hdr);
> insert_tag(sp, &sp->neg->service.hdr);
> make_packet(sp);
>- sendpacket(sp);
>+ ng_pppoe_sendpacket(sp);
> }
>
> static int
>@@ -1105,7 +1112,8 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
> if( m->m_len < sizeof(*wh)) {
> m = m_pullup(m, sizeof(*wh)); /* Checks length */
> if (m == NULL) {
>- printf("couldn't m_pullup\n");
>+ log(LOG_NOTICE, "ng_pppoe[%x]: couldn't "
>+ "m_pullup(wh)\n", node->nd_ID);
> LEAVE(ENOBUFS);
> }
> }
>@@ -1124,7 +1132,10 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
> if( m->m_len < m->m_pkthdr.len) {
> m = m_pullup(m, m->m_pkthdr.len);
> if (m == NULL) {
>- printf("couldn't m_pullup\n");
>+ log(LOG_NOTICE, "ng_pppoe[%x]: "
>+ "couldn't "
>+ "m_pullup(pkthdr)\n",
>+ node->nd_ID);
> LEAVE(ENOBUFS);
> }
> }
>@@ -1147,7 +1158,8 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
> }
> }
> if (m == NULL) {
>- printf("packet fragmented\n");
>+ log(LOG_NOTICE, "ng_pppoe[%x]: packet "
>+ "fragmented\n", node->nd_ID);
> LEAVE(EMSGSIZE);
> }
> }
>@@ -1204,13 +1216,15 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
> utag = get_tag(ph, PTT_HOST_UNIQ);
> if ((utag == NULL)
> || (ntohs(utag->tag_len) != sizeof(sp))) {
>- printf("no host unique field\n");
>+ log(LOG_NOTICE, "ng_pppoe[%x]: no host "
>+ "unique field\n", node->nd_ID);
> LEAVE(ENETUNREACH);
> }
>
> sendhook = pppoe_finduniq(node, utag);
> if (sendhook == NULL) {
>- printf("no matching session\n");
>+ log(LOG_NOTICE, "ng_pppoe[%x]: no "
>+ "matching session\n", node->nd_ID);
> LEAVE(ENETUNREACH);
> }
>
>@@ -1220,7 +1234,8 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
> */
> sp = NG_HOOK_PRIVATE(sendhook);
> if (sp->state != PPPOE_SINIT) {
>- printf("session in wrong state\n");
>+ log(LOG_NOTICE, "ng_pppoe[%x]: session "
>+ "in wrong state\n", node->nd_ID);
> LEAVE(ENETUNREACH);
> }
> neg = sp->neg;
>@@ -1249,7 +1264,7 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
> scan_tags(sp, ph);
> make_packet(sp);
> sp->state = PPPOE_SREQ;
>- sendpacket(sp);
>+ ng_pppoe_sendpacket(sp);
> break;
> case PADR_CODE:
>
>@@ -1311,7 +1326,7 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
> scan_tags(sp, ph);
> make_packet(sp);
> sp->state = PPPOE_NEWCONNECTED;
>- sendpacket(sp);
>+ ng_pppoe_sendpacket(sp);
> /*
> * Having sent the last Negotiation header,
> * Set up the stored packet header to
>@@ -1560,7 +1575,7 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite
> insert_tag(sp, &uniqtag.hdr);
> scan_tags(sp, ph);
> make_packet(sp);
>- sendpacket(sp);
>+ ng_pppoe_sendpacket(sp);
> break;
>
> /*
>@@ -1655,8 +1670,9 @@ ng_pppoe_disconnect(hook_p hook)
>
> /* Generate a packet of that type. */
> MGETHDR(m, M_DONTWAIT, MT_DATA);
>- if(m == NULL)
>- printf("pppoe: Session out of mbufs\n");
>+ if (m == NULL)
>+ log(LOG_NOTICE, "ng_pppoe[%x]: session out of "
>+ "mbufs\n", node->nd_ID);
> else {
> m->m_pkthdr.rcvif = NULL;
> m->m_pkthdr.len = m->m_len = sizeof(*wh);
>@@ -1749,13 +1765,14 @@ pppoe_ticker(node_p node, hook_p hook, v
> break;
> default:
> /* Timeouts have no meaning in other states. */
>- printf("pppoe: unexpected timeout\n");
>+ log(LOG_NOTICE, "ng_pppoe[%x]: unexpected timeout\n",
>+ node->nd_ID);
> }
> }
>
>
> static void
>-sendpacket(sessp sp)
>+ng_pppoe_sendpacket(sessp sp)
> {
> struct mbuf *m0 = NULL;
> hook_p hook = sp->hook;
>@@ -1770,7 +1787,8 @@ sendpacket(sessp sp)
> case PPPOE_DEAD:
> case PPPOE_SNONE:
> case PPPOE_CONNECTED:
>- printf("pppoe: sendpacket: unexpected state\n");
>+ log(LOG_NOTICE, "%s: unexpected state %d\n",
>+ __func__, sp->state);
> break;
>
> case PPPOE_NEWCONNECTED:
>@@ -1807,7 +1825,7 @@ sendpacket(sessp sp)
>
> default:
> error = EINVAL;
>- printf("pppoe: timeout: bad state\n");
>+ log(LOG_NOTICE, "%s: bad state %d\n", __func__, sp->state);
> }
> }
>
>
>
------------------------------
Message: 11
Date: Sat, 05 Aug 2006 00:59:15 +0300
From: Niki Denev <nik...@cytexbg.com>
Subject: linux ioremap equivalent on freebsd
To: freebsd...@freebsd.org
Message-ID: <44D3C333...@cytexbg.com>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I'm in the middle of a struggle to port the linux
nozomi(Option GloberTrotter 3G+ HSDPA cardbus adapter) driver to freebsd.
And given the fact that i have very little previous kernel coding experience i
can't find what i can use in freebsd as equivalent of linux's ioremap().
Any ideas are appreciated. Thanks!
P.S.: here is the original linux driver http://www.pharscape.org/3G/nozomi_2.1_060703.tar.gz
Regards,
Niki Denev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE08MzHNAJ/fLbfrkRAgjHAJ9diB4h2nsrGKZyznNl3nzlRPgQfQCgkN/3
6LsQAU03xH9+gaARrzoevIE=
=2iMR
-----END PGP SIGNATURE-----
------------------------------
Message: 12
Date: Sat, 5 Aug 2006 00:42:12 +0100
From: "Joao Barros" <joao....@gmail.com>
Subject: Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs
To: "Gleb Smirnoff" <gle...@freebsd.org>
Cc: freebsd...@freebsd.org
Message-ID:
<70e8236f0608041642v5c7...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 8/4/06, Gleb Smirnoff <gle...@freebsd.org> wrote:
> On Fri, Aug 04, 2006 at 04:48:49PM +0100, Joao Barros wrote:
> J> On 8/4/06, Gleb Smirnoff <gle...@freebsd.org> wrote:
> J> >On Thu, Aug 03, 2006 at 03:35:04PM +0100, Joao Barros wrote:
> J> >J> Being this a cryptic message to say the least and to probably save
> J> >J> someone some time when presented with this message I attach a patch
> J> >J> that adds the header "pppoe:" in every printf that didn't have it,
> J> >J> making it consistent with the rest of the file.
> J> >
> J> >I've attached a patch that cleans a bit logging in ng_pppoe. It changes
> J> >all printf(9) to log(9). The latter is better since it spams console
> J> >less, if event occurs many times per second. Also I've made the messages
> J> >more clear - prepended node ID where possible, function name when it
> J> >starts with ng_pppoe, or just "ng_pppoe".
> J> >
> J> >Can you please try out this patch and tell whether you like it. If you
> J> >do I will commit it soon.
> J>
> J> Hi,
> J>
> J> I've looked at the patch and it looks ok.
> J> It serves the purpose: make the messages more clear with the added
> J> bonus of more info.
> J> Thanks for taking the time to look into this :-)
>
> Since I don't use ng_pppoe now much, I'd appreciate if you
> do at brief test of this patch, before I commit it.
>
I patched and recompiled the kernel.
After booting I notice that no messages from ppp are logged by syslog
(messages|ppp.log)
If I restart ppp the messages are all logged.
I can't say if this was happening because after setting ppp up I
didn't reboot the machine.
I didn't browse the startup scripts but maybe syslog is not started
before pppoe.
Now it will take more than 17 hours for the session limit to be
exceeded and only then I can say how your patch worked out. I'll make
an update then.
--
Joao Barros
------------------------------
Message: 13
Date: Sat, 5 Aug 2006 07:18:54 +0200 (CEST)
From: Mohacsi Janos <moh...@niif.hu>
Subject: Re: RFC 919 compliance (broadcasts to 255.255.255.255)
To: Benjamin Lutz <ben...@datacomm.ch>
Cc: freebsd...@freebsd.org
Message-ID: <2006080507...@mignon.ki.iif.hu>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 4 Aug 2006, Benjamin Lutz wrote:
> Hello,
>
> I've noticed that FreeBSD does not by default comply to RFC 919, Chapter 7
> (http://tools.ietf.org/html/rfc919). Specifically, it does not handle IP
> packets with a destination address of 255.255.255.255 properly.
>
> 255.255.255.255 is a "limited broadcast address" (the term is not mentioned in
> the RFC, but seems to be in use everywhere else). An IP packet send to that
> address should be broadcast to the whole IP subnet of the broadcasting
> device. However, in FreeBSD (4.11, 5.5, 6.1) this does not work, as is
> evident by this tcpdump output:
>
> 17:00:59.125132 00:12:17:5a:b3:b6 > 00:40:63:d9:a9:28, ethertype IPv4
> (0x0800), length 98: 10.0.0.1 > 255.255.255.255: ICMP echo request, id 33319,
> seq 0, length 64
>
> The destination MAC address is that of my gateway, but it should be
> ff:ff:ff:ff:ff:ff. You can reproduce this by running "tcpdump -en ip proto 1"
> and "ping 255.255.255.255".
>
> I found a discussion from 2003 about this, but it seems to have trailed off
> without coming to a conclusion:
> http://lists.freebsd.org/pipermail/freebsd-net/2003-July/000921.html
>
> I've noticed that the ip(7) manpage lists a SO_ONESBCAST option. The intention
> seems to be to enable packets to 255.255.255.255. However a test with a small
> program showed that this option seems to have no effect, outgoing packets
> still carried the gateway's MAC address as destination.
>
> Btw, Linux and NetBSD both handle packets to 255.255.255.255 as broadcasts.
>
> Now, is this behaviour intentional? Is there a way to turn on RFC 919
> compliance? If not, would someone be willing to add this to the kernel? Should
> I submit a PR?
Does this feature really necessary? For waht purpose? I believe this
feature is more harmful than useful.
Regards,
Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98
>
> Cheers
> Benjamin
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>
------------------------------
Message: 14
Date: Sat, 5 Aug 2006 09:51:22 +0100
From: "Joao Barros" <joao....@gmail.com>
Subject: Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs
To: "Gleb Smirnoff" <gle...@freebsd.org>
Cc: freebsd...@freebsd.org
Message-ID:
<70e8236f0608050151p558...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 8/5/06, Joao Barros <joao....@gmail.com> wrote:
> On 8/4/06, Gleb Smirnoff <gle...@freebsd.org> wrote:
> > On Fri, Aug 04, 2006 at 04:48:49PM +0100, Joao Barros wrote:
> > J> On 8/4/06, Gleb Smirnoff <gle...@freebsd.org> wrote:
> > J> >On Thu, Aug 03, 2006 at 03:35:04PM +0100, Joao Barros wrote:
> > J> >J> Being this a cryptic message to say the least and to probably save
> > J> >J> someone some time when presented with this message I attach a patch
> > J> >J> that adds the header "pppoe:" in every printf that didn't have it,
> > J> >J> making it consistent with the rest of the file.
> > J> >
> > J> >I've attached a patch that cleans a bit logging in ng_pppoe. It changes
> > J> >all printf(9) to log(9). The latter is better since it spams console
> > J> >less, if event occurs many times per second. Also I've made the messages
> > J> >more clear - prepended node ID where possible, function name when it
> > J> >starts with ng_pppoe, or just "ng_pppoe".
> > J> >
> > J> >Can you please try out this patch and tell whether you like it. If you
> > J> >do I will commit it soon.
> > J>
> > J> Hi,
> > J>
> > J> I've looked at the patch and it looks ok.
> > J> It serves the purpose: make the messages more clear with the added
> > J> bonus of more info.
> > J> Thanks for taking the time to look into this :-)
> >
> > Since I don't use ng_pppoe now much, I'd appreciate if you
> > do at brief test of this patch, before I commit it.
> >
>
> I patched and recompiled the kernel.
> After booting I notice that no messages from ppp are logged by syslog
> (messages|ppp.log)
> If I restart ppp the messages are all logged.
> I can't say if this was happening because after setting ppp up I
> didn't reboot the machine.
> I didn't browse the startup scripts but maybe syslog is not started
> before pppoe.
>
> Now it will take more than 17 hours for the session limit to be
> exceeded and only then I can say how your patch worked out. I'll make
> an update then.
Ok, here's the new output just before the connection was dropped
(earlier than usual):
Aug 5 07:28:50 ultra5 kernel: ng_pppoe[5]: session in wrong state
Aug 5 07:28:50 ultra5 last message repeated 3 times
Looks fine to me :-)
--
Joao Barros
------------------------------
Message: 15
Date: Sat, 05 Aug 2006 13:38:48 +0400
From: "Igor A. Valcov" <via...@gmail.com>
Subject: pthreads memoty leak?
To: freebsd...@freebsd.org
Message-ID: <op.tds02...@s4.hibet.ru>
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
Hi
The startup of this program causes memory leak, doesn't it? What's the
reason?
Tested on FreeBSD-6.1 and 5.4 with the same effect.
On Linux work fine.
========================
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
void* mythread(void* arg)
{
return NULL;
}
void threaded()
{
#define size 1
int ret, i;
for (i = 0; i < size; i++) {
pthread_t t_id;
pthread_attr_t pthread_attr;
pthread_attr_init (&pthread_attr);
pthread_attr_setdetachstate (&pthread_attr,
PTHREAD_CREATE_DETACHED);
ret = pthread_create (&t_id, &pthread_attr, mythread, NULL);
pthread_attr_destroy (&pthread_attr);
if (ret)
printf ("pthread_create() returned error value %d\n", ret);
}
}
int main()
{
int i;
for (i = 0; i < 10000000; i++) {
if (i % 1000 == 0)
printf ("main() iteration: %d\n", i);
threaded();
}
printf ("FINISHED.\n");
sleep (3600);
return 0;
}
==============================
--
Igor A. Valcov
------------------------------
Message: 16
Date: Sat, 5 Aug 2006 11:58:39 +0200
From: Hans Petter Selasky <hsel...@c2i.net>
Subject: Re: miibus + USB = problem ?
To: pyu...@gmail.com
Cc: freebsd...@freebsd.org
Message-ID: <200608051158....@c2i.net>
Content-Type: text/plain; charset="iso-8859-1"
On Friday 04 August 2006 02:09, Pyun YongHyeon wrote:
> On Thu, Aug 03, 2006 at 02:44:46PM +0200, Hans Petter Selasky wrote:
> > On Thursday 03 August 2006 04:25, Pyun YongHyeon wrote:
> > > On Wed, Aug 02, 2006 at 02:37:55PM +0200, Hans Petter Selasky wrote:
>
> I can't sure why you need to invoke kthread_exit(9) in aue_miibus_xxx.
> If you want to kill the kernel thread in aue_miibus_xxx you can simply
> send a termination message to kernel thread. Your kernel thread can
> decide when it should terminate if it recevied a termination message.
> Invoking mii_mediachg/mii_tick will end up with calling miibus_xxx to
> to read/write PHY registers from MII layer. So I think you still need
> to handle PHY read/write operations in aue_miibus_xxx. If the PHY
> operation was failed due to removal of hardware it could simply return
> fake value and send a message to terminate the kernel thread.
Yes, I was thinking about the same. I changed the behaviour to return zero if
the thread is gone, and delays are just short-circuited. That way the code
will return to the main thread in a short time, hopefully, where I do a
kthread_exit(0).
--HPS
------------------------------
Message: 17
Date: Sat, 5 Aug 2006 13:51:12 +0200
From: Benjamin Lutz <ben...@datacomm.ch>
Subject: Re: RFC 919 compliance (broadcasts to 255.255.255.255)
To: Mohacsi Janos <moh...@niif.hu>
Cc: freebsd...@freebsd.org
Message-ID: <200608051351....@datacomm.ch>
Content-Type: text/plain; charset="iso-8859-1"
On Saturday 05 August 2006 07:18, you wrote:
> On Fri, 4 Aug 2006, Benjamin Lutz wrote:
> > Hello,
> >
> > I've noticed that FreeBSD does not by default comply to RFC 919, Chapter
> > 7 (http://tools.ietf.org/html/rfc919). Specifically, it does not handle
> > IP packets with a destination address of 255.255.255.255 properly.
> >
> > 255.255.255.255 is a "limited broadcast address" (the term is not
> > mentioned in the RFC, but seems to be in use everywhere else). An IP
> > packet send to that address should be broadcast to the whole IP subnet of
> > the broadcasting device. However, in FreeBSD (4.11, 5.5, 6.1) this does
> > not work, as is evident by this tcpdump output:
> >
> > 17:00:59.125132 00:12:17:5a:b3:b6 > 00:40:63:d9:a9:28, ethertype IPv4
> > (0x0800), length 98: 10.0.0.1 > 255.255.255.255: ICMP echo request, id
> > 33319, seq 0, length 64
> >
> > The destination MAC address is that of my gateway, but it should be
> > ff:ff:ff:ff:ff:ff. You can reproduce this by running "tcpdump -en ip
> > proto 1" and "ping 255.255.255.255".
> >
> > I found a discussion from 2003 about this, but it seems to have trailed
> > off without coming to a conclusion:
> > http://lists.freebsd.org/pipermail/freebsd-net/2003-July/000921.html
> >
> > I've noticed that the ip(7) manpage lists a SO_ONESBCAST option. The
> > intention seems to be to enable packets to 255.255.255.255. However a
> > test with a small program showed that this option seems to have no
> > effect, outgoing packets still carried the gateway's MAC address as
> > destination.
> >
> > Btw, Linux and NetBSD both handle packets to 255.255.255.255 as
> > broadcasts.
> >
> > Now, is this behaviour intentional? Is there a way to turn on RFC 919
> > compliance? If not, would someone be willing to add this to the kernel?
> > Should I submit a PR?
>
> Does this feature really necessary? For waht purpose?
I discovered it when playing with Wake-on-LAN packets. It is possible to send
those with the real subnet's broadcast address, but then you first have to
figure that one out. If you have a network device that doesn't have an IP
configured yet, it would not know the subnet broadcast address.
> I believe this feature is more harmful than useful.
Please elaborate. Remember that routers do not pass on packets to
255.255.255.255. The TTL is effectively 1.
Cheers
Benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20060805/ed5b0704/attachment-0001.pgp
------------------------------
End of freebsd-hackers Digest, Vol 176, Issue 8
***********************************************