Re: Weird path MTU autodiscovery problem in 4.5-RELEASE
On Fri, 01 Feb 2002, Crist J. Clark wrote: CJC> On Fri, Feb 01, 2002 at 02:53:26PM +0200, Alexey Luckyanchikov wrote: CJC> > Hello, CJC> > CJC> > I have such network topology: CJC> > CJC> > ++++++ CJC> > | Server |< MTU 1500 >| Router |< MTU 1476 >| Client | CJC> > ++++++ CJC> CJC> [snip] CJC> CJC> > 14:06:48.682558 router > server: icmp: client unreachable - need to frag (mtu 1476) for server.7 > client.1371: [|tcp] (DF) (ttl 61, id 25428, len 1500) (ttl 253, id 2491, len 56) CJC> > ^^ CJC> > Router say to server that he must to decrease packet size CJC> CJC> Is "router" the same IP address that "server" has as the route to CJC> "client?" That is, there aren't any aliases on "router's" interface CJC> with "server" making problems? "router" have not any aliases on it's interfaces. Seems like problem is in FreeBSD 4.5-RELESE. "Server" with installed 4.4-RELEASE worked without any problems. -- Sincerely, e-mail: [EMAIL PROTECTED] Alexey Luckyanchikov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Luigi's polling code and 4.5R
Luigi Rizzo (rizzo) writes: > Wait a bit -- next week iam going to review the code and > MFC (with the structure that is in -current ie. the new code > in a separate file, kern_poll.c). Sounds good! We're using the code here with 5 x fxps in our firewall, and the load on the box is ridiculously low (0.1 on average). We had it running with 2 x DFE 570-TX for a total of 8 ports, but whatever we tried (including activating polling) the cards would still go into buffer underrun, and eventually lock up. Until we were forced to switch to fxp, we had an ifconfig down/up to unfreeze the cards every 5 minutes just in case :-| I must say I'm not really convinced about the D-Link cards... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Luigi's polling code and 4.5R
what is curious is that I am using a 4-port D-link on our test boxes as primary development cards and they do not seem to freeze. The card uses 21143 and seems quite reliable. I know of a bug in the code on my web site whose symptoms look like a freeze, but that is presumably related to a race in delivering softisr's and so should be card independent and appear with the fxp's as well -- as a matter of fact i first hit it with the "sis" card. cheers luigi On Sat, Feb 02, 2002 at 06:17:05PM +0100, Phil Regnauld wrote: > > Sounds good! > > We're using the code here with 5 x fxps in our firewall, and the > load on the box is ridiculously low (0.1 on average). > > We had it running with 2 x DFE 570-TX for a total of 8 ports, > but whatever we tried (including activating polling) the cards > would still go into buffer underrun, and eventually lock up. > > Until we were forced to switch to fxp, we had an ifconfig down/up > to unfreeze the cards every 5 minutes just in case :-| > > I must say I'm not really convinced about the D-Link cards... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Weird path MTU autodiscovery problem in 4.5-RELEASE
Alexey Luckyanchikov wrote: #>Server have not any filters. ipfw support is compiled in, but first rule #>is 'allow ip from any to any' and dump which you can see below was made #>on server. yeah, but icmp is it's own protocol, so you're probably filtering it and bpf will see it because it sees what comes in on the interface before ipfw processes it. ICMP isn't allowed by default in ipfw. I'd suggest you unload the module, if possible and see if it works correctly then. -- Yours truly, Shaun D. Jurrens [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Weird path MTU autodiscovery problem in 4.5-RELEASE
>#>Server have not any filters. ipfw support is compiled in, but first rule >#>is 'allow ip from any to any' and dump which you can see below was made >#>on server. > > yeah, but icmp is it's own protocol, so you're probably filtering it >and bpf will see it because it sees what comes in on the interface before >ipfw processes it. ICMP isn't allowed by default in ipfw. I'd suggest you >unload the module, if possible and see if it works correctly then. ICMP is an IP protocol, if the very first rule in IPFW is 'allow ip from any to any' then ICMP is allowed. Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Weird path MTU autodiscovery problem in 4.5-RELEASE
On Sat, Feb 02, 2002 at 08:32:49PM +0100, Rogier R. Mulhuijzen wrote: > ICMP is an IP protocol, if the very first rule in IPFW is 'allow ip from > any to any' then ICMP is allowed. uh, that might be ipfw-speak (I don't use or pretend to know ipfw) but ICMP is NOT "part" of IP (that would defeat the whole purpose of using it as a control protocol for IP). Look at /etc/protocols: ip 0 IP # internet protocol, pseudo protocol number icmp1 ICMP# internet control message protocol Adi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Weird path MTU autodiscovery problem in 4.5-RELEASE
> ICMP is an IP protocol like hell it is To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Weird path MTU autodiscovery problem in 4.5-RELEASE
At 12:07 2-2-2002 -0800, R.P. Aditya wrote: >On Sat, Feb 02, 2002 at 08:32:49PM +0100, Rogier R. Mulhuijzen wrote: > > ICMP is an IP protocol, if the very first rule in IPFW is 'allow ip from > > any to any' then ICMP is allowed. > >uh, that might be ipfw-speak (I don't use or pretend to know ipfw) but ICMP is >NOT "part" of IP (that would defeat the whole purpose of using it as a control >protocol for IP). Look at /etc/protocols: > >ip 0 IP # internet protocol, pseudo protocol number >icmp1 ICMP# internet control message protocol 1) /etc/protocols to my knowledge lists IP-protocols... note that 0 is a PSEUDO protocol number. TCP and UDP are listed further down, those are IP protocols. IPv6 that's listed there is 6over4 packets to my knowledge. 2) Even if this were not the case, in IPFW if you allow ip, you allow all. 'all' is nothing but an alias for 'ip' Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Weird path MTU autodiscovery problem in 4.5-RELEASE
On Sat, Feb 02, 2002 at 12:07:29PM -0800, R.P. Aditya wrote: > On Sat, Feb 02, 2002 at 08:32:49PM +0100, Rogier R. Mulhuijzen wrote: > > ICMP is an IP protocol, if the very first rule in IPFW is 'allow ip from > > any to any' then ICMP is allowed. > > uh, that might be ipfw-speak (I don't use or pretend to know ipfw) but ICMP is > NOT "part" of IP (that would defeat the whole purpose of using it as a control > protocol for IP). It sure is an IP protocol. > Look at /etc/protocols: > > ip 0 IP # internet protocol, pseudo protocol number > icmp1 ICMP# internet control message protocol And what does it say at the top of /etc/protocols? # Internet protocols All of the protocols on that list are different protocols you can run over the Internet Protocol (IP). Not only that, but ICMP _is_ also part of IP in the sense that any compliant IP implementation must understand ICMP. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: pptp + mschap
Brian Somers writes: > If you could find a spec on how to talk MSCHAP & MSCHAPv2 to a radius > server, I'd certainly be happy to add support to ppp. You never know > - the client may come back :*) Try these... Microsoft Vendor-specific RADIUS Attributes http://www.ietf.org/rfc/rfc2548.txt Remote Authentication Dial In User Service (RADIUS) http://www.ietf.org/rfc/rfc2865.txt Network Access Servers Requirements: Extended RADIUS Practices http://www.ietf.org/rfc/rfc2882.txt -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: mpd-netgraph problem.
David Gilbert writes: > I'm using mpd-netgraph to attempt to connect an encrypted tunnel. It > appears to connect (according to the messages), but the following is > spit out for most packets I try to put down the tunnel: > > [vpn] LCP: rec'd Protocol Reject #1 link 0 (Opened) > [vpn] LCP: protocol 0x0029 was rejected > [vpn] LCP: rec'd Protocol Reject #2 link 0 (Opened) > [vpn] LCP: protocol 0x00a1 was rejected > > (on the one end) > > [strikeppp] rec'd unexpected protocol 0x0029 on link -1, rejecting > [strikeppp] rec'd unexpected protocol 0x00a1 on link -1, rejecting > [strikeppp] rec'd unexpected protocol 0x0001 on link -1, rejecting > > (on the other) > > The second log also contains lines of the form: > > [strikeppp] rec'd proto 0xee53 on MP link! (ignoring) > [strikeppp] rec'd proto 0xcc0d on MP link! (ignoring) > > ... any ideas? This is usually because one side is sending encrypted traffic that the other is thinking is not encrypted... i.e., it's a side-effect of a negotiation problem. I've just heard from another person with this problem. Check your logs for something like ``"enable chap" required for MPPE'' on one side. As a workaround, if you are doing CHAP in both directions, try turning it off in one direction. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Luigi's polling code and 4.5R
> what is curious is that I am using a 4-port D-link on our > test boxes as primary development cards and they do not seem > to freeze. The card uses 21143 and seems quite reliable. > > I know of a bug in the code on my web site whose symptoms look like > a freeze, but that is presumably related to a race in delivering > softisr's and so should be card independent and appear with the > fxp's as well -- as a matter of fact i first hit it with the "sis" > card. If you're interested, I can give you console access to the box and you can take a look. At least when I tried it, it eventually recovers if you turn off polling. -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
