Re: IPV6 Checksum offload and TSO6
Looked to me like Michael already has the SCTP stuff in the inet6 code. Not sure if it needs further enabling or what?? I'm not positive about what cards are in the netperf cluster. Any card that em, igb, and ixgbe supports can do the TCP/UDP checksum offloads whether in IPv4 or 6 if handed to it. TSO is a TCP segmentation so it also is a matter of IPv6 allowing it to do so, at least that is my present understanding. SCTP offload can only be handled in the igb and ixgbe drivers, none of the em hardware can do it (at least not as of today). Personally its TSO that I care most about, but the protocol checksums might as well be available too. Jack On Wed, Oct 20, 2010 at 3:20 PM, Bjoern A. Zeeb wrote: > On Wed, 20 Oct 2010, Jack Vogel wrote: > > Hi, > > > I had occasion to think about this, and I was wondering if someone is >> working to add >> either or both of these features, Intel's hardware supports it, it does >> not >> seem that >> hard to add, or am I missing something? >> > > Strange that I had been thinking of that last night and talking to > poeple today. It's kind of on the roadmap here for mid-November. > > It's mostly freebsd infrastructure that's missing for it (along with > some cleanup on the flags in a couple of places). tuexen@ wanted to > get the CSUM_* stuff done for SCTP as well but I haven't re-pinged > him on that one yet. > > Do you know if we have Intel cards in the netperf cluster that can > actually do it for testing? What's the matrix for the various cards > for v6 offloads? >TCP/UDP/SCTP? >IP? >TSO? >TOE? > > Imho noone does TOE6 yet (correct me if wrong) but I'd like to get > the others all sorted then. > > /bz > > -- > Bjoern A. Zeeb Welcome a new stage of life. > Going to jail sucks -- All my daemons like it! > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html > ___ 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: IPV6 Checksum offload and TSO6
On Wed, 20 Oct 2010, Jack Vogel wrote: Hi, I had occasion to think about this, and I was wondering if someone is working to add either or both of these features, Intel's hardware supports it, it does not seem that hard to add, or am I missing something? Strange that I had been thinking of that last night and talking to poeple today. It's kind of on the roadmap here for mid-November. It's mostly freebsd infrastructure that's missing for it (along with some cleanup on the flags in a couple of places). tuexen@ wanted to get the CSUM_* stuff done for SCTP as well but I haven't re-pinged him on that one yet. Do you know if we have Intel cards in the netperf cluster that can actually do it for testing? What's the matrix for the various cards for v6 offloads? TCP/UDP/SCTP? IP? TSO? TOE? Imho noone does TOE6 yet (correct me if wrong) but I'd like to get the others all sorted then. /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ 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"
IPV6 Checksum offload and TSO6
I had occasion to think about this, and I was wondering if someone is working to add either or both of these features, Intel's hardware supports it, it does not seem that hard to add, or am I missing something? Cheers, Jack ___ 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: ndis: patch for review
On 10/20/10, Bernhard Schmidt wrote:
> 9, 2010 at 23:53, Paul B Mahol wrote:
>> Hi,
>>
>> First: we should pin curthread on CPU before we check on which CPU is
>> curthread.
>>
>> Second: instead of sti & cli use critical sections when saving %fs
>> register.
>>
>> Third: I do not know what happens if we get preempted while windows
>> code were running,
>> so leave critical section only _after_ executing windows code.
>
>
> Do you have a test case for that? If so, can you post it?
Unfortunately I do not have test case for third problem.
But not using sched_pin or/and critical sections correctly cause
NTOS: timer %p fired even though it was canceled
in my environment - causing watchdog on ndisX.
And attempt to unload miniport driver after that will cause panic
because something got corrupted.
Theoretically when executing windows code there is small chance for
our thread to be preempted and than it will actually cause %fs corruption
on CPU we were running, and reading comments it appears FreeBSD use %fs
for PCPU.
>
>> diff --git a/sys/compat/ndis/kern_windrv.c b/sys/compat/ndis/kern_windrv.c
>> index f231863..ba29fd2 100644
>> --- a/sys/compat/ndis/kern_windrv.c
>> +++ b/sys/compat/ndis/kern_windrv.c
>> @@ -613,8 +613,6 @@ struct gdt {
>> extern uint16_tx86_getfs(void);
>> extern void x86_setfs(uint16_t);
>> extern void *x86_gettid(void);
>> -extern void x86_critical_enter(void);
>> -extern void x86_critical_exit(void);
>> extern void x86_getldt(struct gdt *, uint16_t *);
>> extern void x86_setldt(struct gdt *, uint16_t);
>>
>> @@ -668,8 +666,10 @@ extern void x86_setldt(struct gdt *, uint16_t);
>> void
>> ctxsw_utow(void)
>> {
>> - struct tid *t;
>> + struct tid *t;
>>
>> + sched_pin();
>> + critical_enter();
>>t = &my_tids[curthread->td_oncpu];
>>
>>/*
>> @@ -685,12 +685,9 @@ ctxsw_utow(void)
>>if (t->tid_self != t)
>>x86_newldt(NULL);
>>
>> - x86_critical_enter();
>>t->tid_oldfs = x86_getfs();
>>t->tid_cpu = curthread->td_oncpu;
>> - sched_pin();
>>x86_setfs(SEL_TO_FS(t->tid_selector));
>> - x86_critical_exit();
>>
>>/* Now entering Windows land, population: you. */
>> }
>> @@ -706,11 +703,10 @@ ctxsw_wtou(void)
>> {
>>struct tid *t;
>>
>> - x86_critical_enter();
>>t = x86_gettid();
>>x86_setfs(t->tid_oldfs);
>> + critical_exit();
>>sched_unpin();
>> - x86_critical_exit();
>>
>>/* Welcome back to UNIX land, we missed you. */
>>
>> diff --git a/sys/compat/ndis/winx32_wrap.S b/sys/compat/ndis/winx32_wrap.S
>> index c051504..fa4aa87 100644
>> --- a/sys/compat/ndis/winx32_wrap.S
>> +++ b/sys/compat/ndis/winx32_wrap.S
>> @@ -375,11 +375,3 @@ ENTRY(x86_setfs)
>> ENTRY(x86_gettid)
>>mov %fs:12,%eax
>>ret
>> -
>> -ENTRY(x86_critical_enter)
>> - cli
>> - ret
>> -
>> -ENTRY(x86_critical_exit)
>> - sti
>> - ret
>> ___
>> 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"
>>
>
>
>
> --
> Bernhard
>
___
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: ndis: patch for review
9, 2010 at 23:53, Paul B Mahol wrote:
> Hi,
>
> First: we should pin curthread on CPU before we check on which CPU is
> curthread.
>
> Second: instead of sti & cli use critical sections when saving %fs register.
>
> Third: I do not know what happens if we get preempted while windows
> code were running,
> so leave critical section only _after_ executing windows code.
Do you have a test case for that? If so, can you post it?
> diff --git a/sys/compat/ndis/kern_windrv.c b/sys/compat/ndis/kern_windrv.c
> index f231863..ba29fd2 100644
> --- a/sys/compat/ndis/kern_windrv.c
> +++ b/sys/compat/ndis/kern_windrv.c
> @@ -613,8 +613,6 @@ struct gdt {
> extern uint16_t x86_getfs(void);
> extern void x86_setfs(uint16_t);
> extern void *x86_gettid(void);
> -extern void x86_critical_enter(void);
> -extern void x86_critical_exit(void);
> extern void x86_getldt(struct gdt *, uint16_t *);
> extern void x86_setldt(struct gdt *, uint16_t);
>
> @@ -668,8 +666,10 @@ extern void x86_setldt(struct gdt *, uint16_t);
> void
> ctxsw_utow(void)
> {
> - struct tid *t;
> + struct tid *t;
>
> + sched_pin();
> + critical_enter();
> t = &my_tids[curthread->td_oncpu];
>
> /*
> @@ -685,12 +685,9 @@ ctxsw_utow(void)
> if (t->tid_self != t)
> x86_newldt(NULL);
>
> - x86_critical_enter();
> t->tid_oldfs = x86_getfs();
> t->tid_cpu = curthread->td_oncpu;
> - sched_pin();
> x86_setfs(SEL_TO_FS(t->tid_selector));
> - x86_critical_exit();
>
> /* Now entering Windows land, population: you. */
> }
> @@ -706,11 +703,10 @@ ctxsw_wtou(void)
> {
> struct tid *t;
>
> - x86_critical_enter();
> t = x86_gettid();
> x86_setfs(t->tid_oldfs);
> + critical_exit();
> sched_unpin();
> - x86_critical_exit();
>
> /* Welcome back to UNIX land, we missed you. */
>
> diff --git a/sys/compat/ndis/winx32_wrap.S b/sys/compat/ndis/winx32_wrap.S
> index c051504..fa4aa87 100644
> --- a/sys/compat/ndis/winx32_wrap.S
> +++ b/sys/compat/ndis/winx32_wrap.S
> @@ -375,11 +375,3 @@ ENTRY(x86_setfs)
> ENTRY(x86_gettid)
> mov %fs:12,%eax
> ret
> -
> -ENTRY(x86_critical_enter)
> - cli
> - ret
> -
> -ENTRY(x86_critical_exit)
> - sti
> - ret
> ___
> 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"
>
--
Bernhard
___
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: Monitor mode not working for iwi(4) on 7.X
2010/10/20 Alexey Dokuchaev : > On Tue, Oct 19, 2010 Bernhard Schmidt wrote: >> Alexey Dokuchaev wrote: >> > Not sure if this is a driver or ifconfig(8) problem, but after I -mediaopt >> > monitor, ifconfig(8) still reports it in media line: >> > >> > media: IEEE 802.11 Wireless Ethernet autoselect >> > >> > However, as I said, scan list gets populated, which suggests ifconfig(8) >> > is getting something wrong. Doing -mediaopt monitor the second time >> > "knocks" ifconfig(8) though. >> >> I can't reproduce that on my stable/7 setup, neither in 'UP' nor in 'DOWN' >> state. Can you post the exact command sequence you've used? The output >> differs though.. >> >> # ifconfig iwi0 mediaopt monitor >> # ifconfig iwi0 up >> # ifconfig iwi0 | grep media >> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) >> # ifconfig iwi0 -mediaopt monitor >> # ifconfig iwi0 | grep media >> media: IEEE 802.11 Wireless Ethernet autoselect > > This scenario works. But try it out after aircrack-ng tools, which set > (P)PROMISC mode on the card (and do not clear it after exit, but in my > understanding this should not affect monitor mode and its indication, no?). Correct. # kldload if_iwi # aireplay-ng -9 iwi0 # ifconfig iwi0 iwi0: flags=28943 metric 0 mtu 1500 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) # ifconfig iwi0 -mediaopt monitor # ifconfig iwi0 iwi0: flags=28943 metric 0 mtu 1500 media: IEEE 802.11 Wireless Ethernet autoselect # hmm.. looks correct to me, am I doing something wrong? -- Bernhard ___ 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: Problems with 8.1, PPPoE server, and Cisco client
have you tried pap instead of chap on Cisco dialer? On 10/20/10, Ian Smith wrote: > On Wed, 20 Oct 2010, Paul Thornton wrote: > > [..] > > > With a Windows XP client (I know, it was nearby though) the following > > things happen: > > > > Server -> Client PPP CHAP Success (Welcome!! message). > > Server -> Client PPP CCP config request > > Server -> Client IPCP Config request (setting IP address of server end) > > Client -> Server PPP CCP config request > > - and they carry on here working fine - > > > > With the Cisco client, things break at this point: > > Server -> Client PPP CHAP Success (Welcome!! message). > > Server -> Client PPP CCP Config request > > Server -> Client IPCP Config Request (setting IP address of server end) > > Client -> Server Termination request > > Server -> Client Termination ack > > > > So either that CCP request or the IPCP request is upsetting the Cisco. > > My money's on IPCP or maybe LCP so far .. > > > However, even with its debugging fully on for PPP, it isn't clear why. > > Initially, my server was requesting deflate compression and VJ > > compression - so I disabled all compression options in ppp.conf but it > > made no difference. The tcpdumps were taken after compression was > disabled. > > Good idea, keeps the logging reasonable meanwhile .. > > > The cisco config being used on the WAN interface and Dialer interface > > for testing is as follows. This is an 891 and so is an Ethernet WAN > > port (no VDSL or other cable interface to add problems): > > > > interface GigabitEthernet0 > > no ip address > > ip accounting output-packets > > duplex auto > > speed auto > > pppoe enable group global > > pppoe-client dial-pool-number 1 > > ! > > interface Dialer0 > > description PPPoE dialer > > mtu 1492 > > ip address negotiated > > no ip redirects > > no ip proxy-arp > > ip accounting output-packets > > encapsulation ppp > > ip tcp adjust-mss 1452 > > dialer pool 1 > > dialer-group 1 > > ppp mtu adaptive > > ppp authentication chap callin optional > > ppp chap hostname vt123456...@vdsl01 > > ppp chap password 0 LetMeIn123 > > ! > > ! > > ip route 0.0.0.0 0.0.0.0 Dialer0 > > ! > > dialer-list 1 protocol ip permit > > ! > > Left to those who speak cisco .. > > > Here is part of the tcpdump with the XP client, starting at the CHAP > > success message. I've included quite a lot as there seems to be > > something going on with IPCP and setting DNS addresses - is this normal? > > Looks pretty normal. Omitting 'unknown ctrl-proto (0x80fd)' MPPC stuff: > > > (address ending 5e:ed is the server): > > > > > 14:40:27.733755 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 35: PPPoE [ses 0x20] CHAP (0xc223), length 15: CHAP, > Success (0x03), id 1, Msg Welcome!! > > > 14:40:27.733764 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 26: PPPoE [ses 0x20] unknown (0x80fd), length 6: unknown > ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 > > > 14:40:27.733770 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 32: PPPoE [ses 0x20] IPCP (0x8021), length 12: IPCP, > Conf-Request (0x01), id 1, length 12 > > > encoded length 10 (=Option(s) length 6) > > > 0x: 8021 0101 000a > > >IP-Addr Option (0x03), length 6: 217.65.168.254 > > > 0x: d941 a8fe > > we want this address. > > > > 14:40:27.741992 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE > S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 36: IPCP, > Conf-Request (0x01), id 7, length 36 > > > encoded length 34 (=Option(s) length 30) > > > 0x: 8021 0107 0022 > > >IP-Addr Option (0x03), length 6: 0.0.0.0 > > > 0x: > > >Pri-DNS Option (0x81), length 6: 0.0.0.0 > > > 0x: > > >Pri-NBNS Option (0x82), length 6: 0.0.0.0 > > > 0x: > > >Sec-DNS Option (0x83), length 6: 0.0.0.0 > > > 0x: > > >Sec-NBNS Option (0x84), length 6: 0.0.0.0 > > > 0x: > > it's open to persuasion for all these. > > > > 14:40:27.742107 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 38: PPPoE [ses 0x20] IPCP (0x8021), length 18: IPCP, > Conf-Reject (0x04), id 7, length 18 > > > encoded length 16 (=Option(s) length 12) > > > 0x: 8021 0407 0010 > > >Pri-NBNS Option (0x82), length 6: 0.0.0.0 > > > 0x: > > >Sec-NBNS Option (0x84), length 6: 0.0.0.0 > > > 0x: > > we don't do NBNS. > > > > 14:40:27.742559 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE > S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 12: IPCP, > Conf-Ack (0x02), id 1, length 12 > > > encoded length 10 (=Option(s) length 6) > > > 0x: 8021 0201 000a > > >IP-Addr Option (0x03), length 6: 217.65.168.254 > > > 0x: d
Re: Problems with 8.1, PPPoE server, and Cisco client
On Wed, 20 Oct 2010, Paul Thornton wrote: [..] > With a Windows XP client (I know, it was nearby though) the following > things happen: > > Server -> Client PPP CHAP Success (Welcome!! message). > Server -> Client PPP CCP config request > Server -> Client IPCP Config request (setting IP address of server end) > Client -> Server PPP CCP config request > - and they carry on here working fine - > > With the Cisco client, things break at this point: > Server -> Client PPP CHAP Success (Welcome!! message). > Server -> Client PPP CCP Config request > Server -> Client IPCP Config Request (setting IP address of server end) > Client -> Server Termination request > Server -> Client Termination ack > > So either that CCP request or the IPCP request is upsetting the Cisco. My money's on IPCP or maybe LCP so far .. > However, even with its debugging fully on for PPP, it isn't clear why. > Initially, my server was requesting deflate compression and VJ > compression - so I disabled all compression options in ppp.conf but it > made no difference. The tcpdumps were taken after compression was disabled. Good idea, keeps the logging reasonable meanwhile .. > The cisco config being used on the WAN interface and Dialer interface > for testing is as follows. This is an 891 and so is an Ethernet WAN > port (no VDSL or other cable interface to add problems): > > interface GigabitEthernet0 > no ip address > ip accounting output-packets > duplex auto > speed auto > pppoe enable group global > pppoe-client dial-pool-number 1 > ! > interface Dialer0 > description PPPoE dialer > mtu 1492 > ip address negotiated > no ip redirects > no ip proxy-arp > ip accounting output-packets > encapsulation ppp > ip tcp adjust-mss 1452 > dialer pool 1 > dialer-group 1 > ppp mtu adaptive > ppp authentication chap callin optional > ppp chap hostname vt123456...@vdsl01 > ppp chap password 0 LetMeIn123 > ! > ! > ip route 0.0.0.0 0.0.0.0 Dialer0 > ! > dialer-list 1 protocol ip permit > ! Left to those who speak cisco .. > Here is part of the tcpdump with the XP client, starting at the CHAP > success message. I've included quite a lot as there seems to be > something going on with IPCP and setting DNS addresses - is this normal? Looks pretty normal. Omitting 'unknown ctrl-proto (0x80fd)' MPPC stuff: > (address ending 5e:ed is the server): > > > 14:40:27.733755 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S > > (0x8864), length 35: PPPoE [ses 0x20] CHAP (0xc223), length 15: CHAP, > > Success (0x03), id 1, Msg Welcome!! > > 14:40:27.733764 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S > > (0x8864), length 26: PPPoE [ses 0x20] unknown (0x80fd), length 6: unknown > > ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 > > 14:40:27.733770 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S > > (0x8864), length 32: PPPoE [ses 0x20] IPCP (0x8021), length 12: IPCP, > > Conf-Request (0x01), id 1, length 12 > >encoded length 10 (=Option(s) length 6) > >0x: 8021 0101 000a > > IP-Addr Option (0x03), length 6: 217.65.168.254 > >0x: d941 a8fe we want this address. > > 14:40:27.741992 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S > > (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 36: IPCP, > > Conf-Request (0x01), id 7, length 36 > >encoded length 34 (=Option(s) length 30) > >0x: 8021 0107 0022 > > IP-Addr Option (0x03), length 6: 0.0.0.0 > >0x: > > Pri-DNS Option (0x81), length 6: 0.0.0.0 > >0x: > > Pri-NBNS Option (0x82), length 6: 0.0.0.0 > >0x: > > Sec-DNS Option (0x83), length 6: 0.0.0.0 > >0x: > > Sec-NBNS Option (0x84), length 6: 0.0.0.0 > >0x: it's open to persuasion for all these. > > 14:40:27.742107 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S > > (0x8864), length 38: PPPoE [ses 0x20] IPCP (0x8021), length 18: IPCP, > > Conf-Reject (0x04), id 7, length 18 > >encoded length 16 (=Option(s) length 12) > >0x: 8021 0407 0010 > > Pri-NBNS Option (0x82), length 6: 0.0.0.0 > >0x: > > Sec-NBNS Option (0x84), length 6: 0.0.0.0 > >0x: we don't do NBNS. > > 14:40:27.742559 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S > > (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 12: IPCP, > > Conf-Ack (0x02), id 1, length 12 > >encoded length 10 (=Option(s) length 6) > >0x: 8021 0201 000a > > IP-Addr Option (0x03), length 6: 217.65.168.254 > >0x: d941 a8fe it's happy with our IP addr. > > 14:40:27.756230 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S > > (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP,
Re: Problems with 8.1, PPPoE server, and Cisco client
On 10/20/10 7:23 AM, Paul Thornton wrote: Hi, On 19/10/2010 22:06, Julian Elischer wrote: Wireshark understands all the protocols in question so get packet captures of good and bad sessions (as similar as you can) and see what is different. (wireshark reads tcpdump files so it's easy to capture). As is often the case, the packets on the wire start telling the story of what is happening... still not sure about the why, but progress is being made. Thanks for that nudge. With a Windows XP client (I know, it was nearby though) the following things happen: Server -> Client PPP CHAP Success (Welcome!! message). Server -> Client PPP CCP config request Server -> Client IPCP Config request (setting IP address of server end) Client -> Server PPP CCP config request - and they carry on here working fine - With the Cisco client, things break at this point: Server -> Client PPP CHAP Success (Welcome!! message). Server -> Client PPP CCP Config request Server -> Client IPCP Config Request (setting IP address of server end) Client -> Server Termination request Server -> Client Termination ack So either that CCP request or the IPCP request is upsetting the Cisco. However, even with its debugging fully on for PPP, it isn't clear why. Initially, my server was requesting deflate compression and VJ compression - so I disabled all compression options in ppp.conf but it made no difference. The tcpdumps were taken after compression was disabled. The cisco config being used on the WAN interface and Dialer interface for testing is as follows. This is an 891 and so is an Ethernet WAN port (no VDSL or other cable interface to add problems): interface GigabitEthernet0 no ip address ip accounting output-packets duplex auto speed auto pppoe enable group global pppoe-client dial-pool-number 1 ! interface Dialer0 description PPPoE dialer mtu 1492 ip address negotiated no ip redirects no ip proxy-arp ip accounting output-packets encapsulation ppp ip tcp adjust-mss 1452 dialer pool 1 dialer-group 1 ppp mtu adaptive ppp authentication chap callin optional ppp chap hostname vt123456...@vdsl01 ppp chap password 0 LetMeIn123 ! ! ip route 0.0.0.0 0.0.0.0 Dialer0 ! dialer-list 1 protocol ip permit ! Here is part of the tcpdump with the XP client, starting at the CHAP success message. I've included quite a lot as there seems to be something going on with IPCP and setting DNS addresses - is this normal? (address ending 5e:ed is the server): [...] And here is the similar section from the Cisco router, it all goes downhill quickly (address ending 5e:ed is the server): have you tried to connect this cisco router to anything else pppoe? (take it home and make it connect to your ISP for example?) The command from the server to set an address seems ok so I wonder if there is some setting on the cisco that doesn't like it. Unfortunately, despite having worked for cisco, my IOS foo is pretty weak. 14:59:44.053482 d8:d3:85:c1:5e:ed> 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 35: PPPoE [ses 0x21] CHAP (0xc223), length 15: CHAP, Success (0x03), id 1, Msg Welcome!! 14:59:44.053491 d8:d3:85:c1:5e:ed> 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 26: PPPoE [ses 0x21] unknown (0x80fd), length 6: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 14:59:44.053498 d8:d3:85:c1:5e:ed> 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 32: PPPoE [ses 0x21] IPCP (0x8021), length 12: IPCP, Conf-Request (0x01), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 217.65.168.254 0x: d941 a8fe 14:59:44.059344 54:75:d0:38:ca:7a> d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x21] LCP (0xc021), length 6: LCP, Term-Request (0x05), id 2, length 6 14:59:44.059739 d8:d3:85:c1:5e:ed> 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 26: PPPoE [ses 0x21] LCP (0xc021), length 6: LCP, Term-Ack (0x06), id 2, length 6 14:59:44.060925 54:75:d0:38:ca:7a> d8:d3:85:c1:5e:ed, ethertype PPPoE D (0x8863), length 60: PPPoE PADT [ses 0x21] 14:59:44.060939 d8:d3:85:c1:5e:ed> 54:75:d0:38:ca:7a, ethertype PPPoE D (0x8863), length 38: PPPoE PADT [ses 0x21] [Generic-Error "session closed"] ___ 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: Problems with 8.1, PPPoE server, and Cisco client
Hi, On 19/10/2010 22:06, Julian Elischer wrote: > Wireshark understands all the protocols in question so get packet > captures of good and > bad sessions (as similar as you can) and see what is different. > (wireshark reads > tcpdump files so it's easy to capture). As is often the case, the packets on the wire start telling the story of what is happening... still not sure about the why, but progress is being made. Thanks for that nudge. With a Windows XP client (I know, it was nearby though) the following things happen: Server -> Client PPP CHAP Success (Welcome!! message). Server -> Client PPP CCP config request Server -> Client IPCP Config request (setting IP address of server end) Client -> Server PPP CCP config request - and they carry on here working fine - With the Cisco client, things break at this point: Server -> Client PPP CHAP Success (Welcome!! message). Server -> Client PPP CCP Config request Server -> Client IPCP Config Request (setting IP address of server end) Client -> Server Termination request Server -> Client Termination ack So either that CCP request or the IPCP request is upsetting the Cisco. However, even with its debugging fully on for PPP, it isn't clear why. Initially, my server was requesting deflate compression and VJ compression - so I disabled all compression options in ppp.conf but it made no difference. The tcpdumps were taken after compression was disabled. The cisco config being used on the WAN interface and Dialer interface for testing is as follows. This is an 891 and so is an Ethernet WAN port (no VDSL or other cable interface to add problems): interface GigabitEthernet0 no ip address ip accounting output-packets duplex auto speed auto pppoe enable group global pppoe-client dial-pool-number 1 ! interface Dialer0 description PPPoE dialer mtu 1492 ip address negotiated no ip redirects no ip proxy-arp ip accounting output-packets encapsulation ppp ip tcp adjust-mss 1452 dialer pool 1 dialer-group 1 ppp mtu adaptive ppp authentication chap callin optional ppp chap hostname vt123456...@vdsl01 ppp chap password 0 LetMeIn123 ! ! ip route 0.0.0.0 0.0.0.0 Dialer0 ! dialer-list 1 protocol ip permit ! In terms of the routing, the route being added as a result of the Framed-Route radius attribute does have the correct syntax. For some reason, it had failed to add the /29 route to the routing table in my logs taken yesterday - although that now works fine. That may still be a potential issue but I don't think it is relevant now. To describe what addresses are what (and two of these have changed since yesterday as I was using some that were already occasionally used elsewhere on the network): WAN IP address of router: 217.65.167.128 /32 - set by RADIUS Framed-IP-Address value. LAN subnet of router: 217.65.167.160 /29 - set by RADIUS Framed-Route value. Router's LAN interface has 217.65.167.161/29. IP address of PPPoE server's end of PPP link: 217.65.168.254 VLAN 1005 is just the access side; it has the clients attached to it and has no IP address. Everything happening on there is PPPoE only. The server has another interface which is network side that carries traffic to and from the rest of the world. > also for fun you might look at the documentation for running mpd.. I > dont' remember if it > can do a pppoe SERVER but I vaguely remember that it can. I did once try mpd in the past - I remember it being hard to find any decent documentation for it; especially around PPPoE as a server. It looks very flexible as an option so I may have another crack at it if I can't make the standard ppp work. Does anyone know of any good howto for mpd and pppoe servers? My google skills have lacked severely so far. Here is part of the tcpdump with the XP client, starting at the CHAP success message. I've included quite a lot as there seems to be something going on with IPCP and setting DNS addresses - is this normal? (address ending 5e:ed is the server): > 14:40:27.733755 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S > (0x8864), length 35: PPPoE [ses 0x20] CHAP (0xc223), length 15: CHAP, > Success (0x03), id 1, Msg Welcome!! > 14:40:27.733764 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S > (0x8864), length 26: PPPoE [ses 0x20] unknown (0x80fd), length 6: unknown > ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 > 14:40:27.733770 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S > (0x8864), length 32: PPPoE [ses 0x20] IPCP (0x8021), length 12: IPCP, > Conf-Request (0x01), id 1, length 12 > encoded length 10 (=Option(s) length 6) > 0x: 8021 0101 000a > IP-Addr Option (0x03), length 6: 217.65.168.254 > 0x: d941 a8fe > 14:40:27.741765 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S > (0x8864), length 60: PPPoE [ses 0x20] unknown (0x80fd), length 12: unknown > ctrl-proto (0x80fd), Conf-Request (0x01), id 6, length 12 > encoded length 10 (=Opt
carp and arp_rtrequest: bad gateway 1.1.1.5 (!AF_LINK)
I got 2 servers with CARP enabled. One is MASTER, second - BACKUP. CARP is for HA of running some service on that servers. All works fine, but today I've got interesting case: Service was not responding for 5 minutes. Can't tell more details because it was said by not IT guy. Okay, I went to check logs on master and backup servers. All was fine except dmesg and messages: Master server has no recored in messages for about 1 hour. But on slave server I saw that: Oct 20 12:15:00 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.5 (!AF_LINK) Oct 20 12:15:00 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.6 (!AF_LINK) Oct 20 12:15:00 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.9 (!AF_LINK) .. Oct 20 12:49:58 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.5 (!AF_LINK) Oct 20 12:49:58 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.6 (!AF_LINK) Oct 20 12:49:58 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.9 (!AF_LINK) Total about 300 records. Can anyone comment something about it? What was that? Backup server was loosing connectivity with Master server? In sysctl.conf I've got only net.inet.carp.preempt=1.Now I tuned log to net.inet.carp.log=2. This should log carp info messages. Am I right about loosing connectivity between master-backup servers or there can be another reason? ___ 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: Monitor mode not working for iwi(4) on 7.X
On Tue, Oct 19, 2010 Bernhard Schmidt wrote: > Alexey Dokuchaev wrote: > > Not sure if this is a driver or ifconfig(8) problem, but after I -mediaopt > > monitor, ifconfig(8) still reports it in media line: > > > > media: IEEE 802.11 Wireless Ethernet autoselect > > > > However, as I said, scan list gets populated, which suggests ifconfig(8) > > is getting something wrong. Doing -mediaopt monitor the second time > > "knocks" ifconfig(8) though. > > I can't reproduce that on my stable/7 setup, neither in 'UP' nor in 'DOWN' > state. Can you post the exact command sequence you've used? The output > differs though.. > > # ifconfig iwi0 mediaopt monitor > # ifconfig iwi0 up > # ifconfig iwi0 | grep media > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) > # ifconfig iwi0 -mediaopt monitor > # ifconfig iwi0 | grep media > media: IEEE 802.11 Wireless Ethernet autoselect This scenario works. But try it out after aircrack-ng tools, which set (P)PROMISC mode on the card (and do not clear it after exit, but in my understanding this should not affect monitor mode and its indication, no?). ./danfe ___ 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"
