Re: [PATCH] multiple instances of ipfw(4)
On Mon, Jan 30, 2012 at 10:08 PM, Vadim Goncharov wrote: > Hi Ermal Lu?i! > > On Mon, 30 Jan 2012 13:01:13 +0100; Ermal Lu?i wrote about '[PATCH] multiple > instances of ipfw(4)': > >> from needs on pfSense a patch for allowing multiple intances of >> ipfw(4) in kernel to co-exist was developed. >> It can be found here >> https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff > > Hmm, looking at the lines > > if (oif && !(oif->if_flags & IFF_IPFW_FILTER)) > return (IP_FW_PASS); > > it appears that a patch is made against somewhat private, I couldn't find that > in stock FreeBSD. Yeah its not so polished patch, and the remaining parts are still there in the same repo. Though its redundant to this patch. > >> It is used in conjuction with this tool >> https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c >> It allows creation of contextes/instances and assignment of specific >> interfaces to specific contexts/instances. > > It is not clear how to add a rule to a specific instance with this program. > Simple example: - Create a context with members ipfw_context -a testctx ipfw_context -a testctx -n myiface0 ipfw_context -a testctx -n myiface1 - Set the context ipfw_context -s testctx - Continue business as usual with ipfw/dummynet ipfw add ipfw pipe create ipfw table add >> Surely i know that this is not the best way to implement generically >> but it gets the job done for us as it is, read below. > >> What i would like to know is if there is interest to see such >> functionality in FreeBSD? > >> I am asking first to see if there is some consensus about this as a >> feature, needed or not! >> If interest is shown i will transform the patch to allow: >> - ipfw(8) to manage the contextes create/destroy >> - ipfw(8) to manage interface membership. Closing the race of two >> parallell clients modifying different contextes. > >> There is another design choice to be made about storing the membership >> of interfaces into contexts/instances, but i do not see that as >> blocking. > >> It is quite handy feature, which can be exploited even to scale on SMP >> machines by extending it to bind a specific instance(with its >> interaces) to a specific CPU/core?! > > Not so simple/straightforward questions. On the one hand, there are at least > /some/ people who need this. So the ipfw 'call'/'return' actions were already > implemented, first appearing in 9.0-R / 8.3-R. And melifaro@ has patches to > ipfw table allowing matching againt ifname, setting tablearg, which in > conjunction with 'call' or 'skipto' could be used to make essentially the same > functionality as your proposed patch, already in stock FreeBSD. > Well it tends to get messy if you do not have a smart consumer handling the jumps. Its almost as reprogramming in ipfw language and somehow an admin needs to read this! The intention was be practical and allow easy troubleshooting. > On the other hand, both ipfw contexts and ipfw 'call' are very half-measures. > The only goal was to give people something right now, and see how much this > will be demanded, what feedback they'll give, etc. It is obvious there is no > wide testing of 9.0-R (and 8.3-R too) right now. > It depends on the needs, surely and how colorful you want it to be. > What I mean here about half-measures? The ipfw 'call' is just a sketch of my > old ideas to completely reorganize ipfw to support multiple rulesets. To be > generic and Right Thing(tm), this is a HUGE work, because: > > - each ipfw chain becomes independent netgraph(4) node > - generic ng_pfil node usable not only for firewalls > - chains may be called from each other (see iptables) > - chains (actually netgraph nodes) may be bind to ifaces or any other place > - main unnamed chain is called from pfil as before > - rewrite ipfw & dummynet management from setsockopt() to netgraph messages > - completely rewrite ipfw dynamic rules to not conflict with multiple > rulesets, as now they just jump to parent static rule (need to be more like > pf or iptables states). This item is hard but essential (you'll get a mess > jumping to another ruleset), and ipfw contexts don't handle ot > - while here, do other needed things, e.g. adding support for modules in both > kernel and userland, loadable opcodes, keywords, etc. > if you write a ip/tcp/udp/... stack on netgraph than i will write this :) Though its a matter of preference and how much work its needed to accomplish this! Surely ipfw has seen a lot of hacks in the past and will see in the future but i thik usability is more of a target rather than fancy design. But surely nothing should stop both ways. > Even if not add something like bpf, that's ipfw_ng is probably a more major > change than both ipfw2 and ipfw3 :) > > Due to various reasons in my private life, I was unable to do it in my spare > time previous years. My new employer is a provide
Re: [PATCH] multiple instances of ipfw(4)
On 1/31/12 12:53 AM, Ermal Luçi wrote: On Mon, Jan 30, 2012 at 10:08 PM, Vadim Goncharov wrote: Hi Ermal Lu?i! On Mon, 30 Jan 2012 13:01:13 +0100; Ermal Lu?i wrote about '[PATCH] multiple instances of ipfw(4)': from needs on pfSense a patch for allowing multiple intances of ipfw(4) in kernel to co-exist was developed. It can be found here https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff Hmm, looking at the lines if (oif&& !(oif->if_flags& IFF_IPFW_FILTER)) return (IP_FW_PASS); it appears that a patch is made against somewhat private, I couldn't find that in stock FreeBSD. Yeah its not so polished patch, and the remaining parts are still there in the same repo. Though its redundant to this patch. It is used in conjuction with this tool https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c It allows creation of contextes/instances and assignment of specific interfaces to specific contexts/instances. It is not clear how to add a rule to a specific instance with this program. Simple example: - Create a context with members ipfw_context -a testctx ipfw_context -a testctx -n myiface0 ipfw_context -a testctx -n myiface1 - Set the context ipfw_context -s testctx - Continue business as usual with ipfw/dummynet ipfw add ipfw pipe create ipfw table add Surely i know that this is not the best way to implement generically but it gets the job done for us as it is, read below. What i would like to know is if there is interest to see such functionality in FreeBSD? I am asking first to see if there is some consensus about this as a feature, needed or not! If interest is shown i will transform the patch to allow: - ipfw(8) to manage the contextes create/destroy - ipfw(8) to manage interface membership. Closing the race of two parallell clients modifying different contextes. There is another design choice to be made about storing the membership of interfaces into contexts/instances, but i do not see that as blocking. It is quite handy feature, which can be exploited even to scale on SMP machines by extending it to bind a specific instance(with its interaces) to a specific CPU/core?! Not so simple/straightforward questions. On the one hand, there are at least /some/ people who need this. So the ipfw 'call'/'return' actions were already implemented, first appearing in 9.0-R / 8.3-R. And melifaro@ has patches to ipfw table allowing matching againt ifname, setting tablearg, which in conjunction with 'call' or 'skipto' could be used to make essentially the same functionality as your proposed patch, already in stock FreeBSD. Well it tends to get messy if you do not have a smart consumer handling the jumps. Its almost as reprogramming in ipfw language and somehow an admin needs to read this! The intention was be practical and allow easy troubleshooting. On the other hand, both ipfw contexts and ipfw 'call' are very half-measures. The only goal was to give people something right now, and see how much this will be demanded, what feedback they'll give, etc. It is obvious there is no wide testing of 9.0-R (and 8.3-R too) right now. It depends on the needs, surely and how colorful you want it to be. What I mean here about half-measures? The ipfw 'call' is just a sketch of my old ideas to completely reorganize ipfw to support multiple rulesets. To be generic and Right Thing(tm), this is a HUGE work, because: - each ipfw chain becomes independent netgraph(4) node what about the existing netgraph ipfw node someone wrote a few years ago? I saw it but don't know if it was sent out publicly. - generic ng_pfil node usable not only for firewalls - chains may be called from each other (see iptables) - chains (actually netgraph nodes) may be bind to ifaces or any other place - main unnamed chain is called from pfil as before - rewrite ipfw& dummynet management from setsockopt() to netgraph messages - completely rewrite ipfw dynamic rules to not conflict with multiple rulesets, as now they just jump to parent static rule (need to be more like pf or iptables states). This item is hard but essential (you'll get a mess jumping to another ruleset), and ipfw contexts don't handle ot - while here, do other needed things, e.g. adding support for modules in both kernel and userland, loadable opcodes, keywords, etc. if you write a ip/tcp/udp/... stack on netgraph than i will write this :) Though its a matter of preference and how much work its needed to accomplish this! Surely ipfw has seen a lot of hacks in the past and will see in the future but i thik usability is more of a target rather than fancy design. But surely nothing should stop both ways. Even if not add something like bpf, that's ipfw_ng is probably a more major change than both ipfw2 and ipfw3 :) Due to various reasons in my private life, I was unable to do it in my spare time previous years. My new empl
ports/net/e169-stats (was: UMTS Huawei monitor)
El día Monday, January 30, 2012 a las 12:09:20PM +0100, Matthias Apitz escribió: > > Hello, > > I'm used to connect my FreeBSD laptop or netbooks to Internet using > Huawei USB modems (E220 or E1750) with good results, if the networks > coverage of the provider is good enough in the place in question. > > ... > > ++ > |uptime: hh:mm:ss| > |RSSI: current 11 of 31 [last values: 13, 11, 12, 11, 11. 11. 11, 11, 11]| > | (Mbps): 0.1.2.3.4.5..| > |cur. upload speed: [-->| ]| > |c. download speed: [-->| ]| > |total bytes upld: 1.554.561| > |total bytes down: 5.477.584| > ++ Hello, I was thinking about a Huawei USB modem monitor and got a pointer to the ports/net/e169-stats (thanks to Milan for this); I have checked it out and it does mostly what I was thinking of; I have a few questions which are not answered in the documentation (because there is no manual or other doc :-)) ... anybody out here who is using this tool and could answer perhaps my question? Thanks in advance matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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: ports/net/e169-stats (was: UMTS Huawei monitor)
On Tue, 31 Jan 2012 10:44:14 +0100 Matthias Apitz wrote: > El día Monday, January 30, 2012 a las 12:09:20PM +0100, Matthias > Apitz escribió: > > > > > Hello, > > > > I'm used to connect my FreeBSD laptop or netbooks to Internet using > > Huawei USB modems (E220 or E1750) with good results, if the networks > > coverage of the provider is good enough in the place in question. > > > > ... > > > > ++ > > |uptime: > > hh:mm:ss| > > |RSSI: current 11 of 31 [last values: 13, 11, 12, 11, 11. 11. 11, > > 11, 11]| | (Mbps): > > 0.1.2.3.4.5..| |cur. upload > > speed: [-->| ]| |c. > > download speed: [-->| > > ]| |total bytes upld: > > 1.554.561| |total > > bytes down: 5.477.584| > > ++ > > Hello, > > I was thinking about a Huawei USB modem monitor and got a pointer to > the ports/net/e169-stats (thanks to Milan for this); I have checked > it out and it does mostly what I was thinking of; I have a few > questions which are not answered in the documentation (because there > is no manual or other doc :-)) ... anybody out here who is using this > tool and could answer perhaps my question? Thanks in advance > > matthias Hi, just ask here, I think - maybe add ed...@mavetju.org to CC as he wrote this and should have definite answers, I think. I use some Huawei occasionally with e169-stats to see signal properties. I bet there are others out there using it as well, so "someone" (tm) should know :) Regards, Milan ___ 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: ports/net/e169-stats (was: UMTS Huawei monitor)
El día Tuesday, January 31, 2012 a las 11:01:00AM +0100, Milan Obuch escribió: > > I was thinking about a Huawei USB modem monitor and got a pointer to > > the ports/net/e169-stats (thanks to Milan for this); I have checked > > it out and it does mostly what I was thinking of; I have a few > > questions which are not answered in the documentation (because there > > is no manual or other doc :-)) ... anybody out here who is using this > > tool and could answer perhaps my question? Thanks in advance > > > > matthias > > Hi, > > just ask here, I think - maybe add ed...@mavetju.org to CC as he wrote > this and should have definite answers, I think. I use some Huawei > occasionally with e169-stats to see signal properties. I bet there are > others out there using it as well, so "someone" (tm) should know :) Hi, I'm attaching a cut&paste of the xterm where e169-stats runs and added to this line nunmbers (1-24) and columns (1-80). The upper part, lines 1-12 is all clear; in the lower part I do not understand the values in line 13 and the moving chars (like 'v', ...) which are moving every two seconds (as resultat of DSFLOWRPT) one position from left to right; what they should express exactly? (use a xterm of more the 80 columns to see the file /tmp/xterm.txt correctly) Thanks matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 10203040506070 80 1|.|.|.|.|.|.|.| 1E169 stats (80 x 24) 2 Time online: 1:16:02 3 Mode: HSPA7 / SRVST: 2 09:49 2562 B / 2562 B 4 RSSI: -97 dBm (8) 09:50 2562 B / 2562 B 5 Total: 1568.88 KiB / 5372.76 KiB 09:51 2604 B / 2604 B 6 Now: 500 B / 500 B 09:52 2562 B / 2562 B 7 09:53 2562 B / 2562 B 8 09:54 2604 B / 2604 B 9 09:55 2562 B / 2562 B 10 09:5635.85 KiB / 299.74 KiB 11 09:5771.89 KiB / 718.20 KiB 12 09:58 491.69 KiB / 1462.97 KiB 13 400kB -51dBm v 14v 15 16 17 v 18 19 v v 20v ^ 21 v v v ^ 22 vvv^### 23 v v v ^ v 24 vvv^^v^vv^^^^^vv^^^^vvv 1|.|.|.|.|.|.|.| 10203040506070 80 ___ 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: [PATCH] multiple instances of ipfw(4)
On Mon, Jan 30, 2012 at 01:01:13PM +0100, Ermal Lu?i wrote: > Hello, > > from needs on pfSense a patch for allowing multiple intances of > ipfw(4) in kernel to co-exist was developed. > It can be found here > https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff > > It is used in conjuction with this tool > https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c > It allows creation of contextes/instances and assignment of specific > interfaces to specific contexts/instances. > > Surely i know that this is not the best way to implement generically > but it gets the job done for us as it is, read below. > > What i would like to know is if there is interest to see such > functionality in FreeBSD? > > I am asking first to see if there is some consensus about this as a > feature, needed or not! > If interest is shown i will transform the patch to allow: > - ipfw(8) to manage the contextes create/destroy > - ipfw(8) to manage interface membership. Closing the race of two > parallell clients modifying different contextes. > > There is another design choice to be made about storing the membership > of interfaces into contexts/instances, but i do not see that as > blocking. > > It is quite handy feature, which can be exploited even to scale on SMP > machines by extending it to bind a specific instance(with its > interaces) to a specific CPU/core?! > > Comments/Feedback expected, if i understand what the patch does, i think it makes sense to be able to hook ipfw instances to specific interfaces/sets of interfaces, as it permits the writing of more readable rulesets. Right now the workaround is start the ruleset with skipto rules matching on interface names, and then use some discipline in "reserving" a range of rule numbers to each interface. Before making more changes to the code, it would help if you could give a high level description of 1. what the change does and how specific cases are handled. E.g. With this change you can create multiple rulesets (contexts ?) and bind one or more interfaces to a context. - what happens with outgoing packets where the context to be picked up depend on the route in effect at the time of the transmission ? - what happens with encapsulated interfaces (vlan) ? - can you skipto across contexts (i guess not) ? 2. how intrusive are code changes ? The kernel patch you show seems small, which makes sense as i believe all is needed is to start from a specific chain instead of the default one when an interface is bound to a context. A few comments: - if you use one of the if_ispare directly, instead of renaming it to if_context, this would make backporting and testing easier. - I think the explosion of sockopt names is a bad thing. The IP_FW3 command was introduced exactly to have a single entry point to the firewall and avoid a ton of new names in raw_ip.c and in.h - can you reduce the number of global ipfw-related variables ? There used to be one (layer3_chain), now you have 3 of them. You should delete layer3_chain and replace it with another single global (could be ip_fw_contexts) which contains the whole firewall state. - how do you handle reinjects (e.g. from dummynet or divert) ? I don't remember if the metadata that stores where you reinject the packet also has a pointer to the root of the chain. - i don't completely follow the connection between ip_fw_chain, ip_fw_ctx_iflist, ip_fw_ctxmember, ip_fw_ctx, ip_fw_ctx_list. The way i see it: - the ip_fw_chain could be embedded in the ip_fw_ctx, as they map 1:1 - why do you need ip_fw_ctx_iflist and ip_fw_ctxmember ? You should never need to determine context membership during packet processing, and for sockopt calls you could as well iterate over the list of interfaces; cheers luigi ___ 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: ports/net/e169-stats (was: UMTS Huawei monitor)
On Tue, 31 Jan 2012 11:19:31 +0100 Matthias Apitz wrote: > El día Tuesday, January 31, 2012 a las 11:01:00AM +0100, Milan Obuch > escribió: > > > > I was thinking about a Huawei USB modem monitor and got a pointer > > > to the ports/net/e169-stats (thanks to Milan for this); I have > > > checked it out and it does mostly what I was thinking of; I have > > > a few questions which are not answered in the documentation > > > (because there is no manual or other doc :-)) ... anybody out > > > here who is using this tool and could answer perhaps my question? > > > Thanks in advance > > > > > > matthias > > > > Hi, > > > > just ask here, I think - maybe add ed...@mavetju.org to CC as he > > wrote this and should have definite answers, I think. I use some > > Huawei occasionally with e169-stats to see signal properties. I bet > > there are others out there using it as well, so "someone" (tm) > > should know :) > > Hi, > > I'm attaching a cut&paste of the xterm where e169-stats runs and added > to this line nunmbers (1-24) and columns (1-80). The upper part, lines > 1-12 is all clear; in the lower part I do not understand the values in > line 13 and the moving chars (like 'v', ...) which are moving every > two seconds (as resultat of DSFLOWRPT) one position from left to > right; what they should express exactly? > > (use a xterm of more the 80 columns to see the file /tmp/xterm.txt > correctly) > > Thanks > > matthias Hi, I will test it later to see, but AFAIR this should be running/moving/live graph presentation of signal strength and data transfer (load/speed) done in ASCII, so a bit rough. Not as nice as done in 'properly graphical' way, but usable. If you have steady signal strength, it is not obvious, but when you move a bit, you could see the change. Just guessing now - # is for signal, v is download momentary speed and ^ is for upload. Regards, Milan ___ 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: ports/net/e169-stats (was: UMTS Huawei monitor)
El día Tuesday, January 31, 2012 a las 11:53:48AM +0100, Milan Obuch escribió: > Hi, > > I will test it later to see, but AFAIR this should be > running/moving/live graph presentation of signal strength and data > transfer (load/speed) done in ASCII, so a bit rough. Not as nice as > done in 'properly graphical' way, but usable. If you have steady signal > strength, it is not obvious, but when you move a bit, you could see the > change. Just guessing now - # is for signal, v is download momentary > speed and ^ is for upload. Hi, At the end I decided to understand the source code. Btw: the device port /dev/cuaU0.n is hardcoded set to .2, while mine is .3 for the E1750; the -51 dBm value is just nothing more than the best possible RSSI value 31; the #-line (which is in real a fine line of some ncurses(3) symbol, don't know why cut&paste changed this) is a scaled representation of the RSSI values of the last 80x two seconds; the byte value in line 13 of 400kB is always calculated as the max or RX or TX values of the last 80x two seconds history; and finally 'v' and '^' are used to represent the current RX or TX value in scale with this maximum; I will now watch this movie for a while and see if I can draw some clue from that graphic :-) matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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: msk0: watchdog timeout interface hang
Hi, On Wed, Jan 25, 2012 at 10:20 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Jan 25, 2012 at 3:26 PM, Kim Culhan wrote: >> Running 10-curent from 01-20-12 >> the msk0 interface hung, on the console: >> >> msk0: watchdog timeout >> msk0: prefetch unit stuck? >> msk0: initialization failed: no memory for Rx buffers >> >> Verbose boot dmesg output attached. >> > known issue affecting at least 8-STABLE, 9-STABLE (assumed) and > -current. Already reported in these threads: > > http://lists.freebsd.org/pipermail/freebsd-net/2011-December/030635.html > > http://lists.freebsd.org/pipermail/freebsd-questions/2011-November/235646.html > FWIW, 8-STABLE from yesterday keeps hanging. I'm moving the box to Linux, it became really ridiculous to have such a network driver hang with no more than 3Mbps of traffic (ok, it might be a bit spiky too). - Arnaud > >> Any help is greatly appreciated. >> >> -kim >> >> ___ >> 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" ___ 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"
Difference in address selection between ICMP and TCP
Consider the following: ifconfig em0 inet 1.2.3.4/24 ping 1.2.3.4 Then a tcpdump on lo0 shows: 21:15:56.641571 IP 127.0.0.1 > 1.2.3.4: ICMP echo request, id 36105, seq 10, length 64 21:15:56.641582 IP 1.2.3.4 > 127.0.0.1: ICMP echo reply, id 36105, seq 10, length 64 I think that the address used should have been 1.2.3.4 and not 127.0.0.1. Now when I do a telnet 1.2.3.4 22, I see: 21:17:55.955475 IP 1.2.3.4.38534 > 1.2.3.4.22: Flags [S], seq 904951907, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 1850412 ecr 0], length 0 21:17:55.955487 IP 1.2.3.4.22 > 1.2.3.4.38534: Flags [R.], seq 0, ack 904951908, win 0, length 0 So in this case we actually do use 1.2.3.4! This is on a 8.1 system. A 8.2 system shows the same behaviour and a 7.4 system behaves correctly (i.e.: uses the same address for icmp as for tcp). I tried to investigate the souce code, but my knwoledge about it is a bit rusty :-( -Guido NB: perhaps related: When I do the ping in a vimage on a different VIMAGE-kernel, the ping fails because the source address is never filled in (i.e. is 0.0.0.0) ___ 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: Difference in address selection between ICMP and TCP
On 31.01.2012 21:27, Guido van Rooij wrote: Consider the following: ifconfig em0 inet 1.2.3.4/24 ping 1.2.3.4 Then a tcpdump on lo0 shows: 21:15:56.641571 IP 127.0.0.1> 1.2.3.4: ICMP echo request, id 36105, seq 10, length 64 21:15:56.641582 IP 1.2.3.4> 127.0.0.1: ICMP echo reply, id 36105, seq 10, length 64 I think that the address used should have been 1.2.3.4 and not 127.0.0.1. Now when I do a telnet 1.2.3.4 22, I see: 21:17:55.955475 IP 1.2.3.4.38534> 1.2.3.4.22: Flags [S], seq 904951907, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 1850412 ecr 0], length 0 21:17:55.955487 IP 1.2.3.4.22> 1.2.3.4.38534: Flags [R.], seq 0, ack 904951908, win 0, length 0 So in this case we actually do use 1.2.3.4! This is on a 8.1 system. A 8.2 system shows the same behaviour and a 7.4 system behaves correctly (i.e.: uses the same address for icmp as for tcp). I tried to investigate the souce code, but my knwoledge about it is a bit rusty :-( The way the source address is determined is different between ping-icmp and TCP. For ping-icmp the source address is filled in ip_output() based on the outgoing interface. For all local addresses, including those on real interfaces the loopback interface is used. You can see that by doing a "netstat -ran". -Guido NB: perhaps related: When I do the ping in a vimage on a different VIMAGE-kernel, the ping fails because the source address is never filled in (i.e. is 0.0.0.0) The loopback interface is inaccessible from a jail and thus the source address is never filled in and stays at INADDR_ANY. A fix for either issue is not entirely trivial and fraught with other potential undesired side effects. -- Andre ___ 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"
allowing gif thru ipfw
Seems like a silly question; but how does one allow the packets composing a gif tunnel thru ipfw? I assumed a gif was made up of ipencap (IP proto 4) packets and added rules: $fwcmd add 00140 allow ipencap from $he_tun to me $fwcmd add 00141 allow ipencap from me to $he_tun ($he_tun is an Hurricane Electric provider); but neither of them are hit; so that's wrong... tcpdump -i em_vlan5 -nnvvs0 ip proto 4 doesn't show any packets either... I also have the rule to allow icmp6 thru the gif: $fwcmd add 30132 allow icmp6 from me to any out via gif0 keep-state but that doesn't get hit either. Bottom line: I cannot ping the far end of my ipv6 tunnel. I receive the error "permission denied" ** root@olivia ** ~ ** Tue Jan 31 23:31:43 # ping6 2001:::::1 PING6(56=40+8+8 bytes) 2001:::::2 --> 2001:::::1 ping6: sendmsg: Permission denied ping6: wrote 2001:::::1 16 chars, ret=-1 ping6: sendmsg: Permission denied Am I even correct in assuming that my gif packets are being blocked? Thanks. ___ 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: pf not seeing inbound packets on netgraph interface
On Jan 24, 2012, at 2:57 AM, Andreas Longwitz wrote: > Hi Ed, > >> I am running into a roadblock getting PF to filter traffic on >> a Netgraph interface representing an L2TP/IPSec connection. > >> The problem I have is that PF only sees traffic on the outbound >> side of the netgraph interface. > > This happens because the L2TP packets are tagged with an IPSEC-flag for > later use by ipfw, and this flag is passed to the packets coming from > ng0. Thats done by the netgraph under control of mpd, or better: mpd > does nothing to clear this flag. I was exploring the netgraph sources after sending my original question, and was developing a suspicion that this is what was going on. From my digging, it didn't look like that mpd would be involved enough in the communication channel to be able to clear the flag, even if it wanted to. It would have to be one of the netgraph nodes to do it as the packet passed by, since mpd only gets informed if a control packet hits the l2tp note. Or perhaps I am misunderstanding what you mean, or I am misreading how the data flows around. > > With net.inet.ipsec.filtertunnel=1 you can ignore this IPSEC-flag but > only global for all interfaces in the system. Thats probably not what > you want, especially not for the real hardware interface the > IPSEC-tunnel is going through. It isn't my desired alternative, having already explored that avenue a while back. I could imagine that I would end up with a severely complicated pf ruleset even if I could get things to work. > > I think L2TP under control of mpd should work independent of the > existence of an IPSEC-tunnel and therefore clear this flag: > > --- ng_l2tp.c.orig 2010-04-15 14:40:02.0 +0200 > +++ ng_l2tp.c 2012-01-23 17:09:41.0 +0100 > @@ -752,6 +752,7 @@ >hookpriv_p hpriv = NULL; >hook_p hook = NULL; >struct mbuf *m; > + struct m_tag *mtag; >u_int16_t tid, sid; >u_int16_t hdr; >u_int16_t ns, nr; > @@ -996,6 +997,11 @@ >ERROUT(0); >} > > + /* Delete an existing ipsec tag */ > + mtag = m_tag_find(m, PACKET_TAG_IPSEC_IN_DONE, NULL); > + if (mtag != NULL) > + m_tag_delete(m, mtag); > + >/* Deliver data */ >NG_FWD_NEW_DATA(error, item, hook, m); > > This patch for the l2tp netgraph node does the job and you can use pf on > the ng0 interface without any restrictions. Very cool. Thanks. I will give this patch a spin, and report back with my results. A thought that comes to mind; are there other netgraph modules that would be affected similarly by a packet that comes in with this flag already set? From what I gathered reading the sources, the same mbuf gets used for both the L2TP data packet, and the packet encapsulated within -- it simply trims the header from the mbuf. As such, the mbuf_tags from the L2TP packet propagate across. This seems like this would not be the most obvious behavior, at least in some circumstances. I can see perhaps wanting to propagate things like PF tags from the L2TP packet to the encapsulated packet across from one interface to another, but I can also see not wanting to have that happen. If this same sort of thing happens elsewhere, I wonder if this sort of manipulation wants to happen the moment the packet enters the netgraph system from a ksocket. Perhaps this will break netgraph behavior elsewhere that depends on this? I'm also wondering if making the encapsulated packet even less derivative of the L2TP packet would make unexpected behavior like what I was observing less likely. Again, I'm not familiar enough with all the netgraph modules to know what might depend on this behavior, or if there are historical or functional reasons to keep the behavior as it is. Thanks, Ed Carrel___ 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: allowing gif thru ipfw
01.02.2012 11:36, Eric W. Bates пишет: > Seems like a silly question; but how does one allow the packets > composing a gif tunnel thru ipfw? > > I assumed a gif was made up of ipencap (IP proto 4) packets and added rules: > > $fwcmd add 00140 allow ipencap from $he_tun to me > $fwcmd add 00141 allow ipencap from me to $he_tun > > ($he_tun is an Hurricane Electric provider); but neither of them are > hit; so that's wrong... > > tcpdump -i em_vlan5 -nnvvs0 ip proto 4 > > doesn't show any packets either... Try: tcpdump -i em_vlan5 -nnvvs0 host $he_tun and not tcp and not udp and not icmp Perhaps, you gif is encrypted with ipsec? That changes ip protocol numbers. Eugene Grosbein ___ 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"
