Re: kern/155597: [panic] Kernel panics with "sbdrop" message
Old Synopsis: Kernel panics with "sbdrop" message New Synopsis: [panic] Kernel panics with "sbdrop" message Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 16 12:33:10 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=155597 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: MAC address / per-proto ARP caching in 8.1-RELEASE
On 03/15/11 14:26, Jeremy Chadwick wrote: On Tue, Mar 15, 2011 at 09:30:39AM -0400, Steve Polyack wrote: Is anyone aware of some sort of facility in either FreeBSD 8.1-RELEASE or the em(4) driver which would cause it to cache MAC addresses / ARP entries for hosts on a per-protocol basis? [snipping remaining details; readers can read it here instead:] [http://lists.freebsd.org/pipermail/freebsd-stable/2011-March/061908.html] The only thing I can think of would be flowtable, but I'm not sure if it's enabled by default on 8.1-RELEASE-p2. You can try the following sysctl to disable it (I would recommend setting this in sysctl.conf and rebooting; I don't know what happens in the case you set it on a live system that's already experiencing the MAC issue you describe). net.inet.flowtable.enable=0 Details: http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf I gave this a shot again this morning. It's definitely related to the flowtable: [spolyack@web01 ~]$ time host web00.lab00 ; sudo sysctl net.inet.flowtable.enable=0 ; time host web00.lab00 ;; connection timed out; no servers could be reached real0m10.017s user0m0.000s sys0m0.008s net.inet.flowtable.enable: 1 -> 0 web00.lab00 has address 10.0.1.129 real0m0.069s user0m0.000s sys0m0.003s I'm still curious as to why this is only breaking new outgoing UDP traffic. New TCP connections aren't affected in the same way at all. There also does not seem to be any relevant changes to flowtable code between 8.1-RELEASE and 8.2-RELEASE or 8-STABLE. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Netgraph/mpd5 stability issues
On 16.03.2011 19:21, Mike Tancsa wrote: > A new one it seems. On the console, I have one with full crashdump too. Crashdump and other files are available on request. GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq256: em0:rx 0) trap number = 9 panic: general protection fault cpuid = 3 KDB: stack backtrace: X_db_sym_numargs() at 0x801a227a = X_db_sym_numargs+0x15a kdb_backtrace() at 0x8033f557 = kdb_backtrace+0x37 panic() at 0x8030d517 = panic+0x187 dblfault_handler() at 0x804c2ef0 = dblfault_handler+0x330 trap() at 0x804c34d9 = trap+0x109 calltrap() at 0x804aafe4 = calltrap+0x8 --- trap 0x9, rip = 0x802fe3ee, rsp = 0xff800010f7a0, rbp = 0xff800010f7c0 --- _mtx_lock_sleep() at 0x802fe3ee = _mtx_lock_sleep+0x4e bpf_mtap2() at 0x803b79fa = bpf_mtap2+0x27a ng_bypass() at 0x803dd0aa = ng_bypass+0x1d1a ng_bypass() at 0x803dd581 = ng_bypass+0x21f1 ip_fastforward() at 0x80408566 = ip_fastforward+0x7e6 ether_demux() at 0x803c39c1 = ether_demux+0x131 ether_vlanencap() at 0x803c3dad = ether_vlanencap+0x27d ata_sii_chipinit() at 0x801e757a = ata_sii_chipinit+0xe50a ata_sii_chipinit() at 0x801e78f4 = ata_sii_chipinit+0xe884 intr_event_execute_handlers() at 0x802e6c24 = intr_event_execute_handlers+0x104 swi_add() at 0x802e82b5 = swi_add+0x265 fork_exit() at 0x802e42e8 = fork_exit+0x118 fork_trampoline() at 0x804ab4ae = fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff800010fcf0, rbp = 0 --- Uptime: 2d15h11m31s Dumping 2039 MB (2 chunks) chunk 0: 1MB (155 pages) (CTRL-C to abort) ... ok chunk 1: 2039MB (521840 pages) 2023 2007 1991 1975 1959 1943 1927 1911 1895 1879 1863 1847 1831 1815 1799 1783 1767 Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 06 fault virtual address = 0x1 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x1 stack pointer = 0x28:0xff809299ca90 frame pointer = 0x28:0xff809299cac0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq21: atapci1) trap number = 12 panic: page fault cpuid = 3 1751 1735 1719 1703 1687 1671 1655 1639 1623 1607 1591 1575 1559 1543 1527 1511 1495 1479 1463 1447 1431 1415 1399 1383 1367 1351 1335 1319 1303 1287 1271 1255 1239 1223 1207 1191 1175 1159 1143 1127 1095 1079 1063 1047 1031 1015 999 983 967 951 935 919 903 887 871 855 839 823 807 791 775 759 743 727 711 695 679 663 647 631 615 599 583 567 551 535 519 503 487 471 455 439 423 407 391 375 359 343 327 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 Reading symbols from /boot/kernel/ipmi.ko...done. Loaded symbols for /boot/kernel/ipmi.ko Reading symbols from /boot/kernel/if_lagg.ko...done. Loaded symbols for /boot/kernel/if_lagg.ko #0 doadump () at /home/src/sys/kern/kern_shutdown.c:251 251 if (textdump_pending) (kgdb) bt #0 doadump () at /home/src/sys/kern/kern_shutdown.c:251 #1 0x8030d0d0 in boot (howto=260) at /home/src/sys/kern/kern_shutdown.c:419 #2 0x8030d501 in panic (fmt=Variable "fmt" is not available. ) at /home/src/sys/kern/kern_shutdown.c:592 #3 0x804c2ef0 in trap_fatal (frame=0x9, eva=Variable "eva" is not available. ) at /home/src/sys/amd64/amd64/trap.c:839 #4 0x804c34d9 in trap (frame=0xff800010f6f0) at /home/src/sys/amd64/amd64/trap.c:648 #5 0x804aafe4 in calltrap () at /home/src/sys/amd64/amd64/exception.S:228 #6 0x802fe3ee in _mtx_lock_sleep (m=0xff00070c0828, tid=18446742974221537280, opts=Variable "opts" is not available. ) at /home/src/sys/kern/kern_mutex.c:369 #7 0x803b79fa in bpf_mtap2 (bp=0xff00070c0800, data=Variable "data" is not available. ) at /home/src/sys/net/bpf.c:1872 #8 0x803dd0aa in ng_iface_bpftap (ifp=Variable "ifp" is not available. ) at /home/src/sys/netgraph/ng_iface.c:446 #9 0x803dd581 in ng_iface_output (ifp=0xff0011282000, m=0xff000d196800, dst=0xff800010f9d0, ro=Variable "ro" is not available. ) at /home/src/sys/netgraph/ng_iface.c:396 #10 0xfff
select default outgoin IP for adapter with multiple ips, may be bug
Hello. I am having some troubles configuring adapter with multiple ips, And I believe I have found a bug. The explanation is a bit long... Here it is: XX.YY.2.33/30 at ISPs side used as my default gw XX.YY.2.34/30 at my side I have network XX.YY.95.0/24 routed to me I dont have internet on XX.YY.2.34, but I have on XX.YY.95.0/24 I am trying to configure adapter vlan199 conected to ISP to use ip XX.YY.95.1 as default ip (src-address) for outgoing traffic. I expected that when I add XX.YY.95.1 as first IP and XX.YY.2.34 as second it will be ok. But the order does not matter - XX.YY.2.34 is always used as outgoing IP. When I ping google.com .. I dont get replies, but when I ping -S XX.YY.95.1 google.com - I get replies. Here is the only way that I have found to select XX.YY.95.1 as default outgoing address: add XX.YY.95.1/32 on the adapter, create static route to my default gw (XX.YY.2.34), create default route, add the other ip to the adapter. ifconfig vlan199 create ifconfig vlan199 vlan 199 vlandev fxp0 ifconfig vlan199 up ifconfig vlan199 XX.YY.95.1/32 route add -host XX.YY.2.33 -iface vlan199 route add default XX.YY.2.33 ifconfig vlan199 add XX.YY.2.34/30 But drawback is that I cannot achieve such order in rc.conf. (add ip then routes then again ip) The other problem is that if delete the default gw and add it again, or change it to the same one, then the default outgoing ip resets to XX.YY.2.34. This is why I think that there is someting wrong, may be bug may be I am doing it wrong I dont know. I have tried this on FreeBSD 8.2-RELEASE. I believe on older freebsd versions the default outgoing ip for adapter is the one at the top from ifconfig adapter. Georgi Iovchev ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: select default outgoin IP for adapter with multiple ips, may be bug
On Wed, 16 Mar 2011, Georgi Iovchev wrote: Hello. I am having some troubles configuring adapter with multiple ips, And I believe I have found a bug. The explanation is a bit long... Here it is: XX.YY.2.33/30 at ISPs side used as my default gw XX.YY.2.34/30 at my side I have network XX.YY.95.0/24 routed to me I dont have internet on XX.YY.2.34, but I have on XX.YY.95.0/24 I am trying to configure adapter vlan199 conected to ISP to use ip XX.YY.95.1 as default ip (src-address) for outgoing traffic. I expected that when I add XX.YY.95.1 as first IP and XX.YY.2.34 as second it will be ok. But the order does not matter - XX.YY.2.34 is always used as outgoing IP. When I ping google.com .. I dont get replies, but when I ping -S XX.YY.95.1 google.com - I get replies. Here is the only way that I have found to select XX.YY.95.1 as default outgoing address: add XX.YY.95.1/32 on the adapter, create static route to my default gw (XX.YY.2.34), create default route, add the other ip to the adapter. ifconfig vlan199 create ifconfig vlan199 vlan 199 vlandev fxp0 ifconfig vlan199 up ifconfig vlan199 XX.YY.95.1/32 route add -host XX.YY.2.33 -iface vlan199 route add default XX.YY.2.33 ifconfig vlan199 add XX.YY.2.34/30 But drawback is that I cannot achieve such order in rc.conf. (add ip then routes then again ip) The other problem is that if delete the default gw and add it again, or change it to the same one, then the default outgoing ip resets to XX.YY.2.34. This is why I think that there is someting wrong, Right, the order you add IPs and routes shouldn't matter. I wonder why it does. may be bug may be I am doing it wrong I dont know. I have tried this on FreeBSD 8.2-RELEASE. I believe on older freebsd versions the default outgoing ip for adapter is the one at the top from ifconfig adapter. FreeBSD since 7.2 has been doing "more proper" source address selection for unbound outgoing connections. The solution is called bind. Another solution to try might be setfib(8). /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Jumbo frame support for BGE_ASICREV_BCM5714
On Tue, Mar 15, 2011 at 04:38:44PM -0700, YongHyeon PYUN wrote: > On Mon, Mar 14, 2011 at 09:40:36PM -0700, Vijay Singh wrote: > > > As you know, BCM5714, BCM5715 and BCM5780 use unique jumbo frame > > > scheme that is not compatible with other controllers. All other > > > Broadcom controllers have better jumbo frame scheme. These > > > controllers have one send ring, one standard receive producer ring > > > and one receive return ring. In order to receive jumbo frames on > > > these controllers you have to increase Rx buffer size to hold 9k > > > sized jumbo frame. Two Rx modes(standard Rx BDs and extended Rx > > > BDs) are supported for these controllers. Using extended Rx BDs on > > > BCM5714/BCM5715/BCM5780 reduces the number of Rx BDs to 256 entries > > > which shall reduce the performance. I would use standard Rx BDs to > > > hold 512 entries for RX buffers. > > > > > > I think I received jumbo frame support request for these > > > controllers in past. At that time I had no interests on > > > implementing it due to severe implementation differences. What is > > > your main reason to use jumbo frame on this controller? What is > > > your expectation on performance numbers? I guess no other OSes > > > support jumbo frame on this controller. > > > > Hi Pyun, I am stuck with this NIC due to it being the one present in > > the HW platform that I have to support. The performance is expectation > > is mainly for apps that use large payloads (where something TSO would > > have helped). > > > > Here is experimental patch which I tried not to penalize other > controllers. I don't have BCM5714 controllers so I don't know > whether it works or not. The patch was generated against HEAD and > it would be cleanly applied to 8.2R/7.4R. Due to large bge(4) > changes I guess it wouldn't be applied to 7.2R. But I guess you can > install 8.2R/7.4R to one of your box and experiment this patch for > a while then you can backport this to 7.2R. > You can find the patch at the following URL. > http://people.freebsd.org/~yongari/bge/bge.5714.jumbo.diff > There was a bug in the diff. I updated the diff but URL is the same as before. If you have downloaded the file, please try again. > > -vijay ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/155604: [flowtable] Flowtable excessively caches dest MAC addresses for outgoing UDP traffic
Old Synopsis: Flowtable excessively caches dest MAC addresses for outgoing UDP traffic New Synopsis: [flowtable] Flowtable excessively caches dest MAC addresses for outgoing UDP traffic Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 16 21:09:22 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=155604 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Driver for Realtek RTL8191SE?
It seems we have no driver for the Realtek RTL8191SE/RTL8192SE WiFi chipset. Tried using NDIS with the Windows driver, but no luck there, either. Attaching the pciconf info for this device. Anyone working in this area? Thanks, -jr toshiba_l675.pci Description: Binary data ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Jumbo frame support for BGE_ASICREV_BCM5714
> > There was a bug in the diff. I updated the diff but URL is the same > as before. If you have downloaded the file, please try again. > Hi, thanks a lot for your effort. I will test this out within a week and get you some feedback. Thanks again. -vijay ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
mpd- no ng_l2tp coming up
I tried this on -questions@ but the consensus is to try here. I'm running into all sorts of issues setting up l2tp networking. I think I have the IPSEC part worked out, but testing parts at a time l2tp dies in a hole. I've resorted to mpd as it seems to be widely used in BSD (and linux too..), but the result seems to be the same for other servers as well such as l2tpd. Mpd gave me the most debug info- so it won the toss. I can start the server, it says ok and runs; I check sockstat, l2tp ports are open; I can even check the console (mpd), its says all systems go. I run the client- the connection dies, and so does the server. I've tried to get a clear outline of what is required for a lns (the docs and sample config only define a lac)- there are plenty of client howtos but not many servers. That said I can't see what the hold up is: startup: log +all set webself 0.0.0.0 5006 set webopen #set webauthdisable set user default: load l2tp_vpn l2tp_vpn: set ippool add pool1 192.168.0.42 192.168.0.45 create bundle template B1 set iface enable tcpmssfix set iface idle 1800 set ipcp ranges 192.168.0.40/32 ippool pool1 set ipcp dns 192.168.0.20 set ipcp enable vjcomp set bundle enable compression create link template L1 l2tp set l2tp self 0.0.0.0 #set l2tp hostname set l2tp secret set l2tp disable outcall #set l2tp enable hidden set link action bundle B1 set link no pap chap eap set link yes pap chap set link enable multilink set link mtu 1460 set link enable acfcomp protocomp set link enable incoming #set radius server This is for mpd5, though mpd4 fails similarly as well. Obviously the config is adjusted accordingly, and I have seen one of each in examples found on google. I've gone for a simple as possible to help debug this. mpd.log: Mar 15 23:15:14 bell mpd: Multi-link PPP daemon for FreeBSD Mar 15 23:15:14 bell mpd: Mar 15 23:15:14 bell mpd: process 2762 started, version 5.5 (r...@bell.herveybayaustralia.com.au 10:40 7-Mar-2011) Mar 15 23:15:14 bell mpd: web: listening on 0.0.0.0 5006 Mar 15 23:15:14 bell mpd: EVENT: Registering event EVENT_READ MsgEvent() at msg.c:72 Mar 15 23:15:14 bell mpd: EVENT: Registering event EVENT_READ MsgEvent() done at msg.c:72 Mar 15 23:15:14 bell mpd: EVENT: Registering event EVENT_READ L2tpServerEvent() at l2tp.c:1636 Mar 15 23:15:14 bell mpd: EVENT: Registering event EVENT_READ L2tpServerEvent() done at l2tp.c:1636 Mar 15 23:15:14 bell mpd: L2TP: waiting for connection on 0.0.0.0 1701 Mar 15 23:15:14 bell mpd: EVENT: Processing event EVENT_TIMEOUT ConfigRead() done Mar 15 23:15:36 bell mpd: EVENT: Processing event EVENT_READ L2tpServerEvent() Mar 15 23:15:36 bell mpd: Incoming L2TP packet from 192.168.0.200 47973 Mar 15 23:15:36 bell mpd: L2TP: ppp_l2tp_ctrl_create invoked Mar 15 23:15:36 bell mpd: L2TP: Control connection 0x286f3d08 0.0.0.0 1701 <-> 192.168.0.200 47973 accepted Mar 15 23:15:36 bell mpd: EVENT: Processing event EVENT_READ L2tpServerEvent() done Mar 15 23:15:36 bell mpd: L2TP: RECV [MESSAGE_TYPE SCCRQ] [PROTOCOL_VERSION 1.0] [HOST_NAME "anonymous"] [FRAMING_CAPABILITIES sync=1 async=1] [ASSIGNED_TUNNEL_ID 0x0d78] [RECEIVE_WINDOW_SIZE 1] [CHALLENGE c819a7182517daa2a777da6a7e7e581712745f00e3c707a3f381fb3561faa56e] Mar 15 23:15:36 bell mpd: L2TP: rec'd SCCRQ in state idle Mar 15 23:15:36 bell mpd: L2TP: connected to "anonymous", version=1.0 Mar 15 23:15:36 bell mpd: L2TP: XMIT [MESSAGE_TYPE SCCRP] [HOST_NAME "bell.herveybayaustralia.com.au"] [VENDOR_NAME "FreeBSD MPD"] [BEARER_CAPABILITIES digital=1 analog=1] [RECEIVE_WINDOW_SIZE 8] [PROTOCOL_VERSION 1.0] [FRAMING_CAPABILITIES sync=1 async=1] [ASSIGNED_TUNNEL_ID 0x7008] [CHALLENGE 481df3c95b9e9579adf0cae17d58e680] [CHALLENGE_RESPONSE d6f82bd055e8479f6e8dbe943a5b11c0] Mar 15 23:15:43 bell mpd: L2TP: RECV [MESSAGE_TYPE SCCCN] Mar 15 23:15:43 bell mpd: L2TP: rec'd SCCCN in state wait-ctl-conn Mar 15 23:15:43 bell mpd: L2TP: SCCRP lacks challenge response Mar 15 23:15:43 bell mpd: L2TP: XMIT [MESSAGE_TYPE StopCCN] [ASSIGNED_TUNNEL_ID 0x7008] [RESULT_CODE result=4 error=0 errmsg=""] Mar 15 23:15:43 bell mpd: L2TP: Control connection 0x286f3d08 0.0.0.0 1701 <-> 192.168.0.200 47973 connected Mar 15 23:15:43 bell mpd: L2TP: Control connection 0x286f3d08 terminated: 0 () Mar 15 23:15:43 bell mpd: ASSERT "ctrl->state == CS_DYING" failed: file "l2tp_ctrl.c", line 1426 Mar 15 23:15:43 bell mpd: fatal error, exiting Mar 15 23:15:43 bell mpd: [B1] Bundle: Shutdown Mar 15 23:15:43 bell mpd: [L1] Link: Shutdown Mar 15 23:15:43 bell mpd: L2TP: stop waiting for connection on 0.0.0.0 1701 Mar 15 23:15:43 bell mpd: EVENT: Unregistering event EVENT_READ L2tpServerEvent() at l2tp.c:1671 Mar 15 23:15:43 bell mpd: EVENT: Unregistering event EVENT_READ L2tpServerEvent() done at l2tp.c:1671 Mar 15 23:15:43 bell mpd: PPTP: Total shutdown Mar 15 23:15:43 b
Re: mpd- no ng_l2tp coming up
On 3/16/2011 9:32 PM, Da Rock wrote: > I'm running into all sorts of issues setting up l2tp networking. I think > I have the IPSEC part worked out, but testing parts at a time l2tp dies > in a hole. Try without IPSEC first to make sure you have the l2tp portion correct. Also, make sure no firewall rules are getting in the way. I have this simple mpd5 config file to act as an l2tp server in my test environment startup: # configure mpd users set user admin xxx admin # configure the console set console self 127.0.0.1 5005 set console open # configure the web server set web self 192.168.255.254 5006 set web open log +IPV6CP log +IPV6CP2 default: load l2tpserver l2tpserver: # Define dynamic IP address pool. set ippool add pool1 xx.159.245.1 xx.159.245.5 set ippool add pool1 10.241.241.20 10.241.241.99 set ippool add rfc1918 172.11.22.140 172.11.22.180 # Create clonable bundle template named B create bundle template B set iface idle 1800 set iface enable tcpmssfix set ipcp disable vjcomp set bundle enable ipv6cp set ipcp deny vjcomp set ipcp ranges xx.43.128.6/32 ippool pool1 set ipcp dns yy.211.164.51 zz.212.134.12 #set ipcp nbns 127.0.0.1 # Set bundle template to use create link template L l2tp set l2tp hostname sentex set l2tp disable dataseq set link action bundle B # Enable peer authentication set link disable eap set link enable pap set link disable acfcomp set link disable protocomp set link disable check-magic set link deny acfcomp set link keep-alive 10 60 set link deny protocomp #load radius set link mtu 1492 set link mru 1492 set link enable incoming set link disable peer-as-calling For the client, mpd5 works with the following config l2tp_client: # # PPPoE client: only outgoing calls, auto reconnect, # ipcp-negotiated address, one-sided authentication, # default route points on ISP's end # create bundle static B1 set iface route default set ipcp ranges 0.0.0.0/0 0.0.0.0/0 create link static L1 l2tp set link action bundle B1 set auth authname testaccount-in-mpd-secret-file set auth password thepass set link max-redial 0 set link mtu 1460 set link keep-alive 20 75 set l2tp peer 64.7.128.195 open > I also had an unscheduled reboot (power failure) and that showed up a > warning: "attempt to domain_add(netgraph) after domainfinalize()" which > I could never quite figure was fatal or not. Thats ok. Its not an issue and is more informational than anything > It appears the control connection is setup and then fails for some > inexplicable reason. The client (android) logs show the same, but it is > definitely the server that kills the connection. Anything I've missed? Make sure there are no firewall rules getting in the way. And if possible, use a client that you know "works". The above server works with Windows clients with IPSEC disabled. Start there, or with a FreeBSD client. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: mpd- no ng_l2tp coming up
On 03/17/11 13:59, Mike Tancsa wrote: On 3/16/2011 9:32 PM, Da Rock wrote: I'm running into all sorts of issues setting up l2tp networking. I think I have the IPSEC part worked out, but testing parts at a time l2tp dies in a hole. Try without IPSEC first to make sure you have the l2tp portion correct. Also, make sure no firewall rules are getting in the way. Check the last note- local net only atm for testing, though the result is the same through the firewall and on the public net. IPSEC works (I think), but has been bypassed to resolve the l2tp issues anyway. So the only thing between the server and client is the local network. I have this simple mpd5 config file to act as an l2tp server in my test environment startup: # configure mpd users set user admin xxx admin # configure the console set console self 127.0.0.1 5005 set console open # configure the web server set web self 192.168.255.254 5006 set web open log +IPV6CP log +IPV6CP2 default: load l2tpserver l2tpserver: # Define dynamic IP address pool. set ippool add pool1 xx.159.245.1 xx.159.245.5 set ippool add pool1 10.241.241.20 10.241.241.99 set ippool add rfc1918 172.11.22.140 172.11.22.180 # Create clonable bundle template named B create bundle template B set iface idle 1800 set iface enable tcpmssfix set ipcp disable vjcomp set bundle enable ipv6cp set ipcp deny vjcomp set ipcp ranges xx.43.128.6/32 ippool pool1 set ipcp dns yy.211.164.51 zz.212.134.12 #set ipcp nbns 127.0.0.1 # Set bundle template to use create link template L l2tp set l2tp hostname sentex set l2tp disable dataseq set link action bundle B # Enable peer authentication set link disable eap set link enable pap set link disable acfcomp set link disable protocomp set link disable check-magic set link deny acfcomp set link keep-alive 10 60 set link deny protocomp #load radius set link mtu 1492 set link mru 1492 set link enable incoming set link disable peer-as-calling For the client, mpd5 works with the following config l2tp_client: # # PPPoE client: only outgoing calls, auto reconnect, # ipcp-negotiated address, one-sided authentication, # default route points on ISP's end # create bundle static B1 set iface route default set ipcp ranges 0.0.0.0/0 0.0.0.0/0 create link static L1 l2tp set link action bundle B1 set auth authname testaccount-in-mpd-secret-file set auth password thepass set link max-redial 0 set link mtu 1460 set link keep-alive 20 75 set l2tp peer 64.7.128.195 open I also had an unscheduled reboot (power failure) and that showed up a warning: "attempt to domain_add(netgraph) after domainfinalize()" which I could never quite figure was fatal or not. Thats ok. Its not an issue and is more informational than anything Ok. So then my main question is going to be: when should I see a ng node through ifconfig? Is it "enabled" (for want of a better term) when the server is started, or once a connection is established? Is it the same for mpd4 and mpd5? And shouldn't I see something in the nglist as well? It appears the control connection is setup and then fails for some inexplicable reason. The client (android) logs show the same, but it is definitely the server that kills the connection. Anything I've missed? Make sure there are no firewall rules getting in the way. And if possible, use a client that you know "works". The above server works with Windows clients with IPSEC disabled. Start there, or with a FreeBSD client. Windows "works"? Interesting premise :) Sorry, can't help myself... I have now only got a "clean" network- FBSD only ;) so I'll have to try with an mpd client then. Thanks Mike, I'll be back with some more results soon- it will take time to install mpd. Cheers ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
