Router alert option
Hi Could anyone tell me if Router Alert option processing is implemented in FreeBSD 4.1 ip(v4) stack? Are there any patches available for this? I could find only the option addition part while browsing through the sources. I couldn't find the receiving part of this. Thanks in advance. regards Madhavi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Router alert option
Ping Pan has implemented a complete IP options package for FreeBSD versions up to 4.0. Maybe it's easy to port it to newer versions. See http://www.cs.columbia.edu/~pingpan/software_list.htm Martin > Could anyone tell me if Router Alert option processing is implemented in > FreeBSD 4.1 ip(v4) stack? Are there any patches available for this? I > could find only the option addition part while browsing through the > sources. I couldn't find the receiving part of this. > > Thanks in advance. > > regards > Madhavi. > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
pcap_open_live() takes 1 sec to complete?
Hi, I am writing a small program that does a pcap_open_live() on the Aironet an device, PCMCIA mode. System is a recent -stable on a Toshiba Portege 7200 laptop. Now, pcap_open_live() takes more than 1 sec to return. Is this long time expected? thanks marco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Router alert option
Hi I have seen Mr.Ping Pan's implementation of this. This seems to be just for receiving a packet with some IP option through a raw IP socket. This doesn't seem to be containing the kernel processing part of a packet with router alert option. In netinet6 I have seen that the ip6_input() function sets ours = 1; when it gets a packet with router alert option. Is something similar done in case of IPv4 too? If that's the case, I couldn't figure it out in this patch. Or is it already there in the standard kernel itself? Could some one tell me how a packet with router alert option is handled in ip_input(), or give me some pointers to some description of this processing? thanks & regards Madhavi. On Thu, 6 Dec 2001, Martin Karsten wrote: > Ping Pan has implemented a complete IP options package for FreeBSD versions > up to 4.0. Maybe it's easy to port it to newer versions. See > http://www.cs.columbia.edu/~pingpan/software_list.htm > > Martin > > > Could anyone tell me if Router Alert option processing is implemented in > > FreeBSD 4.1 ip(v4) stack? Are there any patches available for this? I > > could find only the option addition part while browsing through the > > sources. I couldn't find the receiving part of this. > > > > Thanks in advance. > > > > regards > > Madhavi. > > > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-net" in the body of the message > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
IPSEC and IPNAT (was: Re: IPSec)
On Thu, Dec 06, 2001 at 10:22:05PM +0500, Dingo wrote: > ipfilters ipnat We ran into the IPSec intercept problem with 4.3, > can you tell me when the changes were MFCd ? it might just be a matter > of updateing Ipfilter on this specific server. its a 4.3 RELEASE box. > But If I am correct, your telling me i can create a standard VPN, in > tunnel or transport mode, with ipfs ipnat, no gif devices ?? like > > 10.0.xxx.xxx -> ipnat -> 4.23.122.100 -> IPSEC TUNNEL <- 4.22.121.101 <- > ipnat <- 10.20.xxx.xxx > [What's missing in this picture is how ipnat modifies the 10.0 -> 10.20 packets. I will assume it hides the 10.0.xxx.xxx addresses after a single 4.23.122.100.] I'm not fluent in IPFilter (and IPNAT in particular), but I think there may be some difference between how IPNAT and IPDIVERT work. With IPDIVERT, a packet is first passed to a userland process, natd(8) in a similar scenario, and natd(8) writes the modified packet back to kernel which then passes this new packet back to ip_output(). ip_output() is organized so that IPSEC hooks are called before IPDIVERT and IPNAT hooks, but with IPDIVERT it's no problem, since the new packet is passed again to ip_output(), and if you tell your IPSEC to tunnel between 4.23.122.100 and 4.22.121.101, IPSEC will intercept that NATed packet. If IPNAT doesn't do the same, i.e., if it doesn't consider the NATed packet a "new" packet, and just continues with the modified packet, we have a trouble -- we have no way to IPSEC modified packet. Let IPFilter gurus speak up. :-) > On Thu, 2001-12-06 at 11:10, Ruslan Ermilov wrote: > > On Thu, Dec 06, 2001 at 10:02:38PM +0500, Dingo wrote: > > > can you enlighten me a bit, GIF devices are the only way I know how to > > > do tunnel mode IPSec along with NAT > > > > > What kind of NAT? What would you like to NAT: payload or armour? > > ipnat(1) or natd(8)? How, in your opinion, gif(4) devices help > > NAT? > > > > We're runnign an (over Inet) distributed VPN using IPSEC without > > any gif(s), and with NAT (using natd(8)). > > > > ISTR some problems in the past, where IPSEC intercepted packets > > (in ip_output()) before they were passed to "ipfw" and/or "ipf", > > but the order was fixed a later day. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: pcap_open_live() takes 1 sec to complete?
Marco Molteni writes: | I am writing a small program that does a pcap_open_live() on the | Aironet an device, PCMCIA mode. System is a recent -stable on a | Toshiba Portege 7200 laptop. | | Now, pcap_open_live() takes more than 1 sec to return. Is this long | time expected? Hmm, don't seem to recall that. My system is busy doing a make world and stuff. I just tried it and on my busy machine it was less then a second. Note I was not in RFMON mode. It might take longer when I have to switch into RFMON mode. I can try that later. You might try to compare it without RFMON if you are using RFMON. FYI, I put a sample BPF packet dumper up at: http://www.ambrisko.com/doug/an/dump_packet/ I used it to debug the 802.11 packet problem and to look at the raw Aironet Header packets. You'll see it has some test code to check gap length. This is on -stable with my 802.11 aligment fix. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: pcap_open_live() takes 1 sec to complete?
As I recall, delays like that come from the power-saving mode on the card. Turn power-saving off to make them go away. On Thu, Dec 06, 2001 at 10:23:52AM -0800, Doug Ambrisko wrote: > Marco Molteni writes: > | I am writing a small program that does a pcap_open_live() on the > | Aironet an device, PCMCIA mode. System is a recent -stable on a > | Toshiba Portege 7200 laptop. > | > | Now, pcap_open_live() takes more than 1 sec to return. Is this long > | time expected? > > Hmm, don't seem to recall that. My system is busy doing a make world > and stuff. I just tried it and on my busy machine it was less then > a second. Note I was not in RFMON mode. It might take longer when > I have to switch into RFMON mode. I can try that later. You might > try to compare it without RFMON if you are using RFMON. > > FYI, I put a sample BPF packet dumper up at: > http://www.ambrisko.com/doug/an/dump_packet/ > I used it to debug the 802.11 packet problem and to look at the raw > Aironet Header packets. > > You'll see it has some test code to check gap length. > > This is on -stable with my 802.11 aligment fix. > > Doug A. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message -- Barney Wolff "Nonetheless, ease and peace had left this people still curiously tough. They were, if it came to it, difficult to daunt or to kill; and they were, perhaps, so unwearyingly fond of good things not least because they could, when put to it, do without them, and could survive rough handling by grief, foe, or weather in a way that astonished those who did not know them well and looked no further than their bellies and their well-fed faces." J.R.R.T. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: netgraph bridge works on fxp0, fails on wi0
On Thu, Dec 06, 2001 at 08:40:18AM -0500, David Gilbert wrote: > It would seem that it only takes one manufacturer to break this > cycle. There was also more incentive to do this when access points > were $1000 instead of $149. Yes, but for all practical purposes there are only two manufactures which happen to have an highly incestious relationship because there are really only two chipsets on the market. > Didn't older access points simply consist of a router with a pccard > slot? Would they be using custome firmware uploaded to the card? That's how a lot of them work. They do use custom firmware. > Has someone been hacking on this? People are working on it, at least under Linux. This won't solve the vmware problems though because AP firmware doesn't look much like adaptor firmware. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg04348/pgp0.pgp Description: PGP signature
Re: IPSEC and IPNAT (was: Re: IPSec)
On Thu, Dec 06, 2001 at 07:29:27PM +0200, Ruslan Ermilov wrote: > On Thu, Dec 06, 2001 at 10:22:05PM +0500, Dingo wrote: > > ipfilters ipnat We ran into the IPSec intercept problem with 4.3, > > can you tell me when the changes were MFCd ? it might just be a matter > > of updateing Ipfilter on this specific server. its a 4.3 RELEASE box. > > But If I am correct, your telling me i can create a standard VPN, in > > tunnel or transport mode, with ipfs ipnat, no gif devices ?? like > > > > 10.0.xxx.xxx -> ipnat -> 4.23.122.100 -> IPSEC TUNNEL <- 4.22.121.101 <- > > ipnat <- 10.20.xxx.xxx > > > [What's missing in this picture is how ipnat modifies the 10.0 -> > 10.20 packets. I will assume it hides the 10.0.xxx.xxx addresses > after a single 4.23.122.100.] > > I'm not fluent in IPFilter (and IPNAT in particular), but I think > there may be some difference between how IPNAT and IPDIVERT work. > With IPDIVERT, a packet is first passed to a userland process, > natd(8) in a similar scenario, and natd(8) writes the modified > packet back to kernel which then passes this new packet back to > ip_output(). ip_output() is organized so that IPSEC hooks are > called before IPDIVERT and IPNAT hooks, but with IPDIVERT it's > no problem, since the new packet is passed again to ip_output(), > and if you tell your IPSEC to tunnel between 4.23.122.100 and > 4.22.121.101, IPSEC will intercept that NATed packet. > > If IPNAT doesn't do the same, i.e., if it doesn't consider the > NATed packet a "new" packet, and just continues with the modified > packet, we have a trouble -- we have no way to IPSEC modified > packet. Let IPFilter gurus speak up. :-) When you NAT, outgoing packets on the 4.23.122.100 interface get their source address modified if you have a rule like: map 10.0.0.0/16 -> 4.23.122.100 This happens at the end of ip_output after ipsec processing. Return packets will have their destination address changed at the moment thye come in, before ip_input (and ipsec) processing. The packets are already encrypted by then, so no NAT will take place. On the other hand: NAT seems unnecessary since packets are in a tunnel anyway, so the 10 addresses will never show up. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: NOARP - gateway must answer and have frozen ARP table
Garrett and I discussed what IFF_NOARP should mean about 4-5 years ago; we decided that it probably menat "no ARP". We discussed the idea of seperating it out into two flags; "Don't reply to ARP" and "don't pay attention to ARP" but decided to wait and see what people thought. 4-5 years is probably enough time to wait =) My proposal: keep IFF_NOARP, but add IFF_NOSENDARP and IFF_NOREPLYARP (or something, I'm no good at making up names). I agree with Louie that it makes sense for these to be per-interface as opposed to Ruslan's sysctl. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: HEADS-UP: net polling code now in STABLE.
yes,
you are right
regards,
misho
- Original Message -
From: "Luigi Rizzo" <[EMAIL PROTECTED]>
To: "misho" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, December 06, 2001 5:00 AM
Subject: Re: HEADS-UP: net polling code now in STABLE.
> On Thu, Dec 06, 2001 at 04:50:46AM +0200, misho wrote:
> > Hi Luigi,
> >
> > I found this bug several days ago, but I don;t have free time to send
you
> > simple patch.
> > In my opinion it;s better to disable interrupts in xxx_intr() code when
> > device is in polling mode.
> > Something like this:
>
> I have committed a proper fix yesterday.
>
> The code you propose is a safety belt to mask bugs, but *_intr()
> could still be called because other devices are sharing the interrupt
> line (this is actually very common when you have many interfaces).
>
> As a matter of fact, calling *_stop() or writing to I/O registers
> when you get some unwanted interrupts is a bad thing because the
> operations involved can be very time consuming.
>
> cheers
> luigi
>
> > /*
> > * Process interface interrupts.
> > */
> > static void
> > fxp_intr(void *xsc)
> > {
> > struct fxp_softc *sc = xsc;
> > u_int8_t statack;
> >
> > #ifdef DEVICE_POLLING
> > struct ifnet *ifp = &sc->sc_if;
> >
> > if (ifp->if_ipending & IFF_POLLING) {
> > /* this shouldn't happen, we are in polling mode
> >* disable interrupts
> >*/
> > CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL, FXP_SCB_INTR_DISABLE);
> > return;
> > }
> > if (ether_poll_register(fxp_poll, ifp)) {
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
nge: status no carrier
I'm trying to get this Netgear 662T Gigabit card to work in my file server. As soon as the interface is flagged "UP" with "ifconfig nge0 up" or "ifconfig nge0 inet x.x.x.x netmask x.x.x.x", the carrier is lost and the media type (set to auto) changes from "1000baseTX " to "". Manually forcing the media type and mediaopt doesn't return the status of the interface to "active". I've updated to the latest stable kernel. Still, same behavior. Help, please. -- David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
log_in_vain
For the fun of it, I turned on log_in_vain. And I'm seeing *lots* of stuff one might expect (port scans, Nimda poking at my mail server, SMTP to the web server, etc). But I'm also seeing stuff I don't expect, primarily in the areas of DNS and localhost traffic. For example: Dec 6 08:15:39 schplict /kernel: Connection attempt to UDP 216.126.86.8:1262 from 216.126.86.2:53 and Dec 6 08:35:37 haggis /kernel: Connection attempt to UDP 216.126.86.9:1044 from 216.126.86.2:53 and Dec 6 08:34:44 haggis /kernel: Connection attempt to UDP 127.0.0.1:512 from 127.0.0.1:1054 Dec 6 08:34:44 haggis /kernel: Connection attempt to UDP 127.0.0.1:512 from 127.0.0.1:1058 Dec 6 08:34:44 haggis /kernel: Connection attempt to UDP 127.0.0.1:512 from 127.0.0.1:1063 Dec 6 08:34:45 haggis /kernel: Connection attempt to UDP 127.0.0.1:512 from 127.0.0.1:1067 The host at 216.126.86.2 is the first nameserver in the resolv.conf of the both haggis and schplict. It looks to me as if the name server is sending responses back to DNS queries which for some reason haven't waited around. And as far as I know I'm not running biff on haggis. The frequency of the hits makes it look as if it's running something every time ... something ... gets launched. But biff's not in any .profile, .cshrc or .login. So I'm left scratching my head. Can anybody shed some light on this? -- Paul Chvostek <[EMAIL PROTECTED]> Operations / Development / Abuse / Whatever vox: +1 416 598- IT Canadahttp://www.it.ca/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
NAT and ALG
Hi All, How does the NAT in the ip_nat.c take care of FTP port and PASV commands? Regards kshitij
Re: NOARP - gateway must answer and have frozen ARP table
On Thu, Dec 06, 2001 at 12:59:39PM -0800, Bill Fenner wrote: > > Garrett and I discussed what IFF_NOARP should mean about 4-5 years > ago; we decided that it probably menat "no ARP". We discussed > the idea of seperating it out into two flags; "Don't reply to ARP" > and "don't pay attention to ARP" but decided to wait and see what > people thought. 4-5 years is probably enough time to wait =) > > My proposal: keep IFF_NOARP, but add IFF_NOSENDARP and IFF_NOREPLYARP > (or something, I'm no good at making up names). I agree with Louie > that it makes sense for these to be per-interface as opposed to > Ruslan's sysctl. If this is really want to do, I believe you can do it with existing tools. For simplicity, I'm just going to illustrate a way to set it up rather than explain it. Store your IP-MAC address pairs in flat file as proscribed in arp(8), 192.168.10.201:02:03:10:11:12 192.168.10.401:02:03:21:22:23 ... Load your permanent ARP table with a simple, arp -f arp_list.txt In the startup and include, while read $IP $MAC; do ipfw add pass ip from $IP to any via if0 ipfw add pass ip from any to $IP via if0 done < arp_list.txt ipfw add deny ip from any to any via if0 In your rc.firewall. Now you have a static ARP table and all traffic not from those IP addresses is blocked. Since we never ARP for any other addresses, the packets are blocked before we ARP for them, we never get other entries in the ARP table. At least I think this should do what you want. I still am not quite sure what a "one-way ARP" is supposed to gain. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
