Re: OpenBSD kernel janitors
On 30.10-20:26, Miod Vallat wrote: > [ ... ] That's when you need as much support as possible. And > that's the kind of support I, as an individual, can not provide. i believe the task list itself would be positive , even if not much happens around it. they are good for the community as well as the codebase. you are not commiting yourself to mentoring and tutoring every idiot who wants a crack at the kernel, you're simply saying, "look if you think you're good enough to do the work, here are some things that i know, from my experience, need done". the learning and effort comes from interested parties. this sort of delegation does work in other projects, perhaps if we have a good list we can figure out how to make it work here too. -- t t w
Re: OpenBSD kernel janitors
On 31.10-11:12, Nick Guenther wrote: [ ... ] > > and i would suggest that the severe and prevelant attitude toward the > > possibilty of poor patches or under-educated actions is the most > > significant barrier to encouraging new/young developers. > > Well that's the point of it; or at least, a useful side-effect. > Linux can get away with sending fanboi masses at its code because it's > fine with fanboi masses poking at all parts of the kernel, no matter > how secure it may be. Right? i think we'll simply agree to disagree. i personally find it quite disheartening to hear the attitude that prevails here but that's the community's decision. it certainaly seems to refelect the attitute of it's leaders (developers). -- t t w
Re: OpenBSD kernel janitors
On 31.10-09:49, Theo de Raadt wrote: [ ... ] > I'll say it again more clearly -- all of you whiners just plain suck. > We know you'll never write diffs, and it is up to you to prove us > wrong. If you don't write diffs, we have a difficult time feeling any > loss. a software community is made of more than developers. -- t t w
Re: OpenBSD kernel janitors
On 31.10-15:25, mickey wrote: [ ... ] > > on the counter-side we appear to have people who can code but are > > unable to communicate productively otherwise. > > as opposed to a majority of people who talk and not code anything? > here is a solution for you -- read http://openbsd.org/query-pr.html > and start fixing those. pretty simple solution if you get no bugs > of your own. anyone, who thinks that learning and development need nothing more than web web access to PR database is mistaken. development is a complex process, one that requires a great number of things not least which is an idea of where to start. one can also look to the large numbers of patches that are created but never used (yes this is complicated network of reasons too). why must we railroad ourselves to a decision before the discussion has even happened? it would appear that most do not want the discussion to happen even though they are neither obligated to participate or action the ideas within it. that is strange to me but as i've said, i'm new. -- t t w
Re: OpenBSD kernel janitors
On 31.10-09:25, Theo de Raadt wrote: [ ... ] > Lists have been made before, by a few developers. > > It did not work then, and it won't work now. > > Development is not the same process as writing a whiny mail. that is a shame. i can probably better understand the relectance to re-visit this if it has failed before. perhaps, others are right, perhaps linux can tolerate it because it's not as good as openbsd. as for the whining. i'm not. nor am i asking anyone to do anything they are not happy to do. some communities thrive on communication, feedback and ideas. i'm new to the openbsd community. -- t t w
Re: OpenBSD kernel janitors
On 31.10-10:05, Theo de Raadt wrote: [ ... ] > the problem is not our lists. [ ... ] > but no. they intend to keep whining, and saying it is our fault. where you get the "your fault" from is unfathomable. neither is anyone suggesting that the problem is "our lists", simply that a list of "simpler" tasks _may_ encourage younger/new developers to participate. anyway, this really is taking me away from coding now so i'm going to drop off and let us all get back to something productive. p.s: i started looking at the source code some weeks ago. i'm a good way from having a handle on it -- t t w
Re: OpenBSD kernel janitors
On 31.10-09:53, Theo de Raadt wrote: [ ... ] > There is no community that you speak of. that much is apparent. > There are people who write diffs, and people who _don't_ write diffs. > > In that sub-group of people who don't write diffs, there are a few who > whine loudly and say we are the reason why. Boo hoo. i do write diffs. i have never suggested that you (or any other developer on this list) are a motivating factor in that, positive or negative. the fact that i haven't yet writen an openbsd diffs is a seperate issue. quite what all this has to do with whether the janitor list is productive or not is beyond me. you have stated you don't believe it is, the only reason the discussion continues is around name calling. it is all rather perverse and certainaly not a motivator to contibute. i expect that to be no loss to those here. -- t t w
Re: OpenBSD kernel janitors
On 31.10-16:44, Artur Grabowski wrote: [ ... ] > > surely there must be _some_ merit to creating a list of lower level > > development tasks (as dictated by those with experience to judge) to > > encourage people to enter the development cycle. > > The most amusing thing about this thread is that such a list has been > published for years (it's somewhat short right now, but there's some > simple stuff in it) and is the first search hit when you search on one > of the obvious queries on google. i didn't find it on google (i am a google retard), if you post me the link not only will i offer to maintain it for the developers but will endeavour to link-up with the website team to ensure it is easily found. -- t t w
Re: Printing with apsfilter
On 11.11-18:31, Predrag Punosevac wrote: [ ... ] > Could you give any comments about LPRng please? only that i have never really needed it. the stardand lpr distribution has always been sufficient. i've never tried to deploy complex groups/queuing/policies with lpr except under AIX (which has it's own setup/configuration). -- t t w
Re: Printing with apsfilter
On 12.11-12:58, Girish Venkatachalam wrote: [ ... ] > Thanks. I definitely stand corrected. I definitely meant PDL and not > PCL. My memory failed due to lack of proper understanding. Sorry... often make the same error. :-) [ ... ] > I want to know what happens behind the scenes when you type > > $ lpr foo.ps > > Assuming that foo.ps is the output of a2ps. depends on the scenario. if your printer "supports postscript" then nothing much. the lpd accepts the print job, queues it and eventually routes it on to the correct device (sometimes across another lpr session, sometimes via jetdirect, sometimes parallel port, usb, etc, etc). if it's not a postscript printer (e.g. an old hp laserjet that supports PCL) then the lpr system needs to be configured with a filter. this filter simply takes the input, processes it in some way and passes it back to lpd for queuing. generally this filter is ghostscript which processes the postscript to the correct printer language but we used to write scripts and progs for various conversions (e.g. EBCDIC->ASCII, XES->PCL) too, and there are still some examples out there (probably one or too in the standard distribution if you look under /usr/share somewhere). i haven't used the filter program others mentioned but i would guess that it installs itself as the standard lpd filter and is smart enough to make the correct conversions (probably passing a lot of the work to ghostscript for postscript input, hence the reason it asks for which gs printer driver it should use for each device). [ ... ] > And what is the relation between PS and PDF? > > I hear that even PDF is some form of PDL. As you can see I am quite > lost at this point. :) then you need to do a little more research. :-) PDF is very similar to PostScript but it produces much smaller documents (using JPEG compression and other tricks not normally used in PS as they just cause the printer more work) and so is more suitable for storing and exchanging documents in that format (it also has some extensions relating to the "document" it's describing). i don't know of any printers that support printing PDF documents directly but i'm sure they're out there. -- t t w
Re: [OT] making Firefox respect telnet:// URLs
On 11.11-22:32, ropers wrote:
[ ... ]
> So far, I have created a script .telnet4firefox.sh in my home folder,
> made that executable (chmod u+x), and in Firefox' about:config I have
> added a new boolean network.protocol-handler.external.telnet (set to
> true) and a new string network.protocol-handler.app.telnet (set to
> /home/ropers/.telnet4firefox.sh). The contents of the script are:
>
> #!/bin/sh
> xterm -e "telnet ${1##telnet://}"
>
> When I click a telnet URL that does not specify a port, it works,
> xterm launches with telnet, which duly connects to the port.
[ ... ]
> Currently, if I click on telnet://mud.vhdev.com:1991, telnet is called with
>
> telnet mud.vhdev.com:1991
>
> instead of
>
> telnet mud.vhdev.com 1991
just do a little more work with '/bin/sh'. the other example posted
is fine if all URLs are well formed, otherwise i'd suggest you do a
little more work (i.e. don't trust IFS to work).
#!/bin/sh
### execute telnet in xterm
# grab the url ...
URL=$1
# ... and strip the protocol from the front
URL_noproto=${URL#telnet://}
# remove any trailing bits from URL
URL_addr=${URL_noproto%%/*}
# strip URL_addr to the first ':' to get the host ...
host_taint=${URL_addr%:*}
# ... and strip unexpected stuff
host=${host_taint%%[^A-Za-z.-]*}
# strip URL_addr to the last ':' to get the port ...
port_taint=${URL_addr##*:}
#... and strip unexpected stuff
port=${port_taint%%[^0-9]*}
xterm -e "telnet ${host} ${port}"
you could also do a little more sanity checking if you're paranoid
(sensible?) but you won't gain much except overhead by using awk
as the amount of sanity required checking for URLs and all the
possible encodings is extensive.
the best option is probably to invoke perl or python and use a standard
URL library to parse the argument.
--
t
t
w
Re: [OT] making Firefox respect telnet:// URLs
On 12.11-02:24, Ingo Schwarze wrote: [ ... ] > On a side note, do not use > exec "xmessage $url: parse error"; > or surfing to > telnet://localhost:1234&halt# > might yield surprising results. > > Your sh-kludge cited above is even worse; please DO try surfing to > telnet://localhost:1234&xmessage:bad:guys:got:in > but do NOT try surfing to > telnet://localhost:1234&__rm:-rf:~ ^^ mangled to avoid damaged feet nice examples but don't think they'll work. "$3" (i.e. the port parameter) will not include the command arguments. replacing the with '%5C%20' may work depending on how firefox pre-processes the URLs prior to execution. -- t t w
Re: pf max-src-conn states
On 12.11-19:11, Henning Brauer wrote: [ ... ] > > 1. trying to use 'max-src-conn 1' to limit service to one > > connection per host (with overload table) but when i disconnect and > > re-reconnect i get blocked. should this state expire when > > correctly closed, allowing a second connection, or is the timeout > > needed? > > there is always a 2*MSL timeout - any better book covering TCP/IP > basics should give you the plethora of reasons. thanks. will re-test and check. -- t t w
Re: 4.2 patchset for PR#5563/#5704
joel, thanks for the comments. was looking for help when sent the initial email. On 30.01-02:45, Joel Sing wrote: [ ... ] > 1. Both of these PRs have already been resolved and closed - fix committed in > r1.70 of sys/dev/ic/elink3.c (see > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/elink3.c). Help is > always welcome, however fixing a closed bug is kinda pointless :) never fixed it; just wanted a patch against 4.2 without having to use current. that's what the patchset is for. i also changed current to macros because it seemed wrong/bad. [ ... ] > 2. Patches and technical issues are normally directed to tech@ (assuming it's > a diff for an unresolved issue). You'll probably get more of a response than > on [EMAIL PROTECTED] thanks for the pointer. [ ... ] > 3. Patches are usually provided in a unified diff format (-u option). These > are inherently easier to read, especially when sent via email. thanks again. [ ... ] > 4. Patches should be provided against -current, not -stable. If a diff is > accepted for a serious issue it will be back ported and a patch made > available for -stable. that's what i needed and did. wasn't sure whether there was somewhere to post a patchset against stable so others could use it. is that generally done by others (i.e. unwanted) or posted elsewhere? [ ... ] > 5. If you really want to diff against -stable you can use the -rOPENBSD_4_2 > tag when running cvs. eg: aside from the '-u' that's what i did. thanks again for the pointers, much appreciated. -- t t w
isakmp phase 2 negotiation failed
having a nightmare getting two openbsd (one 3.8, one 4.0) boxes to setup a tunnel. finally got the phase 1 negotiation going (or so i believe from reviewing the logs) but it appears that the phase two starts and is just abandoned. my best guess is that the default definitions for QM-ESP-DES-MD5-SUITE are incompatible but i can't seem to get by it. the "-DA=99" output and configuration files are attached in the hope that someone make sense of this. i also have the "-L" dump if anyone needs it. thanks for any assistance. -- t t w # isakmpd configuration [General] Listen-on= 83.104.36.71 [X509-Certificates] CA-directory= /etc/isakmpd/ca/ Cert-directory= /etc/isakmpd/certs/ Private-key=/etc/isakmpd/private/local.key [Phase 1] #84.203.180.117=gw.vpn.cobbled.net [caley01.vpn.cobbled.net] ID-Type=FQDN Name= caley01.vpn.cobbled.net [gw.vpn.cobbled.net] ID-Type=FQDN Name= gw.vpn.cobbled.net [Phase 2] Connections=cobbled-caley [cobbled_net-gw] Phase= 1 Configuration= low-crypto Address=84.203.180.117 ID= caley01.vpn.cobbled.net Remote-ID= gw.vpn.cobbled.net [cobbled-caley] Phase= 2 ISAKMP-peer=cobbled_net-gw Configuration= low-crypto-quick Local-ID= cobbled_net-caley Remote-ID= cobbled_net-all [cobbled_net-all] ID-Type=IPV4_ADDR_SUBNET Network=10.0.0.0 Netmask=255.0.0.0 [cobbled_net-caley] ID-Type=IPV4_ADDR_SUBNET Network=10.192.0.0 Netmask=255.255.0.0 [min-crypto-quick] DOI=IPSEC EXCHANGE_TYPE= QUICK_MODE Transforms= QM-ESP-DES-MD5-SUITE [low-crypto] DOI=IPSEC EXCHANGE_TYPE= ID_PROT Transforms= 3DES-SHA-RSA_SIG [low-crypto-quick] DOI=IPSEC EXCHANGE_TYPE= QUICK_MODE Transforms= QM-ESP-3DES-SHA-PFS-SUITE [demime 1.01d removed an attachment of type application/x-gunzip]
Re: isakmp phase 2 negotiation failed
On 20.09-19:17, Daniel Ouellet wrote: [ ... ] > Do, as you see fit, but my advise to you, wouldn't be to help trying to > get it up as is now, but first run 4.1, then try the new way of doing > it. I think that would be much better spend of time. thanks for the advice. unfortunately both systems are off-site production machines and cannot be easily upgraded. i will try manually keying the tunnel in the short term. thanks again -- t t w
Re: WG: Re: isakmp phase 2 negotiation failed
On 21.09-16:47, Christoph Leser wrote: [ ... ] > > >[low-crypto-quick] > > >DOI=IPSEC > > >EXCHANGE_TYPE= QUICK_MODE > > >Transforms= QM-ESP-DES-MD5-SUITE [ ... ] > Maybe there is a problem with your isakmpd.conf: [ ... ] > names QM-ESP-DES-MD5-SUITE !! > so maybe it should be > > [low-crypto-quick] > DOI=IPSEC > EXCHANGE_TYPE= QUICK_MODE > Suites= QM-ESP-DES-MD5-SUITE > > i.e. transforms is not a valid parameter in the > IPsec-configuration section you were spot on. i'm a little confused as to how my other tunnels are working and also what the difference between transforms and suites are but i _think_ that transforms are for phase-1 and suites are for phase-2. still not quite sure the deliniator there but thanks again ... working like a charm. -- t t w
Re: OpenBSD firewalls as virtual machine ?
On 23.09-01:35, Luca Corti wrote: [ ... ] > > i have a feeling that the funds currently available for your virtualisation > > project would improve the quality and delivery of these requirements. > > If I had such project and funds I'd certainly contribute. In the > meantime I have assigned part of my limited resources to buying the CDs > for the new release... my apologies, i had you confused with the original poster. -- t t w
Re: Help! I'm having Linux foisted on me! (PF queuing woes)
On 19.10-15:15, Richard Wilson wrote:
[ ... ]
> altq on $ext_if cbq bandwidth 9.1Mb queue { adsl_up, sdsl_up }
> altq on $client_if cbq bandwidth 9.1Mb queue { adsl_dn, sdsl_dn }
>
> queue adsl_up bandwidth 256Kb cbq
> queue adsl_dn bandwidth 2Mb cbq
is there a reason that these have no child queues defined? i don't
see how the implied child queues can borrow without that.
--
t
t
w
Re: UPDATE: mozilla-firefox-3.0
On 17.07-10:13, Marco Peereboom wrote: [ ... ] > I am saying that each java app requires its own java runtime because the > previous/next version is incompatible. Nothing new here. this is wrong. java versions are largely compatible and most requirements are library problems, not runtime compatibility (although i believe distribution rights to core components would often restrict packaging for forward compatibility). -- t t w
Re: UPDATE: mozilla-firefox-3.0
On 17.07-12:13, Jason Dixon wrote: > You don't have to be a dick. [ ... ] eh ... ok. i wasn't trying to be; i was trying to be funny but apparently my linguistic skills are on a par with your own. apologies. > [ ... ] I don't know anything about Java > client-side rendering capabilities, and I expressed as such. I'm not > sure why the phrases "image rendering" or "passing instructions" throw > you off. I'm not a flash or java developer, nor do I pretend to be. > But I know that flash is very effective at pushing image rendinering > resource requirements out to the client, rather than relying on enormous > amounts of server-side CPU power. ... but i was also making the point that if you "don't know anything about Java client-side rendering" and are "not a flash or java developer" perhaps you should refrain from spouting technical jargonese on the subject. i know what you're getting but i don't think it's representative of java or flash. the primary reason for flash performing better is that it has better development tools (and a more mature/focused API) for these things. everything you'd need is also available in java. as i said, java is a language, flash is a solution. one could build the same solutions in java, should they choose to engage that, and make them just as performant (qualified, of course, by the platform requirements); it would just take a lot more work. [ ... ] > If you dismiss my comments as fancy, you simply have no experience in > this arena. No reason to be hostile about it. apologies again, it was meant as a lighthearted jibe. p.s: i have some experience in both platforms but would not claim to be an expert in either p.p.s: i expect the server side demands you are experiencing are from a jvm on the server not the actual application demands that you are correlating them to (although i do understand the overlap) -- t t w
Re: UPDATE: mozilla-firefox-3.0
On 17.07-14:16, Jason Dixon wrote: [ ... ] > > ... but i was also making the point that if you "don't know anything > > about Java client-side rendering" and are "not a flash or java developer" > > perhaps you should refrain from spouting technical jargonese on the > > subject. i know what you're getting but i don't think it's representative > > of java or flash. > > I don't have to be a Java or Flash developer to engineer scalable > web architectures (which is what I do). My original statement was that > there _is_ a valid purpose for flash, particularly in client-side > graphics generation. I've seen the good and bad of graphics generation, > particularly with stubborn clients who insist on bad technology (GD, > ImageMagick) for server-side rendering. This is where I'm coming from, > hopefully you understand better the point I was making. Nowhere was I > claiming that Java would be a bad tool (yes, I know it's a language) > because I simply don't know what classes are available for it for > performing client-side rendering. > > I *will* go out on a limb and suggest that it's highly unlikely there > are any native classes for Java that optimize client-side graphics > rendering like Flash. Prove me wrong, perhaps I can recommend it in a > future project. ;) jogl? but that is actually for client side rendering and not the image manipulation that you appear to be talking about. there are plenty of functions in the core java library that could also do the image manipulaton. as i am sure you are well aware the trade-off between transmitting the full image data to the client for manipulation or transmitting a thumbnail and performing manipulations server-side are application specific, not client specific. of course, we are now almost completely lost because we have mixed the client side (which was the initial discussion) with the server side and integration issues of the two. suffice to say, there is no real reason that a flash client couldn't be implemented in java. [ ... ] > > p.p.s: i expect the server side demands you are experiencing are from > > a jvm on the server not the actual application demands that you are > > correlating them to (although i do understand the overlap) > > This has nothing to do with Java or JVMs. Graphics rendering always > requires high amounts of CPU, regardless of the > language/solution/platform. ... and now i'm even more confused as this appears to contradict your previous assertion that flash was more performant. my point was that flash is compiled code and thus does these things faster than inside a jvm. i don't believe your server performance issues relate, in anyway, to the client side software. unless, of course, your point was that flash makes it easier to move the image processing (NOT rendering) off to the client. having implemented this a couple of times in java client i'd have to personally disagree whilst appreciating that common opinion may vary (i.e. flash has more focused development kit for this stuff). -- t t w
Re: UPDATE: mozilla-firefox-3.0
On 17.07-13:21, Marco Peereboom wrote: > On Thu, Jul 17, 2008 at 06:07:05PM +0000, n0g0013 wrote: > > On 17.07-10:13, Marco Peereboom wrote: > > [ ... ] > > > I am saying that each java app requires its own java runtime because the > > > previous/next version is incompatible. Nothing new here. > > > > this is wrong. java versions are largely compatible and most requirements > > are library problems, not runtime compatibility (although i believe > > distribution rights to core components would often restrict packaging > > for forward compatibility). > > I love your optimism. Integration efforts I worked on for a large > company always required to drop 1 run time environment per app. I > promise we tried really really hard to make that one. This meant that > when a loaded box went out the door there were as many as 8 java > runtimes installed on your box. > > Spare me the "but my app is totally 1337 and doesn't need that"; it > simply doesn't apply to many scenarios. you are the first person in a long time to accuse me of optimism, i suppose i should thank you for that, but the statement was made from experience. whatever your personal experiences i still maintain that your orginal statement was wrong, or at the very least, an extremely harsh assessment. -- t t w
Re: UPDATE: mozilla-firefox-3.0
On 17.07-19:33, Edd Barrett wrote: [ ... ] > If you get java awt rendering animations half as decently as the > official flash plugin, I would be suprised! i apologise if i'm becoming overly terse but it's becoming clear that any attempt at discourse here deteriorates, at best, to pissing contest and i'm finding it difficult to dissern between that behaviour and genuine enquiry. the short answer is, it is perfectly possible. -- t t w
Re: UPDATE: mozilla-firefox-3.0
On 17.07-15:35, Nick Guenther wrote: > On Thu, Jul 17, 2008 at 2:33 PM, Edd Barrett <[EMAIL PROTECTED]> wrote: > > > > If you get java awt rendering animations half as decently as the > > official flash plugin, I would be suprised! [ ... ] > Flash is definitely faster. [ ... ] i agree with the "faster" point but the key issue with java is not getting it to render stuff well, it is with the amount of effort required to actually develop the application. flash has cool tools for animating 2D objects, and performing interactions with them; java requires you to write a shit load of code for the same effect. i'm sure SUN was/is hoping that someone will develop a java based animation toolkit to compete with flash but that's yet to happen. in short, flash is a good tool. we'll all look forward to the day that the formats, behaviours and protocols are opened so that we can implement a native, opensource viewer. -- t t w
nat-t dropping response packets
not sure where to start debugging this VPN problem. i have an ipsec,
nat-t tunnel between a development network and the main services hub
using isakmpd. the exchange seems to go smoothly and the tunnel gets
established.
hub(public_ip) --> {inet} <-- ext-gw(nat-ip) <-- dev-gw(private_ip)
however no traffic gets through from the hub. this is a sample dump
of a ping from the VPN hub to the development gateway.
12:02:24.890060 (authentic,confidential): SPI 0x088b62c7:
10.12.228.17 > 10.12.170.9: icmp: echo request (encap)
12:02:24.891659 193.200.155.117.4500 >
193.200.155.18.46289:udpencap: esp 193.200.155.117 >
193.200.155.18
spi 0x088B62C7 seq 2 len 116
12:02:24.892778 193.200.155.18.46289 >
193.200.155.117.4500:udpencap: esp 193.200.155.18 >
193.200.155.117
spi 0xE99A3368 seq 27 len 116
as you can see, the echo request passes out the 'enc0' and down the
tunnel to the remote end, where it is apparently decoded and a ping
response is sent back. this response hits the external interface
and disappears.
i have no clue where to start tracking this down from here. can i
somehow track this lost packet beyond the external inferace? or
must i manually decode the packet at this stage and try to uncover
the issue from there? also, if the packet was malformed or
erroneous could i expect an error log of some description?
any pointers would be appreciated.
nb: disabling 'pf' has no effect
--
t
t
w
Re: nat-t dropping response packets
On 01.09-21:00, Stijn wrote:
> n0g0013 wrote:
> >not sure where to start debugging this VPN problem. i have an ipsec,
> >nat-t tunnel between a development network and the main services hub
> >using isakmpd. the exchange seems to go smoothly and the tunnel gets
> >established.
> >
> > hub(public_ip) --> {inet} <-- ext-gw(nat-ip) <-- dev-gw(private_ip)
> >
> >however no traffic gets through from the hub. this is a sample dump
> >of a ping from the VPN hub to the development gateway.
> >
> > 12:02:24.890060 (authentic,confidential): SPI 0x088b62c7:
> > 10.12.228.17 > 10.12.170.9: icmp: echo request
> > (encap)
> > 12:02:24.891659 193.200.155.117.4500 >
> > 193.200.155.18.46289:udpencap: esp 193.200.155.117 >
> > 193.200.155.18
> > spi 0x088B62C7 seq 2 len 116
> > 12:02:24.892778 193.200.155.18.46289 >
> > 193.200.155.117.4500:udpencap: esp 193.200.155.18 >
> > 193.200.155.117
> > spi 0xE99A3368 seq 27 len 116
> >
> >as you can see, the echo request passes out the 'enc0' and down the
> >tunnel to the remote end, where it is apparently decoded and a ping
> >response is sent back. this response hits the external interface
> >and disappears.
> >
> >i have no clue where to start tracking this down from here. can i
> >somehow track this lost packet beyond the external inferace? or
> >must i manually decode the packet at this stage and try to uncover
> >the issue from there? also, if the packet was malformed or
> >erroneous could i expect an error log of some description?
> >
> >any pointers would be appreciated.
> >
> >nb: disabling 'pf' has no effect
> >
> does the reply packets know the way back? i.e. is there a route defined
> to route the traffic back into the tunnel? Do you see esp traffic
> returning to the development gw?
the dumps are on the hub using both 'enc0' and the external interface.
you can see the echo request go out on 'enc0' (the first line) and
the udpencap pass out the external interface toward the dev-gw. the
final packet above is the returning echo-reply from the dev-gw. it
does not not re-appear anywhere at the hub. you may note that the
ping is sent from the gw and thus i would expect the ping response to
arrive. it doesn't.
in short, yes the dev-gw knows the route back and appears to use it
correctly. it's possible that the returning packet is not an icmp
echo-reply, of course ... although i'm pretty sure i checked that on
the remote side ... i'll double check it.
--
t
t
w
