Re: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd))
On 2008-May-26 19:11:16 +, Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: >We should summarily kill the concept of line disciplines as a >modular component and decide that TTYs can be used with termios(4) >or raw mode and leave it at that. streams anyone? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpfTlr83HmUm.pgp Description: PGP signature
Re: HEAD UP: non-MPSAFE network drivers to be disabled
On May 27, 2008, at 1:12 AM, Julian Elischer wrote: judging by the bug reports when things get broken there are still a lot of people connected to the internet via dial up lines in places off the beaten track, and still a lot of people who when travelling do use dialup still. Some of these also use mpd. I can not say how many plan to keep using this in the future but it may be that the simplest answer is a completely separate sio driver that just has netgraph hooks. I haven't talked with Ed yet but there may be may ways to solve this problem. Take a look at uart(4). It has been designed to allow different kernel interfaces. It currently supports TTYs and keyboards. It should not be too hard to have it hook into netgraph. FYI, -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Adjust Maximum Segment Size?
Stefan Lambrev wrote: Greetings, Is there a way to adjust MSS just like in cisco's "ip tcp adjust-mss"? I want to play only with MSS not with MTU. So far the only solution that I found is pf+scrub, but I wander if it is possible to do it without firewall. there is tcpmssd in ports but that also requires a firewall (ipfw) and divert. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Adjust Maximum Segment Size?
Boris Kovalenko wrote: Hello! Yes, You can with ng_tcpmss Greetings, Is there a way to adjust MSS just like in cisco's "ip tcp adjust-mss"? I want to play only with MSS not with MTU. So far the only solution that I found is pf+scrub, but I wander if it is possible to do it without firewall. Regards, Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" gosh I didn't even know about that ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEAD UP: non-MPSAFE network drivers to be disabled
Marcel Moolenaar wrote: On May 27, 2008, at 1:12 AM, Julian Elischer wrote: judging by the bug reports when things get broken there are still a lot of people connected to the internet via dial up lines in places off the beaten track, and still a lot of people who when travelling do use dialup still. Some of these also use mpd. I can not say how many plan to keep using this in the future but it may be that the simplest answer is a completely separate sio driver that just has netgraph hooks. I haven't talked with Ed yet but there may be may ways to solve this problem. Take a look at uart(4). It has been designed to allow different kernel interfaces. It currently supports TTYs and keyboards. It should not be too hard to have it hook into netgraph. FYI, While this is a good idea on it's own, the difference between what that achieves and what a line discipline achieves is that a line disciplin is hardware independent and can even be used on a virtual device. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEAD UP: non-MPSAFE network drivers to be disabled
Julian Elischer wrote: While this is a good idea on it's own, the difference between what that achieves and what a line discipline achieves is that a line disciplin is hardware independent and can even be used on a virtual device. I was under the impression that the back-end for UART was light weight enough that it could be used as a virtual device. For example: Many years ago I tried to get the WinModem working in my IBM ThinkPad T23. UART lends itself well to being a wrapper for the DSP microcode without having any of the historical tty baggage. In the case of UART the "translation shim" moves from on top of the device node to underneath, in much the same way as has happened for GEOM. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Adjust Maximum Segment Size?
Greetings, Alexander Motin wrote: Stefan Lambrev wrote: Yes, You can with ng_tcpmss Isn't it doable only with ipfw/divert when using ng_tcpmss? I have and some concerns about performance too .. There are several ways to inject packet to ng_tcpmss: - ipfw + divert + ng_ksocket. It should be faster then usual user-level implementation - ipfw + netgraph as described in ng_tcpmss(4) - use ng_tcpmss directly in some complicated netgraph setup. For example, mpd is able to use it. This is probably the fastest and easiest way, but only for some setups. Thanks for all ideas. I think I'll try the route -mtu feature. Looks like easier for implementation and testing. :) Anyway it will be good if we have such feature in the base system. It shouldn't be very difficult? :) -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEAD UP: non-MPSAFE network drivers to be disabled
On May 27, 2008, at 10:50 AM, Julian Elischer wrote: Marcel Moolenaar wrote: On May 27, 2008, at 1:12 AM, Julian Elischer wrote: judging by the bug reports when things get broken there are still a lot of people connected to the internet via dial up lines in places off the beaten track, and still a lot of people who when travelling do use dialup still. Some of these also use mpd. I can not say how many plan to keep using this in the future but it may be that the simplest answer is a completely separate sio driver that just has netgraph hooks. I haven't talked with Ed yet but there may be may ways to solve this problem. Take a look at uart(4). It has been designed to allow different kernel interfaces. It currently supports TTYs and keyboards. It should not be too hard to have it hook into netgraph. FYI, While this is a good idea on it's own, the difference between what that achieves and what a line discipline achieves is that a line disciplin is hardware independent and can even be used on a virtual device. True, but you said: "... the simplest answer is a completely separate sio driver...". This, besides not being true, is just as hardware dependent as uart(4) is. It seems to me that you've conveniently changed the subject to match your point of view :-) -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Adjust Maximum Segment Size?
On Tue, May 27, 2008 at 8:04 PM, Stefan Lambrev <[EMAIL PROTECTED]> wrote: > Greetings, > > Alexander Motin wrote: >> >> Stefan Lambrev wrote: Yes, You can with ng_tcpmss >>> >>> Isn't it doable only with ipfw/divert when using ng_tcpmss? >>> I have and some concerns about performance too .. >> >> There are several ways to inject packet to ng_tcpmss: >> - ipfw + divert + ng_ksocket. It should be faster then usual user-level >> implementation >> - ipfw + netgraph as described in ng_tcpmss(4) >> - use ng_tcpmss directly in some complicated netgraph setup. For example, >> mpd is able to use it. This is probably the fastest and easiest way, but >> only for some setups. >> > > Thanks for all ideas. > I think I'll try the route -mtu feature. > Looks like easier for implementation and testing. :) > Anyway it will be good if we have such feature in the base system. > It shouldn't be very difficult? :) > > -- Actually converting ng_tcpmss to pfil(9) should be easy. Ermal ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Intel embedded NICs not working with FreeBSD 6.2, 6.3 and 7.0
Hi ! I am in contact with Chris Buechler because of pfSense and we he told me to contact Jack Vogel because of some Intel NIC driver problem. FreeBSD detects them as fxp cards which is correct, but they do not work at all, i tried in ACPI and non-ACPI mode and with enabled ROM and disabled ROM and everything, but I cannot get them working... I always get "fxp0 timeout" or fxpX fort he corresponding card... I read it might have something to do with dynamic powersaving mode or else but have no clue how to deactivate, there's no option in the ROM for this. It's an appliance board (NexCom EBC575) with Intel 845GV / Intel 82801DB (ICH4)-chipset and 2 x Intel 82551QM (PRO/100 Network Connection), 1 x ICH4 integrated LAN Int on board. Is there anything I can tot o make it work for now or is it a known problem or else ? Regards, looking forward to hear from you, Martin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Adjust Maximum Segment Size?
Stefan Lambrev wrote: Yes, You can with ng_tcpmss Isn't it doable only with ipfw/divert when using ng_tcpmss? I have and some concerns about performance too .. There are several ways to inject packet to ng_tcpmss: - ipfw + divert + ng_ksocket. It should be faster then usual user-level implementation - ipfw + netgraph as described in ng_tcpmss(4) - use ng_tcpmss directly in some complicated netgraph setup. For example, mpd is able to use it. This is probably the fastest and easiest way, but only for some setups. -- Alexander Motin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ICMP Error transmission/response over IPSec tunnels
Hi,
Today I looked into why I can not get a traceroute across a IPSec IPIP
tunnel an came across an interesting piece of code. Here is a diagram
of the setup:
[Node A] <-> [Router A] <-{IPSec}-> [Router B] <-> [Node B]
If I traceroute from node A to node B I never see the ICMP packet for
the TTL exceeded generated by router b.
So I did a little digging and found and interesting revision of
sys/netinet/ip_icmp.c. In revision 1.93 it seems ume@ added a check for
the flag M_DECRYPTED in icmp_error() and if it was set do not generate
the icmp error message.
So my questions are:
1) Is this check really required?
2) If it is required what makes it required? Is it a problem in the
icmp transmit path, or is there some other reason?
3) It seems the check originated from the KAME project, as FreeBSD no
longer uses the KAME IPSec implementation is check still required?
I found the same check in the netbsd code, but could not find a similar
check in openbsd (although the openbsd ipsec implementation is some what
different from netbsd and freebsd).
Any information about this would be appreciated as I would like to be
able to do traceroutes across my wan.
Thanks
Tom
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPv6/IPv4 DNS resolver source
At Mon, 26 May 2008 18:49:35 -0400, Steve Bertrand <[EMAIL PROTECTED]> wrote: > Is there anyone here who can advise me where in the source tree I would > find the DNS resolver code that performs /A record lookups, and more > specifically, the fallback to A lookup if fails? Assuming you're considering getaddrinfo(), see res_queryN() in lib/libc/net/getaddrinfo.c. BTW: "fallback" does not really accurately describe the behavior. When AF_UNPSEC is specified, both and A queries are issued, whether or not the query fails. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel embedded NICs not working with FreeBSD 6.2, 6.3 and 7.0
On Tue, May 27, 2008 at 11:22 AM, Fuchs, Martin <[EMAIL PROTECTED]> wrote: > Hi ! > > > > I am in contact with Chris Buechler because of pfSense and we he told me > to contact Jack Vogel because of some Intel NIC driver problem. The FreeBSD fxp driver was not written by Intel and I have had nothing to do with it in my tenure in this position. The real maintainer of that driver should help you :) If no one speaks up then we will see again... Jack > > FreeBSD detects them as fxp cards which is correct, but they do not work > at all, i tried in ACPI and non-ACPI mode and with enabled ROM and > disabled ROM and everything, but I cannot get them working... > > I always get "fxp0 timeout" or fxpX fort he corresponding card... I read > it might have something to do with dynamic powersaving mode or else but > have no clue how to deactivate, there's no option in the ROM for this. > > > > It's an appliance board (NexCom EBC575) with Intel 845GV / Intel 82801DB > (ICH4)-chipset and 2 x Intel 82551QM (PRO/100 Network Connection), 1 x > ICH4 integrated LAN Int on board. > > > > Is there anything I can tot o make it work for now or is it a known > problem or else ? > > > > Regards, > > > > looking forward to hear from you, > > > > Martin > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dual stack with multiple addresses in rc.conf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Bertrand <[EMAIL PROTECTED]> wrote: > > ifconfig_fxp0="inet6 2607:f118::b6 prefixlen 64" > ifconfig_fxp0_alias0="inet6 2607:f118::b7 prefixlen 64" > ifconfig_fxp0="inet 208.70.104.210 255.255.255.248" > ifconfig_fxp0_alias1="inet 208.70.104.211 netmask 255.255.255.255" Your config entry for ifconfig_fxp0 is specified twice, so the latter setting overrides the former. When you have multiple settings to apply, you can put them all in one ifconfig entry, although as Max points out, it is more correct to put IPV6 settings in a separate entry. - -- David DeSimone == Network Admin == [EMAIL PROTECTED] "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIPGAVFSrKRjX5eCoRArqwAJ9G8HZbAgAkElHYDmiSphtDO625VACfSQSs IyyVlcyPju6Xsb+YJEhmpW0= =WMCC -END PGP SIGNATURE- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel embedded NICs not working with FreeBSD 6.2, 6.3 and 7.0
Jack Vogel wrote: On Tue, May 27, 2008 at 11:22 AM, Fuchs, Martin <[EMAIL PROTECTED]> wrote: Hi ! I am in contact with Chris Buechler because of pfSense and we he told me to contact Jack Vogel because of some Intel NIC driver problem. The FreeBSD fxp driver was not written by Intel and I have had nothing to do with it in my tenure in this position. The real maintainer of that driver should help you :) fxp(4) doesn't have a real maintainer anymore. I've sent a nice collection of fxp cards and revisions thereof to Pyun YongHyeon in hope of tricking him to become the future maintainer. He's pretty busy with more recent gigabit cards though and I'm not sure when/if he can assume that role. -- Andre If no one speaks up then we will see again... Jack FreeBSD detects them as fxp cards which is correct, but they do not work at all, i tried in ACPI and non-ACPI mode and with enabled ROM and disabled ROM and everything, but I cannot get them working... I always get "fxp0 timeout" or fxpX fort he corresponding card... I read it might have something to do with dynamic powersaving mode or else but have no clue how to deactivate, there's no option in the ROM for this. It's an appliance board (NexCom EBC575) with Intel 845GV / Intel 82801DB (ICH4)-chipset and 2 x Intel 82551QM (PRO/100 Network Connection), 1 x ICH4 integrated LAN Int on board. Is there anything I can tot o make it work for now or is it a known problem or else ? Regards, looking forward to hear from you, Martin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ICMP Error transmission/response over IPSec tunnels
Bjoern A. Zeeb wrote: On Tue, 27 May 2008, Tom Judge wrote: Hi, Today I looked into why I can not get a traceroute across a IPSec IPIP tunnel I guess not an IPIP tunnel but just IPsec tunnel mode? ... Any information about this would be appreciated as I would like to be able to do traceroutes across my wan. The problem has been well known and is on my todo list. I haven't checked the relevant code lately but if I remember the problem is not to be fixed trivially in first place. You should get a reply back from your Node B though, just not from Router B. /bz Hi Bjoern, Yes we do indeed see a reply from node b. It is good to here that this is a known issue. The IPSec configuration is a gif ipip tunnel that is then encrypted with IPSec using esp in tunnel mode as per the ipsec vpn section in the handbook. Do you have any more information on the underlying source of the problem? If so it would help me find the problem. I may setup a small test network to find this problem this evening time permitting. Thanks Tom PS. Could you pm me a link to your RELENG_7 multi ip jail patchs? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ICMP Error transmission/response over IPSec tunnels
On Tue, 27 May 2008, Tom Judge wrote: Hi, Today I looked into why I can not get a traceroute across a IPSec IPIP tunnel I guess not an IPIP tunnel but just IPsec tunnel mode? ... Any information about this would be appreciated as I would like to be able to do traceroutes across my wan. The problem has been well known and is on my todo list. I haven't checked the relevant code lately but if I remember the problem is not to be fixed trivially in first place. You should get a reply back from your Node B though, just not from Router B. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel embedded NICs not working with FreeBSD 6.2, 6.3 and 7.0
Martin, Can you give me a pciconf -l listing please. Jack On Tue, May 27, 2008 at 11:22 AM, Fuchs, Martin <[EMAIL PROTECTED]> wrote: > Hi ! > > > > I am in contact with Chris Buechler because of pfSense and we he told me > to contact Jack Vogel because of some Intel NIC driver problem. > > > > FreeBSD detects them as fxp cards which is correct, but they do not work > at all, i tried in ACPI and non-ACPI mode and with enabled ROM and > disabled ROM and everything, but I cannot get them working... > > I always get "fxp0 timeout" or fxpX fort he corresponding card... I read > it might have something to do with dynamic powersaving mode or else but > have no clue how to deactivate, there's no option in the ROM for this. > > > > It's an appliance board (NexCom EBC575) with Intel 845GV / Intel 82801DB > (ICH4)-chipset and 2 x Intel 82551QM (PRO/100 Network Connection), 1 x > ICH4 integrated LAN Int on board. > > > > Is there anything I can tot o make it work for now or is it a known > problem or else ? > > > > Regards, > > > > looking forward to hear from you, > > > > Martin > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ICMP Error transmission/response over IPSec tunnels
On Tue, 27 May 2008, Tom Judge wrote: Hi, Yes we do indeed see a reply from node b. It is good to here that this is a known issue. The IPSec configuration is a gif ipip tunnel that is then encrypted with IPSec using esp in tunnel mode as per the ipsec vpn section in the handbook. 1) if you do not need the ipip tunnel because you need an interface and "link state changes" only go with the IPsec tunnel mode. 2) If you need the gi tunnel on top and routing, use IPsec transport mode. (ignore the handbook, try to understand it;) Do you have any more information on the underlying source of the problem? If so it would help me find the problem. I may setup a small test network to find this problem this evening time permitting. a test network is not a problem. time is. PS. Could you pm me a link to your RELENG_7 multi ip jail patchs? check the latest status report at... for the link: http://www.freebsd.org/news/status/report-2008-01-2008-03.html#Multi-IPv4/v6/no-IP-jails -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEAD UP: non-MPSAFE network drivers to be disabled
Marcel Moolenaar wrote: On May 27, 2008, at 10:50 AM, Julian Elischer wrote: Marcel Moolenaar wrote: On May 27, 2008, at 1:12 AM, Julian Elischer wrote: judging by the bug reports when things get broken there are still a lot of people connected to the internet via dial up lines in places off the beaten track, and still a lot of people who when travelling do use dialup still. Some of these also use mpd. I can not say how many plan to keep using this in the future but it may be that the simplest answer is a completely separate sio driver that just has netgraph hooks. I haven't talked with Ed yet but there may be may ways to solve this problem. Take a look at uart(4). It has been designed to allow different kernel interfaces. It currently supports TTYs and keyboards. It should not be too hard to have it hook into netgraph. FYI, While this is a good idea on it's own, the difference between what that achieves and what a line discipline achieves is that a line disciplin is hardware independent and can even be used on a virtual device. True, but you said: "... the simplest answer is a completely separate sio driver...". This, besides not being true, is just as hardware dependent as uart(4) is. It seems to me that you've conveniently changed the subject to match your point of view :-) yep :-) we need to decide if the aim is to support just serial ports or any 'tty'. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEAD UP: non-MPSAFE network drivers to be disabled
On May 27, 2008, at 1:49 PM, Julian Elischer wrote: Marcel Moolenaar wrote: On May 27, 2008, at 10:50 AM, Julian Elischer wrote: Marcel Moolenaar wrote: On May 27, 2008, at 1:12 AM, Julian Elischer wrote: judging by the bug reports when things get broken there are still a lot of people connected to the internet via dial up lines in places off the beaten track, and still a lot of people who when travelling do use dialup still. Some of these also use mpd. I can not say how many plan to keep using this in the future but it may be that the simplest answer is a completely separate sio driver that just has netgraph hooks. I haven't talked with Ed yet but there may be may ways to solve this problem. Take a look at uart(4). It has been designed to allow different kernel interfaces. It currently supports TTYs and keyboards. It should not be too hard to have it hook into netgraph. FYI, While this is a good idea on it's own, the difference between what that achieves and what a line discipline achieves is that a line disciplin is hardware independent and can even be used on a virtual device. True, but you said: "... the simplest answer is a completely separate sio driver...". This, besides not being true, is just as hardware dependent as uart(4) is. It seems to me that you've conveniently changed the subject to match your point of view :-) yep :-) we need to decide if the aim is to support just serial ports or any 'tty'. Agreed. ucom(4) is in scope... -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ICMP Error transmission/response over IPSec tunnels
Bjoern A. Zeeb wrote: On Tue, 27 May 2008, Tom Judge wrote: Hi, Yes we do indeed see a reply from node b. It is good to here that this is a known issue. The IPSec configuration is a gif ipip tunnel that is then encrypted with IPSec using esp in tunnel mode as per the ipsec vpn section in the handbook. 1) if you do not need the ipip tunnel because you need an interface and "link state changes" only go with the IPsec tunnel mode. 2) If you need the gi tunnel on top and routing, use IPsec transport mode. (ignore the handbook, try to understand it;) I have 13 nodes in a parital mesh running ospf for routing. It would not be trivial for me to switch from tunnel to transport mode. Also I have not tested quagga in when the ipsec is in transport mode, and I guess I do need interfaces to use with quagga. I may test fixing this additional overhead, but as they say if it's not broken don't fix it. Do you have any more information on the underlying source of the problem? If so it would help me find the problem. I may setup a small test network to find this problem this evening time permitting. a test network is not a problem. time is. Please understand that I was not asking for you to fix this problem just for some pointers into where to start looking. The reason I ask is that you seem to know in what region that the error exists and it would be helpful to me if you could tell me so that I could try to find a solution to the problem myself. At a guess the code that I need to look as it in icmp_error() or further down the icmp transmit path (maybe icmp_reflect or further?). Thanks again. Tom ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ICMP Error transmission/response over IPSec tunnels
On Tue, 27 May 2008, Tom Judge wrote: Bjoern A. Zeeb wrote: On Tue, 27 May 2008, Tom Judge wrote: Hi, Yes we do indeed see a reply from node b. It is good to here that this is a known issue. The IPSec configuration is a gif ipip tunnel that is then encrypted with IPSec using esp in tunnel mode as per the ipsec vpn section in the handbook. 1) if you do not need the ipip tunnel because you need an interface and "link state changes" only go with the IPsec tunnel mode. 2) If you need the gi tunnel on top and routing, use IPsec transport mode. (ignore the handbook, try to understand it;) I have 13 nodes in a parital mesh running ospf for routing. It would not be trivial for me to switch from tunnel to transport mode. Also I have not tested quagga in when the ipsec is in transport mode, and I guess I do need interfaces to use with quagga. I may test fixing this additional overhead, but as they say if it's not broken don't fix it. Ok. So basically you have 12 gif tunnels on each node, if it would be a full mesh. So it's less. So a) you have two endpoints for the gif tunnel which are your Router A, Router B endpoint. So the only thing you would need to secure is your IPIP (gif) tunnel between two nodes (Router A, B). This is what transport mode is for. Running a traceroute, the IP stack would need to send the icmp ttl exceeded packet back via the gif tunnel which then would have to be encrypted. To my memory the problem is that this does not work. You could try to find out at which layer by running tcpdump on the (external) interface and the gif interfaces and if you have enc0 to see if/where the icmp possibly shows up. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd))
On Tue, May 27, 2008 at 8:19 AM, Bruce M. Simpson <[EMAIL PROTECTED]> wrote: > Ed Schouten wrote: With the word `should' I meant that it would still be possible to implement multiple line disciplines with the mpsafetty code. But I really think line disciplines should go. >>> >>> No, don't bother. Remove the entire "abstraction" of linedisciplines. >>> >> >> Your wish is my command. >> > > Like Julian and Robert said, please don't break Netgraph. > > It still needs to hook into tty at a very low level; and the components such > as Bluetooth which can use ttys for low level stream processing, are built > on Netgraph. > > Both SLIP and PPP can be built using Netgraph. > > Other than that, line disciplines can go away. I think line disciplines should go away as such. It would be nice to have a place to hook into (even linux has this), but the line discipline concept is 30 years stale. IMHO, priority #1 is give ttys the first class treatment they need, then priority #2 is to put in some low level hooks for ng_tty or whatever. It would be hard to come up with a more inconvenient interface than we have now. As an example.. look at the CAN_BYPASS_L_RINT stuff. If we had a way to pass a block of characters upstream instead of a single character at a time, then we could build this magic into the input routines instead of the device drivers. The bypass is still useful because it saves considerable cycles for raw tty modes, eg: userland ppp, zmodem upload/downloads etc etc. But the logic for it shouldn't have to be scattered all over the tree due to poor line discipline APIs. -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Atheros 5212 network issues.
> [EMAIL PROTECTED] wrote: >> Hello! >> I am running FreeBSD 7.0 stable. I am having speed issues that I >> was >> not experiencing before when I was running 6.3 stable. >> >> My wireless connection is now unstable and not as much consistent as it >> was before. The wired connection is as usual ~7000kb/up and 800kb/down. >> >> Each test (~20 per day during 5 days) I did was on a 10 second interval, >> speed is fluctuating from ~80kb to ~4000kb down and ~80kb to ~300kb up >> and >> some tests return both download and upload to be very low. >> >> Also, one test can return 300kb down and 80kb up when next one 10 >> seconds >> later returns 80kb down and 300kb up. >> >> Latency is fluctuating as well. >> >> I tried to use another channel, swap disk and wireless card to another >> machine, cvsup and upgrade again. >> >> I didn't changed network settings, firewall rules, and my hostapd >> config. >> >> Here are some more informations on my hardware: >> >> FreeBSD 7.0-STABLE #0: Mon May 19 23:10:53 EDT 2008 >> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MUTEX >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Celeron(R) CPU 1.70GHz (1716.91-MHz 686-class CPU) >> Origin = "GenuineIntel" Id = 0xf13 Stepping = 3 >> >> Features=0x3febfbff >> real memory = 805240832 (767 MB) >> avail memory = 774049792 (738 MB) >> ACPI APIC Table: >> ioapic0 irqs 0-23 on motherboard >> wlan: mac acl policy registered >> kbd1 at kbdmux0 >> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >> RF5413) >> acpi0: on motherboard >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 >> cpu0: on acpi0 >> p4tcc0: on cpu0 >> acpi_button0: on acpi0 >> acpi_button1: on acpi0 >> pcib0: port 0xcf8-0xcff,0x4000-0x40bf on acpi0 >> pci0: on pcib0 >> agp0: on hostb0 >> pcib1: at device 1.0 on pci0 >> pci1: on pcib1 >> vgapci0: mem >> 0xe000-0xe0ff,0xd800-0xdfff irq 16 at device 0.0 on pci1 >> uhci0: port 0xd800-0xd81f >> irq >> 16 at device 29.0 on pci0 >> uhci0: [GIANT-LOCKED] >> uhci0: [ITHREAD] >> usb0: on uhci0 >> usb0: USB revision 1.0 >> uhub0: on usb0 >> uhub0: 2 ports with 2 removable, self powered >> uhci1: port 0xd000-0xd01f >> irq >> 19 at device 29.1 on pci0 >> uhci1: [GIANT-LOCKED] >> uhci1: [ITHREAD] >> usb1: on uhci1 >> usb1: USB revision 1.0 >> uhub1: on usb1 >> uhub1: 2 ports with 2 removable, self powered >> uhci2: port 0xd400-0xd41f >> irq >> 18 at device 29.2 on pci0 >> uhci2: [GIANT-LOCKED] >> uhci2: [ITHREAD] >> usb2: on uhci2 >> usb2: USB revision 1.0 >> uhub2: on usb2 >> uhub2: 2 ports with 2 removable, self powered >> ehci0: mem >> 0xe400-0xe40003ff irq 23 at device 29.7 on pci0 >> ehci0: [GIANT-LOCKED] >> ehci0: [ITHREAD] >> usb3: EHCI version 1.0 >> usb3: companion controllers, 2 ports each: usb0 usb1 usb2 >> usb3: on ehci0 >> usb3: USB revision 2.0 >> uhub3: on usb3 >> uhub3: 6 ports with 6 removable, self powered >> pcib2: at device 30.0 on pci0 >> pci2: on pcib2 >> fxp0: port 0xc000-0xc03f mem >> 0xe305-0xe3050fff,0xe302-0xe303 irq 18 at device 0.0 on pci2 >> miibus0: on fxp0 >> inphy0: PHY 1 on miibus0 >> inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> fxp0: Ethernet address: 00:02:b3:b6:af:59 >> fxp0: [ITHREAD] >> ath0: mem 0xe304-0xe304 irq 21 at device 1.0 on >> pci2 >> ath0: [ITHREAD] >> ath0: using obsoleted if_watchdog interface >> ath0: Ethernet address: 00:14:a5:0d:c0:91 >> ath0: mac 10.5 phy 6.1 radio 6.3 >> fxp1: port 0xc400-0xc43f mem >> 0xe3052000-0xe3052fff,0xe300-0xe301 irq 22 at device 2.0 on pci2 >> miibus1: on fxp1 >> inphy1: PHY 1 on miibus1 >> inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> fxp1: Ethernet address: 00:02:b3:b6:af:09 >> fxp1: [ITHREAD] >> vr0: port 0xc800-0xc8ff mem >> 0xe3051000-0xe30510ff irq 16 at device 3.0 on pci2 >> vr0: Quirks: 0x0 >> vr0: Revision: 0x43 >> miibus2: on vr0 >> ukphy0: PHY 8 on miibus2 >> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> vr0: Ethernet address: 00:50:ba:18:ff:5f >> vr0: [ITHREAD] >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 31.1 on pci0 >> ata0: on atapci0 >> ata0: [ITHREAD] >> ata1: on atapci0 >> ata1: [ITHREAD] >> pci0: at device 31.3 (no driver attached) >> pci0: at device 31.5 (no driver attached) >> fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on >> acpi0 >> fdc0: [FILTER] >> sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on >> acpi0 >> sio0: type 16550A >> sio0: [FILTER] >> sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 >> sio1: type 16550A >> sio1: [FILTER] >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> pmtimer0 o
Re: ICMP Error transmission/response over IPSec tunnels
Bjoern A. Zeeb wrote: On Tue, 27 May 2008, Tom Judge wrote: Bjoern A. Zeeb wrote: On Tue, 27 May 2008, Tom Judge wrote: Hi, Yes we do indeed see a reply from node b. It is good to here that this is a known issue. The IPSec configuration is a gif ipip tunnel that is then encrypted with IPSec using esp in tunnel mode as per the ipsec vpn section in the handbook. 1) if you do not need the ipip tunnel because you need an interface and "link state changes" only go with the IPsec tunnel mode. 2) If you need the gi tunnel on top and routing, use IPsec transport mode. (ignore the handbook, try to understand it;) I have 13 nodes in a parital mesh running ospf for routing. It would not be trivial for me to switch from tunnel to transport mode. Also I have not tested quagga in when the ipsec is in transport mode, and I guess I do need interfaces to use with quagga. I may test fixing this additional overhead, but as they say if it's not broken don't fix it. Ok. So basically you have 12 gif tunnels on each node, if it would be a full mesh. So it's less. So a) you have two endpoints for the gif tunnel which are your Router A, Router B endpoint. So the only thing you would need to secure is your IPIP (gif) tunnel between two nodes (Router A, B). This is what transport mode is for. Running a traceroute, the IP stack would need to send the icmp ttl exceeded packet back via the gif tunnel which then would have to be encrypted. To my memory the problem is that this does not work. You could try to find out at which layer by running tcpdump on the (external) interface and the gif interfaces and if you have enc0 to see if/where the icmp possibly shows up. I did this by running ng_iface into ng_ksocket(UDP) and using transport mode for all the UDP packets I had scripts to do it all, but unfortunately it was at a previous company. I allocated a number to each site from 1 to 8 and the endpoints inside the tunnels were 10.42.ME.YOU 10.42.YOU.ME. The scripts were identical on each machine, and to add a new machine I just added it to the list in the script, distributed the new script, and ran it again on each machine.. /bz ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel embedded NICs not working with FreeBSD 6.2, 6.3 and 7.0
On Tue, May 27, 2008 at 08:22:56PM +0200, Fuchs, Martin wrote: > Hi ! > > > > I am in contact with Chris Buechler because of pfSense and we he told me > to contact Jack Vogel because of some Intel NIC driver problem. > > > > FreeBSD detects them as fxp cards which is correct, but they do not work > at all, i tried in ACPI and non-ACPI mode and with enabled ROM and > disabled ROM and everything, but I cannot get them working... > > I always get "fxp0 timeout" or fxpX fort he corresponding card... I read > it might have something to do with dynamic powersaving mode or else but > have no clue how to deactivate, there's no option in the ROM for this. > > > > It's an appliance board (NexCom EBC575) with Intel 845GV / Intel 82801DB > (ICH4)-chipset and 2 x Intel 82551QM (PRO/100 Network Connection), 1 x > ICH4 integrated LAN Int on board. > > > > Is there anything I can tot o make it work for now or is it a known > problem or else ? > Since there are too many variants of fxp hardwares it would be even better to post the output of the following. o pciconf -lcv o dmesg output related with fxp(4) o devinfo -rv | grep oui o vmstat -i > > > Regards, > > > > looking forward to hear from you, > > > > Martin -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/124021: [ip6] [panic] page fault in nd6_output()
Old Synopsis: page fault in nd6_output() New Synopsis: [ip6] [panic] page fault in nd6_output() Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed May 28 03:49:54 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=124021 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd))
Hello Peter, * Peter Wemm <[EMAIL PROTECTED]> wrote: > As an example.. look at the CAN_BYPASS_L_RINT stuff. If we had a way > to pass a block of characters upstream instead of a single character > at a time, then we could build this magic into the input routines > instead of the device drivers. I still haven't had time to add the CAN_BYPASS_L_RINT functionality back. I was thinking about adding the actual copying to the buffers inside the TTY layer, which means we can finally remove all that redundant code from the drivers. But this is still on my TODO list. ;-) -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://80386.nl/ pgpkTJbAesjhE.pgp Description: PGP signature
