Sebastien Roy wrote: > On Mon, 2009-08-03 at 21:51 -0400, James Carlson wrote: >> That might do it. Or all links could have addresses with some of them >> just reporting a zero-length address. > > Hmm, tunnels are weird in that they don't have a zero-length address. > They have addresses, but they're not printed in Ethernet-like fashion, > and for some reason, someone decided to print them in a different spot > in the ifconfig output than the Ethernet address is printed on Ethernet > interfaces (before the IP interface addresses instead of after). In > addition to that, some tunnels have two addresses rather than one.
Actually, other point-to-point media have the same issue. It's not uncommon to have both a local address and a remote one. But I get the point about having to handle the odd legacy output format. > I'm not exactly sure I have a handle on how a solution would look any > better than a simple "is this a tunnel" check given these constraints. OK. >>>> snoop_ether.c: >>>> >>>> 1704: what happens with IPsec or labeling? >>> There are no IPsec headers here. Promiscuous streams get their packets >>> from GLDv3. On receive, IPsec processing occurs before packets are >>> passed up to GLDv3. On transmit IPsec processing occurs after packets >>> have been send down by GLDv3. >> That's might be true with some tunnel-mode IPsec configurations, but I'm >> not so sure it's generally true. I'd expect that you can have >> essentially arbitrary IPv6 headers between the outer and inner tunnel >> headers. >> >> (Unless the kernel is doing something here to rewrite these headers to >> remove things the user "shouldn't" see ...) > > IPsec headers are removed by the IPsec processing code before iptun ever > gets it paws on the packets. That's true for all protocols above ip, > not just iptun. > > I suppose something could have added other extension headers, and snoop > could handle those so that the user-land filter has the correct offsets. That's what I was asking about. It seemed odd to just "assume" that a certain sequence of headers was always present. > Someone please tie a cinder block to snoop and throw it in the Charles. > Oh, did I say that out loud? ;-) Still waitin' on wireshark. :-< >>>> dladm.xcl: >>>> >>>> Check that your getopt strings aren't showing up in the text for >>>> translation. (The additions here seem sparse.) >>> ACCEPT: The architecture around this facility looks way out of hand and >>> unmaintainable. Shouldn't it be implied that if it's not wrapped around >>> in a gettext(), then it doesn't need translating? >> You and meem can have a replay of the same argument I had with him. I >> agree with you, and if it were my code, I wouldn't use this ".xcl" >> thing, but meem finds the gettext() wrappers everywhere to be more >> offensive for some reason, so that's why a lot of this code needs to be >> maintained this way. > > I've added the strings. I'm almost certain that many projects and bug > fixes have already resulted in this file being out of date already. > Perhaps it will prove to be useless over time and the argument can make > itself. I did the same sorts of fixes in RBridges. Yes, many bug fixes and other small changes (and some not-so-small, such as Crossbow) have caused this file to drift out of date. It's obscure, and unless you pay close attention to translation issues and actually examine the .po files (as the other test methods are awful), you'll never even notice the creeping crud. As I said, it's something to argue about with meem. He's the advocate. >> Does this mean that '.' is intentionally allowed for non-tunnel vanity >> names? So I can use "foo.bar.baz0" if I want, and it doesn't imply >> driver foo with modules bar and baz? Is this something that will be >> documented? > > Yes, it's in the design document which is part of the PSARC materials, > and the NOTES section of the dlpi(7P) man page will be updated. OK; cool. >>>> minorperm: >>>> >>>> There's a new iptun.conf but no minorperm entry for iptun. >>> ACCEPT: Curiously, the lack of a minor_perm entry for iptun has not >>> prevented /dev/net nodes from having the correct 666 permissions. >> There's a lot in that area that's mysterious to me. > > I'll talk to Cathy to get to the bottom of how this was working before. Other good people to talk with are Darren Moffat and Gary Winiger. This is related to device allocation. -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ networking-discuss mailing list [email protected]
