xl0: no memory for rx list -- packet dropped!
One of the machines on our network spits out the following (constantly): xl0: no memory for rx list -- packet dropped! It is of course unreachable through the network. This popped up on 4.2-RELEASE one single time, then went away after a reboot. Now, on 4.3-RELEASE, it was running fine till about two hours ago. Reboots aren't helping. dmesg returns: 3Com 3c905B-TX Fast Etherlink XL Any help or explanation would be greatly appreciated. Cheers, Munish Chopra _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: size of data to ip layer from tcp layer
This is not quite true. MSS can be set arbitrarily by the other end of the connection, and if the receiver is on a link with bigger MTU, or just wants things in big batches, it can set MSS up to 65535. It's up to your own end to check both MSS and the link MTU and decide what size segs to send down to IP. IP will fragment if it gets something it can't send on the link in one frame. 1460 is 1500 minus 20 for the IP header and 20 for the TCP header - Standard Ethernet data max is 1500, not 1460. For some special applications (Bridge trunking) this can be expanded somewhat. It would be a very bad idea to hard-code 1460 into any software you're writing. Barney Wolff On Fri, May 11, 2001 at 02:45:10AM -0400, [EMAIL PROTECTED] wrote: > Hi, > This is regarding the size of data from TCP/UDP layer to the ip layer. The number of >bytes sent from tcp layer to ip layer to send depends on the tcp MSS (maxium segment >size).For an ethernet this size is 1460 bytes. > > Based on the above my understanding is this. > > a) Since MSS is 1460 bytes the maximum number of bytes sent from TCP to iplayer >cannot exceed this value. > b) The maximum sized packet that can be received by ip layer from ethernetdevice >is 1460 bytes. > c) In case the packet is fragmented at the sending end, at the receiving after >reassembly the maximum packet size cannot exceed 1460 bytes. > > Please mail me if my understanding is correct. > Also whether for ipv6 there is any change. > > regards > ravi prasad To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
mbuf organization in case 65536 bytes of data.
Hi, My doubt is how data will be organized in buffers in case we want to transmit large amount of data. My doubt is regarding the organization of mbufs in case we want to transmit the maximum ip datagram size. In the normal case data is stored in clusters for data size greater than 208 bytes. My doubt is how the data will be organized in case of such large data. If mbufs are used we will have a long chain. Whether any other buffers are used.how the data is organized in such a case? How the data will be organized in case we want to transmit jumbograms in ipv6. I think that cluster concept of 2K bytes is too small. regards ravi prasad __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
mbuf organization
Hi, My doubt is how data will be organized in buffers in case we want to transmit large amount of data. My doubt is regarding the organization of mbufs in case we want to transmit the maximum ip datagram size. In the normal case data is stored in clusters for data size greater than 208 bytes. My doubt is how the data will be organized in case of such large data. If mbufs are used we will have a long chain. Whether any other buffers are used.how the data is organized in such a case? How the data will be organized in case we want to transmit jumbograms in ipv6. I think that cluster concept of 2K bytes is too small. regards ravi prasad __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: gif tunnel woes
hello, regarding to the note on: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+2538+/usr/local/www/db/text/2001/freebsd-net/20010506.freebsd-net the symptom is repeatable. however, it seems to me that the multi destination mode is poorly documented, and needs certain (strange) configuration to work properly. i have no idea how can it be useful. the destination tunnel gateway address is taken from rt_gateway, so i guess you'd need to set routing table like this: % route add -inet 192.168.10.0 24.27.51.59 % route change -inet 192.168.10.0 24.27.51.59 -ifp gif0 which seems very counter-intuitive to me (NOTE: i did not test this). my preference is to dropp support for multi-destination mode from gif(4), as the multi-destination behavior is violating network layering (rt_gateway is in inner header, and gif(4) multi-destination mode uses it to determinte outer header). itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: gif tunnel woes
On Sat, 12 May 2001, Jun-ichiro itojun Hagino wrote: > hello, regarding to the note on: > > > http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+2538+/usr/ > local/www/db/text/2001/freebsd-net/20010506.freebsd-net First off thanks a million for the response. > >the symptom is repeatable. however, it seems to me that the multi >destination mode is poorly documented, and needs certain (strange) >configuration to work properly. i have no idea how can it be useful. The reason I was experimenting in it was because using bi-directional gif tunnels, the number of them has to be staticlly compiled in ther kernel and has no way of growing the actual number of gif interfaces dynamically. So my options were to build N number of gif interfaces for every machine, or use nos-tun. The multi-destination tunnels could have been a work around...if they would have worked right. >the destination tunnel gateway address is taken from rt_gateway, >so i guess you'd need to set routing table like this: > >% route add -inet 192.168.10.0 24.27.51.59 >% route change -inet 192.168.10.0 24.27.51.59 -ifp gif0 > >which seems very counter-intuitive to me (NOTE: i did not test this). > >my preference is to dropp support for multi-destination mode >from gif(4), as the multi-destination behavior is violating network >layering (rt_gateway is in inner header, and gif(4) multi-destination > mode uses it to determinte outer header). Which would be fine. It would be nice to have a way to grow these gif tunnels on the fly, then nos-tun could be strapped as well. Nick Rogness <[EMAIL PROTECTED]> - Keep on Routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: gif tunnel woes
> > my preference is to dropp support for multi-destination mode from > gif(4), as the multi-destination behavior is violating network layering > (rt_gateway is in inner header, and gif(4) multi-destination mode > uses it to determinte outer header). There's certainly a bunch of NBMA network media out there. The problem is abusing the routing table next hop as a way to specify the remote tunnel endpoint. This should be an attribute of the gif interface, configured outside of the routing infrastructure. Or, perhaps treated like ARP for ethernet; it's just an accident that the "MAC" address for a multi-point NBMA tunnel is an IPv4/IPv6 address. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
FreeBSD breaks sockets two ways...
I have run into two issues, that I find really, really annoying. This
is in FreeBSD 4.3 and 5.x. Bot machines are on a local (non-switched)
segment (it works the same with a switch, but taking that out proves
it is not the switch causing the problem).
Primus
--
The first is that when you create a socket, and bind it to a
specific local IP address, and then connect, it fails to
allocate an automatic port private to the socket; specifically:
int s;
struct sockaddr_in sockaddr;
s = socket(AF_INET, SOCK_STREAM, 0);
bzero(&sockaddr,sizeof(sockaddr));
sockaddr.sin_family = AF_INET;
sockaddr.sin_addr.s_addr = s_addr2;
sockaddr.sin_port = 0;
if (bind(s, (struct sockaddr *) &sockaddr, sizeof(sockaddr)) == -1) {
perror("bind");
errx(1, "bind failed");
}
...in other words, the sockets are all hashed into the same
(global) collsion domain, even though they are _not_ global,
they are specific to a particular IP address.
Secondus
On an OS where the above actually works (e.g. _not_ FreeBSD), when
I make connections from two ports which are the same, but with
different IP addresses, it seems that the MAC address is used by
FreeBSD to differentiate connections, and _not_ the IP/port pair.
This means that on FreeBSD, the incoming connection on two different
source IPs from the same MAC address end up resetting the first
connection, when the second one comes in; instead of getting two
total connections, I end up getting only a single connection.
Both of these seem to be serious screwups in the routing code hash
lookup algorithm, acting as if everything is in the INADDR_ANY
domain, and as if it were keying off the MAC address, and not the
IP address... as it should be.
Has anyone else seen this? Obviously, it's hard to reproduce
FreeBSD-to-FreeBSD (at least without a BPF program on the client
side to cause the problem)...
I'm primarily interested in a fix for 4.3.
Thanks,
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: FreeBSD breaks sockets two ways...
Are you sure it's failing to allocate the port? I had a similar problem in trying to connect to a service, but found out that aliasing an IP didn't add the arp entry in the routing table (local connections were failing). If I added the arp entry by hand, everything was happy (is IP aliasing a part of the scneario you're describing?). arp -s a.b.c.d 00:60:08:aa:aa:aa pub arp -s a.b.c.e 00:60:08:aa:aa:ab pub A tad annoying, but it seems to work (yeah, I know about the ethers file, but I refuse to use it). -sc On Fri, May 11, 2001 at 11:43:00PM +, Terry Lambert wrote: > I have run into two issues, that I find really, really annoying. This > is in FreeBSD 4.3 and 5.x. Bot machines are on a local (non-switched) > segment (it works the same with a switch, but taking that out proves > it is not the switch causing the problem). > > > Primus > -- > > The first is that when you create a socket, and bind it to a > specific local IP address, and then connect, it fails to > allocate an automatic port private to the socket; specifically: -- Sean Chittenden PGP signature
gateway+multi-PPPoE
Hi! I'm triyng to set-up a Gateway that will use 3 different PPPoE (to the same provider) adsl connection (3 modem , 3 account), to distribute it back to a soho network. In instance to get the more bandwith possible. I've been able to set-up the gateway with one modem by using netgraph and PPP. I tought that using mpd would allow me to to get the maximun of these three connections. It seem to work well on the gateway. But the rest of the network is dead (the gate way see everybody and vice versa) but station dont see the net. If somebody have any idea how to make that thing work it will be a great help. P.S. I try that solution, if there's other who work better, please tell me . thanks Nicolas Beauchesne [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: gif tunnel woes
>> my preference is to dropp support for multi-destination mode from >> gif(4), as the multi-destination behavior is violating network layering >> (rt_gateway is in inner header, and gif(4) multi-destination mode >> uses it to determinte outer header). > >There's certainly a bunch of NBMA network media out there. The problem is >abusing the routing table next hop as a way to specify the remote >tunnel endpoint. This should be an attribute of the gif interface, >configured outside of the routing infrastructure. Or, perhaps treated >like ARP for ethernet; it's just an accident that the "MAC" address for >a multi-point NBMA tunnel is an IPv4/IPv6 address. well, in the case of ARP entries, you know that it is a layer-2 address (MACaddress) on rt_gateway because it is tagged as AF_LINK. for the routing entries used by gif multi desination mode, rt_gateway field is not distinguishable (if it is outer addr or inner addr). also i guess it unsuitable to compare with NBMA networks, as with most of the NBMA networks i guess rt_gateway field takes an AF_LINK sockaddr, not an AF_INET. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: FreeBSD breaks sockets two ways...
] Are you sure it's failing to allocate the port? ] ] I had a similar problem in trying to connect to a service, but ] found out that aliasing an IP didn't add the arp entry in the routing ] table (local connections were failing). If I added the arp entry by ] hand, everything was happy (is IP aliasing a part of the scneario ] you're describing?). ] ] arp -s a.b.c.d 00:60:08:aa:aa:aa pub ] arp -s a.b.c.e 00:60:08:aa:aa:ab pub ] ] A tad annoying, but it seems to work (yeah, I know about the ] ethers file, but I refuse to use it). -sc Unfortunately, I'm very certain. I talked to Bill Paul about the gratuitous ARP problem last night; I was well aware of it; we added the ARP entries by hand to the target for the aliases on the source machine. I'm _positive_ on the outbound connection problem (the code fragment I attached should have done the job, and I've seen the FreeBSD code that's the problem, but am still pondering about how to fix it; I think I'll have to do two lookups, or hang a chain off a hash bucket indexed by IP last (instead of port). Hopefully, someone will get to this before I do. We've also tried by setting up the ARP table for the target machine, and then written the aforementioned BPF program to stage the connection attempts from a single client machine. We did the same thing from a second client on the same segment. The single client, two IP attempt failed, while the two machine attempt succeeded. The only difference in the packets that was reported by tcpdump was the source MAC address -- otherwise, they were byte-for-byte identical. So there is definitely a problem there with the index being by MAC instead of IP. Maybe this came in as part of the "aliased IP NFS client being seen as an attacker by the server" fix? Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
